nginx rewrite优化核心是提升匹配精度与效率：精简正则、锚定边界、优先字面量匹配；用location =和return替代冗余rewrite；避免last引发的location重匹配与循环；慎用if，多用map预编译分流。
Nginx rewrite 规则本身开销不大，但写法不当会显著拖慢请求处理——尤其在高并发下，正则匹配、重复重定向、嵌套 location 匹配都可能成为瓶颈。优化核心不是“少用 rewrite”，而是让每次匹配更准、更短、更可控。
精简正则表达式，避免贪婪匹配
过度使用 .* 或未锚定的模式（如 /api/.*）会让 PCRE 引擎反复回溯，大幅增加 CPU 消耗。应始终用 ^ 和 $ 明确边界，优先使用字面量前缀匹配。
- ❌ 避免：
rewrite /api/(.*)$ /v1/$1 last;（.*可能匹配过长路径，触发回溯） - ✅ 推荐：
rewrite ^/api/([0-9]+)/?$ /v1/$1? permanent;（限定数字、可选结尾斜杠，无歧义） - 用
location = /exact-path替代正则匹配固定路径，性能接近零开销
用 return 替代简单重定向
当只需返回 301/302 时，return 指令比 rewrite 快 3–5 倍——它不触发正则引擎，也不参与 location 重匹配，直接生成响应。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- ❌ 不必要 rewrite：
rewrite ^/old.html$ /new.html permanent; - ✅ 更优写法：
location = /old.html { return 301 /new.html; } - 批量跳转可结合 map 指令预编译映射表，避免每个请求都走正则
规避 location 级联与循环重写
rewrite + last 会触发 URI 重匹配 location，若规则设计不当（比如 /api ⇄ /v1 相互 rewrite），不仅引发 500/503，还会放大 CPU 和上下文切换开销。
- 检查所有
last规则是否最终落入无 rewrite 的 location 块中 - 禁用不必要的嵌套：把跨 location 的逻辑收敛到单个 location 内，用 if（慎用）或 map 处理分支
- 上线前用
nginx -t+ 日志rewrite_log on;（仅调试）验证执行路径是否收敛
减少 if 判断和运行时条件
if 指令在每个请求中都会求值，且内部隐含正则匹配（如 $http_user_agent ~* "bot"），是常见性能雷区。
- 静态分流尽量用
map：提前构建键值映射，O(1) 查找 - 非必要不判断请求方法、头字段；POST 路由可通过 location 前缀区分（如
location /api/v1/post/） - 真需条件逻辑，优先用
try_files或error_page替代 if + rewrite 组合
