死链查询，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /26b3717492bf.html
📄
死链查询，源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回正常并不代表用户侧正常，边缘节点异常时最该保留的是同一URL在源站与边缘两侧的完整响应证据，包括状态码、响应头、时间戳、节点标识和请求链路，而不是只留一张“源站200”的截图。下面用一个假设情境把决策过程串起来。
假设情境：同一URL，两个人看到两种结果
假设某站点运维在源站直接请求 /old-page，得到200；而SEO同事从办公网络访问同一地址，看到404或连接重置。两人各执一词，因为各自手里的证据只覆盖了自己那一侧。此时不要急着判定谁对，而要先把分歧转成可核对的证据项。
关键动作是：固定同一URL、同一时间窗口、分别从源站直连和经过边缘节点各取一次响应，并记录请求发起位置。这个动作的结果决定了下一步是查缓存、查回源配置，还是查节点本身。
边缘异常时必须留下的响应证据
只记录“正常/异常”不够，要留下能复现判断的字段：
curl -I或等效请求得到的完整响应头，含状态码、cache-control、age、via、x-cache一类缓存标识（字段名以实际返回为准，不预设）。- 请求时间戳，精确到分钟，源站与边缘两侧时间要能对齐。
- 边缘节点标识：能区分命中了哪个节点或哪个缓存层的信息。
- 请求链路：从哪台机器、哪个网络出口发出，是否经过代理。
这些字段的作用是让“源站正常、边缘异常”从口头描述变成可复核的对照。若边缘返回404而源站返回200，且边缘响应带明显的缓存命中标识，那么下一步优先查该URL在边缘的缓存副本，而不是直接改源站。
源站侧要同步保留什么，避免单边结论
源站侧证据不是用来“证明自己没问题”，而是用来排除回源环节的干扰：
- 源站直连请求的响应头与状态码，与边缘请求放在同一张对照记录里。
- 源站访问日志中该时间窗口内是否收到来自边缘的回源请求，以及回源请求的结果。
- 若边缘未回源就直接返回异常，说明问题在边缘缓存或节点逻辑，源站日志里不会有对应记录——这本身就是一条证据。
如果源站日志显示边缘确实回源且源站返回200，但用户侧仍是404，那么分歧点就落在边缘到用户这一段，证据重点转向边缘响应头和节点状态。
把分歧转成可核对项目的记录方式
建议用一张对照记录，而不是零散截图。每条记录至少包含：URL、请求发起位置、时间、状态码、关键响应头、是否回源。假设记录如下（仅为说明格式的虚构示例）：
- URL：
/old-page；源站直连：200，无缓存标识；边缘：404，带缓存命中标识。 - 结论方向：优先核查边缘缓存副本，而非修改源站内容。
这里要说明一个适用条件：边缘返回404不能单独证明缓存副本错误，也可能是边缘规则、回源路径或节点配置导致。因此记录里必须同时保留“是否回源”这一项，用来区分不同原因。
另外，抓取量或某类请求量在某段时间归零，也不能单独证明处理正确；它可能来自抓取频率变化、日志保留周期或采集口径调整，需要结合上述对照记录一起判断。
拿到证据后的下一步怎么走
如果证据显示边缘未回源且返回异常，下一步是核对边缘缓存与规则配置，并在修改后重新取一次同URL的对照响应，确认两侧一致；如果证据显示边缘已回源而源站返回正常，则重点转向边缘到用户链路。每一次修改后都重新记录，才能让“已修复”有可核对依据，而不是依赖某一方的口头确认。
最后提醒：robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，这些与边缘异常排查是不同层面的问题，不要用它们替代响应证据来判断边缘是否正常。
