Kudos 机器人与 502 报错：AO3 经历过的“技术轶事”

这篇只讲几件 AO3 比较有意思的技术轶事。

1. Kudos Bot：突然暴涨的“游客点赞”

Kudos 是 AO3 上最轻量的反馈方式，就是“我喜欢这篇”。正常情况下，一个登录用户只能给同一篇作品点一次 kudos，游客也会受到限制。

但从 2021 年 10 月左右开始，很多作者发现自己的作品突然收到大量游客 kudos。有些作品很久没有更新，也不在热门 fandom 首页，却在短时间里多出几十、上百甚至更多 guest kudos；还有人注意到 kudos 增长和 hits 增长对不上。于是大家开始把它叫作 Kudos Bot¹。

这件事诡异的地方在于：它不像普通读者，也不像正常宣传带来的流量。Fanlore 对这段事件的整理提到，当时没有确定原因，猜测包括误触发的爬虫、恶作剧或其他 bot 行为。一个比较有效的临时办法，是把作品锁成只允许登录用户访问，因为游客无法进入后，也就不能留下 guest kudos¹。

2. 502：AO3 很早就被流量挤过

AO3 的 502 报错不是新鲜事。早在 2011 年，OTW 就专门解释过 AO3 为什么经常出现“sad 502 page”：访问量增长太快，服务器承受不住。那篇文章提到，2011 年 9 月 25 日，AO3 有 105,000 次访问、46,000 个独立访客和 575,000 次页面浏览，而这已经成了一个“相当普通”的日子²。

2012 年，官方又发过一次性能说明。那时 AO3 平均每天已经有超过 150 万 pageviews，访问还会集中在欧美用户下班、放学后的晚间高峰。官方解释得很直接：请求太多，系统处理不过来，用户就会看到 502³。

还有一个很有 AO3 味道的例子：2012 年年初，官方用 “Rush hour on the AO3!” 解释新年期间的访问高峰。2012 年 1 月 2 日，AO3 有 182,958 次访问和 1,066,216 次 pageviews；同一篇公告还提到 Yuletide 等挑战活动带来了大量新作品⁴。

所以，502 并不总是“网站坏了”。很多时候它只是很朴素的容量问题：大家同时来读文、发文、刷新更新，服务器就处理不过来。

3. Elasticsearch：AO3 的搜索和标签并不轻松

AO3 的 502 也不只和“访问量太大”有关。2017 年，官方解释过另一个很具体的问题：用户发布或编辑作品时，AO3 需要更新作品上每个 tag 的使用次数。热门 tag 会被很多作品同时使用，这些记录在更新时会被锁住，数据库一忙起来，发文、改文甚至整个网站都可能变慢，严重时就会出现 502⁵。

这件事很能说明 AO3 的标签系统为什么难维护。对读者来说，tag 只是页面上的几个词；对系统来说，它们是搜索、过滤、统计、自动补全和 tag wrangling 背后持续变化的数据。

2018 年，AO3 做过一次大型搜索功能升级，把 Elasticsearch 从 0.90 升级到 6.2。这个更新带来了我们现在很熟悉的一些功能：排除标签、筛选 crossover、按完结状态、更新时间和字数范围过滤等⁶⁷。官方当时还提到，旧的 bookmark 代码在处理大 tag 的 wrangling 变化时会给服务器带来压力，而 Elasticsearch 6 能更好地处理超过 7400 万条 bookmarks⁷。

所以，AO3 的“搜索”不是一个简单的搜索框。它背后连着几百万作品、几千万书签、无数用户自定义 tag，以及志愿者长期整理出来的 canonical tag 关系。你点一下过滤条件，系统其实在替你穿过一整套很复杂的同人分类网络。

4. 2023 年 DDoS：从“自己扛”到接入 Cloudflare

2023 年 7 月，AO3 遭遇了一次大规模 DDoS 攻击。官方公告说，从 2023 年 7 月 10 日约 12:00 UTC 到 7 月 11 日 16:00 UTC，AO3 大部分时间不可用。官方同时说明，没有档案数据泄露，用户不需要担心密码或私人信息被攻破⁸。

