排查nginx 502/504需先看error.log中具体错误描述：如“connection refused”属502，主查后端存活与配置；“upstream timed out while reading response header”属504，主调proxy_read_timeout等超时参数，并直连验证后端响应。
排查 Nginx 代理转发超时引发的网关报错（502/504），核心是盯紧错误日志里的具体错误码和上下文，再结合超时类型反向定位环节。不能只看“502”或“504”两个数字，要读清后面那句关键描述。
看错误日志里到底写了什么
执行：
tail -f /var/log/nginx/error.log | grep -i "upstream\|timeout\|502\|504"
重点关注以下三类典型报错：
- "connect() failed (111: Connection refused)" → 后端根本没监听，或地址/端口写错，属于 502，和超时无关
- "upstream timed out (110: Connection timed out) while connecting to upstream" → 连接阶段卡住，proxy_connect_timeout 触发，常见于网络不通、防火墙拦截、后端启动慢
- "upstream timed out (110: Connection timed out) while reading response header from upstream" → 连接已建好，但等响应头太久，proxy_read_timeout 触发，属典型 504 场景
区分是 502 还是 504，决定排查方向
两者表面都是“网关报错”，但根源完全不同：
-
502 Bad Gateway：Nginx 没拿到合法 HTTP 响应——可能是后端崩溃、返回乱码、主动 RST 断连、TLS 握手失败（缺
proxy_ssl_server_name on） - 504 Gateway Timeout：Nginx 连上了后端，也发了请求，但后端迟迟不回完整响应——本质是后端慢或 Nginx 等不及了
日志里若出现 "upstream timed out"，基本就是 504；若出现 "Connection refused"、"No route to host"、"SSL alert number 80"，则归为 502。
对照配置检查超时参数是否合理
找到触发日志的 location 或 upstream 块，核对以下三项是否匹配业务实际：
-
proxy_connect_timeout：建议设为 30–60 秒，覆盖后端冷启动或网络抖动时间 -
proxy_read_timeout：普通接口至少 120 秒；流式接口、大文件上传、长轮询必须设为 3600 或更高 -
proxy_send_timeout：一般与 read timeout 一致即可，除非后端接收请求极慢
注意：这些值必须大于后端自身处理耗时，并留出缓冲余量。例如后端平均响应 80 秒，proxy_read_timeout 至少设为 120 秒。
验证后端是否真在响应，排除假性超时
别信日志一面之词，动手验证：
- 用
curl -v http://后端地址:端口/health直连后端，看响应时间和状态码 - 同时开两个终端：一个跑
tail -f error.log，另一个反复 curl，观察哪次请求对应哪条日志 - 若直连快但 Nginx 转发就超时，说明问题出在 Nginx 到后端链路（如中间防火墙静默断连、TCP keepalive 未启用）
