Nginx 400错误怎么产生的，如何定位，如何解决?

off999 2025-01-23 20:16 35 浏览 0 评论

nginx400错误如何产生的呢？遇到问题该如何定位呢？

今天遇到一个比较难以解释的问题，上传一个大文件时（比如20M）接口请求日志已经在nginx的access.log中打印了，并且报400，但是nginx并没有转发到后端服务器。同样的接口，如果上传一个小一点的文件（比如10M）是能够正常处理的。

先来看看我的定位流程。

定位流程

web端查看错误信息。
后端查看网关、应用服务的日志信息，发现没有任何调用日志打印出。
怀疑是nginx配置的问题，限制了请求的报文大小。
检测nginx配置正常，client_max_body_size配置的很大，不存在配置过小的问题。
查看nginx服务access日志，发现报400错误。
通过curl在网关服务器上调用与web相同的配置的接口，文件使用50M（比发生错误的20M文件还大）文件，请求正常。

疑问

上面的定位结果，让我很费解。

既然curl调用web端相同配置的接口正常说明网关和应用服务配置没有问题，不存在后端服务对报文大小的限制问题。

但是nginx已经有打印了接口日志，为什么没有到转发到网关呢？

根据定位的信息进行假设，如果请求没有到打到nginx可以理解，就是中间的网络限制的报文长度；可是目前现象是到了nginx却没有转发，但同样的请求只要文件较小就正常处理，说明是文件较大的原因。

后来和同事讨论，认为是web端经过一系列网络才能到达nginx，中间的网络对请求的大小进行了限制，请求虽然到达了nginx，但是文件却没有完全接收，导致nginx等待一定时间后超时导致400报错。

因为刚开始对nginx打印了错误日志，却没有转发想不通，所以专门去确认了一下nginx打印access日志时，报文是不是完全接收完成了。事实是nginx接收到了报文头并没有完全接收完报文最后也是会打印access日志的。

nginx打印接口日志时，请求内容并不一定全部接收了

下面来看下nginx的打印日志的处理逻辑：

1.当nginx打印接口日志时，请求文件中的数据不一定全部接收到了。这取决于nginx配置中的client_max_body_size参数和请求文件的大小。

client_max_body_size参数限制了nginx允许接收的请求体大小。如果请求文件的大小超过了该值，nginx将会返回一个413 Request Entity Too Large错误，此时请求文件中的数据并没有被完全接收。

2.如果请求文件的大小小于等于client_max_body_size，nginx在接收到报文头后，会根据请求头字段：Content-Length中的大小尝试将整个请求文件读入内存中。如果读入时发生了错误，例如网络故障，那么请求文件中的数据也不会被完全接收，如果超过一定时间没有读取完Content-Length长度的数据会报400错误。

常见nginx 400原因

request_uri 过长超过nginx配置大小。
cookie或者header过大超过nginx配置大小。
请求头HOST字段为空。
content_length和body长度不一致。
网络传输丢包导致的400异常。
原因是客户端Post请求包在网络传输过程中部分丢失导致nginx不能接收完成的报文，客户端超时断开连接（客户端超时后发RST报文断开连接），这时候nginx记录了400，其实也就是content_length和body长度不一致的问题。

这些错误其实都是发生在nginx这一层，即nginx处理时认为客户端请求格式错误，于是直接返回400，不会向upstream server转发请求，因而upstream server对这些错误请求其实完全是无感知的。

还有要注意的一点是，日后分析nginx日志，还要看看access日志中upstream_addr是否已经是upstream server的有效地址了，如果有说明已经是正常转发到了，如果没有说明nginx层就已经错误了，没有继续向后转发。

定位结论

根据日志和nginx相关知识，我们得出了以下结论。

1、在服务器上通过curl命令是可以上传50M的大文件的。

2、web端上传20M的大文件时，会出现nginx报400错误，但是没有转发到我们的网关，说明nginx并没有继续转发。

3、在服务器上使用curl能够正常上传，可以确定我们的配置没有什么问题（不会限制大文件）。

4、给出的结论是，因为通过web端上传时，经过了一系列网络（比如网络映射等），根据nginx的400报错，可以推断出在我们的nginx之前的网络对了请求的大小做了限制，我们的nginx收到的请求头大小和收到的报文长度不一致报400，相当于nginx一直等待到超时，但是由于nginx之前的网络做了请求限制，导致超时。

分析nginx日志