先确认故障范围
记录 502 出现的时间、是否所有页面都受影响、后台是否可访问、是否只在高峰期发生，以及近期是否升级、迁移或修改配置。不同页面和不同地区的表现，有助于判断问题发生在 CDN、Web 服务还是应用层。
服务器故障
网站出现 502 Bad Gateway，通常从哪里查起？
502 并不等于网站文件一定损坏。Nginx 无法从上游服务取得有效响应时，可能与 PHP-FPM、资源、超时或代理配置有关。
Nginx 与 PHP-FPM 是常见检查点
PHP 网站常见链路是 Nginx → PHP-FPM → 应用程序 → 数据库。502 可能来自 PHP-FPM 未运行、连接异常、进程耗尽或应用崩溃。需要结合 Nginx 错误日志、PHP 日志及服务状态判断，不能仅凭一个状态码下结论。
资源与超时也会造成间歇性故障
磁盘空间不足、内存压力、数据库连接过多、慢查询或外部接口长时间无响应，都可能间接引起网站超时。单纯把超时时间调大，可能掩盖真正的性能问题。
恢复后要排查重复发生的原因
网站重新能访问之后，仍应核对错误日志、资源变化、计划任务和近期代码部署。涉及备份、服务重启或配置调整时，先评估对在线业务的影响并保留回滚方案。
排查前先记录这些信息
502 通常表示网关或反向代理没有从上游服务获得有效响应。具体原因可能在 PHP-FPM、应用进程、超时、网络或资源限制，不能只看错误页面就认定是 Nginx 本身的问题。
- 记录出现时间、受影响 URL 和是否所有页面都异常。
- 查看 Nginx 错误日志与对应应用服务日志的同一时间段。
- 确认近期是否更新 PHP、插件、代码、配置或服务器资源。
修复后如何验证
先检查受影响页面与登录、表单、支付等关键流程，再观察错误日志与服务器资源是否恢复稳定。对生产环境的重启、配置变更或回滚，应先评估业务影响并保留备份。
参考资料
需要进一步排查？ 如果网站已经影响访问、订单或数据安全，可先描述问题，再根据实际情况确认处理范围。