Nginx rewrite 的核心是精准匹配、安全跳转与容错兜底，需按路径类型差异化处理：静态资源直接放行，API 请求避免干扰，仅对纯页面路径重写；推荐 location + rewrite + try_files 三层协同，并规避循环重写、query string 丢失、flag 误用等高危陷阱。
在 Nginx 中，rewrite 不是简单替换路径的“快捷键”，而是请求路由控制的关键环节。真正有效的高级用法，核心在于**精准匹配 + 安全跳转 + 容错兜底**，而不是堆砌正则。
按路径类型做差异化重写
不能对所有请求一视同仁。静态资源、API 接口、前端页面逻辑完全不同，重写策略必须区分：
- 静态文件（.js/.css/.png/.woff2等）应直接放行，避免重写后 404；可用
if ($request_uri ~* "\.(js|css|png|jpg|gif|ico|svg|woff2?)$") { break; } - API 请求（如以 /api/、/v1/ 开头）通常由后端服务直供，不应被前端迁移规则干扰；可用
if ($request_uri ~* "^/(api|v1|health)/") { break; } - 仅对剩余的纯页面路径（如
/about、/product/123）执行重写，确保语义清晰、影响可控
用 location + rewrite + try_files 构建安全链
单条 rewrite 指令极易失控。生产环境推荐三层协同：
-
第一层：location 精确圈定范围，例如
location / { ... }或更细粒度的location ^~ /old/ { ... }，避免正则 location 的优先级干扰 -
第二层：rewrite 做内部路径转换，如
rewrite ^/(.*)$ /new/$1 break;，注意用break防止二次匹配（尤其搭配proxy_pass时） -
第三层：try_files 提供 fallback，在目标 location 中配置
try_files $uri $uri/ /new/index.html;，保障 SPA 路由不崩，也避免因文件缺失导致 404
规避常见高危陷阱
这些细节看似微小，却常引发线上故障：
-
循环重写：比如
rewrite ^/(.*) /new/$1 last;放在根 location，当请求已是/new/xxx，仍会再次匹配并重写为/new/new/xxx；应加前缀排除：rewrite ^/(?!new/)(.*)$ /new/$1 break; -
查询参数丢失或错乱：rewrite 默认保留 query string，但若 replacement 以
http://开头，则变成 302 重定向，浏览器地址栏暴露新路径且可能触发 CORS；内部跳转请勿加协议头 -
flag 误用：
last触发新一轮 location 匹配，适合需要重新路由的场景；break终止当前块内后续 rewrite，适合代理前路径整理；redirect和permanent是 HTTP 重定向，会改变用户可见 URL
适配典型业务场景的写法
不同目标对应不同结构，不是套模板：
-
SPA 全量接管：只重写非静态、非 API 路径，全部指向
/new/index.html，靠前端 router 处理；配合try_files实现无刷新路由 -
版本路径迁移（如 / → /v2/）：用否定前瞻
^(?!v2/)排除目标路径，避免嵌套；rewrite 后接break，再走proxy_pass -
域名级跳转：replacement 必须含协议和域名，如
http://new.com$request_uri，flag 用permanent表达 301 意图
