502 和 504 都表示请求经过了 Nginx，但代理链路没有正常完成。502 通常是上游连接失败、连接被重置或返回无效响应；504 通常是连接或读取上游响应超时。不要一开始就盲目增大超时时间，它可能掩盖真正的性能问题。
一、先确认范围和时间线
所有接口还是少数 URI；
所有实例还是单个上游；
持续发生还是流量高峰出现；
是否与发布、扩容、证书、DNS 或网络变更重合；
客户端、CDN、负载均衡和 Nginx 各层状态码是否一致。
二、读取错误日志关键字
grep -E 'upstream|connect\(\) failed|timed out|reset|prematurely closed' /var/log/nginx/error.log | tail -100常见信息：
connect() failed (111: Connection refused)：上游端口未监听或服务未启动；upstream timed out：连接、发送或读取上游响应超时；connection reset by peer：上游主动重置，可能是进程重启或网络中断；upstream prematurely closed connection：上游未完整返回就关闭；no live upstreams：所有上游被判定不可用。
三、从 Nginx 主机直连上游
curl -sv --connect-timeout 3 --max-time 10 http://UPSTREAM:PORT/health
nc -vz -w 3 UPSTREAM PORT
getent hosts upstream.example.com必须从 Nginx 所在机器或容器测试，因为运维电脑能访问不代表代理节点能访问。若使用域名上游，还要考虑 DNS 缓存、解析变化和 resolver 配置。
四、检查上游服务
ss -lntp | grep ':PORT'
systemctl status app-service
journalctl -u app-service --since '-30 minutes'继续检查进程重启、OOM、线程池和连接池耗尽、慢 SQL、下游接口超时、GC 停顿和文件描述符不足。504 的根因经常位于数据库或第三方依赖，而不是 Nginx。
五、检查连接和资源
ss -s
sar -n TCP,ETCP 1 10
cat /proc/sys/net/netfilter/nf_conntrack_count 2>/dev/null
cat /proc/sys/net/netfilter/nf_conntrack_max 2>/dev/null关注 SYN 堆积、TIME_WAIT、重传、连接跟踪表、端口耗尽以及负载均衡设备状态。Nginx 本身还应检查 worker 连接数、打开文件限制和上游 keepalive。
六、核对超时配置
proxy_connect_timeout 3s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;
send_timeout 30s;连接超时应较短，读取超时应根据接口正常耗时和业务目标设置。超时链路要满足“内层先超时、外层后超时”，并为调用方留出处理错误的时间。重试只适合幂等请求，避免重复下单或重复写入。
七、紧急止血
摘除异常上游实例；
回滚最近发布；
扩容应用、线程池或连接池；
对非核心接口限流或降级；
临时调整合理的超时，但同步记录风险；
若单个依赖异常，启用熔断避免拖垮整个集群。
八、长期治理
在访问日志记录 upstream 地址、状态码、连接时间和响应时间；
对 502/504 按 URI、上游和实例维度告警；
为服务建立健康检查、优雅启停和连接排空；
建立 Nginx、应用、数据库和链路追踪的统一时间线；
通过压测确定容量与超时，而不是事故时拍脑袋修改。
总结
502 重点回答“为什么没有得到有效响应”，504 重点回答“时间花在哪里”。从 Nginx 错误日志提取上游地址和失败阶段，再沿应用、数据库与外部依赖追踪，才能快速定位并避免超时配置掩盖根因。