📍 WDQWDWQD987AAAAA:216.73.217.100
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9fbb3931108e.html
📄

www域名配置，源站正常而边缘节点异常时应保留哪些证据

当源站直接访问返回正常，而经过边缘节点后出现异常时，最该保留的不是一段“打不开”的截图，而是一组能区分“源站内容问题、边缘缓存问题、DNS解析问题、回源链路问题”的证据。下面用一个假设情境说明该保留什么、为什么保留、以及这些证据如何改变下一步动作。

假设情境：一次无法复现的边缘异常

假设某站点使用 www 域名对外服务，源站 IP 直接请求 Host: www.example.com 时返回 200 和正确页面；但通过边缘节点访问同一 URL，间歇性返回旧页面或 502。运维重启边缘缓存后恢复，几小时后再次出现。此时如果只记录“重启后好了”，下一次异常仍然无法定位。真正需要保留的证据，是能证明异常发生在哪一层、持续多久、影响哪些请求的那部分数据。

必须保留的第一组证据：同一请求的对照记录

边缘异常的核心难点是“源站正常”并不等于“用户拿到的是源站当前内容”。因此要保留同一 URL、同一时间窗口内，源站直连与边缘访问的成对记录。每条记录至少包含：完整 URL、请求时间（带时区）、请求方法、请求头中的 Host、User-Agent、Accept-Encoding、Cookie 是否存在，以及响应状态码、响应头中的 Age、Cache-Control、Via、X-Cache 一类缓存标识字段，最后是响应体摘要或哈希。

成对记录的价值在于：如果源站响应体哈希与边缘响应体哈希不同，而边缘响应头带有较大的 Age，那么问题更可能落在缓存层而非源站；如果边缘响应头没有缓存标识、状态码却是 502，则应把注意力转向回源链路或边缘到源站的连接。没有这组对照，后续任何判断都只能靠猜。

需要保留的第二组证据：DNS 与节点归属信息

www 域名通常通过 CNAME 指向边缘服务，再由边缘服务决定回源。异常时如果只保留“解析到某个 IP”，信息量很低。应保留解析链路：www 的 CNAME 目标、该目标当前解析出的 A 或 AAAA 记录、解析时间与 TTL。若使用多个权威解析或存在多地递归解析差异，应分别记录不同递归解析器得到的答案，而不是只记录本地一次结果。

同时保留边缘节点的归属线索，例如响应头中的节点标识、请求命中的机房代码，或边缘服务商提供的请求 ID。这些字段能把“某一次异常”归属到具体节点或具体回源路径。若同一 URL 在不同节点表现不同，问题范围就缩小到节点或节点到源站的链路；若所有节点一致异常，则更可能是配置或源站侧的统一问题。这里的关键动作是：先固定一个可复现的异常请求，再分别从两个以上节点发起相同请求，比较响应头与响应体，而不是反复刷新同一节点。

第三组证据：时间线与变更记录

间歇性异常往往与某个变更时间点相关。应保留异常首次出现和恢复的时间点，以及该时间窗口内做过的操作：边缘缓存刷新、回源配置调整、DNS 记录修改、源站发布、证书更新、防火墙或安全策略变更。记录要写到“谁在什么时间改了什么”，而不是只写“已处理”。

如果异常在缓存刷新后消失、又在 TTL 到期后重现，这说明刷新只是暂时清除了旧对象，并未解决产生旧对象的原因。此时下一步不应继续刷新，而应检查边缘缓存键的组成：是否把 Cookie、查询参数或 Vary 头纳入了缓存键，是否因为缓存键过粗导致不同用户拿到同一份缓存。反过来，如果刷新后长时间不再出现，且变更记录中没有其他动作，那么更合理的解释是某次回源超时或节点临时故障，而不是配置错误——但这一结论仍需要下一次异常时的对照记录来验证。

哪些证据不该被当作结论

请求量、抓取量或某监控指标突然归零，不能单独证明边缘处理正确。归零还可能来自监控采样中断、日志采集延迟、流量本身下降，或统计口径变化。同样，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录，这些与边缘异常不是同一层问题，不应混在同一份证据里下结论。

另一个常见误区是只看状态码。边缘返回 200 但内容是旧版本，与边缘返回 502，是两类完全不同的故障。前者应优先查缓存键与缓存 TTL，后者应优先查回源连接与源站健康检查。把两类现象合并成“边缘有问题”，会让后续排查失去方向。

把证据转成下一步动作

保留证据的最终目的是决定下一步做什么。可以按以下顺序判断：

1. 若源站与边缘响应体哈希不同，且边缘响应头显示命中缓存，先查缓存键与 TTL，再决定是调整缓存规则还是仅刷新对象。
2. 若边缘响应头显示未命中缓存却仍异常，查回源请求是否携带了正确的 Host 与协议，再查源站是否对回源 IP 有额外限制。
3. 若只有部分节点异常，保留节点标识并对比节点到源站的链路，而不是全量刷新所有缓存。
4. 若异常与某次变更时间吻合，先回滚或复现该变更，再决定是否保留新配置。

无论走哪一步，都应把本次保留的对照记录、解析链路、节点标识和时间线归档，并在下一次异常时用同样字段再次采集，这样两次记录才能比较。假设某次异常在调整缓存键后不再出现，也不能只凭一次恢复就认定原因，仍需在下一个流量周期内确认同一类请求不再返回旧内容，才能把该动作视为有效修复。