Nginx日志故障排查：如何解决502错误

时间：2026-07-14

Nginx报出502 Bad Gateway，这大概是运维同学最头疼的问题之一了。明明网站平时跑得好好的，突然就给你“罢工”，页面一片空白，只剩下“502”三个数字。其实，这个错误说白了就是Nginx作为中间人，去问上游服务器（比如PHP-FPM、Node.js或Tomcat）要数据，结果上游没理它，或者回了一句“我搞不定”。那么，从哪里开始查？

1. 看日志，这是最关键的入口

想要解决502错误，第一件事就是去看Nginx的日志，这可是咱们的“指南针”。通常，日志文件在/var/log/nginx/error.log，路径也可以通过nginx -V确认。日志里的信息非常直接：

如果看到connect() failed (111: Connection refused)，那就说明Nginx压根连不上上游服务器——大概率是PHP-FPM没启动，或者端口号搞错了。
如果报告upstream timed out，那就是上游处理太慢，Nginx等不及了，需要调整超时设置。
如果是Permission denied，那就是权限问题，比如套接字文件或目录的访问权限不够。

2. 确认上游服务器是否“活着”

很多502错误，根源就在上游服务挂了。所以，下一步就是确认上游服务的运行状态。

如果是PHP-FPM，运行systemctl status php-fpm（或service php-fpm status）。如果没启动，就执行systemctl start php-fpm。
如果是Node.js或Python应用，用ps aux | grep node（或grep python）看看进程还在不在。如果进程消失了，赶紧重启，比如用pm2 restart app。

3. 核对Nginx与上游的通信配置

配置错误是502错误的“隐形杀手”，很多时候都是因为这里没写对。重点检查两个地方：

proxy_pass或fastcgi_pass指令里的地址，必须和上游服务器实际监听的地址一致。比如PHP-FPM监听的是Unix套接字，Nginx这边就要写成fastcgi_pass unix:/run/php/php-fpm.sock;；如果Node.js监听8080端口，就用proxy_pass http://127.0.0.1:8080;。
端口号别搞混了。Nginx配置里写的是8080，但上游实际在9000端口上等着，那自然就连接不上。

4. 检查网络和防火墙

有时候，Nginx和上游服务器之间网络不通，或者防火墙拦住了。可以用几条命令快速验证：

先ping <上游服务器IP>，看看网络通不通。
再用telnet <上游服务器IP> <端口>（或nc -zv <端口>）测试端口连通性。如果连不上，就得检查防火墙规则了。Ubuntu系统用ufw allow <端口>，CentOS系统用firewall-cmd --add-port=<端口>/tcp --permanent，然后记得firewall-cmd --reload。

5. 调整Nginx超时设置

如果上游服务器处理请求比较慢（比如执行复杂查询或上传大文件），默认的超时时间（通常60秒）可能不够，Nginx就会报502。这时候，需要在Nginx配置里增加超时参数，可以放在http、server或location块中：

proxy_connect_timeout 300s;  # 连接上游服务器的超时时间
proxy_send_timeout 300s;     # 向上游服务器发送请求的超时时间
proxy_read_timeout 300s;     # 从上游服务器读取响应的超时时间
fastcgi_read_timeout 300s;   # 如果使用PHP-FPM，也要同步调整

修改后，记得重载Nginx：systemctl reload nginx。

6. 检查系统资源限制

服务器资源耗尽，也会导致上游服务无法响应。比如CPU或内存被占满，或者文件句柄数不够用。可以用top查看CPU使用率，free -h查看内存使用率。如果文件句柄数太小（默认1024），可以修改/etc/security/limits.conf，添加* soft nofile 65535和* hard nofile 65535，然后重启服务。

7. 去看看后端应用的日志

如果Nginx日志里没有明确提示，那就得去翻上游应用的日志了。比如PHP-FPM的日志在/var/log/php-fpm.log，Node.js的日志可能是app.log。这些日志里往往藏着更具体的错误信息，比如代码异常、数据库连接失败等。举个例子，PHP-FPM日志里出现WARNING: [pool www] child exited with code 1，这说明PHP进程异常退出，通常需要检查代码或扩展兼容性。

8. 其他常见原因，也不能忽视

权限问题：确保Nginx用户（比如www-data或nginx）有权访问上游服务器的目录或套接字文件。比如/run/php/php-fpm.sock的权限应为660，所属组设置为Nginx用户组。
缓冲区不足：如果响应数据过大，可能需要调整Nginx的缓冲区设置，比如fastcgi_buffer_size 64k; fastcgi_buffers 16 64k;。
恶意攻击：如果502错误突然大量出现，不排除是DDoS攻击。可以用netstat -antp查看异常连接数，并通过防火墙限制IP访问频率。