现象

用户访问网站时，浏览器返回 HTTP 5xx 状态码。500 为服务器内部错误，502 为网关错误，503 为服务不可用，504 为网关超时。不同代码代表故障点不同，需精准区分。

原因

500 错误通常由后端应用（如 PHP、Java）代码异常、配置文件语法错误或权限问题引起。502 错误多为反向代理（Nginx/Apache）无法从上游服务（PHP-FPM、Node.js）获取有效响应，常因上游进程崩溃或端口不通。503 错误表示服务器过载或维护模式，常见于资源耗尽或限流策略触发。504 错误则是上游服务响应时间超过代理设定的超时阈值，多因代码执行慢或数据库查询卡顿。

先自查（3 分钟）

首先确认故障范围。若仅单台服务器出错，重点检查该节点；若多台同时出错，考虑网络或共享资源问题。立即查看 Web 服务器错误日志，这是定位 5xx 错误最快的手段。不要直接重启服务，先保留现场日志。

登录服务器，查看 Nginx 或 Apache 错误日志。Ubuntu/Debian 默认路径如下：

tail -n 50 /var/log/nginx/error.log

若是 Apache，查看：

tail -n 50 /var/log/httpd/error_log

根据日志中的报错信息（如 "Bad Gateway"、"Connection refused"、"Timeout"）初步判断是 502 还是 504，或是 500 的具体代码异常。

解决步骤

针对 500 错误，重点检查后端应用日志和配置。以 PHP 为例，检查 PHP 错误日志：

tail -n 50 /var/log/php8.2-fpm.log

若提示配置文件语法错误，使用 PHP 检查配置：

php -l /etc/php/8.2/fpm/pool.d/www.conf

针对 502 错误，验证上游服务进程是否存活。检查 PHP-FPM 状态：

systemctl status php8.2-fpm

若进程未运行或处于 failed 状态，尝试重启：

注意：重启服务会短暂中断当前请求，建议在业务低峰期操作。

systemctl restart php8.2-fpm

若进程正常但仍报 502，检查端口监听情况（默认 9000）：

ss -tlnp | grep 9000

针对 503 错误，检查系统资源。查看 CPU 和内存使用率：

top -bn1 | head -20

若资源占用极高，检查是否有进程僵死或并发量过大。临时缓解可重启 Web 服务，但需解决根本的资源瓶颈。

针对 504 错误，检查超时设置。在 Nginx 配置中，调整 proxy_read_timeout 等参数。编辑 Nginx 主配置：

注意：修改配置前建议备份原文件。

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

使用 vi 或 nano 编辑，找到 http 或 server 块，增加或修改超时时间（单位秒）：

proxy_read_timeout 60s;
proxy_connect_timeout 10s;

测试配置语法并平滑重载：

nginx -t
systemctl reload nginx

验证

执行上述操作后，使用 curl 命令在服务器本地测试，确认状态码恢复正常：

curl -I http://localhost

若返回 200 或 301/302 状态码，说明服务已恢复。随后在浏览器清除缓存后重新访问，确认前端显示正常。持续监控日志 5 分钟，确保无新错误产生。

预防

建立日志轮转机制，避免日志文件过大占用磁盘空间。定期监控服务器 CPU、内存及磁盘 I/O，设置告警阈值。优化应用代码，避免长事务和死循环。为 Web 服务器配置合理的超时参数和连接池大小。定期备份配置文件，防止误操作导致服务不可用。

在奇异互动如何最快处理

若通过日志确认是代码或配置问题，请自行修复。若怀疑是底层硬件故障或网络不通，进入会员中心「云服务器详情页」，点击「VNC 控制台」查看系统是否卡死或蓝屏。若 VNC 显示系统正常但网络不通，可尝试「重启」实例。若重启无效且确认非代码问题，直接提交工单，选择关联具体云服务器产品，并附上「错误日志截图」、「Nginx 配置片段」及「发生时间点」，以便工程师快速定位。