GoForum🌐 V2EX

20260526 - 关于已经修复的 404 bug 的具体原因

Livid · 2026-05-26 22:58 · 0 次点赞 · 13 条回复

假设有恶意程序写一个简单的循环,持续访问不存在的 topic id ,那么每次 V2EX 接收到这样的请求,还需要从数据库里查了之后,才知道是无效的 topic id ,这个查询过程就会很浪费资源。

所以程序中有这样的一种机制,如果 topic id 明显大于某个值,那么就不用查任何数据库资源,直接返回 404 。

这个值应该是被定期更新并且加上一个足够大的安全值。

但是由于最近测试服里的一个 bug ,导致这个值自从测试服上线之后,就一直没有被正确更新。因此当 topic id 持续增长,终于来到旧值 + 安全值的边界时,所有新的 topic id 就都 404 跳转了。

这个问题的根源是测试服上更新全站统计数据进 Memcached Key 时的 bug ,这个 bug 现在已经修复(测试服在这个地方现在使用了单独的 Memcached Key )。

13 条回复
aheadlead · 2026-05-26 23:03
#1

没想到竟然是一个这样简单的问题..

InDom · 2026-05-26 23:03
#2

啊?

povsister · 2026-05-26 23:08
#3

我这类似用途是靠 id 算法,全局时间+safe margin 搞的。通过当前时间+id 编码规则就能很容易初步判定 id 是不是伪造的。后面被枚举刷太狠了就又在回源套了层布隆,也是时间校验,安全值范围内允许回源否则一律拦截。

最开始考虑过全局通过有状态存储维护这个上限,但组件太多依赖一个单点就很麻烦。

Pipecraft · 2026-05-26 23:08
#4

那现在已经公开秘密了,这个机制似乎不能防止恶意程序了。

ByteRan · 2026-05-26 23:13
#5

有点像千年虫的 BUG

zhouzoki · 2026-05-26 23:13
#6

现在应该有更好的方法了吧

MFWT · 2026-05-26 23:18
#7

@Pipecraft 应该也不追求完全拦住吧,至少抬高一点门槛

Livid · 2026-05-26 23:18
#8

@Pipecraft 很可能这个机制现在也是不需要的。

一些这样的逻辑都是当年应对某些恶意访问时写的。

然后年复一年这样的逻辑堆太多,本身也是一种问题。

itechify · 2026-05-26 23:28
#9

哈哈哈哈哈,这也能宕机一天。历史遗留的 feature ,堆积的临时性代码,可以考虑做下减法了🤣

tty0 · 2026-05-26 23:33
#10

可不可以将 ID 改为编码? 先校验自定义编码是否有效, 有效再去查询数据库.

JoeJoeJoe · 2026-05-26 23:38
#11

哈哈哈哈 这是有历史沉淀的站点才能出现的问题😂

Tink · 2026-05-26 23:53
#12

这个机制感觉可以考虑用别的算法替代掉

GeorgeV · 2026-05-26 23:53
#13

v 站的这个 feature 很有趣,时不时来一下也蛮好的

添加回复
你还需要 登录 后发表回复

登录后可发帖和回复

登录 注册
主题信息
作者: Livid
发布: 2026-05-26
点赞: 0
回复: 0