我不会起名字322· 后端 / 算法 / 数据库 技术栈 力扣 Hot100 Go 项目 Redis MySQL文章目录Nginx 502 与 504 的区别一次请求在两个超时点上的失败一、一个请求在 Nginx 上会经过两个超时二、502 Bad Gateway连接层面的失败触发条件日志里长什么样排查顺序一个高频坑keepalive 连接被复用三、504 Gateway Timeout等待响应超时触发条件日志排查方向504 时不要盲目调大超时四、一张对照表五、带走物Nginx 502 与 504 的区别一次请求在两个超时点上的失败一、一个请求在 Nginx 上会经过两个超时Nginx 作为反向代理时一次请求要跨两条 TCP 连接client ────①──── Nginx ────②──── upstream(应用)对应两组超时连接超时参数超时后返回① 客户端 → Nginxclient_header_timeout/client_body_timeout408 / 499② Nginx → upstreamproxy_connect_timeout/proxy_read_timeout/proxy_send_timeout502 或 504502 和 504 的差异就出在第 ② 条连接的不同阶段连不上TCP 握手失败、连接被拒、upstream 不存在→502连上了但等不到响应upstream 处理太慢→504这个区分非常重要因为两者的排查方向完全不同。二、502 Bad Gateway连接层面的失败触发条件Nginx 在以下情况返回 502proxy_connect_timeout默认60s内没能和 upstream 建立 TCP 连接upstream 直接拒绝了连接端口没监听upstream 在发送响应头之前就把连接关了DNS 解析不出 upstream 域名upstream 的 keepalive 连接已经被对端关掉Nginx 复用了一条死连接。日志里长什么样2026/10/13 00:12:03 [error] 12345#0: *6789 connect() failed (111: Connection refused) while connecting to upstream, client: 10.0.0.5, server: api.example.com, request: POST /order HTTP/1.1, upstream: http://10.0.1.20:8080/order关键字段connect() failed (111: Connection refused) while connecting to upstream。其他常见变体# 连不上超时 connect() failed (110: Connection timed out) while connecting to upstream # 没有可用上游 no live upstreams while connecting to upstream # 上游提前关闭连接 upstream prematurely closed connection while reading response header from upstream # 域名解析失败 no resolver defined to resolve xxx排查顺序# 1. upstream 还活着吗ss-lntp|grep8080# 2. 从 Nginx 这台机器上能连上吗关键要在 Nginx 本机测curl-v-m3http://10.0.1.20:8080/healthz# 3. DNS 能解析吗如果 upstream 写的是域名nslookupupstream.internal# 4. 看 Nginx 的错误日志tail-100/var/log/nginx/error.log|grep-iupstream一个高频坑keepalive 连接被复用这个坑很值钱。如果 upstream比如某个应用有keepalive 超时Tomcat 默认 20s、Go 的默认更长它会在空闲一段时间后主动发 FIN 关闭连接。而 Nginx 的 upstream keepalive 连接池不一定立刻感知到等到下一个请求复用这条已经半关闭的连接时就会报 502。解决办法是给 upstream 配 keepalive 并合理设置upstream backend { server 10.0.1.20:8080; keepalive 64; # 每个 worker 维护的连接池大小 } server { location / { proxy_pass http://backend; proxy_http_version 1.1; # keepalive 需要 HTTP/1.1 proxy_set_header Connection ; # 清空 Connection 头不要传 close proxy_connect_timeout 5s; # 连接超时不要设太长快速失败 proxy_read_timeout 30s; } }proxy_http_version 1.1和proxy_set_header Connection 这两行缺一不可否则 keepalive 不生效Nginx 会每条请求新建连接。三、504 Gateway Timeout等待响应超时触发条件TCP 连接建立成功了但 upstream 在proxy_read_timeout默认60s内没有返回任何数据。注意是没返回任何数据不是没返回完整响应——upstream 只要持续在发数据就不会触发。日志2026/10/13 00:15:41 [error] 12345#0: *6790 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 10.0.0.5, server: api.example.com, request: GET /report HTTP/1.1, upstream: http://10.0.1.20:8080/report关键字段upstream timed out while reading response header from upstream。排查方向502 查的是能不能连上504 查的是为什么慢# 1. 直接打 upstream量一下真实耗时curl-wdns%{time_namelookup} tcp%{time_connect} ttfb%{time_starttransfer} total%{time_total}\n\-o/dev/null-shttp://10.0.1.20:8080/report# 2. 上游慢在哪看应用的慢查询 / 慢日志 / pprofttfb首字节时间如果就超过 60s那 Nginx 报 504 是正确的——问题在上游不在 Nginx。504 时不要盲目调大超时很多人第一反应是把proxy_read_timeout从 60s 调到 300s。这通常是个坏主意请求会在 Nginx 上挂住 5 分钟占住一个 worker 连接客户端或更上游的网关大概率早就超时断开了这个请求变成了纯粹的浪费上游慢的根因没解决只是把 504 变成很慢的成功。正确顺序先量出上游真实耗时 → 优化上游加索引、加缓存、异步化 → 最后再考虑调整超时值并且超时应逐级收敛下游 上游 网关 客户端。四、一张对照表502 Bad Gateway504 Gateway Timeout失败阶段建立连接 / 连接被拒已连接但等不到响应相关参数proxy_connect_timeoutproxy_read_timeout/proxy_send_timeout日志关键词connect() failed while connecting to upstreamupstream timed out while reading response header常见原因应用没启动、端口不通、DNS 失败、keepalive 死连接应用慢慢 SQL、下游依赖慢、死循环排查动作从 Nginx 本机 curl upstream直接打 upstream 量 ttfb误治调大 connect 超时调大 read 超时应先优化上游还有两个容易混淆的状态码一并记住499客户端在 Nginx 返回之前就断开了。这通常是更上游的网关超时比 Nginx 短导致的——不是 Nginx 的问题是超时链路上层设短了。503upstream 被max_fails标记为不可用或者所有节点都被摘掉了。查nginx.conf里的max_fails/fail_timeout。五、带走物排查流程1. 看 Nginx error.log 的关键词 ├─ connect() failed ... while connecting to upstream → 502查连通性 ├─ upstream timed out ... reading response header → 504查上游耗时 ├─ no live upstreams → 503查 max_fails └─ access log 里是 499 → 客户端/上层网关先断了 2. 502在 Nginx 本机执行 ss -lntp | grep port # 端口在不在 curl -v -m 3 http://upstream # 能不能连 3. 504直接打上游量 ttfb curl -w ttfb%{time_starttransfer}\n ... 4. 顺手检查 upstream 是否配了 keepalive 缺 proxy_http_version 1.1 Connection → 每次新建连接502 概率上升一句话结论502 是连不上504 是连上了但等不到前者查连通性后者查耗时——两者不要混着排查。