抓取诊断下载耗时 1.2 秒 源站只用了 80ms

记录一下那天晚上的排查过程。百度抓取诊断里平均下载耗时 1.2 秒，源站 access_log 记录的 request_time 只有 80ms。中间的 CDN 与 WAF 各加了一层处理，缓存未命中时还要回源一次探测。

刚开始盯着「回源用的协议是 HTTP/1.1，串行握手把延迟放大了」，折腾了半个多小时，排掉了。

这类报错背后常见的原因有几处，逐个排除就行。WAF 对每个请求做了一次同步的规则匹配，耗时没有记在源站日志里。还有一种是CDN 缓存未命中时先发探测请求再回源，等于两次往返。

不容易想到的是，WAF 对每个请求都要回源查一次 IP 信誉 超时后直接放行兜底。

先对比边缘与源站的耗时头

curl -sI https://www.example.com/ | grep -iE 'server-timing|x-cache|age'

给回源开启长连接与 HTTP/2

proxy_http_version 1.1; proxy_set_header Connection "";

再往下把 WAF 的静态规则改为异步日志模式

modsecurity_rules 'SecRuleEngine DetectionOnly';

复测下载耗时曲线

for i in 1 2 3; do curl -s -o /dev/null -w '%{time_total}\n' https://www.example.com/; done

怎么算真的好了，看的是同一批现象。开启长连接并调整 WAF 模式后，边缘侧统计的下载耗时降到 220ms，抓取诊断里的曲线和源站日志基本对齐。

容易忽略的是，源站日志只覆盖到应用层，中间每一跳都要单独看耗时，光比对 request_time 会得出完全错误的结论。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。