内链，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /31a26bde3fea.html
📄
内链，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站返回正常、但边缘节点上的内链表现异常时，最该保留的是能区分“内容问题”和“分发问题”的对照证据，而不是单点截图。核心是同一 URL 在源站与边缘节点两侧的响应头、状态码、响应体片段、抓取时间与节点标识，以及内链跳转链在两侧的差异记录。没有这些对照，后续任何修复都只能靠猜。
先看一个假设情境：同一页面两侧表现不一致
假设你有一个栏目页 A，源站直连时返回 200，页面里指向详情页 B 的内链也能正常跳转。但通过边缘节点访问时，A 页面里的同一条内链有时跳向缓存旧版本，有时返回 404，而 B 本身在源站是正常的。你已经清过缓存、换过浏览器、也检查过页面模板，问题仍在。这时要做的不是继续改模板，而是先固定证据，判断异常究竟发生在边缘节点的缓存、回源还是重写规则上。
这个假设的重点在于：源站正常只说明“内容源”没问题，不能推出“分发链路”没问题。内链在边缘节点异常，常见原因包括缓存了旧 HTML、边缘重写规则改写了链接、回源请求被拦截、或者不同节点版本不一致。保留证据的目的，是让这些可能原因可以被逐一排除，而不是一次性全部归因于缓存。
必须保留的第一组证据：同一 URL 的双侧响应记录
对出现异常的内链目标页，分别从源站直连和边缘节点发起请求，记录以下内容。注意记录时间要精确到分钟，并注明请求时使用的节点或地区标识，否则后续无法复现。
- 状态码：源站返回什么，边缘节点返回什么。两者不一致时，优先怀疑边缘层。
- 响应头：重点看缓存命中标记、缓存年龄、回源标记、内容类型和重定向相关字段。这些字段能说明边缘节点是直接返回了缓存，还是回源取到了不同结果。
- 响应体片段：不需要保存整页，但要保存内链所在区域的 HTML 片段，确认链接地址是否被改写、是否指向旧路径。
- 请求时间与节点标识：同一 URL 在不同时间、不同节点可能结果不同，缺少这两项就无法判断是偶发还是稳定异常。
实际动作：把源站与边缘节点的两组记录并排保存，标注差异点。如果只有边缘节点返回旧链接，而源站响应体里是新链接，那么问题基本可以定位在边缘缓存或边缘重写，而不是页面模板。下一步就应该去查边缘缓存规则和重写规则，而不是继续改源站代码。
第二组证据：内链跳转链的逐跳记录
内链异常经常不是单跳问题，而是跳转链中间某一跳被边缘节点改写。对每条可疑内链，记录从点击到最终落地页的完整跳转链，包括每一跳的 URL、状态码和跳转类型。源站和边缘节点各做一次，比较差异。
如果源站跳转链是 A→B→C，边缘节点变成 A→B→D，那么 D 就是需要重点核查的对象。此时要保留 D 的响应头，确认它是边缘节点生成的错误页、旧缓存页，还是被重写规则指向了其他地址。这个动作的结果会直接决定下一步：如果是缓存旧页，处理缓存；如果是重写规则，处理规则；如果是回源被拦截，处理回源配置。
这里要说明一个适用条件：跳转链记录必须使用不执行 JavaScript 的请求方式，否则前端脚本产生的跳转会混入记录，掩盖边缘层本身的改写。如果你怀疑异常由前端脚本引起，应单独保留脚本执行前后的两份记录，而不是合并成一份。
第三组证据：边缘节点之间的差异样本
边缘节点通常不止一个。只测一个节点，可能把“个别节点异常”误判为“整体异常”。应至少选择多个不同节点或地区做同样请求，记录每个节点的状态码、缓存命中和响应体片段。
如果只有部分节点异常，证据要能回答两个问题：异常节点是否集中在同一版本或同一地区；正常节点返回的是缓存版本还是回源版本。这两个答案会影响处理方式。若异常集中在同一版本，可能是发布不同步；若正常节点也返回缓存，则说明缓存本身不是唯一变量，重写规则或回源策略也需要一起核查。
不要用请求量或抓取量的变化来证明节点异常。请求量下降可能来自统计口径变化、流量波动或采集延迟，不能单独作为边缘节点故障的证据。它只能作为辅助线索，必须和双侧响应记录一起看。
第四组证据：改动留痕与回滚点
在开始修复前，先记录当前边缘配置、缓存规则和重写规则的版本或摘要，并保存一份可回滚的快照。这一步常被跳过，但它是判断“修复动作是否真的改变了结果”的前提。
每次调整后，重复前面的双侧请求和跳转链记录，比较调整前后的差异。如果调整后边缘节点返回的响应体片段与源站一致，跳转链也一致，说明该次调整有效；如果只是状态码从 404 变成 200，但响应体仍是旧链接，则问题没有真正解决。
这里要区分一个常见误判：边缘节点返回 200 不等于内链正确。200 只说明请求成功，不说明返回的 HTML 里链接地址是对的。因此响应体片段和跳转链记录必须保留，不能只看状态码。
什么时候这些证据还不够
如果双侧响应记录、跳转链和多节点样本都一致，但用户仍反馈内链异常，那么异常可能不在服务端分发层，而在客户端环境、DNS 解析差异或中间网络设备。此时应补充记录客户端解析到的节点地址、请求时的完整响应头，以及是否经过代理。没有这些补充信息，继续在源站和边缘配置里找原因会偏离方向。
另外，如果边缘节点异常伴随证书错误或重定向到 HTTP，不要直接归因于 HTTPS 配置。HTTPS 不保证链路无故障，证书问题也可能只是边缘节点配置不一致的表现之一。应把证书链、协议版本和重定向记录一并保留，再判断问题层级。
最后，所有证据都要带时间戳和节点标识保存，并按“源站—边缘节点—客户端”三层归档。这样做的实际结果是：下一次异常复现时，你可以直接对比历史记录，判断是同一问题再次出现，还是新的变化，而不必从零开始排查。
