error_log 是定位 Nginx Rewrite 循环最直接、最可靠的依据，它记录“rewrite or internal redirection cycle”错误及后续 URI、权限或文件缺失等关键线索，并支持 debug 日志逐帧还原跳转链。
error_log 是定位 Nginx Rewrite 循环最直接、最可靠的依据，它不依赖外部工具或模拟请求，而是由 Nginx 自身在执行过程中主动记录的关键诊断信息。
直接暴露循环事实
当 Rewrite 规则陷入无限跳转，Nginx 会在 error_log 中明确输出：
- “rewrite or internal redirection cycle”——这是死循环的铁证，不是推测，是引擎主动终止后打出的错误信号
- 紧随其后的 “internally redirecting to "/xxx"”——指出循环卡死在哪个 URI，比如
/index.php或/api/，帮你快速锁定问题 location - 该错误默认以 crit 级别记录，即使日志级别设为 warn 或 error，这条消息依然会出现，确保不会被过滤掉
揭示真实诱因，避免误判
很多“循环”其实是假象，真正问题是文件不可访问。error_log 会同时记录底层系统错误：
- “Permission denied”：说明 Nginx 工作进程（如 www-data）对目标路径没有读或执行权限，导致 try_files 后续反复 fallback
-
“No such file or directory”：表明 root 路径配置错误，或 try_files 最后一项（如
/index.html）根本不存在，触发内部重定向兜底失败 - 这两类错误往往和循环错误相邻出现，顺序翻几行就能确认——先有访问失败，才有重试循环
配合 debug 日志还原完整跳转链
普通 error_log 只报结果，开启 debug 后可看到每一步 rewrite 如何生效：
- 日志中会出现 “rewrite phase: 3”、“rewriting "/old/path" using "^/old/(.*)$" => "/new/$1" 等逐帧记录
- 能清晰识别哪条
rewrite、if或try_files触发了重复匹配，比如last后新 URI 又落入同一 location - 推荐在特定 location 内单独启用：
error_log /var/log/nginx/rewrite-debug.log debug;，避免全局日志爆炸
辅助验证高危配置组合
查到循环 URI 后，error_log 提供上下文线索，帮你聚焦检查易出错的写法：
- 是否用了无条件
rewrite ^/(.*)$ /index.php?$1 last;，而/index.php又命中当前 location？ - 是否在
if块里用rewrite，但正则没加$锚点，导致/v1/api又被同一 if 匹配？ - 是否混用
try_files $uri $uri/ /index.html;和前端路由 fallback，却没用 named location 隔离？
不复杂但容易忽略：error_log 不是事后分析工具，而是 Nginx 执行时的“黑匣子”。只要打开它，循环问题就几乎无法隐藏。
