遇到 Nginx 返回 5xx 时，最怕的不是报错本身，而是分不清问题到底出在 Nginx、后端服务，还是服务器资源与网络链路。本文把常见的 500、502、503、504 排查方法按“先定位、再分流、最后预防”的顺序整理出来，便于你根据日志特征快速缩小范围，也能判断该优先改配置、查服务，还是处理性能瓶颈。
先看错误日志，确认故障落点
排查 5xx 的第一步不是改配置，而是先读取 Nginx 错误日志。它通常位于 /var/log/nginx/error.log；如果当前环境做过自定义，也可以先用 nginx -V 确认编译参数和相关路径。
实时观察日志，最直接的办法是：
tail -f /var/log/nginx/error.log重点关注三类信息：
- 错误类型，例如
Permission denied、Connection refused、upstream timed out； - 报错关联的配置文件和行号，例如
conf.d/default.conf:10； - 后端服务抛出的具体异常，例如 PHP-FPM 日志中的
child exited on signal 11。
这一步的作用，是先把故障归到具体层级。比如看到权限错误，就先查文件访问权限；看到连接被拒绝，就转向后端服务状态和端口；看到超时，就优先怀疑后端处理慢、超时设置不足或网络延迟偏高。只有先把线索定准，后面的排查才不会变成盲目试错。
4 类常见 5xx 错误分别怎么查
500 Internal Server Error：优先查配置、脚本和权限
500 的成因通常比较杂，但高频问题往往集中在四类：Nginx 配置语法写错、后端脚本本身报错、服务器资源不足，以及 Nginx 进程没有足够权限访问站点文件或日志目录。
建议按下面的顺序处理：
- 先检查 Nginx 配置语法：
sudo nginx -t。如果有报错，按提示修正，比如补上break，或给变量补上$。 - 再检查后端脚本日志。PHP-FPM 常见日志位置是
/var/log/php-fpm/error.log或www-error.log，可据此定位语法错误、运行时异常，或通过调整memory_limit处理内存相关问题。 - 核实服务器资源：
df -h查看磁盘空间，确保/分区剩余空间大于 10%；free -m查看内存占用，尽量不要长期高于 80%。 - 最后检查权限。确认 Nginx 进程用户，如
www-data，对站点根目录有读取权限，例如chmod 755 /var/www/html；对日志目录有写入权限，例如chmod 775 /var/log/nginx。
如果日志中既没有明显的连接失败，也没有超时信息，500 往往更适合从配置语法、应用代码和本机资源这三个方向并行检查。
502 Bad Gateway：重点确认上游服务是否正常
502 一般表示 Nginx 作为网关时，拿不到可用的上游响应。最常见的情况是后端服务没有启动、端口或地址配置错误、Nginx 到后端的通信被防火墙拦截，或者后端进程已经崩溃。
排查时可以先做四件事：
- 确认后端服务状态：
systemctl status php-fpm，如果服务未启动，则执行systemctl start php-fpm。如果后端是 Tomcat，也按同样思路检查tomcat服务。 - 核对 Nginx 的
proxy_pass配置，确保 IP 与端口准确无误，例如proxy_pass http://127.0.0.1:9000;，避免把实际监听端口写成 8080 之类的错误值。 - 检查防火墙规则。Ubuntu 可查看
ufw status，CentOS 可查看firewalld status，确认没有拦截 Nginx 与后端之间的 9000、8080 等通信端口。 - 查看后端服务日志。如果 PHP-FPM 日志中出现
child exited on signal 11，通常意味着进程异常退出，需要继续回到代码和内存设置，例如检查数组越界、空指针等问题，必要时调整memory_limit = 256M。
判断 502 的关键点在于：Nginx 本身可能工作正常，真正异常的是它依赖的上游服务。只要把“服务是否在线、地址是否正确、链路是否可达”这三项核实清楚，问题范围通常会迅速缩小。
503 与 504：一个偏过载，一个偏超时
503 Service Unavailable 和 504 Gateway Timeout 经常一起出现，但两者的故障指向并不相同。503 更像是“当前服务扛不住”或“服务被主动关闭”，而 504 通常意味着“后端处理太慢，Nginx 等超时了”。
先看 503。常见原因包括服务器过载、数据库或 API 等后端服务不可用，以及误开启维护模式。可按以下顺序处理：
- 用
top或htop查看负载。如果%CPU持续超过 80%、%MEM超过 70%，就要考虑优化程序、限制流量或直接扩容。 - 直接测试后端接口，例如
curl http://127.0.0.1:8080/api。如果这里已经返回错误，说明问题不在 Nginx，而在后端服务本身；必要时可重启数据库，如systemctl restart mysql。 - 检查 Nginx 配置中是否存在维护模式，例如
location / { return 503; }，如果是误配，应注释或删除。 - 适当调整连接数。在
/etc/nginx/nginx.conf的events块里增大worker_connections，例如调整为 1024，并重启 Nginx 使其生效。
再看 504。它通常由后端处理时间过长、Nginx 超时设置偏短或网络延迟较高引起。对应处理方法如下：
- 先优化后端性能，例如为数据库建立索引、避免全表扫描，或把大文件上传改成切片上传。
- 根据实际处理耗时调整 Nginx 超时参数，可在对应
location中设置：
location /api {
proxy_pass http://backend;
proxy_connect_timeout 30s;
proxy_read_timeout 180s; # 关键参数，根据后端处理时间调整
proxy_send_timeout 30s;
}- 检查网络稳定性。使用
ping测试 Nginx 与后端之间的时延；如果超过 100ms，就需要继续排查链路质量、路由配置或跨地域部署带来的影响。 - 如果单台后端长期压力过大，可以引入负载均衡，通过
upstream分发请求：
upstream backend {
server 192.168.1.101:8080;
server 192.168.1.102:8080;
}
location /api {
proxy_pass http://backend;
}简单说，503 更偏“服务不可用”，要先确认是不是资源打满、依赖服务挂了，或者配置里主动返回了 503；504 则要重点判断慢点出现在应用、数据库、超时参数，还是网络链路。
想少遇到 5xx，日常要补上哪些预防措施
5xx 问题很难完全避免，但可以通过监控、备份和压力测试把大部分风险提前暴露出来。
- 监控与告警：用 Prometheus + Grafana 持续观察 CPU、内存、磁盘、请求量和错误率。比如把错误率超过 1% 设为告警阈值，尽量在用户大面积感知前发现问题。
- 定期备份：将
/etc/nginx/下的配置文件和/var/www/html/下的网站数据纳入定期备份，避免配置误改或数据损坏后难以及时恢复。 - 压力测试：用 JMeter 或 Locust 模拟高并发访问，提前找出瓶颈。例如在并发量超过 1000 时出现 502，就说明当前后端实例数、连接数或资源配置已经不足。
从运维实践看，5xx 真正难处理的地方并不是单个报错码，而是定位路径混乱。只要固定成“先日志、再分类型、再查资源和后端、最后复盘预防”的流程，大多数故障都能在较短时间内找到原因。
