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

重庆虚拟主机：源站正常而边缘节点异常时应保留哪些证据

当源站响应正常、但边缘节点返回错误或旧内容时，先别急着改配置或换主机。应保留三类证据：源站直连的响应记录、边缘节点返回的完整响应头与状态码、以及两者在同一时间窗口内的对比样本。这些证据能帮你判断是缓存层、回源链路还是节点本身的问题，也决定接下来该保留现状、改写规则还是退出当前节点。

为什么源站正常不能证明边缘链路正常

源站正常只说明后端应用和数据库这一层能返回正确内容。边缘节点是另一段独立链路，它可能缓存了旧版本、回源时走了不同线路、或者节点上的配置与应用预期不一致。两者是不同环节，一个正常不能推出另一个正常。

判断的关键是区分“内容错误”和“链路错误”。如果边缘返回的是旧页面，多半是缓存问题；如果返回 5xx 或连接中断，而源站直连正常，则更可能是回源或节点故障。这个区分决定了你该保留缓存证据还是链路证据。

必须保留的源站侧证据

源站侧证据的作用是证明“后端此刻能给出正确结果”，它是后续对比的基准。

• 源站直连的完整响应头，包含状态码、Date、Last-Modified、ETag、Cache-Control。
• 请求时的准确时间戳，精确到分钟，便于和边缘记录对齐。
• 同一 URL 的响应正文摘要，用哈希或前若干字符即可，不必存整页。
• 源站访问日志中对应时间段的条目，确认请求是否真的到达了后端。

保留这些字段的原因是可复查：当边缘节点返回的 Last-Modified 或 ETag 与源站不一致时，就能定位到缓存副本与源站版本脱节，而不是笼统地说“内容不对”。

必须保留的边缘侧证据

边缘侧证据要能回答“节点到底返回了什么、它认为自己在做什么”。

• 边缘返回的完整响应头，重点看状态码、Age、Via、X-Cache 一类缓存标记，以及 Server。
• 响应正文与源站版本的差异对比，指出具体是旧内容、错误页还是空白。
• 出现异常时的节点标识或接入点信息，便于确认是个别节点还是普遍现象。
• 多次请求的结果，区分稳定复现和偶发。

Age 较大且内容偏旧，通常指向缓存未及时更新；状态码为 5xx 且没有缓存标记，则更可能指向回源失败。这两类证据导向的处理动作不同。

用时间对齐把两组证据连起来

单独看源站记录或边缘记录都不够，必须做时间对齐。做法是：在相近时间点分别请求源站直连地址和边缘地址，记录两次请求的时间戳与响应头，然后逐字段比对。

假设一个场景：源站在 10:00 返回 200 且 ETag 为 A，边缘在 10:01 返回 200 但 ETag 为 B 且 Age 为 3600。这种组合说明边缘持有一份较旧的缓存副本，而源站已经更新。此时应保留缓存规则相关的证据，而不是去排查源站应用。反过来，如果边缘返回 502 而源站直连正常，Age 字段缺失，证据就指向回源链路中断，此时保留节点与回源配置信息更有价值。

这个对比方法的价值在于，它把“哪个环节出错”从猜测变成可验证。数字只是示例，实际以你自己的记录为准。

证据如何影响保留、改写还是退出

证据齐了之后，决策取决于异常的性质。

1. 保留现状：如果异常只在个别节点偶发、源站与边缘版本一致，且短时间内自行恢复，保留证据并继续观察是合理的。此时贸然改配置可能引入新变量。
2. 改写规则：如果证据显示是缓存过期策略或回源头设置导致的版本脱节，且源站始终正常，那么调整缓存与回源规则比更换主机更对症。改写前先备份原规则，便于回退。
3. 退出当前节点：如果多个节点持续返回错误、回源链路反复中断，而源站证据一直正常，说明问题在边缘侧且不受你控制，此时考虑切换节点或服务方才有意义。

一个实际动作是：先把上面两类响应头按时间对齐存成一份对比记录，再根据差异字段决定下一步。如果差异集中在缓存标记，就先查缓存规则；如果差异集中在状态码和连接，就先查回源链路。这个动作的结果直接决定你是改规则还是换节点，避免在错误方向上反复调整。