Nginx 502 Bad Gateway排查指南：从错误日志到上游服务定位

1. 502不是你写错了代码，而是Nginx替你背了一口锅

坦白讲，我刚开始接触Nginx反向代理那阵子，一看到502 Bad Gateway就慌，第一反应是“我的应用是不是崩了”，第二反应是“是不是Nginx配置写错了”。后来踩的坑多了，才慢慢意识到一件事：502这个报错，本质上不是Nginx自己出了问题，而是它作为“中间人”，没能从上游服务器拿到一个合法的HTTP响应，于是只好向客户端甩出一张“我尽力了，但上游没理我”的告示。

拿现实生活打个比方。你去一家餐厅点菜，服务员（Nginx）把你的单子递给后厨（后端服务），后厨要么锅坏了、要么火没点着、要么厨师根本没上班，反正迟迟端不出菜来。服务员等了一会儿，实在没办法，只能出来跟你说：“抱歉，这道菜做不了。”这个“做不了”，就是502 Bad Gateway。

所以处理502问题的第一步，不是盯着Nginx的配置瞎猜，而是先搞清楚一个核心逻辑：Nginx只是转发者，真正出问题的往往在后端。但这里有一个让人头疼的地方——Nginx作为统一的入口，把所有上游的乱七八糟的问题都包装成了同一个502返回给你，真正的原因被藏在了日志和上游服务的运行状态里。这也是为什么网上搜“502 Bad Gateway解决方案”能搜出一大堆互相矛盾的说法，因为每个502背后的真相都不同。

这篇文章，我把自己这些年排查502的整套思路、常用命令、以及那些容易让人绕远路的坑全部梳理一遍。不保证你看完就永远不会再遇到502，但至少下次再碰到，你能有条不紊地顺着链路去定位，而不是盲改配置碰运气。

2. 一次完整请求的“接力赛”：Nginx到底在哪里接的棒

在动手排查之前，建议先花三分钟把Nginx反向代理的请求链路在脑子里过一遍。很多朋友查了半天没头绪，就是因为对整个链条上的环节没有概念，一上来就改配置，越改越乱。

2.1 请求从客户端到后端的完整路径

一次正常的请求，走的是这样一条链路：

客户端发起HTTP请求 → Nginx接收请求 → Nginx根据配置的location规则匹配 → Nginx将请求转发给upstream（上游服务器） → 上游服务器处理请求并返回响应 → Nginx接收到响应后返回给客户端。

整个过程看起来简单，但每个环节都有各自可能出问题的地方：

• 客户端到Nginx之间，可能出现网络不通、DNS解析失败、连接被拒。
• Nginx到上游服务器之间，可能出现连接超时、上游服务未启动、端口监听异常。
• 上游服务器处理过程中，可能出现进程崩溃、线程阻塞、内存溢出。
• Nginx接收上游响应时，可能出现响应头不完整、响应体过大、缓冲区不足。

2.2 502和504、500的本质区别

很多人把502、504、500混为一谈，其实它们的含义完全不同：

通俗点说，500是后端自己写代码炸了，502是后端根本没给出像样的响应，504是后端响应太慢把Nginx的耐心耗尽了。排查思路上，502和504经常一起出现，因为很多超时场景下，Nginx等不到上游响应，可能返回502，也可能返回504，取决于具体的超时配置和上游断开的方式。

2.3 为什么Nginx会把所有上游问题都“包装”成502

这是理解502的关键点。Nginx作为代理层，它对上游的期望其实非常简单：你给我一个合法的HTTP响应，包括完整的状态行和响应头。只要上游没做到这一点——不管是连接就失败了，还是响应写到一半断掉了，还是返回了一堆无法解析的内容——Nginx都会在它的错误日志里记录一条“upstream prematurely closed connection”或“connect() failed”之类的信息，然后向客户端返回502。

换句话说，502是一个“结果”，真正的“原因”全都藏在Nginx的error.log里。这也是我每次排查502的第一动作：不是去看业务日志，不是去重启服务，而是先打开Nginx的错误日志，看看到底是哪个环节出了问题。

3. 我惯用的排查套路：三步锁定问题根源

这里直接给出一套我实际工作中使用频率非常高的排查流程，按顺序走下来，大概率能定位到问题所在。

