如何检查网站死链，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c17dd3209e5d.html
📄
如何检查网站死链，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站直接返回正常而通过边缘节点访问出现 4xx/5xx 或超时，不要只保留“页面打不开”的截图。你至少应保留同一 URL 在源站直连与边缘节点两条路径上的响应头、时间戳、节点标识、请求方法与完整重定向链，并把这些记录固定到同一个可复现的请求上。这样做的目的不是证明谁对谁错，而是把“源站正常、边缘异常”的分歧变成可核对的项目。
假设情境：一条链接在两种路径下给出不同结果
假设某站点的产品页 /p/example 被内链引用。运维在源站服务器上直接请求，得到 200；SEO 通过公网域名请求，连续两次得到 404，且响应来自边缘节点。此时团队里可能出现三种说法：页面确实被删了、边缘缓存没刷新、源站某次发布把文件删了又恢复。三种说法对应的证据不同，不能靠一句“我这边是好的”结束。
把分歧转成项目，第一步是固定请求条件：同一 URL、同一方法（GET 或 HEAD 要写清楚）、同一 Host 头、是否带 Cookie、是否跟随重定向。第二步是同时采集两条路径的证据。第三步才是判断死链是否存在，以及是否需要清理内链或改配置。
源站与边缘节点各应保留什么
源站侧要保留的是原始响应，而不是经过代理后的结果。建议记录：请求时间（含时区）、请求 URL、请求方法、源站返回的状态码、响应头中的 Content-Type、Cache-Control、ETag 或 Last-Modified、响应体前若干字节或明确的空响应标记。如果源站有访问日志，同时保留该次请求在日志中的对应行，用来核对是否真的到达了应用层。
边缘节点侧要保留的是路径信息。建议记录：边缘节点标识或机房标识、边缘返回的状态码、Age、X-Cache 一类缓存命中标记（若存在）、Via 或类似代理链字段、Location（若发生重定向）、以及边缘节点回源时看到的源站状态。若边缘节点没有暴露这些字段，就把“缺少哪些字段”本身作为证据写下来，而不是用推测补全。
两条路径的记录必须能对齐到同一次或同一组请求。做法可以是在短时间内连续发起，并保留请求发出的时间戳。若两次请求间隔过长，源站可能已经发生变化，证据的可比性会下降。
如何用这些证据区分原因，而不是直接下结论
下面是一组可区分原因的证据对照，仍以上面的假设为例：
- 源站 200、边缘 404，且边缘响应带缓存命中标记：更可能是边缘缓存了旧的 404，或缓存键把不同内容混在一起。下一步应核对缓存规则和缓存键，而不是先改源站文件。
- 源站 200、边缘 404，边缘响应无缓存命中标记：更可能是边缘回源时请求被改写，或回源路径与直连路径不同。下一步应比对边缘回源请求的 Host、路径和查询串。
- 源站 200、边缘 5xx 或超时：更可能是边缘到源站的网络、证书或回源配置问题。下一步应检查回源链路，而不是把 URL 当作死链删除。
- 源站直连也出现 404，只是不同时间点结果不同：说明问题可能不在边缘，而在源站发布或路由。下一步应回到源站日志和发布记录。
这里要强调一个动作及其影响：如果你先按“死链”处理，把内链删掉或改成 301，那么边缘异常的证据会被覆盖，后续再排查时很难还原当时两条路径的差异。相反，先保留证据再决定是否改链接，能让后续动作有依据。
把证据固定成可复查的记录
记录不必复杂，但要能让另一个人复现。可以按下面顺序整理：
- 写清假设：源站正常、边缘异常，并注明这是待验证的判断。
- 列出请求条件：URL、方法、Host、是否跟随重定向、请求时间。
- 分别粘贴源站与边缘的响应头关键字段，标注哪些字段缺失。
- 写下已排除和未排除的原因，例如“已确认源站返回 200，未确认边缘回源请求是否被改写”。
- 给出下一步动作和判定条件，例如“若边缘回源请求路径与直连不一致，则调整回源配置后重测”。
如果团队要把这条记录交给开发或运维，最好附上可执行的请求命令或检查项，而不是只给结论。命令中的域名、路径和请求头应使用实际值；若涉及内部地址，按团队规范处理，不要写进公开文档。
什么时候可以判定为死链，什么时候应继续观察
只有当源站和边缘节点在多次、可比的请求下都返回表示资源不存在的状态，并且排除了缓存、回源改写和发布时序之后，才适合按死链处理。若只有边缘节点异常，而源站持续正常，更合理的动作是修边缘配置或刷新缓存，而不是删内链。若边缘节点异常是间歇性的，应保留多次请求的时间序列，观察是否与发布、缓存过期或节点切换相关。
另外，抓取工具或监控里某条 URL 的请求量归零，不能单独证明死链已被正确处理。它也可能是抓取频率调整、监控规则变更或该 URL 不再被引用所致。判断时要回到响应证据本身。robots.txt 的限制不等于索引移除，站点地图也不保证收录；这些规则不能替代对源站与边缘响应差异的核对。若站点同时使用 HTTPS，也不要因为证书正常就认为边缘回源一定没有问题，两者需要分别检查。
把上面的记录做完后，你会得到一个明确的分岔：证据指向边缘缓存或回源配置，就按边缘问题处理；证据指向源站资源确实不存在，才进入死链清理流程。这样，多个角色对同一事实的不同理解，就变成了可以逐项核对的项目。
