VPS出现Nginx 502 Bad Gateway时，先查Nginx错误日志中的上游错误，再确认后端进程、监听地址和请求路径。502说明网关没有取得可用的上游响应，它不同于Nginx自己未启动，也不能靠刷新页面判断根因。
先用错误日志把502分型
在变更服务前记录故障时间、请求域名、URI、Nginx配置版本和上游类型，并查看对应站点的错误日志。常见信息可以快速缩小范围：
| 日志线索 | 常见含义 | 下一步 |
|---|---|---|
| connect() failed (111: Connection refused) | 上游端口没有监听或进程拒绝连接 | 检查服务状态与监听地址 |
| No such file or directory | Unix Socket路径不一致或文件未创建 | 核对Nginx与应用配置 |
| Permission denied | Socket目录、文件或安全策略阻止访问 | 检查用户、权限与SELinux/AppArmor |
| upstream timed out | 上游未在超时前返回 | 检查慢请求、依赖和资源压力 |
| upstream prematurely closed connection | 应用崩溃、主动关闭或响应格式异常 | 对齐应用日志与进程事件 |
不要只看浏览器中的502页面，因为CDN、负载均衡和Nginx都可能生成类似状态页。应确认响应来自哪一层。
第一步：确认上游服务真的在运行
sudo systemctl status php-fpm
sudo systemctl status your-app.service
sudo ss -lntp
sudo ss -lx服务名因发行版、PHP版本和部署方式而不同，应使用本机真实单元名称。服务显示active也不代表它监听了Nginx配置中的端口或Socket；必须把监听结果与upstream、proxy_pass或fastcgi_pass逐字对齐。
第二步：区分TCP端口和Unix Socket问题
使用TCP上游时，要核对IP、端口和地址族。应用只监听127.0.0.1时，容器或另一网络命名空间中的Nginx不能直接访问；应用只监听IPv6也可能与IPv4配置不匹配。
使用Unix Socket时，要核对文件是否存在、Nginx工作进程用户能否穿过父目录并读写Socket，以及PHP-FPM重启后是否创建到新路径。不要用全局放宽权限掩盖配置不一致。
第三步：容器部署要沿真实网络路径检查
容器内的127.0.0.1只代表该容器自身。Nginx在宿主机、独立容器或编排网络中时，应使用实际暴露端口、服务名和网络。检查容器状态、端口映射、健康检查和最近退出原因，并确认应用没有只绑定在错误接口。
直接重建容器可能丢失现场。先保存日志、镜像版本、环境变量名称和部署变更，再决定回滚或重启。
第四步：超时不是简单把数值调大
出现upstream timed out时，应先找出请求在哪一步变慢：数据库锁、外部API、DNS、磁盘I/O、CPU或内存压力都可能拖住上游。提高proxy_read_timeout或fastcgi_read_timeout只会延后报错，不能修复慢查询和资源瓶颈。
- 对齐Nginx访问日志、错误日志和应用日志的时间戳。
- 检查CPU、内存、I/O和进程数是否在故障时异常。
- 复现单个请求，避免用并发压力掩盖根因。
- 确认应用的超时、网关超时和外部依赖超时关系合理。
第五步：配置与权限修改前先做安全检查
sudo nginx -t
sudo systemctl reload nginx只有配置检查通过才重载Nginx。修改PHP-FPM池、应用服务或安全策略时，也应使用对应的语法检查和最小变更。能reload就不要无理由重启整台VPS，以免同时丢失日志和其他服务。
恢复后怎么验收
- 从Nginx所在环境直接访问上游健康端点，确认TCP或Socket可达。
- 通过正式域名访问故障URI，确认状态码和正文恢复。
- 检查Nginx与应用日志没有继续产生同类错误。
- 观察多个请求与一个正常流量窗口，避免把偶发成功当作恢复。
- 为上游存活、响应时间、502比例和资源压力设置独立监控。
502和504有什么区别
两者都可能来自网关链路。502通常表示连接失败、无效响应或上游提前关闭；504更明确地表示网关等待上游超时。但具体实现和多层代理可能改变表现，所以仍应以生成响应的网关日志和上游日志为准。
