应通过 wrk + perf 实测 rewrite 在高频爬虫下的真实 CPU 开销，重点分析正则匹配、变量展开、重定向跳转三部分；用 map 替代 if、前缀 location 快速终止、limit_req 限流，并禁用 rewrite_log 避免日志瓶颈。
直接测试 rewrite 规则对 CPU 的影响，不能只看规则本身是否“简单”，而要看它在真实高频爬虫请求场景下的实际执行开销——尤其是正则匹配、变量展开、重定向跳转等环节。Nginx 的 rewrite 是在 location 匹配后、内容处理前执行的，属于请求处理早期阶段，频繁触发确实会抬高 CPU 使用率，尤其当正则复杂或嵌套多层时。
用 ab 或 wrk 模拟爬虫高频请求，结合 perf 定位 rewrite 热点
单纯看 top 或 htop 只能看到 nginx worker 进程整体 CPU 占用，无法区分是 rewrite、proxy_pass 还是日志写入导致的。推荐用 Linux perf 工具采样：
- 先启用带 debug 日志的 Nginx（编译时加
--with-debug，或使用官方 debug 包），并在配置中临时开启error_log /var/log/nginx/debug.log debug; - 用
wrk -t4 -c100 -d30s http://your-site/模拟爬虫并发请求（注意 URL 要命中含 rewrite 的 location） - 同时运行
perf record -g -p $(pgrep nginx | head -1) -F 99，持续 20 秒左右 - 执行
perf report --no-children，重点关注ngx_http_rewrite_handler、ngx_regex_exec、ngx_http_script_flush_complex_value等函数的占比
把 rewrite 规则拆解为可测量的子步骤：正则 vs 变量 vs 跳转
rewrite 开销主要来自三部分，需分别验证：
-
纯正则匹配：如
rewrite ^/old/(.*)$ /new/$1 permanent;。可用nginx -t不会报错，但不代表快——复杂正则（尤其带回溯的，如.*.*或未锚定的^.*\.js$）在大量请求下极易引发 ReDoS -
变量展开与计算：如
set $flag "1"; if ($arg_x = "a") { set $flag "2"; } rewrite ^(.*)$ /api?flag=$flag last;。每次请求都会执行变量赋值和条件判断，比无 if 的 rewrite 多约 15%–30% CPU 时间（实测常见于 Tengine 2.3.3 / Nginx 1.20） -
重定向响应生成：用
redirect或permanent会强制构造 301/302 响应头，比last或break多出 header 构建和字符串拼接开销，对高频爬虫尤为明显
用 map 替代 if + rewrite，降低条件判断开销
Nginx 官方明确建议避免在 location 中使用 if，因其会在每次请求时重新解析条件表达式。高频爬虫场景下，更高效的做法是用 map 预计算：
map $arg_user_agent $should_block {
~*(python-requests|Go-http-client|masscan) 1;
~*Baiduspider 0;
default 0;
}
server {
location / {
if ($should_block) { return 403; }
# → 改为：
# try_files $uri @block;
}
}实际上，map 在配置加载时就完成编译，运行时只是 O(1) 查表，比每次执行 if 正则快 3–5 倍。配合 try_files 或 error_page，可完全规避 rewrite 的条件分支开销。
开启 rewrite_log 并限流，避免日志本身成为瓶颈
调试时开启 rewrite_log on; 很有用，但生产环境绝对禁用——每条 rewrite 日志都会触发一次 glibc strftime() 和磁盘 I/O，在万级 QPS 下可能让 CPU 花费 20%+ 在日志格式化上。替代方案：
- 用
log_subrequest on;+ 自定义 log_format 记录 $request_length、$request_time、$upstream_response_time，间接反映 rewrite 是否拖慢了请求链路 - 对疑似恶意 UA 的 IP 段，优先用
limit_req限速（如limit_req zone=spider burst=5 nodelay;），从源头减少 rewrite 执行次数 - 将 rewrite 规则按优先级分组，用
location ^~ /api/等前缀匹配快速终止，避免进入正则 location
不复杂但容易忽略：rewrite 的性能损耗不是线性的，而是随请求特征陡增——一个看似简单的 rewrite ^/(\d+)/?$ /item?id=$1 last;，在爬虫故意构造 /12345678901234567890/ 这类超长数字路径时，正则引擎可能因回溯爆炸导致单请求耗尽一个 worker 线程。所以压测时务必混入边界路径样本。
