502错误从定位到修复：运维实战排查流程

502错误表示作为网关或代理的服务器（如Nginx）从上游服务器（如PHP-FPM、Gunicorn、后端API）收到无效响应。常见原因包括上游服务未运行、端口未监听、进程挂死、响应超时、连接被拒绝或返回违规头信息。

第一步：确认上游服务状态

首先检查后端服务是否存活。对于PHP-FPM，执行 systemctl status php-fpm 或 ps aux | grep php-fpm 看进程是否存在。若未启动，尝试 systemctl start php-fpm 并查看启动日志。对于其他后端，使用 curl -v http://127.0.0.1:9000/status 或对应健康检查端点，观察连通性与响应。

第二步：分析代理层错误日志

Nginx错误日志通常位于/var/log/nginx/error.log。搜索“502”或“upstream”关键词，典型记录如“connect() failed (111: Connection refused)”指示端口未监听，“upstream timed out”则说明响应超时。日志会提示上游地址，须确认地址、端口与上游实际监听一致。

第三步：检查端口与防火墙

使用 netstat -tlnp | grep 9000 或 ss -tlnp | grep 9000 确认上游端口监听状态。注意监听地址是127.0.0.1还是Unix socket，Nginx配置中的fastcgi_pass或proxy_pass必须与之匹配。若使用socket文件，检查文件权限和目录存在性。

第四步：排查超时与缓冲设置

当后端处理时间过长，Nginx会在达到proxy_read_timeout或fastcgi_read_timeout后断开并返回502。可在Nginx配置的location或upstream块中临时增大超时值观察是否消失，例如 fastcgi_read_timeout 60s;。长期应优化后端处理逻辑或调整进程数。

第五步：查看服务器资源与限制

后端进程耗尽内存或进程数达到上限也会导致无响应。通过 top、free -h 查看CPU与内存使用。若使用PHP-FPM，检查 pm.max_children 是否过小，日志中会出现“server reached pm.max_children setting”提示。按需调整后重载服务。

第六步：代码与框架层面的排查

有时502由后端程序致命错误导致，例如PHP代码执行超时、内存溢出、死循环。启用PHP错误日志并观察对应时间点的记录。可在脚本入口加入try-catch并输出简单提示，快速验证是否由代码异常引发。