nginx 502错误根源在upstream通信异常，需查error.log中connect refused、timeout、no live upstreams等关键词，并结合access.log与curl实测定位。
直接看 error.log 里带 upstream 的报错行，重点关注连接失败、超时和重定向循环这三类线索，就能快速锁定代理转发失败的根源。
重点盯住这几类 upstream 错误关键词
代理转发失败不会报“proxy_pass 语法错误”——那类问题在 nginx 启动时就拦下了。真正运行中出问题，error.log 通常会明确写出底层通信异常：
-
connect() failed (111: Connection refused)：后端根本没监听，或
proxy_pass写错了 IP/端口（比如写成8081，但服务只在8080） -
upstream timed out (110: Connection timed out)：后端响应太慢，或
proxy_read_timeout设得太短 -
no live upstreams while connecting to upstream：用了
upstream块，但所有 server 都被健康检查标记为 down，或压根没配置health_check -
rewrite or internal redirection cycle：location 和 rewrite 规则互相触发跳转，常见于路径末尾斜杠不一致 +
proxy_redirect配置不当
用命令快速抓取关联错误
别手动翻日志，用终端命令直击问题时间点：
- 实时观察：`tail -f /var/log/nginx/error.log | grep -E "(upstream|connect|timeout|rewrite)"`
- 查最近一次 502/504 请求前后 10 秒内的全部错误：`sed -n '/2026\/09\/03.*14:5[7-9]/,/^$/p' /var/log/nginx/error.log | grep -E "(emerg|error|upstream)"`（按实际时间微调）
- 确认日志级别够用：检查
nginx.conf的http块里是否设了error_log /path/to/error.log warn;，低于warn级别可能漏掉关键提示
结合 access.log 看完整链路
error.log 告诉你“哪里断了”，access.log 能帮你确认“是不是真断了”：
- 查状态码：`awk '$9 ~ /^5[0-9][0-9]$/ {print $0}' /var/log/nginx/access.log | tail -5` —— 找出最近的 5xx 请求
- 比对上游地址：同一时间戳下，看
$upstream_addr是否为空、为-，或指向一个明显异常的 IP:Port - 核对后端返回码：若
$upstream_status是-或缺失，说明连接阶段就失败，不是后端业务问题
排除日志本身不可用的干扰
如果 error.log 是空的，或者只有旧记录，说明 Nginx 根本没成功初始化日志模块：
- 先确认真实日志路径：打开
nginx.conf，找error_log指令，它写的路径才是准的 - 检查目录权限：`ls -ld $(dirname /your/real/error.log)`，确保 nginx 运行用户（如
nginx或www-data）有写权限 - 查系统层报错：`journalctl -u nginx -n 30 -e` 或 `systemctl status nginx`，常能看到更早的启动失败原因
