速读摘要：接入 WAF 确实会增加几毫秒到几十毫秒的延迟，主要来自规则检测和回源多一跳。但由于 WAF 节点有就近接入和边缘缓存能力，综合下来多数站点的访问速度反而不降反升。本文拆解延迟构成，并给出实测和优化方法。
一、延迟从哪来
接入 WAF 后，请求链路从”用户 → 源站”变成了”用户 → WAF 节点 → 源站”。多出来的这一跳，就是延迟增加的直接来源。
但注意：这一跳不是”白增加”的，它还带来了就近接入和缓存加速。所以最终效果要看两方面抵消后的净值。
二、延迟的构成拆解
| 环节 | 说明 | 典型耗时 |
|---|---|---|
| DNS 解析 | 解析到 WAF 节点 | 0-50ms（有缓存可忽略） |
| TCP 握手 | 与 WAF 建立连接 | 1×RTT |
| TLS 握手 | HTTPS 加解密协商 | 1-2×RTT |
| 规则检测 | WAF 执行防护规则 | 5-30ms |
| 回源请求 | WAF 到源站 | 取决于两者距离 |
| 源站处理 | 业务逻辑执行 | 取决于业务 |
三、为什么可能反而更快
3.1 就近接入
用户访问的是离他最近的 WAF 节点，而不是你机房所在地。对于跨地域、跨运营商的用户，这一点带来的收益远超多一跳的损耗。
举例：
源站在北京，用户在广州
直连：广州 → 北京，跨区延迟 ~40ms
接 WAF：广州 → 广州节点(WAF) → 北京源站
前段 ~5ms + 节点回源 ~40ms
但节点与源站之间通常走优质线路，
实际总延迟往往仍低于普通跨区直连3.2 边缘缓存
静态资源（js/css/图片）可以在 WAF/CDN 节点直接返回，根本不回源。这部分请求的延迟几乎为零。
3.3 连接复用
WAF 节点与源站之间通常保持长连接，省掉了每次请求重新握手的时间。
四、实测方法
# 测试接入 WAF 前后的响应时间
# 方法 1：curl 计时
curl -s -o /dev/null -w "总耗时: %{time_total}s\n连接: %{time_connect}s\n首字节: %{time_starttransfer}s\n" \
https://你的域名/
# 方法 2：多次测速取平均（更准确）
for i in {1..10}; do
curl -s -o /dev/null -w "%{time_total}\n" https://你的域名/
done | awk '{sum+=$1} END {print "平均:", sum/NR, "秒"}'
# 方法 3：对比回源直连（需源站可达）
# 若直连与经 WAF 的差距 < 50ms，属于正常范围五、优化延迟的手段
| 手段 | 效果 | 实施难度 |
|---|---|---|
| 精简防护规则 | 减少检测耗时 | 低 |
| 静态资源走 CDN | 避免经过 WAF 检测 | 低 |
| 开启 HTTP/2 或 HTTP/3 | 多路复用，减少握手 | 低 |
| 开启 TLS 会话复用 | 减少握手开销 | 低 |
| 避免复杂正则规则 | 降低单请求检测成本 | 中 |
| 选择多节点厂商 | 就近接入收益更大 | 取决于厂商 |
| 源站与节点同区域 | 缩短回源距离 | 中 |
六、合理的延迟预期
| 场景 | 合理增加范围 |
|---|---|
| 同城访问（源站与用户同城） | +10 到 +30ms |
| 跨省访问 | -50 到 +10ms（可能变快） |
| 跨境访问 | -200 到 -50ms（就近接入收益大） |
| 静态资源（命中缓存） | 几乎无影响 |
| 动态接口 | +20 到 +50ms |
如果实测延迟增加超过 100ms，就需要排查：是不是规则太多、回源线路差、或者节点距离太远。
七、场景对比示例
场景：内容站，源站在北京
未接 WAF：
北京用户：120ms
广州用户：260ms
成都用户：290ms
平均：223ms
接入 WAF（多节点）：
北京用户：135ms（+15ms）
广州用户：150ms（-110ms）✅
成都用户：170ms（-120ms）✅
平均：152ms（整体更快）✅
结论：多地域用户时，WAF 往往能提升整体速度。八、小结
WAF 会增加”规则检测”和”回源一跳”的延迟，但也带来”就近接入”和”边缘缓存”的收益。对于多地域访问的站点，整体速度往往不降反升。优化重点是把静态资源交给 CDN、精简规则、开启 HTTP/2 和会话复用。若延迟增加超过 100ms，就要认真排查原因。
