虚拟主机：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /65c735260ac2.html
📄
虚拟主机：源站正常而边缘节点异常时应保留哪些证据
结论先行：当源站直连正常、但通过边缘节点访问出现异常时，最值得保留的不是“页面打不开”的截图，而是能区分源站响应、边缘缓存状态和回源链路的三类证据。缺少完整日志权限时，仍可先固定响应头、带时间戳的请求记录和节点侧错误码；这些证据足以判断问题是否落在边缘层，但不足以单独证明缓存配置就是根因。
先分清源站正常与边缘异常的证据边界
源站正常通常表现为：直接请求源站 IP 或回源域名时返回预期的状态码和内容，响应时间稳定。边缘节点异常则表现为：同一 URL 经边缘访问时返回 5xx、旧内容、空内容或超时，而源站侧没有对应错误。此时应保留的证据包括：
- 带完整响应头的边缘响应，例如
cache-control、age、via、x-cache等字段，用于判断命中、回源或绕过。 - 同一时刻的源站直连响应头，作为对照，确认源站返回的缓存指令是否与边缘行为一致。
- 请求时间、URL、请求方法、客户端地区或节点标识（若可获得），用于判断是个别节点还是多个节点。
- 边缘返回的错误页或错误码原文，不要只截取浏览器渲染后的画面。
这些证据的共同作用是建立时间线：边缘异常发生时，源站是否仍在正常响应。如果源站响应头与边缘响应头对同一资源的缓存策略不一致，下一步应优先核对边缘缓存规则，而不是直接改源站代码。
一个反例：源站正常也可能被误判为边缘异常
假设源站直连返回 200，边缘返回 502。若只看到这两个结果，容易直接归因于边缘节点故障。但存在另一种合理解释：源站对边缘回源请求做了限制，例如只允许特定回源 IP 或特定 Host 头，导致边缘回源被拒，而人工直连时使用了被允许的路径。此时边缘 502 是回源失败的结果，不是边缘节点自身异常。
要排除这个反例，需要保留边缘回源请求的源站侧访问记录，或至少保留边缘响应中与回源相关的错误信息。如果拿不到源站日志，可以做一个最小动作：用与边缘相同的 Host 头和请求路径，从一台非源站机器发起请求，观察源站是否返回相同错误。若结果不同，说明回源条件存在差异，结论应改为“回源链路异常”，而非“边缘节点异常”。
缺少权限时仍可执行的最小动作
没有边缘日志、没有源站日志、也没有节点控制台权限时，仍可执行以下动作，并明确其能推出与不能推出的结论：
- 连续多次请求同一 URL，记录每次的状态码、响应头和响应体摘要。若多次结果不一致，说明问题可能与缓存命中状态或节点选择有关；若始终一致，不能据此排除偶发节点故障。
- 更换请求路径或查询参数，观察边缘是否回源。若带随机参数时正常、不带参数时异常，说明缓存键或缓存规则可能参与其中；但这只是相关性，不能单独证明缓存规则是根因。
- 检查响应头中是否出现边缘节点标识或缓存状态字段。若字段显示命中且内容陈旧，下一步应申请清除该 URL 的边缘缓存并再次观察；若清除后恢复，只能说明该次异常与缓存内容有关，不能推断所有节点都已恢复。
- 记录异常发生和恢复的时间点。若恢复时间与缓存过期时间吻合，可作为缓存层问题的辅助证据；若恢复时间与任何已知操作都不吻合，则不能把恢复归因于某次操作。
哪些证据不能单独证明边缘节点异常
请求量或抓取量归零、某个统计面板显示异常、单个用户报告访问失败，都不能单独证明边缘节点异常。请求量下降还可能来自客户端网络、DNS 解析、源站限流或统计口径变化；单个用户报告还可能受本地缓存或代理影响。要支撑“边缘节点异常”的判断，至少需要同一 URL 在边缘与源站两侧的可对照响应，以及异常在时间上的可重复性。
同样，robots.txt 的抓取限制不等于可靠的索引移除，站点地图不保证收录，HTTPS 也不保证安全无漏洞或排名。这些事实在排查边缘异常时只作为背景：不要因为边缘返回了 403 或 404 就推断搜索引擎侧一定如何处理，不同搜索引擎的支持情况须分别核查。
下一步动作与判断顺序
完成证据固定后，按以下顺序推进：先确认异常是单 URL、单目录还是全站；再确认边缘响应头是否显示缓存命中；然后核对源站对回源请求的响应是否与直连一致。若证据显示边缘缓存命中且内容陈旧，下一步是清除该 URL 缓存并观察同一 URL 的响应头变化；若证据显示边缘未命中且回源失败，下一步是核对回源 Host、回源 IP 限制和源站访问日志。若以上都无法获取，则只能把结论限制为“边缘侧异常现象已记录，根因待定”，并保留时间戳和响应头原文，供后续有权限时继续核对。
