域名选择技巧：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /4f9a9285d959.html
📄
域名选择技巧：源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常、边缘节点异常时，最该保留的不是“页面打不开”的截图，而是能区分“边缘配置问题”和“域名解析问题”的对照证据。至少应同时保留源站直连结果、边缘节点返回结果、解析记录快照和请求时间戳，四类证据缺一类，后续判断就容易走偏。
先区分两种条件：源站直连正常与边缘返回异常
源站直连正常，指绕过边缘节点、直接请求源站IP或源站域名时能拿到预期响应。边缘返回异常，指经CDN或其他边缘层访问时出现状态码异常、内容错误或超时。这两种条件同时成立时，问题大概率出在边缘层或解析层，而不是源站本身。
但“源站正常”本身也要有证据支撑。只凭浏览器能打开源站页面不够，因为浏览器可能命中本地缓存。更可靠的做法是用curl -I直接请求源站，记录HTTP状态码、响应头和响应时间。如果源站返回200且内容长度与预期一致，才能把源站排除在主要嫌疑之外。
反过来，如果源站直连也异常，那就不属于本篇讨论的范围，应先排查源站服务本身。这个前提不成立时，继续保留边缘证据意义有限。
必须保留的四类证据及各自作用
第一类是源站直连证据。用curl -I https://源站地址或指定源站IP请求，保存完整响应头和状态码。它回答的是“源站是否真的正常”。
第二类是边缘节点返回证据。用同一路径请求边缘域名，保存状态码、响应头和响应体片段。它回答的是“边缘层返回了什么”。
第三类是解析记录快照。用dig或nslookup查询边缘域名，记录返回的CNAME链和A记录。如果解析结果指向了错误节点或解析尚未生效，边缘异常就有了合理解释。
第四类是时间戳和请求路径。同一分钟内的源站请求和边缘请求才有对照价值。如果两次请求相隔数小时，中间可能发生了配置变更，对照就失去意义。
这四类证据的作用不是证明谁对谁错，而是把“源站问题”“边缘配置问题”“解析问题”三种解释分开。缺少解析快照时，边缘异常可能被误判为配置错误；缺少源站直连证据时，源站问题可能被误判为边缘问题。
一个假设例子：同一路径两种结果如何对照
假设某站点源站直连返回200，边缘访问返回502。此时先保留源站响应头，再保留边缘响应头，然后查询边缘域名的解析记录。如果解析记录正常指向边缘服务商，但边缘返回502，说明问题在边缘回源配置或边缘节点本身。如果解析记录指向了一个已停用的旧节点，那问题在解析层，不需要改源站配置。
这个例子的关键动作是“先查解析，再决定是否改边缘配置”。如果跳过解析查询直接改边缘回源设置，可能改错方向，甚至把原本正常的源站配置改乱。动作的结果直接影响下一步：解析正常则排查边缘配置，解析异常则先修正解析。
哪些情况下这些证据不够用
如果边缘异常只出现在特定地区或特定运营商，单次请求证据就不够。需要保留不同地区、不同运营商的请求结果，才能判断是局部节点问题还是全局问题。此时可借助多地探测工具，但要注意工具本身也可能命中缓存。
如果异常表现为间歇性超时，单次请求证据同样不够。应保留多次请求的时间序列，记录每次的状态码和耗时。只有一次超时不能证明边缘节点持续异常，可能只是瞬时网络抖动。
另外，robots.txt的抓取限制不等于可靠的索引移除，站点地图不保证收录，这些与边缘异常排查无关，不应混入证据清单。边缘异常的证据只围绕请求、响应和解析展开。
保留证据后的下一步动作
证据齐全后，下一步不是立刻改配置，而是先做一次对照复现：在同一时间窗口内，再次请求源站和边缘，确认异常是否稳定复现。如果稳定复现，且解析记录正常，再检查边缘回源配置和缓存规则。如果解析记录异常，先修正解析并等待生效，再复测边缘返回。
如果异常无法稳定复现，应保留多次请求记录，并观察是否与特定时间段或特定节点相关。此时不宜贸然修改配置，因为修改可能掩盖真实原因。保留证据的价值在于，它让后续每一步修改都有对照依据，而不是凭感觉试错。
