监控nginx重定向循环的核心是让日志清晰暴露每次内部跳转路径，需启用debug日志精准定位、用tail+grep捕获关键信号、结合curl-iv验证响应头，并通过独立access日志比对原始与最终路径。
监控 Nginx 重定向跳转循环导致的死循环，核心不是“实时告警”，而是让日志能清晰暴露每一次内部跳转路径，并快速识别出重复、递增或闭环的模式。重点不在装多少监控工具，而在让 Nginx 自己把过程“说出来”。
启用 debug 级别错误日志并精准定位位置
默认 error_log 只报一句 rewrite or internal redirection cycle while internally redirecting to "/xxx"，但看不出怎么走到这一步。必须开启 debug 日志：
- 先确认支持：运行
nginx -V 2>&1 | grep -o with-debug，有输出才可用 - 不要在 http 块全局开 debug（日志爆炸），只在可疑的 server 或 location 块中加：
error_log /var/log/nginx/loop-debug.log debug; - 确保 Nginx 工作用户（如 www-data）对日志路径有写权限
用 tail + grep 实时捕获关键线索
日志量大，需过滤真正反映循环的信号：
- 执行：
tail -f /var/log/nginx/loop-debug.log | grep -E "(internal redirection|rewritten data|matched location|rewrite phase: 3)" - 重点关注：
– 出现 internal redirection cycle（已触发保护机制）
– 连续多行 rewritten data: "/a" → "/b" → "/a"（闭环）
– 同一正则反复 matches "/index.php?path=..." 且参数越嵌越长（如 ?path=index.php?path=index.php）
– rewrite phase: 3 多次出现（说明 rewrite 阶段被反复进入）
配合 curl -Iv 验证客户端实际行为
日志告诉你 Nginx 内部做了什么，curl 告诉你浏览器看到什么，两者必须一致才能闭环：
- 执行：
curl -Iv https://example.com/path - 观察响应头中的 Location 字段是否与日志中 rewrite 的目标 URI 一致
- 如果不一致（例如日志显示重写为
/api/v2/user，但 curl 返回Location: /login），说明跳转来自后端，问题不在 Nginx rewrite，而在应用层
设置独立 access 日志辅助比对原始与最终路径
避免 debug 日志淹没，可对高风险路径打标记录更轻量的上下文：
- 在 http 块顶部定义变量：
map $request_uri $log_redirect { default 0; ~^/app/ 1; ~^/api/ 1; } - 在对应 location 中加：
access_log /var/log/nginx/redirect-trace.log main if=$log_redirect; - 自定义 log_format 加入
$uri、$request_filename、$args，就能看清 rewrite 后真实访问的是哪个文件或路径
