网站出现 502 Bad Gateway 的排查方法

先确认影响范围和发生时间

502 表示网关或代理无法从上游获得有效响应。先确认是单个页面、整个站点还是特定地区受影响，并记录首次出现时间、最近部署和配置变更。避免在没有证据时连续重启多个服务，导致日志和现场信息丢失。

1. 从不同网络复现并记录 URL、时间和错误页面。
2. 查看是否只有某个 API 路径异常。
3. 对照部署记录和监控，确认错误开始时间。
4. 在不影响用户的前提下保存相关日志。

检查代理层日志和配置

sudo nginx -t
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

错误日志可能提示连接被拒绝、上游超时、DNS 解析失败或权限问题。核对 proxy_pass 地址、端口、协议和 upstream 名称，并确认配置加载的是你正在编辑的文件。

确认上游进程与端口可用

sudo systemctl status app.service --no-pager
sudo journalctl -u app.service -n 100 --no-pager
sudo ss -lntp

• 进程是否仍在运行，是否因内存不足反复退出。
• 应用是否监听反向代理配置中的地址和端口。
• 本机防火墙或容器网络是否阻断了代理到应用的流量。
• 应用日志是否显示启动失败、数据库超时或请求耗尽。

修复后验证并避免复发

根据证据修复配置、依赖或应用问题。涉及配置变更时先备份，运行语法检查后再 reload；涉及应用版本时保留上一个可用版本。修复后从入口和上游分别检查，确认错误率、日志和核心页面恢复。

谨慎重启生产服务

重启可能中断现有请求并掩盖根因。若确需重启，先确认影响范围、持久化状态和回滚方案，并在维护窗口内执行。

面板环境（如 1Panel）的排查差异

用面板部署的站点，排查入口有两处变化。其一，应用通常以容器或守护进程方式运行，面板"应用列表"里的运行状态就是上游状态，先看它再登服务器。其二，端口映射：面板应用实际监听的端口，可能与 Nginx 配置里 proxy_pass 写的端口不同，排查时以面板应用详情里显示的端口为准。

• 面板应用显示停止或重启中：上游就是挂了，先看应用日志找崩溃原因，而不是急着点重启。
• 应用日志（容器日志）能看到依赖缺失、数据库连不上这类启动失败的真实报错。
• 面板生成的反向代理配置一般可靠，除非手动改过，否则最后才查它。

错误日志关键词对照

error.log 关键词	含义	优先动作
Connection refused	上游进程没在监听：没启动，或端口写错	确认进程状态与监听端口
upstream timed out	上游活着但没在时限内回应	查应用慢在哪里：数据库、外部请求、死循环
no live upstreams	upstream 里所有节点都不可用	逐个检查上游成员状态
Permission denied	代理进程无权连接上游（常见于 Unix socket）	检查 socket 文件权限与属主

下一步该读什么

相关教程

• 常见 HTTP 状态码：先分清 5xx 家族里 502 与 504 的差别
• Linux 资源使用率查看：内存耗尽导致进程退出，是 502 的常见根因
• 1Panel 建站部署：面板环境的完整建站流程