应将 rewrite 限定在具体 location 块中，避免 server 级滥用；简单跳转优先用 return；慎用 if + rewrite，改用 map 或 try_files；务必验证重定向链与响应头。
避免在 server 块中滥用全局重写，核心是控制作用范围、明确触发条件、减少隐式行为。rewrite 指令若不加约束地放在 server 级别（即 location 外），会无差别匹配所有请求 URI，容易引发意外跳转、循环重定向或覆盖预期逻辑。
把 rewrite 放进具体的 location 块里
绝大多数重写需求都有明确路径前缀（如 /old/、/api/v1/），应限定在对应 location 中处理：
- location /old/ { rewrite ^/old/(.*)$ /new/$1 permanent; }
- location = / { return 301 https://$host/?SSO=1; } —— 根路径跳转用 return 更清晰
- 避免写成：server { rewrite ^/old/ /new/ permanent; } —— 这会匹配所有以 /old/ 开头的请求，包括 /old-api/、/old-admin/ 等非目标路径
优先用 return 替代简单重定向
当目标只是状态码 + 固定跳转地址（如 HTTP→HTTPS、根路径加参数），return 比 rewrite 更轻量、更安全：
- return 301 https://$host$request_uri; —— 语义明确，不走正则引擎，无匹配歧义
- return 404; 或 return 403; —— 直接终止，不触发后续 rewrite 或 location 匹配
- rewrite 在需要捕获路径片段并重组时才必要，比如 /user/123 → /profile?id=123
慎用 if + rewrite，改用 map 或 try_files
if 在 server 或 location 中嵌套 rewrite 是高危操作，易导致重复执行、变量未初始化或逻辑错乱：
- 不要写：if ($args !~ "SSO=1") { rewrite ^(.*)$ $1?SSO=1? permanent; }
- 推荐用 map 预定义变量：map $arg_SSO $need_sso { "" "1"; default ""; }，再配合 if ($need_sso) { return 301 ...; }
- 静态资源重写可用 try_files：try_files $uri $uri/ /index.php?$args;
始终验证重定向链与响应头
配置后必须确认实际返回行为是否符合预期，尤其注意 Location 头是否含内网端口或错误域名：
- 用 curl -I http://example.com/test 跟踪跳转，检查 Location 是否干净
- 清除浏览器缓存再测 —— 301 会被强缓存，旧规则可能长期生效
- 查看 error.log 是否有 “rewrite or internal redirection cycle” 报错，说明规则自循环
