限流恢复后还会误伤访客？429 事故复盘先查计数键

把限流阈值调高，页面恢复了，却说不出为什么会触发——这样的429事故很容易重来。复盘首先要回答：规则究竟把哪些请求算在一起？按代理连接IP、真实客户端IP、账号、接口还是其他键计数，会得到完全不同的结果。

错误率下降只能证明眼前的拒绝减少，不能单独证明规则合理。更有用的交接成果是一条完整关系：失败请求 → 产生429的层 → 规则与计数键 → 实际触发序列 → 调整后的对照样本。

应用没有报错，不代表入口没有拦截

先拿到一个具体失败请求，记录时间、URL、请求方法、请求ID和返回内容类型。再到CDN、网关、反向代理和应用中寻找同一请求。如果请求在边缘被拒，应用日志没有记录是可能的；这时只看应用CPU会错过原因。

不要为了让监控变绿，把拒绝页面的状态码改成200。对浏览器来说，它仍可能拿不到商品内容；对按JSON解析的客户端来说，返回一页HTML也不是成功。

两种值得重放的教学场景

场景一：所有用户挤进一个桶。反向代理后的服务若直接按连接IP计数，多个用户可能共用代理地址。需要确认真实客户端IP如何被恢复、信任哪些代理，而不是随意接受访客填入的 X-Forwarded-For。后者可能让请求者伪造身份，破坏限流本来的目的。

场景二：一张页面触发多种资源请求。HTML、脚本、图片和接口若被同一短窗口规则合并计算，HTML成功不代表页面完整。应查看首次加载的请求序列，判断公开可缓存资源是否与昂贵接口混用了额度。分开计数或改进缓存是否合适，要由实际成本与访问模式决定。

这两个例子用来帮助排查，并非所有429都来自配置错误。确实过载时，首先要保障服务容量，不能为了消除错误数取消所有保护。

涉及搜索爬虫时，再加一列“身份依据”

日志中的 User-Agent 写着 Googlebot，不足以证明来者身份。需要按官方方法验证来源，再决定是否对公开读取路径采取差异化策略。不要把后台、登录和写入接口一起放行。

光算的Googlebot 429 与限流计数对象排查把代理IP、资源突发和身份验证放在同一条检查路径中，可作为SEO负责人和运维共同整理样本的参考。它不提供适用于所有站点的固定限流阈值。

响应里有 Retry-After 时，也只能把它当作等待提示。客户端应避免立即无限重试，但不能承诺搜索爬虫会在某个秒数结束后立刻再来，更不能用等待头长期掩盖服务不可用。

关闭工单前，留下这些字段

• 原规则的目的、责任人、版本和作用路径。
• 计数键、时间窗口、触发动作，以及是否共享额度。
• 调整前后的同类请求样本和原故障URL返回的实际正文。
• 正常访客、必要资源与高成本接口的对照结果。
• 服务容量观察结果，以及临时规则下一次复查的条件。

如果变更只是应急提高阈值，应如实写成临时措施，并明确后续要验证什么。恢复结论可以是“原路径当前无429且内容正常”，搜索引擎抓取是否逐步恢复则另行观察。把这两项分开，团队才不会反复改规则追逐一个并不即时更新的数字。