error_log 是 Nginx 检测非法重定向路径最直接、最底层的“真相来源”，忠实记录文件系统访问失败、内部跳转失控、权限拒绝等真实异常，暴露表面正常实则危险的重定向行为。
error_log 是 Nginx 检测非法重定向路径最直接、最底层的“真相来源”。它不依赖响应状态码是否被掩盖，也不受 access_log 记录逻辑干扰，而是忠实记录文件系统访问失败、内部跳转失控、权限拒绝等真实异常，从而暴露那些表面看似正常（如返回 200 或 302），实则路径非法或配置危险的重定向行为。
直接暴露重定向引发的底层失败
当重定向目标指向一个根本不存在或不可访问的路径时，Nginx 在尝试服务该路径时会触发 open() 或 stat() 系统调用。一旦失败，error_log 就会明确写出错误原因：
-
open() "/path/to/file" failed (2: No such file or directory)→ 路径拼错、root/alias配置偏差、大小写错误、或文件被删除； -
open() "/path/to/file" failed (13: Permission denied)→ Nginx 进程用户无目录执行权（x）或文件读取权（r）； -
stat() "/path/to/file" failed (13: Permission denied)→ SELinux/AppArmor 主动拦截，传统权限检查通过但安全模块拒绝。
这类日志比 access_log 中的 404 更可靠：即使因 try_files 或 rewrite 导致请求被内部重定向多次，最终落到非法路径上，error_log 仍会如实记录最后一次失败尝试。
捕获重写/重定向循环的明确信号
非法重定向常演变为死循环（例如 / → /index.html → /），Nginx 会在达到内部跳转上限（默认 10 次）后报错：
-
rewrite or internal redirection cycle while internally redirecting to "/xxx"
紧跟其后的internally redirecting to "/xxx"显示卡住的 URI，是定位循环起点的关键线索。
仅靠 access_log 看不到这个过程——它可能只显示一个 500，而 error_log 直接点明“是重定向自己绕晕了”，并给出循环终点路径。
识别恶意扫描伪装成重定向的行为
攻击者常构造大量非法路径（如 /.git/config、/backup.zip、/wp-admin/install.php）试探敏感文件。这些请求多数不触发常规页面逻辑，却必然导致 open() failed (2: No such file or directory)。error_log 中高频出现含 .git、.env、phpmyadmin 等关键词的此类错误，就是全路径暴力扫描的铁证——与是否发生重定向无关，但说明重定向规则（如 try_files $uri $uri/ /index.html）正被滥用来“兜底”这些非法路径，反而暴露了攻击痕迹。
辅助验证 proxy_redirect 是否生效
在反向代理场景中，后端返回 Location: http://internal:8080/path 是常见问题。error_log 不直接记录 Location 头，但会记录后续因该地址无法访问引发的底层错误：
-
connect() failed (111: Connection refused)→ Nginx 尝试连接后端原始Location地址失败，说明proxy_redirect未正确重写； -
upstream timed out→ 后端响应慢，Nginx 在等待修正后的Location头时超时，间接反映重定向链卡在上游。
结合 access_log 中的 $upstream_http_location 字段，就能交叉确认：后端返回了什么、Nginx 是否改写、改写后是否可访问。
启用 debug 日志看清每一步跳转
默认 error_log 只报结果。要追踪非法重定向的完整路径链（比如 /api/v1/user → rewrite → /index.php → try_files → /index.html → 再次匹配同一 location），需临时开启 debug 日志：
- 在对应
server或location块中设置error_log /var/log/nginx/debug.log debug; - 观察
rewrite phase: X, "/old" -> "/new"、test location: "/index.html"等逐跳记录，精准定位哪条指令把合法请求引向了非法路径。
不复杂但容易忽略