3.1 第一步：看Nginx错误日志，找出精确报错信息

Nginx的错误日志默认位置是/var/log/nginx/error.log，但具体路径取决于你的编译参数和配置文件。你可以通过以下命令确认：

bash复制nginx -T 2>/dev/null | grep "error_log"

拿到日志路径后，动态跟踪最近的错误：

bash复制tail -f /var/log/nginx/error.log

常见的报错信息和对应的原因如下：

这一步往往能直接告诉你答案，但很多人会忽略它，直接去看业务日志，反而绕了远路。

3.2 第二步：确认上游服务本身的状态

根据错误日志的提示方向，去检查上游服务。最基础的三板斧：

bash复制# 检查端口监听
netstat -tlnp | grep 8080

# 测试上游端口是否响应
curl -v http://127.0.0.1:8080/health

# 查看上游服务的进程状态
ps aux | grep java
ps aux | grep gunicorn
ps aux | grep node

这里的核心思路是：先绕过Nginx，直接访问上游服务。如果直接curl上游端口都失败，那问题百分百在上游，Nginx只是个传话的；如果直接curl成功但通过Nginx访问失败，那重点就要检查Nginx的配置了。

我遇到过一个很经典的场景：业务方说“Nginx反代502了”，结果我curl后端服务的健康检查接口，发现响应时间长达30秒。单独看服务进程是活的，但请求根本处理不过来，这就是典型的应用层问题。

3.3 第三步：检查Nginx配置中与upstream相关的关键参数

如果上游服务本身正常，直接访问也通，那问题多半出在Nginx与上游之间的配置细节上。需要重点核对的有这样几个点：

nginx复制upstream backend {
    server 127.0.0.1:8080;
    keepalive 32;
}

location /api/ {
    proxy_pass http://backend;
    proxy_connect_timeout 5s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
}

• proxy_connect_timeout：Nginx与上游建立连接的超时时间，默认60秒。
• proxy_read_timeout：Nginx等待上游响应头的超时时间，默认60秒。
• proxy_send_timeout：Nginx向上游发送请求体的超时时间，默认60秒。
• keepalive：upstream连接池中保持的空闲长连接数。

很多502场景，改这几个参数就能解决。比如上游接口本身是个慢接口，处理一次要90秒，而Nginx的proxy_read_timeout只有60秒，那到了60秒Nginx就会主动断开，返回502。这种问题在业务日志里往往看不到任何异常，因为上游还在慢吞吞地处理，只是Nginx等不起了。

4. 高频触发场景和对应的修复方案

这一节我把实际工作中遇到频率最高的几类502原因拆开细讲，每一种都附上具体的修复手段。

4.1 上游服务未启动或崩了：最朴素也最常见

场景描述：后端服务上线后忘了启动，或者运行过程中OOM被系统杀了，或者部署时搞错了端口。Nginx转发过去，发现端口根本没人监听，直接报Connection refused。

验证方式：

bash复制netstat -tlnp | grep <上游端口>

如果没有任何输出，说明端口没监听。这时候需要去上游服务所在的主机上看进程状态、查启动日志，把服务拉起来。

修复动作：启动或重启上游服务，并确认端口开始监听。

经验补充：这种场景下，Nginx的错误日志里会是大量连续的connect() failed (111: Connection refused)，非常好辨认。另外提醒一句，很多云服务器有进程守护工具，但守护脚本本身可能有问题——比如启动命令里的路径写错了，或者环境变量没加载，导致守护工具反复拉起服务、反复失败。所以看到端口没监听时，别急着手动启，先看看上游服务自身的日志，避免“启了又死、死了又启”的循环。

4.2 upstream组里所有服务器都被标记为不可用

这是有一定Nginx使用经验的人才会遇到的坑。Nginx对upstream中的每个server节点有健康检查机制，如果某个节点连续多次通信失败，Nginx会将它标记为不可用，并在接下来的fail_timeout时间内不再把请求转发给它。如果你的upstream里只有一个节点，而这个节点被标记为不可用，那么所有请求都会直接返回502，错误日志里会出现：

code复制no live upstreams while connecting to upstream

