如何检查网站死链：访问量突增时如何区分资源压力与配置错误
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /09545427194a.html
📄
如何检查网站死链：访问量突增时如何区分资源压力与配置错误
先给一个有条件的结论：如果死链检查在访问量突增期间集中爆发，且受影响链接的响应时间随并发上升而同步恶化、并发回落后自动恢复，更可能是资源压力；如果受影响范围固定在某一类URL、某条规则或某个目录，且与并发量无关，则更可能是配置错误。这个判断成立的前提是你手头有分时段的响应码与响应时间数据，而不是只看总量。
先看错误分布，而不是错误总数
访问量突增时，死链数量上升几乎是必然的，因为请求基数变大了。真正有区分度的是错误的分布形态。
- 资源压力的特征：错误分散在多种URL类型上，404、500、503、超时混在一起，且集中在流量峰值的那几分钟到几十分钟内。
- 配置错误的特征：错误集中在特定路径前缀、特定参数形式或特定跳转规则上，峰值前后都存在，只是被流量放大后才被注意到。
实际操作：按分钟聚合日志中的状态码，分别画出总量曲线和各类错误曲线。如果错误曲线与流量曲线几乎重合，先怀疑资源；如果错误曲线在流量起来之前就已经存在一个稳定底数，先怀疑配置。
用并发回落做一次对照，而不是靠猜
区分这两类原因最直接的动作，是在可控范围内降低并发或分批放量，然后观察同一批URL的表现。
假设某目录下有200个链接在峰值时返回超时。把并发降到峰值的三分之一后重新请求同一批URL：
- 如果绝大多数恢复正常，说明瓶颈在服务端处理能力、连接数或上游依赖，属于资源压力。
- 如果仍然稳定返回同样的错误码，说明这些URL本身或它们经过的规则有问题，属于配置错误。
这个动作的价值在于它改变的是负载，而不是URL集合。变量只有一个，结论才有可比性。反过来，如果同时改了缓存策略又改了并发，就无法归因。
会让上述结论失效的反例
有一个常见反例：资源压力和配置错误同时存在，且互相掩盖。比如某条重写规则写错，导致一批URL先进入一个昂贵的处理分支，平时量小看不出来，峰值时这批URL把连接池占满，于是其他正常URL也开始超时。
这种情况下，并发回落会让“其他正常URL”恢复，看起来像纯资源问题，但那批规则命中的URL依旧报错。判断方法是把URL按是否命中该规则分成两组，分别看恢复情况。如果只有一组恢复，说明配置错误是触发点，资源紧张是后果。此时先修规则，再评估容量，顺序反了会反复复发。
另一个会让结论失效的情况是外部依赖抖动。上游接口或DNS解析在峰值期间不稳定，表现和资源压力几乎一样。区分办法是看错误是否只出现在需要该外部依赖的URL上，而不是所有URL。
检查死链时该记录哪些字段
要让上面的判断可执行，日志和检查结果至少需要保留这些字段：
- 请求时间，精确到分钟，便于和流量曲线对齐。
- 完整URL与命中的规则标识，便于按组划分。
- 响应状态码与响应耗时，两者要分开看。
- 是否命中缓存、是否经过重定向，用于排除中间层干扰。
注意，robots.txt 的抓取限制不等于可靠的索引移除，它只能约束合规爬虫的抓取行为，不能作为死链处理的替代手段。站点地图也不保证收录，提交了站点地图并不代表这些URL会被抓取或索引，因此不能用站点地图的提交结果来判断死链是否已修复。
下一步动作取决于你分到了哪一组
如果证据指向资源压力，下一步是扩容或限流，并复测同一批URL在同等并发下的表现；如果证据指向配置错误，下一步是修正规则后用相同并发复测，确认错误不再随流量放大。两组都命中时，先修配置再调容量。无论哪种情况，复测都要用同一批URL和同一套并发条件，否则新一轮数据无法和上一轮对照，判断会退回原点。
