网站502错误怎么解决？

网站打开后显示“502 Bad Gateway”，通常说明网关或反向代理未能从上游服务获取有效响应。后端程序停止、代理地址错误、PHP-FPM连接异常，都可能导致这一问题。

本文以Linux服务器上的Nginx网站为例，按照“查看日志—检查后端—修复配置—验证访问”的顺序排查。

操作前说明： 文中的域名、端口、服务名称和日志路径均为示例，请按实际环境替换。修改配置前先备份；使用宝塔、OpenResty或容器部署时，应操作实际运行的服务实例。

1. 查看Nginx错误日志

先记录报错时间和访问路径，再检查同一时间段的错误日志：

sudo tail -n 80 /var/log/nginx/error.log

如果该路径不存在，应从网站配置中的error_log指令查找实际位置。也可以使用下面的命令查看配置文件内容：

sudo nginx -T

输出可能包含内部地址或认证配置，分享前需要脱敏。

常见日志与排查方向如下：

日志关键词	排查方向
`Connection refused`	后端未启动、监听地址或端口不正确，也可能存在主动拒绝连接的规则
`No such file or directory`	连接Unix Socket时，检查文件路径及PHP-FPM是否启动
`Permission denied`	检查Socket、父目录权限，以及SELinux等访问控制
`upstream prematurely closed connection`	检查后端崩溃、主动断开或进程被终止
`upstream sent too big header`	检查后端响应头大小及对应代理缓冲配置

重点查看日志中的upstream字段，确认Nginx实际连接的是哪个地址。

如果网站前面还有CDN或负载均衡，应结合各层日志判断502由哪一层产生，不能只根据错误页面上的名称下结论。

Linux查看Nginx错误日志排查网站502

2. 检查HTTP后端端口和响应

对于Java、Node.js、Python等HTTP应用，先核对Nginx配置中的proxy_pass地址。

例如：

proxy_pass http://127.0.0.1:8080;

如果后端直接运行在同一台服务器、同一网络命名空间中，可以检查8080端口：

sudo ss -lntp '( sport = :8080 )'

只有表头、没有监听记录，说明当前环境下未发现该端口的监听服务。

接着测试后端HTTP响应：

curl --noproxy '*' --connect-timeout 5 --max-time 10 \
  -sS -D - -o /dev/null -H 'Host: example.com' \
  http://127.0.0.1:8080/

请将域名、端口和路径替换为实际值，Host应与代理转发给后端的值一致。

根据结果继续排查：

连接被拒绝： 检查应用进程、监听端口和绑定地址。
连接超时： 检查网络路径、访问规则及后端是否卡住。
返回HTTP响应： 说明本次请求已到达HTTP服务，还需判断状态码和业务内容是否正常。

首页返回200，并不能证明其他接口正常。应继续测试原先出现502的页面或接口。

注意：PHP-FPM使用FastCGI协议，不能用上述HTTP请求直接测试其9000端口。

3. PHP网站检查PHP-FPM

如果静态页面正常，PHP页面报502，应优先检查PHP-FPM。

以服务名php8.3-fpm为例：

sudo systemctl status php8.3-fpm --no-pager
sudo journalctl -u php8.3-fpm --since "30 minutes ago" --no-pager

实际名称可能是php-fpm或其他版本名称；面板安装的PHP也可能由面板管理。

重点核对PHP-FPM池配置中的listen，是否与Nginx的fastcgi_pass一致。

例如，PHP-FPM配置为：

listen = /run/php/php8.3-fpm.sock

对应的Nginx配置应指向同一Socket：

fastcgi_pass unix:/run/php/php8.3-fpm.sock;

升级PHP后，如果Nginx仍然指向旧版本Socket，就可能持续出现502。

遇到权限错误，应检查Socket所属用户、用户组和父目录权限，并通过PHP-FPM的权限配置进行修正。不要直接使用chmod 777作为通用解决办法。

4. Docker部署检查容器和网络

如果后端运行在Docker中，先查看容器状态和近期日志：

docker ps -a
docker logs --since 30m --tail 100 app
docker port app

