域名解析没问题，服务器也Ping得通，但网站就是打不开，还报502或504——这种情况，大概率不是你代码的锅，而是服务器环境配置出了问题。

　　很多站长遇到502/504的第一反应是“服务器挂了”或者“被攻击了”，然后慌慌张张去重启Nginx、重启PHP、甚至重启整个服务器。结果呢?运气好能撑几分钟，运气不好重启完照旧。问题的根源根本没找到。

　　今天这篇不扯虚的，直接告诉你502和504到底是什么意思、什么原因、怎么一步步排查。文章里会带具体的命令和配置片段，照着做就行。

　　先搞清楚502和504的区别

　　别看这两个状态码长得像，它们表示的问题完全不同，排查方向也完全不同。

　　502 Bad Gateway：翻译过来叫“错误的网关”。在典型的LNMP/LAMP架构里，Nginx(或Apache)是前端网关，PHP-FPM、Tomcat、Node.js这些是后端应用。当Nginx把请求转发给后端，后端没有给出有效响应时，Nginx就返回502。通俗点说就是：网关联系不上工人，或者工人撂挑子了。

　　504 Gateway Timeout：网关没超时，后端在规定时间内没干完活，网关等不下去了，直接给客户端返回超时。通俗点说就是：工人接了活，但干得太慢，网关不等了。

　　一个是不干活(502)，一个是干得太慢(504)。搞清楚这个，排查思路就清晰了。

　　端口层面的检查

　　场景一：后端服务根本没在监听

　　最典型的502原因：PHP-FPM没启动，或者启动后挂了。

　　先检查端口监听状态：

ss -tlnp | grep 9000
# 或者
netstat -tlnp | grep 9000

　　如果返回空，说明PHP-FPM没有监听9000端口。这时候检查PHP-FPM服务状态：

systemctl status php8.1-fpm
# 或者你用的版本
systemctl status php7.4-fpm

　　看到 active (running) 是正常状态。如果显示 failed 或 inactive，直接启动：

systemctl start php8.1-fpm

　　启动后再次检查端口，确认监听了再试访问。

　　注意：如果你的PHP-FPM配置是走Unix Socket而不是TCP端口，那grep 9000是查不到的。这时候要看socket文件是否存在：

ls -la /run/php/php8.1-fpm.sock

　　文件存在的话，还要确认Nginx配置文件里的 fastcgi_pass 参数是用的socket路径还是IP端口，两者必须一致。

　　场景二：后端服务改端口了，Nginx没跟上

　　有些情况下，你手动改了PHP-FPM或Tomcat的监听端口，但忘了更新Nginx的代理配置。这时候后端服务跑得好好的，但Nginx还在往老的端口转发请求，自然响应不了。

　　检查Nginx的站点配置：

cat /etc/nginx/sites-available/你的站点.conf | grep -E "fastcgi_pass|proxy_pass"

　　如果是PHP站点，你会看到类似：

fastcgi_pass unix:/run/php/php8.1-fpm.sock;
# 或者
fastcgi_pass 127.0.0.1:9000;

　　确保这个地址和端口与你实际运行的服务完全一致。

　　如果改完配置，记得重载Nginx：

nginx -t  # 先测试配置语法是否正确
systemctl reload nginx

　　防火墙层面的检查

　　端口监听正常，但外部访问不到——这种时候八成是防火墙挡住了。不过注意：如果是本地访问(服务器自己访问自己)能通，外网访问不通，那才叫防火墙问题。 如果本地都访问不了，那说明服务本身没起来，别先查防火墙。

　　检查当前防火墙规则：

iptables -L -n -v | grep 9000

　　如果没有任何输出，说明防火墙没有针对9000端口的规则，那一般不会拦截。但如果你用的是云服务商的安全组(比如华纳云安全组)，那是云平台层面的防火墙，服务器内部 iptables 是看不到的。

　　云安全组是大坑：很多新手配好了服务器所有东西，本地curl 127.0.0.1能通，外网浏览器就是访问不了。这时候去云控制台检查安全组/防火墙规则，看你的网站端口(80/443)是否对外开放了。如果是自定义端口，记得手动添加放行规则。

　　还有一个容易忽略的点：SELinux。如果你用的是CentOS/RockyLinux这类系统，SELinux可能会拦截Nginx访问PHP-FPM的socket文件。检查SELinux状态：

getenforce

　　如果返回 Enforcing，可以临时关闭测试：

setenforce 0

　　关掉后网站恢复正常的话，说明是SELinux的锅。永久解决需要配置SELinux布尔值，这里不展开，生产环境不建议直接永久关闭。

　　连接数和进程池的问题

　　这是502最常见也最隐蔽的原因之一：PHP-FPM的进程池被耗尽了。

　　当并发请求数超过 pm.max_children 的设置值，新的请求会排队等待。如果队列也满了，Nginx再转发请求过来，PHP-FPM直接拒绝连接——于是502就出现了。

　　查看PHP-FPM的进程数和状态：

ps aux | grep php-fpm | wc -l

　　同时检查PHP-FPM的慢日志：

tail -f /var/log/php8.1-fpm.log

　　如果看到类似 WARNING: [pool www] seems busy 的告警，说明进程池确实吃紧了。

　　解决方案有两种：

　　1. 调高 pm.max_children 和 pm.start_servers 的值(前提是服务器内存足够)。

　　2. 优化代码逻辑，减少单个请求的执行时间。

　　另外，PHP执行超时也是502的常见诱因。如果你的某个脚本执行时间超过了Nginx的 fastcgi_read_timeout 设置，Nginx就会中断连接，返回502。检查Nginx配置里的超时参数：

fastcgi_connect_timeout 60;
fastcgi_send_timeout 60;
fastcgi_read_timeout 60;

　　这三个值如果你的业务有耗时操作(比如导入大批量数据、生成报表)，调到300秒甚至更高都不是问题。

　　504的根源在于执行时间

　　504几乎永远是时间相关的。要么是后端处理太慢，要么是超时设置太短。

　　第一站：检查PHP-FPM的 request_terminate_timeout

　　这个参数决定了PHP脚本能运行的最长时间。默认值是0(无限制)，但很多环境会被设为30秒或60秒。如果你的业务里确实有超过这个时间的操作，就把这个值调大。

　　第二站：检查Nginx的超时设置

　　和上面提到的 fastcgi_read_timeout 同理，如果这个值设置得比PHP执行时间短，Nginx就会在PHP还没跑完的时候提前超时，返回504。

　　对于反向代理场景(比如Node.js、Java后端)，检查 proxy_read_timeout：

proxy_read_timeout 300s;

　　第三站：检查数据库查询

　　很多时候504不是服务器配置的问题，而是SQL写得烂，查了十几秒才返回数据。这种时候调大超时只能掩盖问题，治本还是得优化索引、优化SQL、或者加缓存层。

　　建议开启MySQL的慢查询日志，看看哪些查询拖慢了整体响应：

# 临时开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;

　　超过2秒的查询就记录下来，针对性优化。

　　总结：遇到502/504，别慌，也别动不动就重启。其实说到底，502和504是服务器运维里最常规的问题，排查手段非常标准化。只要把日志看明白，把端口关系理清楚，绝大多数情况10分钟内就能定位到原因。

　　最后多说一句：不要害怕看错误日志。 很多新手遇到报错第一反应是去搜索引擎复制粘贴错误码，但日志里的每一行都在直接告诉你问题出在哪儿。学会读日志，比记住一百条排查命令都管用。