error_log 不记录反向代理配置解析异常，因语法错误在 nginx -t 或 reload 时直接报错退出；仅当配置通过解析、运行时出现连接问题（如 Connection refused、timeout）才记入 error_log；access_log 更适于排查代理逻辑是否生效。
error_log 本身不记录反向代理配置解析异常——这类问题根本不会走到日志写入阶段，而是在 nginx -t 检查或 reload 时直接报错退出。
配置语法错误：nginx -t 是第一道关卡
proxy_pass 写错地址、缺少分号、upstream 名称拼错、location 嵌套非法等，都属于配置解析期错误。Nginx 启动或重载时会拒绝加载，并在终端或系统日志中输出明确提示：
-
典型报错示例：
nginx: [emerg] invalid URL prefix in /etc/nginx/conf.d/app.conf:12或nginx: [emerg] unknown directive "prox_pass" -
必须执行：
nginx -t验证语法；若失败，nginx -t -v可显示更详细上下文 -
注意路径：宝塔用户日志路径常为
/www/wwwlogs/nginx_error.log，但此类解析错误一般不写入该文件
运行时连接类错误：error_log 才真正开始记录
配置能通过 nginx -t，不代表代理能通。此时 error.log 才成为关键线索，记录的是 Nginx 尝试与后端通信时的实际失败：
- connect() failed (111: Connection refused) → 后端进程未监听指定端口，或容器/防火墙阻断
-
upstream timed out (110: Connection timed out) → 网络可达但响应超时，需调大
proxy_connect_timeout或检查后端负载 - no live upstreams while connecting to upstream → upstream 块中所有 server 都被标记为 down（如健康检查失败），或根本没有定义 upstream
- recv() failed (104: Connection reset by peer) → 后端主动断连，常见于应用崩溃、协议不匹配（如 HTTP/1.0 vs HTTP/1.1）
为什么 access_log 更值得优先关注？
多数“代理没生效”不是因为配置解析失败，而是逻辑走偏——比如请求根本没命中 location，或被 rewrite/return 提前终结。这时 error.log 安静如初，但 access.log 会暴露真相：
- 某条请求的
$upstream_addr字段为空或为-，说明 proxy_pass 根本没触发 -
$upstream_status显示502或404，说明已发往后端，问题在下游而非 Nginx 配置本身 - 配合
$request_uri和$uri对比，可快速识别路径重写是否意外改变了转发目标
调试建议：从验证到日志，分层推进
- 先运行
nginx -t，确保配置无语法错误 - 再用
nginx -s reload，观察终端是否提示成功；失败则看 stderr 输出 - 发起一次测试请求，立刻检查
access.log中对应行的关键字段 - 若 access.log 显示异常（如 upstream_addr 缺失、upstream_status 异常），再查
error.log补充底层通信细节 - 临时将
error_log级别提至debug（仅限排查），可捕获更多内部决策过程，但切记事后调回
