域名信息查询：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d63067c637cd.html
📄
域名信息查询：源站正常而边缘节点异常时应保留哪些证据
当你在本地或源站直接访问一切正常，但通过边缘节点或CDN回源路径访问却出现错误时，域名信息查询的重点不是确认域名是否到期，而是采集能区分“源站问题”与“边缘链路问题”的证据。核心动作是：在边缘节点异常的时间窗口内，分别从源站直连和边缘路径抓取同一资源的响应头、状态码与解析结果，并记录时间戳。只有两组证据同时存在，后续的排查或工单才有可对比的基线。
先固定一个可复现的异常样本
不要凭“用户说打不开”就开始查。选一个具体的URL或接口，要求它能稳定复现异常。假设你的图片资源 https://static.example.com/a.jpg 在边缘节点返回 502，但源站直连返回 200。这个对比本身就是最有价值的证据。操作上：
- 用
curl -I分别请求源站IP和边缘域名，保存完整响应头，包括server、via、x-cache、age等字段。 - 记录请求发出时的本地时间与响应返回时间，精确到秒，便于和边缘节点的日志对齐。
- 如果异常是间歇性的，至少连续采集三次，标注每次是否复现。
这个动作的结果决定了下一步：如果源站直连也失败，问题在源站，不需要继续查边缘；如果只有边缘路径失败，才进入域名解析与节点层面的证据采集。
域名信息查询要采哪几类解析证据
边缘节点异常时，域名信息查询的目标是判断解析结果是否因节点位置不同而产生差异。需要保留的证据包括：
- 权威DNS记录快照：从权威服务器直接查询A、AAAA、CNAME记录，确认记录本身没有在异常时间窗口内被改动。
- 不同递归解析器的结果：用公共解析器和本地解析器分别查询同一域名，对比返回的IP集合是否一致。如果不一致，说明存在解析缓存或调度差异。
- 边缘节点实际回源的IP：如果边缘平台提供回源日志或诊断工具，导出异常请求对应的回源IP和端口。
这里要说明一个适用条件：解析结果不一致不必然等于故障原因。地理调度、Anycast和缓存TTL都会造成正常差异。只有当异常请求集中指向某个特定回源IP，而该IP在源站侧无访问日志时，解析证据才指向边缘链路。
区分源站与边缘责任的关键证据组合
单看状态码容易误判。以下两组证据组合能帮你做出取舍：
- 指向边缘责任的组合：源站直连返回200且源站访问日志中有该请求记录；边缘路径返回502且边缘日志显示回源超时或连接被拒；权威DNS记录在异常期间未变更。
- 指向源站责任的组合：源站直连间歇性返回500；源站日志中出现大量来自边缘回源IP的5xx；边缘节点返回的5xx与源站错误时间戳吻合。
假设一个场景：边缘节点返回502，但源站直连稳定200，且源站日志中完全没有边缘回源IP的请求记录。这时更可能是边缘节点到源站的网络路径中断，而不是源站应用故障。此时应保留边缘节点的回源诊断输出和本地到源站的 traceroute 结果，作为向边缘服务商提交工单的依据。
把证据整理成可执行的处理路径
采集完证据后，按以下顺序决定动作：
- 如果源站直连异常，先处理源站，暂停边缘层排查。
- 如果源站正常且权威DNS未变更，将边缘回源日志、响应头对比和解析结果打包，提交给边缘服务商。
- 如果解析结果在不同递归解析器间不一致，检查TTL设置和是否存在多条CNAME记录，确认是否为调度策略的正常表现。
- 在等待边缘服务商回复期间，保留原始证据文件，不要覆盖或重新抓取，以免丢失时间戳。
需要提醒的是，robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些与边缘异常排查无关，但在你决定是否临时下线某个资源时需要单独评估。整个处理过程中，域名信息查询提供的是解析层面的基线，它不能替代源站日志和边缘回源日志的交叉比对。只有把解析证据、响应头对比和日志时间线放在一起，才能判断问题出在哪一段链路，并决定下一步是修源站、改解析还是提工单。