这种情况通常发生在后端发布重启期间：发布工具先把服务停了，Nginx恰好在这个窗口期连续探测失败，于是在接下来的默认10秒内（fail_timeout默认值），即使后端服务已经拉起来了，Nginx也不会把流量转发过去，导致持续一小段时间的502。

修复方案：

• 调大fail_timeout和max_fails的容忍度，比如max_fails=3 fail_timeout=30s。
• 使用proxy_next_upstream配置，让Nginx在某个上游节点失败时自动尝试下一个节点。

nginx复制upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
}

location /api/ {
    proxy_pass http://backend;
    proxy_next_upstream error timeout http_502 http_503;
}

经验补充：proxy_next_upstream不是万能的。如果你后端接口不是幂等的（比如下单、转账），开启proxy_next_upstream后，Nginx在上游已经处理完但响应超时的情况下，会把请求重试到下一个节点，可能导致重复下单。对于这类接口，建议只开启proxy_next_upstream error timeout，不要加http_502和non_idempotent，降低重复风险。

4.3 keepalive配置不匹配导致连接被重置

这个坑非常隐蔽，我印象极深。有一次帮一个团队排查问题，Nginx错误日志里没有Connection refused，而是大量出现：

code复制upstream prematurely closed connection while reading response header from upstream

上游服务用的是HTTP/1.1，而Nginx配置了keepalive 32，也就是Nginx和上游之间维持了一批长连接。按理说这是性能优化，不应该出问题才对。问题出在哪里呢？出在上游服务的Web容器配置里，它自身的keep-alive超时时间很短，或者干脆关闭了长连接。于是Nginx以为那个连接还能用，把请求扔过去，结果上游早就把连接关了，只好重新建连，但Nginx的keepalive池子里还留存着脏连接，导致请求失败。

修复方案：让Nginx的keepalive配置和上游服务的keep-alive设置保持一致。

nginx复制upstream backend {
    server 127.0.0.1:8080;
    keepalive 16;
}

location /api/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

这里有个细节需要注意：使用keepalive时，必须将proxy_http_version设置为1.1，并清空Connection请求头。这是Nginx官方文档推荐的写法，很多教程里没写，抄配置时容易漏掉。

经验补充：如果你用的是Spring Boot内置的Tomcat，默认的keep-alive配置通常是够用的；但如果你用的是某些云厂商的网关产品，或者自研的HTTP框架，就一定要确认连接超时参数。曾经有个案例，上游是用Python写的一个轻量HTTP服务，框架默认的连接空闲超时只有5秒，而Nginx keepalive池里的连接闲置了10秒后被复用，必然失败。

4.4 响应头过大：缓冲区装不下的尴尬

错误日志里出现：

code复制upstream sent too big header while reading response header from upstream

就是上游返回的HTTP响应头超过了Nginx默认的缓冲区大小。Nginx默认的proxy_buffer_size是4k或8k（不同版本略有差异），如果上游返回的Cookie、自定义响应头特别长，或者集成了单点登录后响应头里塞了大量信息，就很容易超限。

修复方案：

nginx复制location /api/ {
    proxy_pass http://backend;
    proxy_buffer_size 128k;
    proxy_buffers 4 256k;
    proxy_busy_buffers_size 256k;
}

经验补充：Nginx官网对这个参数的解释比较简短，实际调优时要注意，proxy_buffer_size只是单个响应头的缓冲区，proxy_buffers是整个响应体的缓冲区池。如果只是响应头超限，通常调大proxy_buffer_size就够了，没必要把proxy_buffers调得非常大，否则会浪费内存。另外，如果你用的是proxy_buffering off关闭了缓冲，那proxy_buffer_size仍然生效，别忽略。

4.5 代理到HTTPS上游时的SSL握手失败

现在很多后端服务内部也启用了HTTPS，Nginx反代到上游时需要做SSL握手。如果上游的证书是自签名的、或者SSL协议版本不匹配、或者上游的TLS配置有问题，Nginx转发请求就会在握手阶段失败。

错误日志示例：

code复制SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure)

修复方案：

• 确认上游SSL配置正确，证书有效。
• 在Nginx的location或upstream配置中指定正确的SSL参数。

nginx复制upstream backend {
    server 127.0.0.1:8443;
}

