死链检查：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0e69f6b912a7.html
📄
死链检查：源站正常而边缘节点异常时应保留哪些证据
结论先说：如果源站返回正常、边缘节点却返回4xx或5xx，不要急着改源站，也不要只截一张浏览器报错图。应保留“同一URL、同一时间窗、不同节点”的对照证据，证明异常发生在边缘层，而不是内容已删除。只有当日志、响应头和节点回源记录能互相对上，才适合把处理动作指向CDN或边缘配置；若缺少这些证据，先补测再动配置。
先分清两种成立条件：边缘异常还是源站异常
边缘节点异常有一个可区分特征：同一URL在短时间内从源站直连正常，经边缘访问却稳定失败。此时应保留三类证据：边缘返回的状态码与响应头、源站直连的对照响应、以及边缘回源日志中的状态与时间戳。
反过来，如果源站直连也开始返回404或500，或者边缘失败只出现在单个地区且几分钟后自愈，就不能直接判定为边缘节点问题。前者说明源站内容或应用已变化，后者更像临时网络抖动。两种情况下的下一步动作完全不同：前者查源站，后者先观察并保留时间线。
假设某商品页在源站直连返回200，经边缘访问返回404，且边缘回源日志显示回源请求也返回200。这个假设组合说明边缘缓存或路由层可能把正常响应改写成了错误响应。此时应保留该URL的完整请求头、响应头、节点标识和时间戳，再提交给边缘服务方核查，而不是先删除或重发源站页面。
必须保留的证据清单
- 请求侧证据：完整URL、请求方法、请求头中的Host与User-Agent、访问时间（含时区）。
- 边缘响应证据：状态码、响应头中的缓存状态字段、边缘节点标识、返回内容长度。
- 源站对照证据：同一时间窗内直连源站的响应状态码与响应头。
- 回源记录：边缘回源请求的状态码、回源时间、回源目标地址类型。
- 时间线：异常首次出现与最后一次出现的时间，以及期间是否有人改过缓存规则或发布过内容。
这些证据的作用不是凑材料，而是让“源站正常”这个判断可复查。只有源站对照与边缘响应同时存在，才能把问题定位到边缘层。缺少源站对照时，边缘返回404也可能只是源站内容已被删除，只是你还没直连确认。
一个容易让结论失效的反例
如果边缘节点返回404，但源站直连也返回404，那么“源站正常”这个前提就不成立。此时保留再多边缘证据也不能证明边缘层有问题，因为内容本身已经不可访问。正确动作是回到源站检查页面是否被删除、路由是否被改、权限是否变化。
另一个反例是：边缘失败只出现在某个地区，且源站直连和回源日志都正常。这更可能是局部网络或DNS解析差异，而不是边缘节点整体异常。此时应保留不同地区的解析结果和访问时间，先确认影响范围，再决定是否调整边缘配置。把局部抖动当成全局故障，容易导致过度修改。
下一步动作：先固化证据，再决定改哪一层
实际动作可以这样安排：先对同一URL做源站直连与边缘访问的对照测试，记录状态码和时间；再导出边缘回源日志，筛选该URL在异常时间窗内的记录；最后把三份材料按时间对齐。
如果对齐后显示源站正常、回源正常、边缘响应异常，下一步应联系边缘服务方并提交证据，要求核查节点缓存与路由配置。若对齐后显示源站也异常，下一步应回到源站排查内容与应用。这个动作的结果直接决定后续处理方向：证据指向边缘，就不要改源站；证据指向源站，就不要只刷新缓存。
需要提醒的是，边缘返回404并不等于搜索引擎会立即移除该URL，robots.txt中的抓取限制也不等于可靠的索引移除。站点地图不保证收录。保留证据的目的是让排查有据可依，而不是承诺任何收录或排名结果。先确认异常发生在哪一层，再决定是否提交死链处理，才是可复查的路径。
