要让 error_log 发挥深度排障作用，必须同时满足编译支持（nginx -v | grep with-debug）、作用域精准（仅限 server 或 location 块，可配合 debug_connection 限 ip）和日志可读（聚焦 [debug] 行及关键匹配、重写、代理、ssl 等线索）。
确认 Nginx 编译时已启用 debug 支持
绝大多数系统包（如 Ubuntu apt、CentOS yum 安装的 nginx）默认不带 debug 日志功能。运行：
nginx -V 2>&1 | grep -o with-debug
有输出才表示可用；若无，需从源码重新编译并添加 --with-debug 参数。OpenResty 用户通常已内置该支持。
在最小必要作用域中启用 debug 日志
debug 日志量极大，绝不能放在全局（main 上下文）或 http 块顶层。应只加在怀疑出问题的局部：
- 在具体 server 块内：
error_log /var/log/nginx/debug_api.log debug; - 更精准地，在某个 location 块内：
error_log /var/log/nginx/debug_v2.log debug; - 配合
debug_connection 192.168.1.100;可限制仅对指定 IP 生效，大幅减少干扰 - 路径需确保 Nginx 工作进程用户（如 www-data 或 nginx）有写权限
聚焦识别 [debug] 开头的关键线索
日志中只有带 [debug] 前缀的行才是有效调试信息。重点关注以下模式：
-
test location: "/api/v2/"→ 开始匹配 location -
using configuration "/api/v2/"→ 成功进入该 location 块 -
rewrite phase: 3→ 进入重写阶段（phase 3 是 rewrite 指令执行期） -
"^/api/v2/(.*)$" matches "/api/v2/users"→ 正则成功匹配并显示捕获组 -
http proxy header: "GET /path HTTP/1.0"→ 已向 upstream 发起代理请求 -
ssl handshake: TLSv1.3或SSL_do_handshake() failed→ SSL 握手细节
搭配验证手段避免误判
单看 debug 日志容易淹没重点，建议同步操作：
- 用 curl -v http://host/path 观察真实响应头与状态码，对照日志中
upstream timed out或rewrite or internal redirection cycle - 在目标 location 中临时加
return 200 "in /v2";，确认是否真的进入了该块 - 对复杂正则，先拆解测试：比如先验证
^/api/，再加v\d+，最后补捕获组 - 若用了
if判断变量，注意它独立执行，日志中会单独出现if condition true行，需结合上下文判断