location /api/ {
    proxy_pass https://backend;
    proxy_ssl_verify on;
    proxy_ssl_certificate /etc/nginx/client.crt;
    proxy_ssl_certificate_key /etc/nginx/client.key;
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
}

经验补充：如果上游使用自签名证书，可以先设置proxy_ssl_verify off测试连通性，确认是证书校验问题后再决定是关闭校验还是配置正确的CA证书。生产环境不建议长期关闭校验，特别是涉及敏感数据的接口。

4.6 防火墙、安全组和SELinux：那些看不到的拦路虎

这个场景非常容易被人忽略。Nginx和上游服务在同一台机器上时，很少有人会想到防火墙的问题。但如果你用的是Linux服务器，并且开启了SELinux，Nginx默认是不允许发起网络连接的。

错误日志示例：

code复制connect() failed (13: Permission denied) while connecting to upstream

如果看到Permission denied而不是Connection refused，基本可以锁定SELinux或者防火墙拦截。

排查命令：

bash复制# 查看SELinux状态
getenforce

# 临时关闭SELinux
setenforce 0

# 查看防火墙规则
firewall-cmd --list-all
iptables -L -n

修复方案：

• 如果SELinux拦截了Nginx的网络访问，使用setsebool -P httpd_can_network_connect 1放行。
• 如果是firewalld拦截，添加放行规则：

bash复制firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --reload

经验补充：很多云服务器还有安全组规则，即使服务器本机防火墙放行了，安全组没放行从Nginx机器到上游机器的端口，一样连不通。这种问题在本地复现不了，只有线上才有，排查时一定别忘了看安全组。

4.7 DNS解析问题：上游域名解析不到或解析到错误IP

这种场景常见于Nginx反代到某个域名而不是IP的情况。比如你配置了：

nginx复制proxy_pass http://internal-service.example.com;

Nginx在启动时会解析一次域名，缓存解析结果。如果上游服务做了迁移、换了IP，而Nginx没有reload，它仍然会把请求转发到旧IP，导致502。

排查方法：

bash复制# 用nslookup或dig确认域名解析结果
nslookup internal-service.example.com
dig internal-service.example.com

# 查看Nginx进程实际使用的DNS解析结果
nginx -T 2>/dev/null | grep resolver

修复方案：

• 在Nginx配置中显式指定resolver，并启用动态解析：

nginx复制resolver 8.8.8.8 valid=30s;
location /api/ {
    set $backend "http://internal-service.example.com";
    proxy_pass $backend;
}

这里有个关键点：只有当proxy_pass后面跟的是变量时，Nginx才会在每次请求时动态解析域名。如果直接写域名，Nginx只在启动或reload时解析一次。所以要通过变量方式实现动态DNS解析。需要注意的是，使用变量后proxy_pass中不能带URI，否则行为会不符合预期。这是我实际踩过的坑，配的时候小心一点。

4.8 上游主动断开连接：应用自身的问题

错误日志里的经典台词：

code复制upstream prematurely closed connection while reading response header from upstream

除了keepalive配置不匹配之外，还有一个更常见的原因：上游应用在处理请求时直接崩溃了。比如后端是PHP-FPM，某个请求触发了fatal error，进程直接退出；或者后端是Python的gunicorn，worker因为内存问题被杀掉了。

排查方向：

• 查看上游服务自身日志，看是否有异常堆栈。
• 检查上游服务的内存和CPU使用率。
• 检查上游服务的worker进程数量是否配置合理。

你的业务日志里可能写了一大堆错误堆栈，把核心异常找出来修复就行。如果没有任何日志就崩了，大概率是被系统OOM Kill了，执行dmesg | tail -20看看有没有Out of memory相关的记录。

5. 那些让人抓狂的隐藏坑：非常规502场景复盘

上面那些是常规套路，下面这几个坑属于“不遇到还好，一遇到就头大”的类型，全都来自我个人的真实经历。

5.1 客户端与Nginx之间的连接异常也会表现为502

大多数人对502的理解是“Nginx与上游之间出了问题”，但有些场景下，问题出在客户端这边。这里有一个典型：客户端建立了连接之后，长时间没有发送完整的请求数据，Nginx等待超时直接断开连接。某些应用在弱网环境下，上传大文件时，或者客户端使用了不规范的HTTP库时，很容易触发这种状况。

