什么是二级域名源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5a29e4e25460.html
📄
什么是二级域名源站正常而边缘节点异常时应保留哪些证据
先给结论：源站正常只能说明回源那一侧暂时没暴露问题，不能证明用户拿到的是同一份响应。遇到二级域名在边缘节点异常，最该保留的是能区分“回源内容变了”“边缘缓存旧了”“节点或线路单独出问题”“客户端或本地网络干扰”这四类解释的证据。下面用一个假设情境把取证顺序和取舍讲清楚。
假设情境：同一二级域名，两台机器结果不同
假设你有 img.example.com 这个二级域名，源站直接访问返回 200 和一张正常图片。但同事在另一个城市打开同一路径，拿到的是旧图或 404。此时不要先改源站，也不要先清空整个缓存。先固定三组对照：你自己的机器、同事的机器、以及一台与两边都不同的第三方节点。每组都记录时间、解析结果、响应状态、响应头和响应体摘要。只有对照成立，才能判断异常是跟着人走、跟着网络走，还是跟着边缘节点走。
第一类证据：解析与节点归属
二级域名常被 CNAME 到 CDN 或边缘服务，解析结果会因地区和运营商不同。需要保留的是：
- 同一时刻不同网络下的
A/CNAME查询结果，注明查询工具和出口位置； - 响应头里能标识边缘节点的字段，例如
Via、X-Cache、Server、Age，原样抄录； - 该请求命中的边缘节点 IP 或机房标识，以及它是否与解析结果一致。
如果两台机器解析到不同节点，一台正常一台异常，问题更可能在单个节点或回源链路，而不是源站文件本身。下一步应固定异常节点 IP，再向同一节点重复请求，观察是否稳定复现。
第二类证据：缓存状态与回源行为
边缘异常最常见的一种解释是缓存了旧响应或错误响应。要保留能区分“缓存命中”和“回源失败”的字段：Age 是否很大、X-Cache 是 HIT 还是 MISS、Cache-Control 与 Expires 是否被边缘改写。假设源站返回 Cache-Control: max-age=60，但边缘响应里 Age 是 86400，这就提示边缘层可能没有按预期遵守缓存指令，或中间还有一层缓存。
可执行动作：对同一 URL 追加一个不会命中缓存的查询串（例如 ?probe=1），再请求一次。如果带查询串正常、不带查询串异常，优先怀疑缓存键或缓存策略；如果两者都异常，缓存解释的权重下降，应转向节点和回源链路。
第三类证据：源站回源日志与边缘日志的对应关系
源站正常不代表边缘一定回源成功。需要把边缘请求 ID、时间戳、回源状态码和源站访问日志对齐。重点看三件事：
- 边缘异常的那次请求，源站日志里有没有对应记录；
- 如果有记录，源站返回的状态码和响应大小是否与边缘展示一致；
- 如果没有记录，说明请求可能没到达源站，问题在边缘或中间链路。
这一步的结果直接决定下一步：有回源记录但内容不一致，查缓存和压缩、字符集等响应处理；没有回源记录，查边缘节点健康、防火墙和回源超时。注意，抓取量或请求量短时归零不能单独证明某个处理正确，它也可能是采集延迟、日志采样或流量本身下降造成的。
第四类证据：客户端与本地网络干扰
有时异常只在某一台机器上出现，原因是本地 DNS 缓存、代理、浏览器缓存或安全软件。保留证据时至少包括：无代理直连结果、清空本地 DNS 缓存后的解析结果、以及不同浏览器或无痕窗口的响应。若只有一台机器异常，而其他网络和节点都正常，优先排查客户端，不要动边缘配置。这里要区分：搜索引擎、平台推荐和广告各有自己的抓取与展示逻辑，本问题只针对二级域名作为资源或页面入口时的边缘响应，不把三者混在一起判断。
证据保留的最小清单与决策顺序
把上述内容压缩成一份可复查记录：时间、请求 URL、出口网络、解析结果、边缘节点标识、响应状态码、关键响应头、响应体摘要、是否命中缓存、源站是否有对应日志。假设记录显示：只有某运营商网络异常、解析到同一节点、Age 很大、带查询串正常、源站无对应回源日志。这组证据更支持“该节点缓存了旧响应且未按预期回源”，而不是源站内容错误。
按这个顺序行动：先固定异常范围，再验证缓存解释，最后才考虑刷新缓存或切换节点。每次动作后重复同一组探测，比较哪些字段变了。若刷新后 Age 归零且响应恢复，说明缓存解释成立；若刷新后仍异常，应保留刷新前后的完整记录，转向节点和链路排查。这样做的价值在于，下一次异常出现时你能用同一套证据快速判断，而不是凭感觉反复操作。