这次事件后来有一篇很值得读的 Systems 委员会复盘。按那篇文章的时间线，7 月 10 日 11:48 UTC 左右，AO3 开始看到异常流量；正常高峰大约是每分钟 150,000 个请求，但攻击期间 spikes 超过每分钟 1,000,000 个请求，最高到 1,500,000 个请求。7 月 11 日 00:21 UTC，数据中心通知 AO3，攻击流量超过了 1.2 Tbps，约是当时带宽容量的 600 倍⁹。

一开始，Systems 志愿者尝试自己挡：维护模式、前端层处理、在防火墙上封被滥用的页面、临时限速。但攻击不断换目标，最后已经超过了他们自己的网络和服务器能处理的范围。7 月 11 日，团队开始接入 Cloudflare，并通过 Project Galileo 获得更高级的防护；当天 15:42 UTC 左右，AO3 再次完全可访问⁹。

Cloudflare 后来的案例研究也提到，这次攻击让 AO3 总计离线 28 小时，并提到 OTW 的全部项目都是在线项目，一旦下线，就无法完成它们的使命¹⁰。

5. Cloudflare 解决了攻击，也带来了新问题

接入 Cloudflare 后，AO3 不再是完全裸着承受流量。问题是，防护也会改变用户体验。

AO3 官方公告说，他们临时开启了 Cloudflare 的 Under Attack mode。用户访问 AO3 页面时，可能会看到 Captcha 验证；官方也承认，一些浏览器和旧设备当时无法正常访问 AO3。这些措施是临时的，会在攻击停止后重新评估⁸。

Systems 委员会的复盘也提到，后续 8 月仍有攻击。大多数被 Cloudflare 拦下，没有明显影响；但 8 月 30 日和 31 日仍出现过短暂问题。有一次自动规则带来了一点 collateral damage，用户会看到 Cloudflare 默认的 “Sorry, you have been blocked” 页面，后来 AO3 才换成更温和的自定义提示页⁹。

这就是安全防护很现实的一面：它能挡攻击，但也可能误伤正常用户，尤其是设备旧、网络复杂等。

对中文用户来说，这种变化还会经过镜像站再放大一层。很多人会通过镜像访问 AO3，nightalk 就是其中比较常被提到的名字。镜像不是 AO3 官方服务，通常依赖主站内容和自己的代理链路。如果 AO3 主站进入 Cloudflare 验证、临时调整安全规则，用户就可能打不开。

6. 用户怎么共渡难关：把宕机也变成梗

AO3 不可用时，用户通常不会安静等着。

2023 年 DDoS 期间，AO3 官方公告最后专门提到，他们看到了用户发来的支持消息和 cute gifs⁸。TechCrunch 还写过一个有趣的现象：AO3 恢复后，仍有人留在 Downdetector 评论区聊天，甚至把 AO3 和 Downdetector 写成拟人关系，形成了一个临时的 “Downdetector fandom”¹¹。如果你想看 AO3 最近是否有人集中报告故障，也可以直接看 Downdetector 上的 AO3 状态页。

网站崩了，当然很烦；但用户的第一反应不是只骂服务器，而是去状态账号下面发图、在评论区写段子、互相通报“现在能不能打开”。技术问题变成社区事件，社区事件又很快长出梗图和玩笑。

结尾：这些故障也是 AO3 的运行记录

这些事放在一起看，AO3 的技术史可能并不完美。它有被游客 kudos 机器人刷到作者怀疑人生的时候，有早年因为流量太大反复 502 的时候，有为了搜索和标签系统不断升级底层工具的时候，也有被 DDoS 打到不得不紧急接入 Cloudflare 的时候。

但这也说明它不是一个静止的档案馆。它会被用户增长推着扩容，会被搜索和标签压力推着升级基础设施，会被攻击推着改安全策略，会被机器人逼着重新思考游客互动。

所以，AO3 的“技术轶事”并不只是 bug 和故障。它也是一个大型同人社区在现实互联网里运转时，留下来的运行记录。