不过这种场景在错误日志里往往不是upstream开头的报错，而是client timed out或client intended to send too large body之类的。所以看到502时，也要稍微留个心眼，看看是不是client side的问题。

5.2 响应体太大，磁盘写满导致缓冲失败

Nginx在做反向代理时，如果开启了响应缓冲，会先把上游的响应数据写入临时文件（proxy_temp_path指定的位置），再转发给客户端。如果proxy_temp_path所在的磁盘分区被写满了，Nginx写临时文件失败，会直接向客户端返回502。

错误日志示例：

code复制/var/cache/nginx/proxy_temp/xxx: No space left on device

修复方案：

• 清理磁盘空间。
• 将proxy_temp_path迁移到空间充足的分区。
• 或者关闭响应缓冲（proxy_buffering off），但代价是上游响应会一边收一边发给客户端，性能和可靠性都会下降，不建议在高流量场景下这么做。

判断方法：

bash复制df -h

看到磁盘使用率100%，基本就能实锤了。

5.3 UNIX Domain Socket 和 TCP Socket 的混淆

有些后端服务（比如FPM、Uvicorn）监听的是UNIX Domain Socket而不是TCP端口。在Nginx里配置时，要写socket文件的路径：

nginx复制upstream backend {
    server unix:/var/run/php-fpm/www.sock;
}

如果socket文件路径写错了，或者运行Nginx的用户对socket文件没有读写权限，就会报：

code复制connect() failed (2: No such file or directory) while connecting to upstream

或

code复制connect() failed (13: Permission denied) while connecting to upstream

这个坑在PHP-FPM场景下特别常见。换个PHP版本、重新编译一下，socket文件路径可能就变了，如果Nginx配置没同步更新，502就来了。排查方法很简单：确认socket文件是否真实存在，以及Nginx进程用户（通常是nginx或www-data）是否有权限访问这个文件。

5.4 容器化环境里的网络模式问题

现在很多服务跑在Docker或Kubernetes里，502的排查又多了一层复杂性。在Docker里，Nginx容器要访问另一个容器，得保证两个容器在同一个网络里，或者通过宿主机IP访问。

常见错误场景：

• Nginx容器通过localhost:8080访问上游容器，但容器里的localhost是容器自身，不是宿主机，也不是其他容器。
• Docker Compose里服务名解析正常，但单独启动Nginx容器时没有加入同一个自定义网络。
• Kubernetes里Service的targetPort配置错误，导致Nginx通过Service转发时连不到Pod的端口。

解决方式：

• 确认Nginx容器能ping通上游容器的IP或服务名。
• 确认防火墙没有阻断容器间通信。
• 不要在容器内使用localhost访问其他容器，应该用服务名或宿主机IP。

经验补充：我曾经处理过一个K8s环境下的502，Pod都活着、Service也存在、端口也正常，但就是502。最后发现是Service的selector写错了，后端Pod的label跟Service不匹配，导致Service后端的Endpoint列表为空。用kubectl get endpoints一看，Endpoint数是0，问题一目了然。

6. 从源头减少502的几点配置习惯

排查完问题之后，更重要的是提前预防。下面这几个配置习惯，是我在经历过多次502之后沉淀下来的，分享出来供参考。

6.1 超时时间设置要符合真实业务场景

很多人直接用默认配置，但默认配置不一定适合你的业务。如果你的上游接口本身就慢，那就别把超时时间设得太短，否则只是制造“假性502”。

建议的初始配置：

nginx复制proxy_connect_timeout 5s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

如果业务接口偶尔会长时间运行（比如导出报表、批量计算），要单独为这些接口配置更长的超时时间：

nginx复制location /api/slow-report {
    proxy_pass http://backend;
    proxy_read_timeout 300s;
}

6.2 使用upstream多节点提升可用性

如果是重要服务，尽量部署多个实例，并在upstream中配置多个节点。配合健康检查，即使单个节点挂了，Nginx也能自动把请求转发到其他可用节点。

