页面加载速度优化：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /0ef880ccd89e.html
📄
页面加载速度优化：源站正常而边缘节点异常时应保留哪些证据
先把“源站正常”拆成两层：源站直接响应正常，和源站对边缘节点的回源响应正常。这两层只要有一层没验证，就不能把问题归到边缘。真正该保留的证据，是能同时证明源站侧无异常、边缘侧有异常、且异常可复现的那一组材料。
先分清两种相反解释
源站监控全绿、边缘侧用户却持续变慢，通常落在两种解释上。第一种是边缘节点自身或边缘到源站的链路有问题，源站只是没被直接打到。第二种是源站对边缘的响应已经变了，只是源站监控的采样路径没覆盖到，比如监控探针走的是直连、命中缓存或另一个出口。
两种解释对应的处理方向完全相反：前者要推动边缘侧排查节点和回源链路，后者要回到源站查回源响应、缓存策略或出口差异。证据不足时贸然改缓存或回源配置，可能把本来只影响部分节点的问题扩散到全站。
能区分两种解释的证据
核心是拿到“同一时刻、同一资源、两条路径”的对照记录。具体包括：
- 从边缘节点侧发起的请求记录：状态码、各阶段耗时、响应体大小、命中的缓存状态。
- 从源站直连发起的同一请求记录：同样的状态码与耗时字段，作为基线。
- 边缘到源站的回源请求记录：如果边缘侧能看到回源状态码和耗时，这是最关键的一条。
- 故障发生的时间戳与受影响节点标识，精确到分钟，便于和源站日志对齐。
- 用户侧可复现的请求样本：完整 URL、请求头中的关键字段、发生时刻。
如果边缘侧耗时长、回源耗时也长，而源站直连耗时正常，说明问题更可能在回源链路或源站对特定来源的响应上。如果边缘侧耗时长、回源耗时正常，则更可能是边缘节点处理或边缘到用户的链路问题。这两组对照能把解释收窄到一侧。
一个可操作的取证顺序
不要一上来就抓全量日志。先做一次最小对照：在同一分钟内，分别从边缘节点和源站直连请求同一个静态资源，记录状态码、总耗时和响应体大小。如果边缘侧返回的是缓存内容而源站直连返回的是最新内容，还要记录两者的内容差异和缓存标识。
这一步的结果会直接决定下一步。若边缘侧返回缓存且耗时正常，问题可能不在这个资源上，应换一个未命中缓存的资源再测。若边缘侧回源耗时明显高于源站直连，下一步就该保留回源请求的完整头信息和源站对该请求的响应记录，而不是继续在边缘侧加大采样。
证据里容易被忽略的两项
第一项是缓存状态。边缘节点返回的响应是否来自缓存，会改变你对“慢”的归因。命中缓存的慢和回源的慢是两回事，前者指向边缘节点本身，后者指向回源路径或源站。记录缓存状态比记录总耗时更能说明问题在哪一层。
第二项是请求头差异。源站可能对来自边缘节点的请求做了不同处理，比如根据来源 IP 段、Host 或特定头字段返回不同内容。保留边缘侧发出的完整请求头，和源站直连发出的请求头做对比，才能排除“源站对边缘的响应本来就不一样”这种情况。
假设例子：如何用对照收窄结论
假设某静态资源在边缘侧平均耗时 800 毫秒，源站直连平均 120 毫秒；边缘侧回源请求耗时 700 毫秒，状态码正常。这组数据指向回源链路或源站对边缘来源的响应，而不是边缘节点到用户的链路。此时应保留回源请求的完整记录和源站对应时段的访问日志，下一步去核对源站是否对边缘来源做了限速、分流或不同的缓存策略。
反过来，若边缘侧总耗时 800 毫秒、回源仅 100 毫秒，则问题更可能在边缘节点处理或边缘到用户的传输上，保留节点标识和边缘侧处理阶段的耗时记录，下一步推动边缘侧排查该节点。两种情况下要保留的证据不同，先做对照再决定抓什么，比一次性抓全量更有效。
保留证据时的边界
证据只能说明“发生了什么”，不能单独证明“为什么”。边缘侧耗时归零或某节点请求量骤降，也可能只是采样点变更、缓存命中变化或流量调度调整，不能直接当作问题已修复的结论。保留原始记录、标注采集方式和时间，比给出一个结论更有用。等对照数据齐了，再判断该改边缘配置还是回源策略。
