应直接压测改写前后的最终路径，对比端到端延迟与qps变化；若延迟差超5–10ms或qps降超15%，说明瓶颈在后端处理或磁盘读取等环节，而非rewrite本身。
直接压测改写后的最终路径，比追踪 rewrite 执行次数更有效。
用 wrk 或 ab 模拟真实请求链路
rewrite 的性能损耗不体现在“跳转次数”上，而体现在每次请求的端到端延迟和吞吐变化。重点不是数它内部重写了几次，而是看用户从发起到收到响应花了多久、QPS 能跑到多少。
- 对原始 URL（如 /old/product/123）发起压测，记录 avg latency 和 req/s
- 对 rewrite 后实际命中目标的 URL（如 /api/item?id=123 或静态文件路径）单独压测，作为基准线
- 对比两组结果：若延迟差值超过 5–10ms 或 QPS 下降超 15%，说明 rewrite 后续环节（比如后端处理、磁盘读取）成了瓶颈，而非 rewrite 本身
关掉日志和冗余模块再对比
access_log、复杂 log_format、try_files 多级 fallback 这些常比 rewrite 更吃资源。测试前先简化环境：
- 临时注释掉 access_log 指令，或设为
off - 把 try_files $uri $uri/ /index.html 暂时换成明确的 root + index，避免磁盘探测开销
- 禁用所有 if 块（尤其带正则判断的），它们在每个请求中都会执行，开销远高于 rewrite
用 nginx -T + curl -I 验证 rewrite 是否真被触发
很多所谓“多次跳转”其实是配置错误导致的循环或无效匹配。先确认规则是否按预期工作：
- 运行 nginx -T 查看最终生效的完整配置，确认 rewrite 所在 location 块没有被更高优先级的块覆盖
- 用 curl -I http://test.local/old/path 观察响应头：
— 返回 200 且地址栏不变 → 是内部重写（用的 last 或 break）
— 返回 301/302 且含 Location → 是外部重定向（用了 redirect 或 permanent） - 如果返回 500，很可能是 last 触发了 location 重匹配但没找到对应块，此时应检查 rewrite 后的 URI 是否能被某个 location 正确捕获
监控 worker 进程 CPU 和正则匹配耗时
rewrite 性能问题极少来自逻辑本身，多因低效正则拖慢解析。重点关注：
- 避免以 .* 开头的 regex（如
rewrite ^.*$ /new last;），改用更精确前缀匹配 - 用 nginx -t -v 看是否启用了 PCRE JIT（高并发下可提升正则性能）
- 观察 top 中 worker 进程 CPU 占用：若持续高于 70% 且压测 QPS 上不去，大概率是正则或后续操作（如 PHP 执行）卡住，不是 rewrite 指令的问题
