一张图读懂Nginx常规报错，让处理报错信手拈来-平芜编程栈

上周帮一个同事排查问题，他说上传一个8M的图片报413，问我是不是Nginx出bug了。

我一看，client_max_body_size默认是1M，改到100M就好了。但他说改完了还是不行——原来后端的PHP也没配，upload_max_filesize还是2M。

一个413，折腾了他一下午。

这件事让我想把Nginx常见的报错整理一下。502、504、499、403、413、400，每个报错代表什么问题？怎么一步步排查？今天一张图讲清楚。下次你再遇到，10分钟内就能定位到问题层。

一张图表带你走通Nginx报错排查路线图

先上干货。把最常见的几个报错按“问题出在哪一层”分了类：

收到Nginx报错 → 是4xx还是5xx？
4xx（客户端问题）→ 检查客户端请求格式、权限
5xx（服务端问题）→ 检查后端服务状态、超时配置

下面我把每个报错拆开讲，结合我遇到过的案例。

方向一：502 Bad Gateway——后端挂了或连不上

这是我遇到最频繁的报错。

第一次遇到502，我以为是Nginx的问题，重启了好几次Nginx，没用。后来才发现，是后端的PHP-FPM进程挂了。

502的本质：Nginx作为网关，向后端（PHP-FPM、Tomcat、Node.js）发请求，但没收到有效响应。

常见原因和排查方法：

原因	怎么确认	怎么解决
后端服务没启动	`ps aux	grep php`
后端服务崩了	看后端日志	修复bug，加监控自动重启
后端端口不对	`netstat -anp	grep 端口`
防火墙拦了	`telnet 后端IP 端口`	开端口

我当时怎么排查的：

遇到502，先做三件事：

后端服务在不在？ps aux | grep -E "php|java|node"
端口通不通？curl -v http://127.0.0.1:8080
Nginx error.log说了什么？tail -f /var/log/nginx/error.log

这三步走完，90%的502都能定位。

配置层面的预防：

location / { proxy_pass http://backend_servers; proxy_next_upstream error timeout invalid_header http_500 http_502 http_503; proxy_next_upstream_tries 2; }

这样配之后，一个后端挂了，Nginx会自动尝试下一个。

方向二：504 Gateway Timeout——后端干活太慢了

504和502经常被搞混。

502= 后端没响应（挂了或连不上）
504= 后端响应了，但太慢了，Nginx等得不耐烦了

504的本质：Nginx向后端发了请求，在proxy_read_timeout规定的时间内没收到完整响应，主动断开了。

常见场景：

场景	为什么超时	怎么办
后端处理慢	数据库查询慢、调用外部API慢	优化后端性能，或加缓存
上传大文件	文件大，上传时间长	调大`client_body_timeout`
后端有慢SQL	SQL跑了几十秒	优化SQL，加索引
PHP执行超时	`max_execution_time` 太小	调大PHP配置

我当时怎么排查的：

有一次导出报表，点完按钮转了30秒，然后504了。Nginx error.log显示：

upstream timed out (110: Connection timed out) while reading response header from upstream

马上明白是超时时间太短。默认proxy_read_timeout是60秒，报表导出要90秒。

怎么解决：

location /report/ { proxy_pass http://backend_servers; proxy_read_timeout 120s; # 给报表导出加长时间 }

⚠️注意：不要全局调大超时时间。只有确实需要长时间处理的接口才单独配，否则一个慢接口会拖住所有请求。

方向三：499 Client Closed Request——用户等不及关掉了

这个报错比较特殊。它不是Nginx主动报的，是客户端主动断开连接时Nginx记录下来的。

本质：用户发请求给Nginx，Nginx转给后端，后端还在处理，用户等不及关了浏览器/点了取消。

常见场景：

场景	说明
接口响应慢	用户转了几圈就关了
移动端网络差	请求发出去，信号断了
爬虫/脚本	设置了超时时间，到点断开
用户狂点刷新	上一个请求还没完，又发了新的

499是不是问题？

正常用户偶尔499 →可以接受
大量499 → 说明后端响应太慢，用户等不及都跑了 →这是业务问题

怎么排查：

看Nginx access.log，统计499的比例：

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

如果499很多，同时504也很多，说明后端太慢。如果只有499没有504，可能是用户网络问题。

方向四：403 Forbidden——权限不够

403相对好排查，就是Nginx没有权限读这个文件，或者配置不允许访问。

常见原因：

原因	怎么解决
文件权限不对	`chmod 755` 或`chown www-data`
SELinux拦了	`setenforce 0` 临时关掉测试，确认后配策略
index指令没配	访问目录但没有index文件，且`autoindex off`
禁止IP访问	检查`deny`指令

我遇到的一个真实案例：

配了一个新站点，html文件都放好了，访问就是403。查了半天，发现是SELinux在作怪。

临时关闭测试：setenforce 0
永久关闭（生产慎用）：vi /etc/selinux/config改SELINUX=disabled

方向五：413 Request Entity Too Large——文件太大了

上传大文件时遇到的经典报错。

本质：client_max_body_size限制了请求体大小，默认是1M。

怎么解决：

client_max_body_size 100M;

⚠️注意：只配Nginx不够，后端也要配。比如PHP要改upload_max_filesize和post_max_size。

方向六：400 Bad Request——请求格式有问题

400相对少见，但遇到就很头疼，因为Nginx给的提示很少。

常见原因：

原因	说明
请求头太大	Cookie太多，超过了`large_client_header_buffers`
Host头不对	请求的域名Nginx不认识
请求格式错误	非HTTP协议的数据打到了80/443端口

排查方法：

error_log /var/log/nginx/error.log debug;

然后看error.log里有没有具体提示。

一个真实的排查案例

上周同事跑过来说：“网站502了，帮我看看。”

我按路线图走了一遍：

第1步：看Nginx error.log
connect() failed (111: Connection refused) while connecting to upstream
“Connection refused” = 后端端口没监听

第2步：检查后端服务
ps aux | grep java（没输出）

第3步：启动服务
systemctl start myapp
curl localhost:8080（通了）

5分钟搞定。同事说他自己折腾了半小时。

排查路线图的价值就在这里——不慌，一步一步来，10分钟内一定能定位到问题层。

常见报错速查表

报错	中文意思	问题在哪	第一反应
502	网关错误	后端挂了	`ps` 看后端在不在
504	网关超时	后端太慢	看是不是慢SQL/大文件
499	客户端断开	用户等不及	看后端响应时间
403	禁止访问	权限不足	检查文件权限/SELinux
413	实体太大	文件超限	调大`client_max_body_size`
400	错误请求	请求格式不对	看debug日志
404	找不到	路径不对	检查`root`和`try_files`