500是后端程序执行失败，查应用日志；502是Nginx与后端通信中断，检查后端存活及响应有效性；503是服务主动拒收请求，排查限流、健康检查或资源耗尽；504是后端响应超时，调整proxy_read_timeout等超时参数。
Linux 下 Nginx 遇到 500、502、503、504 这四类状态码，表面看都是“服务器出错了”，但背后指向的故障层级、责任方和排查路径完全不同。快速区分它们，是缩短故障恢复时间的关键。
500 Internal Server Error：后端程序执行失败
这不是 Nginx 的问题，而是它转发请求后，后端应用（如 PHP、Java、Node.js）在处理过程中抛出了未捕获异常、语法错误、数据库连接失败、空指针等内部错误，最终返回了一个无意义或格式异常的响应体，Nginx 只能兜底返回 500。
- 重点查后端日志（如 php-fpm.log、application.log 或 stdout/stderr），不是 Nginx error.log
- 前端 Network 面板里看 Response Body，有时会带堆栈或 message 字段（即使状态码是 500）
- 常见诱因：代码逻辑缺陷、环境变量缺失、依赖服务不可达、内存溢出导致进程崩溃
502 Bad Gateway：Nginx 与后端通信中断
Nginx 成功连上了后端（比如 127.0.0.1:8080），但后端没给它一个合法的 HTTP 响应——可能是进程已死、连接被重置、响应头格式错误、或者数据包被截断。它本质是“代理收到了垃圾数据”。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 先确认后端服务是否存活：curl -v http://127.0.0.1:8080/health 或 ss -tlnp | grep :8080
- 检查 Nginx error.log，典型报错如 "upstream prematurely closed connection" 或 "no live upstreams"
- 高频原因：后端进程意外退出、PHP-FPM worker 耗尽、proxy_buffer 参数过小导致大响应体丢包、SELinux 或防火墙拦截了回环通信
503 Service Unavailable：服务主动拒收请求
后端本身可能正常，但 Nginx 或后端主动拒绝了当前请求。常见于限流、维护模式、资源枯竭等有意识的保护行为，属于“我暂时不接单”，而非“我挂了”。
- 检查 Nginx 配置中是否有 limit_req、limit_conn 或 return 503 指令
- 查看 upstream 块是否配置了 max_fails 和 fail_timeout，触发健康检查失败后自动摘除节点
- 后端若使用连接池（如数据库），连接池满也会向上游返回 503；PHP-FPM 的 pm.max_children 耗尽时同样如此
504 Gateway Timeout：后端响应太慢，Nginx 先放弃了
Nginx 已和后端建立连接并发出请求，也收到了部分响应（比如响应头），但等不到完整响应体就超时了。此时后端很可能还在跑，只是卡在 SQL、IO 或第三方调用上。
- error.log 中典型提示："upstream timed out (110: Connection timed out) while reading response header from upstream"
- 关键参数有三个：proxy_connect_timeout（建连）、proxy_send_timeout（发请求）、proxy_read_timeout（等响应）——需按业务耗时合理调大
- 注意：proxy_read_timeout 不是“总耗时上限”，而是“两次读操作之间的间隔上限”，长响应体分块传输时容易误判超时
