Nginx 报 502 Bad Gateway 怎么办？
502 表示 Nginx 作为反向代理连不上后端：先查后端服务是否在跑（systemctl status）、端口/socket 是否匹配、超时与缓冲区配置，再看 error.log 定因。本文给出完整排查链。
核心认知：502 的含义是"Nginx 作为网关/反代，从上游（后端应用）拿到了无效响应"——Nginx 自己是好的，问题在后端应用或两者的连接上**。排查顺序：①后端服务活着没 → ②Nginx 配置的上游地址/端口对不对 → ③看 /var/log/nginx/error.log 的具体报错 → ④按报错类型对症处理。**
第一步：确认 Nginx 与后端都在跑
systemctl status nginx
systemctl status php-fpm # 或你的应用服务：gunicorn/node/java...
ss -ltnp | grep -E '9000|8080|3000' # 后端端口在听吗
后端挂了：拉起来（systemctl start）并查它为什么挂（它的日志）。
第二步：核对上游配置
location / {
proxy_pass http://127.0.0.1:8080; # 端口和后端真实监听一致吗？
}
- 用 unix socket 的（
fastcgi_pass unix:/run/php-fpm.sock）：socket 文件存在吗、权限对吗 - 容器/跨机场景：IP 与端口、防火墙、容器网络是否通
第三步：看 error.log 定因
tail -50 /var/log/nginx/error.log
| 日志关键词 | 病因 | 处理 |
|---|---|---|
connect() failed (111: Connection refused) |
后端没监听/已挂 | 拉起后端，查崩溃原因 |
upstream timed out (110) |
后端处理太慢 | 加大 proxy_read_timeout，更要查后端慢的原因 |
no live upstreams |
upstream 组全不可用 | 检查后端的健康与负载 |
recv() failed (104: Connection reset) |
后端主动断连（崩溃/超时杀） | 看后端日志，查内存/OOM |
(13: Permission denied) socket |
SELinux 或 socket 权限 | setsebool httpd_can_network_connect 1 或修权限 |
第四步：常见调整
location / {
proxy_pass http://127.0.0.1:8080;
proxy_connect_timeout 10s;
proxy_read_timeout 60s; # 后端慢接口要放宽
proxy_send_timeout 60s;
}
改完 nginx -t && systemctl reload nginx。
观测云对照
502 应该被监控抓住而不是用户。 DataKit 采集 Nginx 日志后，Pipeline 解析状态码，监控器对 5xx 比例/数量阈值告警；配合后端应用的 APM 链路，502 是"后端挂了"还是"后端慢了"直接分晓。
常见问题（FAQ）
Q：偶发 502 又自动恢复？
A：典型是后端不稳定（OOM 重启、连接池打满、慢查询堆积），查后端资源与日志的时间点关联。
Q：502 和 504 的区别？
A：502=拿到无效响应/连不上；504=连上了但等响应超时。504 更明确指向"慢"。
Q：负载均衡下部分请求 502？
A：upstream 里个别后端不健康，给 upstream 配健康检查（商业版或被动 max_fails），并把问题后端踢出去修。
