500错误常因rewrite规则无条件循环或变量异常引发，需检查匹配范围、last/break使用、变量有效性，并优先用return实现跳转以避免循环。
500 错误由 rewrite 规则写错引发时，核心问题不是“跳转失败”，而是重写逻辑失控导致内部处理循环或变量异常，最终触发 Nginx 的保护机制（如 rewrite 超限、空变量引用等）而返回 500。排查需聚焦规则行为、匹配范围和执行流程，而非仅看状态码。
检查 rewrite 是否无条件反复触发
这是最常见原因：规则没有判断前提，每次请求都执行，且重写后的新 URI 又能再次命中同一 location，形成闭环。
- 例如：
location /old/ { rewrite ^/old/(.*)$ /new/$1 last; }—— 若/new/xxx仍被该location /old/匹配（比如用了前缀匹配且未加^~），就会无限重入 - 验证方法：用
curl -I http://host/old/test查看响应头是否含Location（说明是 301/302 外部跳转）；若没跳转但返回 500，大概率是内部 rewrite 循环 - 临时加日志辅助判断：
rewrite_log on;（需编译时启用 debug 日志），再查error.log中 rewrite 的逐次执行轨迹
确认 last 和 break 的使用是否符合意图
last 会终止当前 location，用新 URI 重新匹配 location；break 则留在当前 location 继续执行后续指令（如 proxy_pass 或 try_files）。用错会导致路径错乱或循环。
- 做内部路径改写（不对外跳转）时，应优先用
break，而不是last - 若必须用
last，确保目标 URI 不会再次落入当前 location 的匹配范围——可改用更精确的 location 类型，如location ^~ /old/或location ~ ^/old/ - 避免在正则 location 中嵌套无条件
rewrite ... last，极易失控
排查变量引用和语法错误
rewrite 中引用未定义变量、空值变量或拼错变量名（如 $arg_id 写成 $args_id），Nginx 在解析阶段可能不报错，但在运行时因取值为空或非法，触发内部异常，返回 500。
- 检查所有
$xxx变量是否真实存在且有值，尤其$request_uri、$args、$query_string等易受编码影响的变量 - 避免在 rewrite 中直接拼接未校验的用户输入变量，如
rewrite ^/user/(.*)$ /api/user/$1?token=$arg_token last;—— 若$arg_token为空，可能导致后端路由异常 - 用
nginx -t只能检测语法，不能发现运行时变量问题；需结合 error.log 中类似zero length regex pattern或invalid number of arguments in rewrite的提示定位
用 return 替代 rewrite 实现简单跳转
如果目的只是 301/302 重定向（如旧链接迁移），return 比 rewrite ... last 更安全、更明确，且不参与 location 重匹配，彻底规避循环风险。
- 正确写法：
location = /old/path { return 301 https://example.com/new/path; } - 支持变量：
location /old/ { return 301 /new/$1; }（配合正则 location 使用） -
return是立即响应，不进入 rewrite 流程，也不触发 location 重匹配，逻辑清晰、开销低、不易出错