其中app需要替换为实际容器名称。

常见问题是把容器内的127.0.0.1误认为宿主机或其他容器。

在常见桥接网络部署中：

部署方式	连接地址检查重点
Nginx在宿主机，应用在容器	核对容器发布到宿主机的地址和端口
Nginx与应用分别在容器中	核对是否加入同一自定义网络，并使用可解析的服务名和容器端口
应用容器反复退出	先查看启动日志、配置及依赖服务

例如，两个容器处于同一自定义网络，后端服务名为app且监听8080端口时，代理地址可能是：

proxy_pass http://app:8080;

后端还需要监听容器内可被其他容器访问的地址。仅监听自身回环地址，可能导致其他容器无法连接。

宿主机访问成功，也不能直接证明Nginx容器能够访问，应从Nginx所在的网络环境继续验证。

5. 检查资源不足和后端异常退出

如果网站平时正常，高峰期频繁出现502，需要结合故障时间检查资源和应用日志：

free -h
df -h
df -i
sudo journalctl -k --since "30 minutes ago" --no-pager

重点关注：

内存是否不足，是否出现OOM终止进程的记录。
磁盘空间或inode是否耗尽。
后端是否在报错时间附近退出或重启。
数据库、缓存等依赖服务是否异常。
PHP-FPM是否出现工作进程达到上限的提示。

不要看到PHP-FPM繁忙就直接大幅增加pm.max_children。应先评估单个进程占用的内存，并检查慢请求，否则可能进一步加重内存压力。

6. 核对代理协议和配置

后端进程存在、端口也正常，但网站仍然502时，需要核对实际请求使用的协议。

后端类型	配置检查重点
HTTP服务	`proxy_pass`应使用正确的HTTP地址
HTTPS服务	核对HTTPS地址、TLS握手及后端要求的SNI
PHP-FPM	使用`fastcgi_pass`连接正确的地址或Socket

如果日志提示响应头过大，应先检查异常Cookie、重复响应头等应用问题，再按HTTP代理或FastCGI类型评估对应缓冲参数。

调大超时时间不能解决所有502。 地址错误、连接被拒绝和Socket不存在，都需要修复具体原因。

7. 修复后验证配置并复测

Nginx检测配置并复测网站访问状态

完成必要的配置修改后，先检测，再重载Nginx：

sudo nginx -t && sudo systemctl reload nginx

以上命令适用于由systemd管理、服务名为nginx的环境。自定义安装、面板或容器部署，应使用对应实例的配置检测和重载方式。

nginx -t通过，只说明配置检测通过，并不代表后端一定可用。

接着复测网站：

curl --noproxy '*' --connect-timeout 5 --max-time 10 \
  -sS -D - -o /dev/null https://example.com/

将域名和路径替换为实际故障地址，并在浏览器中确认页面内容正常。

验证时应同时确认：

原来报错的页面或接口已恢复。
Nginx没有新增同类错误。
后端进程保持稳定，没有反复退出。
登录、查询等相关业务功能正常。

如果只修复了后端故障，没有修改Nginx配置，通常无需额外重载Nginx。

8. 常见问题

502和504有什么区别？

502表示网关从上游收到无效响应；504表示网关未能及时收到所需的上游响应。具体原因仍需结合产生错误的那一层日志判断。

重启服务器能解决吗？

重启可能暂时恢复服务，但配置错误、程序缺陷和资源不足可能再次触发故障。应先保留日志并定位原因，再决定是否需要重启相关服务。

只有开启CDN后才出现502怎么办？

应对比CDN回源和直接访问源站的结果，核对回源地址、端口、协议、Host及HTTPS相关设置。源站如果只允许CDN节点访问，直接测试失败也不能单独证明源站故障。

需要提交哪些排查信息？

联系莱卡云技术支持时，可提供实例信息、故障时间及所在时区、访问域名、报错路径、相关日志和近期变更记录。提交前请删除密码、令牌、Cookie等敏感内容。

处理网站502时，先找到产生错误的网关及其上游地址，再沿着日志检查后端服务，通常能够更快缩小故障范围。