canonical：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bd5c5fc33935.html
📄
canonical：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站返回的 canonical 正确，不代表边缘节点交付给爬虫的版本也正确。此时最有价值的证据不是“源站没问题”的截图，而是同一 URL 在源站响应与边缘响应之间的逐字节差异记录。你需要保留的是能证明差异存在、差异范围以及差异持续时间的材料，而不是只保留一份源站自检结果。
先固定请求条件，再谈证据
边缘异常往往只在特定条件下出现：特定机房、特定 UA、特定 Accept-Encoding，或缓存命中与回源两种状态。若两次抓取的条件不同，得到的差异无法归因。建议先固定以下变量并记录在案：
- 完整请求 URL，包含协议与查询串，不做规范化后再比对。
- 请求头原文，重点是
User-Agent、Accept-Encoding、Host。 - 响应状态码与响应头完整列表，尤其是缓存状态类字段。
- 抓取时间与时区，精确到秒。
- 解析到的边缘节点 IP 或机房标识，以及是否命中缓存。
这里有一个容易忽略的取舍：直接请求源站 IP 并带上 Host 头，能得到源站真实输出；而通过边缘域名请求，得到的是交付输出。两者都要留，缺任何一方都无法说明“源站正常”这个前提是否成立。
要保留的三层证据，而不是一份截图
第一层是原始响应。把源站响应和边缘响应的完整头部与正文分别存成文件，不要只截图 canonical 那一行。canonical 可能出现在 HTML 的 <link rel="canonical"> 中，也可能通过 HTTP 头 Link 传递；边缘改写可能只动了其中一处，只截一行会漏掉冲突。
第二层是差异对照。对两份正文做逐行比较，标出 canonical 行、其他头部、以及是否出现额外注入内容。比较时保留原始行号，方便后续复查。若正文被压缩或分块传输，先解压再比较，并保留解压前后的哈希值。
第三层是时间序列。同一 URL 在多个时间点重复抓取，记录每次的差异是否一致。单次差异可能是回源抖动，持续多次的差异才更接近稳定行为。这里要说明一个假设：如果只在缓存过期后的首次请求出现差异，而在缓存命中时正常，那问题更可能出在回源链路或边缘改写规则，而不是缓存本身。这个推断需要更多样本支持，不能仅凭一次结果下结论。
一个可执行的排查动作及其影响
假设你在边缘域名上抓到一个页面，canonical 指向了一个不该出现的旧地址，而源站直连返回的是正确地址。此时先做这个动作：用同一请求头分别请求源站 IP 与边缘域名，各保存一份完整响应，然后对正文做逐行比较。
比较结果会直接决定下一步：
- 若正文除 canonical 外完全一致，差异集中在单一字段，优先检查边缘的 HTML 改写或注入规则。
- 若正文出现额外脚本或结构变化，说明边缘层做了内容加工，需要连同加工规则一起取证。
- 若源站响应本身也随请求头变化，则“源站正常”的前提需要重新界定，先缩小到具体请求头组合。
这个动作的价值在于把模糊的“看起来不对”变成可复核的差异清单。后续无论是找运维、找 CDN 支持，还是自己调整规则，都能用同一份材料复现问题，而不是靠口头描述。
哪些现象不能单独作为结论
抓取量或日志中某条记录归零，不能单独证明边缘处理正确。它还可能来自抓取频率下降、日志采样、请求被合并，或该 URL 本身不再被访问。同理，边缘返回 200 也不代表交付内容与源站一致，状态码正常与内容正确是两件事。
还要区分缓存与改写这两种解释：缓存可能返回旧版本，改写可能在每次回源时都注入内容。区分方法是绕过缓存直接回源，以及在不同时间点重复抓取。若绕过缓存后差异消失，缓存嫌疑更大；若绕过缓存后差异仍在，改写嫌疑更大。两种解释对应的修复路径不同，证据不足时不要急着改配置。
把证据整理成可交接的最小集合
最终保留的材料不必很多，但要让另一个人能独立复现。最小集合包括：请求原文、两份完整响应、差异对照文件、抓取时间线，以及一份说明当前假设与待验证点的短注。短注里写清楚哪些结论已有证据支持，哪些还只是推测。
如果问题涉及具体平台或服务商，核验时以对方提供的官方文档和工单记录为准，不要依赖第三方转述。整理好这份集合后，下一步才是决定改边缘规则、改缓存策略，还是继续扩大采样范围；在此之前，任何配置改动都缺少可对照的基线。
