Nginx location重写规则是实现旧URL平滑迁移最直接高效的方式：精准定位旧路径（优先^~或=），用rewrite转换路径，配合permanent/redirect等flag控制跳转，避免循环与遗漏。
在 Nginx 的 location 块中配置重写规则，是实现旧版 URL 平滑迁移最直接、高效的方式。核心在于：用精准的 location 定位旧路径范围，再通过 rewrite 指令完成路径转换，配合合适的 flag 控制跳转行为，全程不依赖后端，兼顾 SEO 和用户体验。
明确匹配范围，优先使用 ^~ 或 = 精准定位
避免正则干扰和优先级混乱，应根据旧 URL 特征选择匹配方式：
- 若旧链接有固定前缀（如
/old/），用location ^~ /old/ { ... }——^~表示前缀匹配且优先于正则，性能好、意图清晰； - 若某条高频旧链接完全确定（如
/old/about.html），单独写location = /old/about.html { rewrite ... permanent; }，确保零误伤； - 避免在通用
location / { ... }中堆砌 rewrite，容易被其他规则覆盖或引发冲突。
编写 rewrite 规则，注意捕获、参数与结尾问号
rewrite 的正则要严格对应 URI（不含查询参数），替换时合理引用变量：
- 捕获路径片段：如旧链接
/old/2020/05/post-abc.html→ 新链接/blog/abc，写为rewrite ^/old/\d{4}/\d{2}/post-(.+)\.html$ /blog/$1 permanent;； - 提取查询参数：如
/product.php?id=123→/products/123，可用$arg_id直接获取参数值，写为rewrite ^/product\.php$ /products/$arg_id? permanent;（末尾?表示清空原参数，防止拼接）； - 保留参数时省略
?，Nginx 会自动追加原 query string。
选对 flag，区分内部跳转与浏览器重定向
flag 决定用户是否看到地址变化，也影响后续 location 匹配逻辑：
- 对外迁移必须用
permanent（301）或redirect（302）——搜索引擎和浏览器会更新记录； -
last和break是内部重写，地址栏不变，适用于后端路径映射（如静态资源别名），不适用于用户可见的 URL 迁移； - 切勿混用
permanent和last，二者语义冲突：一个发 HTTP 跳转响应，一个停止重写流程并重新匹配 location。
防错与验证，避免循环和漏匹配
上线前务必检查两类典型问题：
- 循环重定向：确保新路径不被同一 location 规则再次匹配（例如新路径也以
/old/开头）； - 覆盖遗漏：先列全旧 URL 模式，按频率从高到低、从具体到泛化排列规则，高频精确匹配放前面，兜底泛匹配放后面；
- 快速验证：用
curl -I https://example.com/old/article?id=123查看Location响应头；也可临时改用return 200 "to: /news/123";辅助调试 rewrite 结果。
