企业级Nginx URL重写与跳转是围绕可控性、可追溯、零循环、低开销构建的闭环机制，需严格遵循匹配—替换—执行逻辑，优先用return/try_files/proxy_pass替代易错的rewrite，规避500/301循环等线上事故。
企业级 Nginx URL 重写与跳转不是“加几行 rewrite 就完事”，而是围绕可控性、可追溯、零循环、低开销构建的一套闭环机制。它既要满足业务迁移、SEO 权重继承、HTTPS 强制等刚性需求，又要规避配置错位、正则失控、flag 误用导致的 500/301 循环/404 泛滥等线上事故。
核心原则：rewrite 不是万能胶，而是精密阀门
rewrite 指令本质是 URI 处理流水线上的一个环节，必须嵌入明确上下文（server 或 location），且严格遵循“匹配—替换—执行”三层逻辑：
- 匹配必须用 PCRE 正则，
/old这类裸字符串会误匹配所有含/old的路径；应写为^/old$（精确匹配）或^/old/(.*)$（带捕获） - 替换目标支持相对路径（
/new/$1）、绝对路径（/app/index.html）、完整 URL（https://$host/new$1）；一旦含协议头，Nginx 自动触发 301/302，无需显式 flag - flag 决定后续流程：
permanent（301）、redirect（302）、break（终止本 location 内 rewrite，继续执行 proxy_pass/root）、last（重试 location 匹配）
关键避坑：90% 的线上问题出在位置与 flag 错配
rewrite 放错块、选错 flag，轻则跳转失效，重则请求陷入死循环：
-
强制 HTTPS 必须用 return，禁用 if + rewrite：在
server { listen 80; }块中直接写return 301 https://$host$request_uri;；避免if ($scheme = http) { rewrite ... permanent; }—— if 在 server 级使用有隐式限制，且效率低、易出错 -
location 内 rewrite 优先用 break，慎用 last：例如
location /img/ { rewrite ^/img/(.*)$ /static/$1 break; root /var/www; }；若用last，重写后会跳出当前 location 重新匹配，可能进错规则甚至触发无限循环 -
禁止在 if 块外、或 HTTP server 块中配 HSTS：Strict-Transport-Security 只在 HTTPS 响应中生效；HTTP 块里加
add_header完全无效，还可能干扰调试
生产就绪：跳转链必须可验证、可审计、可降级
上线前需闭环验证三件事，缺一不可：
-
跳转状态码与目标地址：用
curl -I http://example.com/old-path确认返回 301，Location头指向预期 HTTPS 地址；对 HTTPS 请求，再用curl -I https://example.com/old-path验证是否 200 或正确内部重写 -
正则覆盖边界场景：测试
/old、/old/、/old-page、/old?x=1等变体，确认仅命中预期路径；建议用rewrite_log on;+error_log /path/to/error.log notice;开启调试日志定位匹配失败原因 -
证书与响应头完整性：HSTS 生效前提包括——全站 HTTPS 稳定运行、证书链完整（
openssl s_client -connect example.com:443 | openssl x509 -noout -text查CA Issuers）、HTTPS server 块中启用add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
替代方案优先级：能不用 rewrite，就不硬上
rewrite 是强大但易错的工具，高可用场景应优先选用更健壮的原生指令：
-
简单跳转首选 return：如域名归一、HTTPS 强制、维护页跳转，
return 301 https://new.com$request_uri;比rewrite更快、更安全、无正则开销 -
前端单页应用（SPA）用 try_files：Vue/React 路由需将所有非静态资源请求兜底到
index.html，try_files $uri $uri/ /index.html;比rewrite ^(.*)$ /index.html break;更清晰、无循环风险 -
服务拆分/代理路由首选 location + proxy_pass：把
/api/v1/映射到后端集群，直接location /api/v1/ { proxy_pass https://backend; }，比用 rewrite 中转更高效、更易监控