nginx复制upstream backend {
    server 10.0.0.1:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:8080 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

注意不要把所有鸡蛋放在一个篮子里。如果两个节点部署在同一台物理机上，那机器挂了，两个节点都挂了，高可用也就失去了意义。

6.3 配置错误日志报警

502不是每次都能被你第一时间发现的。尤其是在凌晨，业务低峰期，服务悄悄挂了又重启了，你没有感知，但用户已经骂娘了。建议给Nginx的错误日志配置一个简单的监控报警，比如用tail -F配合grep关键字，或者接入监控系统做日志关键字告警。

最简单的Shell思路：

bash复制tail -F /var/log/nginx/error.log | grep --line-buffered "upstream" | while read line; do
    echo "$line" | curl -fsS -X POST "https://your-alert-hook" -d "text=$line" >/dev/null 2>&1
done

这只是个思路，生产环境建议用成熟的采集系统，但核心逻辑一样：把Nginx错误日志里的upstream关键字当作重点监控对象，一旦出现，立刻通知。

6.4 平滑升级和reload的时机

修改Nginx配置后，一定要用nginx -t先检查语法，再用nginx -s reload平滑生效。

bash复制nginx -t
nginx -s reload

这里提醒一个新坑：如果你改了upstream节点列表，但上游服务本身还没准备好接受流量（比如还在启动中、端口还没监听），reload之后就会出现间歇性的502。所以部署顺序很重要：先启动上游服务，确认端口正常监听，再reload Nginx。

7. 绕过Nginx直接压测上游：验证问题归属的最快方法

最后这一点，是我在带团队时反复强调的：判断502问题归属，最高效的方法就是绕过Nginx，直接打上游。有人觉得这个操作太粗暴，但往往最直接的方法最省时间。

具体操作分三步：

第一步，确定上游地址。看Nginx配置里proxy_pass指向哪里，拿到协议、IP、端口。

第二步，直接用curl访问上游。如果上游是HTTP服务：

bash复制curl -v http://127.0.0.1:8080/health

注意这里要把你实际请求的路径写上去，不要只测根路径。有些服务根路径是404，但业务接口是正常的；反过来也有可能根路径正常，但具体业务接口超时。

第三步，观察结果：

• curl秒回且状态码正常 → 问题大概率在Nginx配置层，继续查Nginx和上游之间的细节。
• curl超时或连接失败 → 问题在上游，去查上游服务的状态。
• curl能通但非常慢 → 问题可能在上游性能，也可能是上游与Nginx之间的网络链路。

这里有一个经验之谈：如果curl上游正常，但通过Nginx访问就是502，优先检查以下几项：

1. proxy_pass路径是否写对了（尤其是是否带了/尾巴，这个细节很多人会忽略）。
2. Nginx与上游之间是否有防火墙或安全组拦截。
3. Nginx配置的proxy_set_header是否影响了上游处理逻辑。

比如有些上游服务会校验Host请求头，如果Nginx没把原始的Host传过去，上游直接返回403或断开连接，Nginx包装成502返回给客户端。

nginx复制location /api/ {
    proxy_pass http://backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

这组配置看似基础，但实际上非常关键，很多奇奇怪怪的502都是因为少了某个header导致的。

8. 关于502这件事的最后一句话

我处理过的Nginx 502问题，少说也有几十次了。回过头来看，这个问题本身并不复杂，真正让人头大的，是它背后可能的原因太多：服务挂没挂、网络通不通、配置对不对、资源够不够、超时合不合理——每一个环节都可能是元凶。但换个角度想，也正是因为你无法一眼看出原因，才更说明系统性的排查方法有多重要。

我个人最核心的体会就是三条：第一，日志为王，先看Nginx的error.log再动手；第二，绕过Nginx直测上游，快速划分责任边界；第三，不要把超时、缓冲区这些参数当成固定值，它们要根据实际业务场景去调优。 把这三点做到位，502就从“玄学”变成了“科学”。

再分享一个小技巧：如果你经常处理这类问题，建议把Nginx的error.log级别调到info，虽然会增加日志量，但在排查问题时能看到更多细节。另外，每次修改配置后记录一下变更原因，下次遇到问题不用重头猜一遍。我一般会在配置目录里建一个CHANGELOG文件，每次改了什么、为什么改，都随手记一笔。这个习惯帮我节省了大量重复排查的时间。