Nginx 502 排查：先看错误日志，再改配置

网站出现Nginx 502时，先确认反向代理还是PHP-FPM链路出错。通过时间、请求路径和上游日志对照，判断该检查连接、进程还是应用异常。

502页面只说明网关没有拿到可用的上游响应，并没有直接告诉你应用为什么失败。把超时时间全部调大，可能让故障等待更久，却没有修复连接失败。排查时应从一条可复现请求开始。

先确认代理链路

写出请求经过的组件：浏览器、CDN、Nginx、应用服务。如果使用PHP-FPM，请把它单独写出来，普通HTTP反向代理和FastCGI连接不能混为一谈。记录访问时间、请求路径和错误状态，之后在相同时间窗口里对照日志。

在有服务器权限的环境中，先检查Nginx配置是否能通过语法验证，再查看报错对应的上游地址。示例命令为：

nginx -t

此命令只检查配置，不等于网站服务已恢复。不要把测试通过当成应用健康的证据。

按日志线索选择下一步

连接被拒绝时，检查目标进程是否运行、监听地址是否一致、端口是否写错。找不到Unix socket时，检查服务实际生成的socket路径以及Nginx是否有访问权限。日志指向上游提前关闭连接时，对照应用日志、进程退出记录和资源使用情况。

只有日志显示等待超时，而且应用本身可完成请求时，才讨论合适的超时预算。排查应区分建立连接耗时和读取响应耗时；不要在没有证据时同时修改所有timeout参数。若静态文件正常、动态请求失败，把重点放到应用链路；若所有请求都失败，重新核对入口代理和服务状态。

验证恢复并防止复发

修复后重复同一个请求，同时记录状态码、响应时间和应用日志。再挑选登录页、文章页和一个轻量接口，确认恢复不是只覆盖首页。生产环境的压力测试应单独安排，不要在正在排障的机器上临时制造大量请求。

将根因写成一句具体的话，例如“应用监听端口变更后，上游地址未更新”，比“服务器卡了”更有复用价值。保留变更前后的配置差异，但从日志截图和分享资料中去除令牌、密码及内部敏感地址。本文提供诊断方法，未声称对你的服务器完成实测。

参考资料与适用范围

Nginx：HTTP代理模块

PHP官方：运行时安全相关参考

本文为原创方法教程，不包含未经运行的性能测试结论。示例地址和命令需要替换为你自己的环境；官方服务与界面可能更新，操作前应复核当前文档。资料核对日期：2026年10月7日。