📍 WDQWDWQD987AAAAA:216.73.216.251
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /937f339a4318.html
📄

站长死链查询：一次小流量灰度如何暴露全量发布的例外

小流量灰度只放大了被抽中的那部分请求，而全量发布后，边缘缓存、移动端渲染、历史外链和低频入口会把另外一批死链带进日志。所以灰度通过不等于全量安全，真正要查的是灰度样本没覆盖到的例外，而不是把灰度结果再跑一遍。下面用一个假设情境说明怎么把例外找出来。

假设情境：灰度放量后死链反而增加

假设某站点改版，把一批旧栏目链接统一跳转到新路径。先在 5% 流量灰度：站长死链查询工具和服务器日志里 404 都很少，团队判断可以全量。全量后第二天，日志中的 404 数量不降反升，来源集中在移动端和几个老入口。这个反常结果不是灰度本身错了，而是灰度样本的构成与全量不同。

要区分解释，先做一件具体动作：把灰度期和全量后的 404 日志按 User-Agent、Referer、请求路径前缀分组，对比同一路径在两段时间的出现次数。如果某路径在灰度期几乎为零、全量后突然出现，它大概率是灰度未覆盖的入口，而不是新产生的错误。

灰度覆盖不到的几类例外

• 缓存层差异：灰度可能只命中部分节点，全量后其他节点的旧缓存仍指向已下线路径。
• 客户端差异：灰度样本以桌面为主，全量后移动端或旧版客户端的跳转规则未生效。
• 入口差异：低频外链、站内搜索历史词、邮件模板里的链接在灰度期几乎不被触发。
• 渲染差异：需要脚本执行的链接在爬虫视角和用户视角下表现不同，灰度只测了其中一种。

这些例外的共同点是：它们在灰度流量中的出现概率低，但不代表不存在。判断时不要只看 404 总量，要看同一路径在灰度与全量之间的出现次数变化。总量上升可能来自爬虫重新抓取，也可能来自真实用户，这两者的下一步处理完全不同。

用可核对证据区分不同解释

面对死链增加，至少有两种成立条件不同的解释：一是改版规则本身漏了某些入口，二是抓取行为变化让原本存在的死链被更多记录。区分方法是核对请求来源和响应链。

1. 取全量后新增的 404 路径，逐条回放请求，记录状态码、跳转链和最终响应。
2. 对照灰度期的同一路径记录，确认它在灰度期是否被请求过。
3. 检查 robots.txt 是否在灰度后改动过。抓取限制变化会改变爬虫行为，但抓取限制不等于可靠的索引移除，不能据此判断链接已被处理。
4. 检查站点地图是否仍包含已下线路径。站点地图不保证收录，但包含死链会持续引导抓取。

如果回放显示跳转链在某一跳返回 404，问题在规则；如果回放正常而日志仍有 404，问题可能在缓存或客户端。这一步的结果直接决定下一步是改跳转规则还是清缓存。

一次动作与它的结果如何影响下一步

假设核对后发现，新增 404 中有相当比例来自一个未纳入灰度的旧入口。此时合理的动作不是立刻全站回退，而是先给这个入口补上跳转规则，再单独对这个入口做一次小范围验证。验证通过后，再决定是否扩大修复范围。

反过来，如果新增 404 集中在爬虫请求且路径早已失效，处理重点就不是跳转，而是清理站点地图和内部引用，并观察后续抓取是否减少。两种结果的下一步完全不同，所以不能用一个“死链变多”的结论覆盖所有情况。

全量发布前值得补的一步

灰度样本要尽量覆盖不同客户端、不同入口和不同缓存节点，而不是只按流量比例随机抽取。全量发布前，可以用站长死链查询的结果与灰度期日志做一次路径级对比，重点看灰度期请求次数为零但站点地图或外链中存在的路径。HTTPS 不保证安全无漏洞或排名，它也不能替代对跳转链和入口覆盖的核查。把例外先找出来，全量发布后的死链才更可能落在预期范围内。