特殊后缀域名，源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /0bd183713408.html
📄
特殊后缀域名，源站正常而边缘节点异常时应保留哪些证据
先给结论：当源站直连返回正常、但经过边缘节点后出现错误或内容不一致时，最该保留的是能证明“同一请求在两条路径上结果不同”的对照证据，而不是只截一张报错图。下面用一个假设情境把决策过程走一遍。
假设情境：源站正常，边缘却回 5xx
假设你有一个使用特殊后缀域名的站点，例如以 .travel 或 .museum 结尾。你从源站服务器本机执行 curl -I，返回 200 和正确内容；但从外部访问域名时，边缘节点返回 502，或返回一个旧的缓存页面。你按常规清了缓存、重发了配置，问题依旧。这时要做的第一件事不是继续改配置，而是固定现场证据，因为边缘节点的状态会随缓存过期、节点切换而变化，一旦现场消失，你无法判断是配置问题还是节点问题。
必须成对保留的证据：请求与响应
核心原则是“同一请求、两条路径、成对留存”。单独一条边缘报错记录说服力有限，因为对方可以解释为源站瞬时故障。
- 请求侧：完整 URL、请求方法、请求头（尤其 Host、User-Agent、Accept-Encoding、Cookie 中与分地区或分语言相关的字段）、发起时间（带时区）、发起位置或出口 IP 归属地。
- 响应侧：状态码、全部响应头（重点看缓存命中标识、回源标识、节点标识、Age、Via 等）、响应体前若干字节的原文或哈希。
- 对照侧：同样参数直连源站的结果，以及换一个网络出口再访问边缘的结果。
把这三组放在一起，才能说明“源站给的是 A，边缘给的是 B”。如果只有 B，没有 A，任何结论都是猜测。
特殊后缀容易漏掉的一个变量：解析与回源链路
特殊后缀域名本身不影响 HTTP 语义，但它常与特定的注册管理机构、DNS 服务商和 CDN 节点调度绑定，排查时容易漏掉解析层。要保留的证据包括：
- 解析记录快照：A/AAAA/CNAME 记录、TTL、查询时间。用
dig或nslookup分别从本地和公共解析器查询，保留两次结果。 - 解析结果差异：如果不同解析器返回不同节点 IP，说明调度在起作用，这本身就是证据，而不是噪声。
- 回源链路记录：边缘节点回源时用的 Host、协议（HTTP 还是 HTTPS）、端口。回源 Host 写错会让源站返回默认站点或 404，而直连测试却正常。
一个实际动作：把边缘回源请求的 Host 与源站虚拟主机配置逐字比对。如果发现回源用的是 IP 而非域名，且源站按域名区分站点，那么“源站正常”只是因为你直连时带了正确 Host，边缘路径根本没打到同一个站点。这个动作的结果会直接改变下一步——从“怀疑节点故障”转为“修正回源 Host 配置”。
时间线比单点截图更有用
边缘异常往往间歇出现。建议按时间顺序记录：
- 首次发现异常的时间，以及此前最后一次确认正常的时间。
- 期间做过的每一次操作（清缓存、改配置、切换节点、重发解析），以及操作后立即复测的结果。
- 异常是否与特定地区、特定运营商、特定时间段相关。
如果异常只在某几个出口出现，且这些出口解析到同一批节点，指向节点或调度问题；如果所有出口都异常，但直连源站正常，更可能是回源配置或边缘与源站之间的协议不匹配。这两种判断对应完全不同的下一步，所以时间线和出口信息不能省。
哪些现象不能单独当作结论
排查中容易过度解读几类信号。抓取量或请求量突然归零，可能是日志采样、日志轮转、监控口径变化，也可能是真的中断，不能只凭一个数字断定边缘出了问题。同样，边缘返回 200 也不代表内容正确，缓存返回旧页面时状态码依然是 200，所以必须比对响应体而不是只看状态码。
另外要区分证据的用途：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些与边缘异常是不同层面的问题，不要在排查边缘时把它们混进同一份证据清单，否则会稀释真正有用的对照记录。
整理成可交接的证据包
最终应形成一份可复查的材料：请求与响应的成对记录、解析快照、回源链路参数、时间线，以及你据此做出的判断和下一步动作。这样无论是自己隔天回看，还是交给 CDN 或 DNS 服务方，对方都能复现同一个请求并比对结果。证据的价值不在于数量，而在于它能否让另一个人用同样的输入得到同样的输出——做不到这一点，再多截图也无法推动问题解决。
