二级域名与主域名区别：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /20bedc17d0ca.html
📄
二级域名与主域名区别：源站正常而边缘节点异常时应保留哪些证据
有条件的结论是：当主域名源站返回正常、而某个二级域名的边缘节点响应异常时，应优先保留能证明“同一时刻、不同解析路径、不同响应结果”的对照证据，而不是只保存一张报错截图。如果异常只出现在你自己的网络或单个设备上，这套证据链会失效，需要先排除本地因素再继续。
先固定时间与解析路径，再谈证据
边缘节点异常最常见的争议是“我这边正常、你那边不正常”。要把它变成可核对的项目，第一步是把时间、解析结果和请求目标固定下来。
- 记录异常发生的具体时间，精确到分钟，并注明时区。
- 保留主域名与二级域名在同一时刻的解析结果，包括返回的 IP 或 CNAME 记录。
- 保留请求的完整 URL、请求方法和响应状态码。
- 记录执行这些操作的网络环境，例如运营商、地区、是否使用代理。
这些字段的作用是让不同角色能复现同一条件。缺了时间，日志无法对齐；缺了解析结果，就无法判断请求是否真的落到了异常节点上。
源站与边缘节点的对照证据怎么取
核心动作是构造一组可比较的请求，让源站和边缘节点的差异自己显现出来。一个可用的假设例子是：假设主域名解析到源站 IP，二级域名解析到边缘节点 CNAME，两者返回同一份内容。
- 直接向源站 IP 发起请求，并带上二级域名的 Host 头，记录状态码和响应体摘要。
- 向二级域名的正常解析结果发起请求，记录同样的字段。
- 如果两者结果不同，再重复几次，确认差异是否稳定。
这个动作的结果会直接影响下一步：如果源站与边缘节点响应一致，问题可能不在边缘层，而应转向缓存、DNS 或客户端；如果稳定不一致，证据就指向边缘节点本身，可以据此向对应服务方提出核对请求。
哪些证据容易被误当成结论
请求量、抓取量或某个监控指标归零，不能单独证明边缘节点处理正确或错误。它还有几种合理解释：统计口径调整、采集任务中断、采样窗口错位，或者异常请求根本没到达被统计的那一层。
同理，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。这些现象与边缘节点异常没有直接因果，把它们混进同一份证据里，只会让分歧更难收敛。保留证据时应区分“直接观测到的响应差异”和“间接的统计变化”，不要把后者当作前者的证明。
把分歧转成可核对项目的一个做法
当多个角色对同一事实理解不同时，可以建立一份最小核对表，让每个人填写自己观测到的那一格。假设的核对表可以包含四项：观测时间、解析结果、请求目标、响应状态。任何一格为空，就说明该观测不足以支撑结论。
执行这个动作后，通常会暴露两种结果：一是大家其实在测不同的目标，二是确实存在同一目标下的稳定差异。前者需要先统一测试对象，后者才进入边缘节点的排查。这样处理的好处是把“我觉得有问题”变成“在某个时间点、某个解析路径下、某个请求返回了不同结果”，后续动作才有依据。
下一步动作与适用条件
在证据收集齐之后，下一步是选择保留还是切换。如果差异稳定且集中在边缘节点，应保留原始响应记录，并同时记录你为绕过异常所做的任何临时改动，例如修改本地解析或调整回源配置。这些改动会影响后续判断，必须一并留档。
需要说明适用条件：这套方法针对的是源站可正常响应、异常只出现在边缘路径的场景。如果源站本身也返回异常，或者异常无法在多次请求中复现，就应先处理源站或复现条件，而不是继续扩大边缘证据的收集范围。整个过程的目的是让结论可以被别人核对，而不是替某一方下判断。
