网站加载速度：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /80cfc1a2f730.html
📄
网站加载速度：源站正常而边缘节点异常时应保留哪些证据
先给出结论：当源站响应时间稳定、边缘节点却出现高延迟或错误率上升时，最该保留的是能证明“差异发生在边缘层”的对照证据，而不是单点的速度截图。具体包括同一URL在源站直连与经边缘两条路径下的响应头、时间分段、错误码分布，以及边缘节点标识。保留这些证据后，你才能决定是继续观察、改写缓存与回源策略，还是临时把流量切回源站。缺少完整日志权限时，至少也要留下带时间戳的双路径对比记录，否则后续无法区分是边缘故障、局部网络抖动，还是源站某一类请求变慢。
为什么单看源站正常不足以排除边缘问题
源站正常通常只说明应用和数据库这一层没有整体崩溃，但边缘节点是独立的一层：它有自己的缓存、回源连接池、TLS终止和路由。边缘节点异常时，源站可能因为收到的请求变少而显得更“正常”。
一个常见误判是：监控面板显示源站P95延迟下降，就认为一切正常。实际上这可能是边缘节点大量返回缓存命中或直接报错，根本没有回源。因此，判断异常位置需要的是同一时间窗口内的分层对照，而不是单一层的健康指标。
如果只有源站监控而没有边缘日志，你能做的判断是有限的：可以确认源站没有整体过载，但不能推出边缘节点没有问题，也不能推出用户侧体验正常。
必须保留的四类证据及各自能证明什么
下面四类证据按优先级排列。即使权限受限，也建议至少保留前两类。
1. 双路径响应头与时间分段
对同一个URL，分别记录直连源站和经过边缘节点的响应。重点保留：
server、via、age、x-cache等能标识边缘处理的头；- DNS解析时间、TCP连接时间、TLS握手时间、首字节时间、内容下载时间；
- 请求发出时的本地时间戳和时区。
这些数据能证明差异是发生在连接建立阶段、等待首字节阶段，还是传输阶段。如果直连源站首字节时间稳定，而经边缘节点时首字节时间大幅波动，同时age为0或缺失，说明边缘很可能没有命中缓存并回源受阻。这一步的结果会直接影响下一步：若差异集中在TLS握手，应优先查边缘证书与协议配置；若集中在首字节，应优先查回源链路与缓存策略。
2. 边缘节点标识与错误码分布
保留出错请求对应的边缘节点ID或机房代码（如果响应头或日志中有）。同一URL在不同边缘节点上表现不同，说明问题不是全局性的，而是特定节点或区域。
同时记录HTTP状态码的分布：502、503、504分别指向不同的失败环节。502通常表示边缘无法从上游获得有效响应，504表示回源超时。只有状态码而没有节点标识，无法判断是单节点故障还是配置推送导致的全局问题。
需要说明的是，错误码统计归零不能单独证明处理正确，因为流量可能已经被切走或缓存全部命中，错误只是没有机会出现。
3. 缓存命中状态与回源请求记录
保留异常时间段内边缘节点的缓存命中率和回源请求量。如果命中率骤降、回源量骤升，同时源站响应时间仍正常，说明压力卡在边缘到源站这一段，而不是源站处理能力不足。
如果拿不到边缘侧的回源日志，退一步可以保留源站入口日志中来自边缘节点IP段的请求记录，观察请求频率和来源是否异常。但这只能证明源站收到了什么，不能证明边缘发出了什么。
4. 变更与配置时间线
保留异常出现前后边缘侧的任何变更记录：缓存规则、回源超时、证书、WAF规则、节点调度策略。时间线的价值在于把“异常开始时间”和“变更生效时间”对齐。如果两者接近，优先怀疑变更；如果异常早于任何变更，则应先排查节点本身或上游网络。
保留、改写还是退出：三种取舍的适用前提
证据齐备后，决策取决于异常的范围和持续时间。
- 保留现状并继续观察：适用于异常只出现在少数边缘节点、错误率低且没有扩散趋势，同时你已能定位到具体节点。此时贸然改动全局配置可能把局部问题放大。继续观察的前提是你能持续采集上述证据。
- 改写边缘策略：适用于异常与缓存或回源配置相关，例如回源超时设置过短导致504集中出现。改写前应保留一份当前配置快照，改完后用同样的双路径方法复测。注意，改写配置后错误消失，不能直接证明是配置导致的，还需要对比变更前后的节点分布。
- 临时退出边缘、切回源站：适用于异常持续扩大、影响核心页面且短时间无法定位。切回源站是止损动作，不是修复动作。执行前要确认源站容量能否承接全部流量，否则会把边缘故障变成源站故障。切回后仍需保留边缘侧证据，否则恢复边缘时无法验证问题是否解决。
这三种选择并不互斥。常见顺序是：先保留证据并观察，确认范围后改写策略，若仍无改善再临时退出。
权限或数据不足时的最小动作
如果你没有边缘日志的读取权限，也没有完整的APM数据，仍然可以执行一个最小动作：在本地或一台独立主机上，用脚本对同一URL分别做直连和经边缘的定时请求，记录响应头、状态码和分段耗时，持续一段时间。
假设某页面直连源站首字节时间稳定在200毫秒左右，经边缘节点则在200毫秒到数秒之间波动，且波动请求的响应头中age为0。这个假设例子说明的是比较方法：固定变量、对照两条路径。它能支持“边缘回源环节可疑”这个方向，但不能单独证明是哪个节点或哪条规则导致的，也不能推出所有用户都受影响。
这个动作的结果会决定下一步：如果波动集中在特定时间段，应去核对那段时间的边缘变更记录；如果波动与请求来源地域相关，应优先排查区域节点而非全局配置。
哪些结论不能从这些证据中推出
保留证据的目的是缩小范围，不是直接定罪。以下几点需要特别克制：
- 源站响应正常，不能推出边缘节点没有问题；
- 某个边缘节点错误率高，不能推出该节点所在区域的所有用户都受影响；
- 切换回源站后速度恢复，不能推出边缘节点已修复；
- 错误码或请求量归零，不能单独证明处理正确，也可能是流量被切走或缓存全部命中；
- 双路径对比中出现差异，不能排除本地网络或测试主机自身的干扰。
把证据保留到能回答“差异在哪一层、哪个节点、哪个时间段”这三个问题，再决定保留、改写还是退出，比凭单次测速结果直接改配置更稳妥。
