全链路压测中Nginx rewrite规则的核心是验证其在真实流量路径中的稳定性与副作用，而非单独测试性能；需通过响应头、日志、链路追踪确认生效，重点观测正则回溯、重定向放大、缓存失效等高压下暴露的问题。
在全链路压测环境中测试 Nginx rewrite 规则的执行效率，核心不是“单独测 rewrite”，而是看它在真实流量路径中是否引入可观测延迟、是否放大瓶颈、是否影响链路稳定性。rewrite 是 Nginx 请求处理阶段（phase）中较早执行的模块（位于 server_rewrite 和 location_rewrite 阶段），本身开销极小，但不当配置可能引发重定向循环、正则回溯、或干扰后续代理/缓存逻辑，从而在高压下暴露问题。
确认 rewrite 是否真正在压测链路中生效
很多团队误以为写了 rewrite 就一定起作用，其实它只对匹配到的请求生效。需先验证：
- 用
curl -I或压测工具单请求加-v参数，确认响应头中Location出现预期跳转，且状态码为 301/302； - 检查 Nginx access log 中
$status和$request_time字段，筛选出 301/302 请求，观察其平均耗时是否明显高于普通 200 请求； - 在全链路追踪（如 SkyWalking、Jaeger）中标记 rewrite 相关 span，确认它是否被纳入主调用链——若 rewrite 后发生外部跳转（如跳到另一个域名），该跳转会中断当前 trace，需额外埋点补全。
压测中重点观测 rewrite 引发的副作用
rewrite 本身不耗 CPU，但以下行为在高并发下会成为瓶颈：
-
正则表达式回溯爆炸：避免使用贪婪匹配（如
.*）、嵌套量词（如(a+)+），尤其在if ($args ~* ...)中；可用nginx -t检查语法，更推荐用map指令替代复杂 if + rewrite； - 重定向放大流量：一个客户端请求触发 302 跳转，会变成两个 HTTP 请求（原始 + 重定向后），QPS 翻倍，后端服务、网关、DNS 解析压力同步上升；压测时需对比「开启 rewrite」和「关闭 rewrite 直接访问目标路径」的后端负载差异；
-
破坏缓存与连接复用：301/302 响应默认不可缓存（除非显式加
Cache-Control），且浏览器/客户端通常不会复用跳转后的连接，导致更多 TCP 握手和 TLS 开销；可结合proxy_cache缓存跳转响应，或改用内部重写（rewrite ... last;）避免外部跳转。
用真实压测数据定位 rewrite 性能影响
不要只看 Nginx 的 QPS 或 CPU，要分层比对：
- 在相同压测脚本下，分别测试：A. 原始 URL 直接访问 vs B. 经 rewrite 跳转后的 URL，对比两组的 P95 延迟、错误率、后端服务 QPS 分布；
- 用
dstat -c --top-cpu观察压测期间 Nginx worker 进程 CPU 占用是否突增，再用perf top -p $(pgrep nginx)看热点是否落在ngx_http_script_regex_start_code（正则执行）或ngx_http_send_special（发送 3xx）； - 检查
nginx -V输出中是否启用--with-pcre-jit，开启 JIT 可显著加速复杂正则；未启用时，高并发下正则匹配可能成为 CPU 瓶颈。
