NGINX 反向代理：许多 html 状态代码 400 响应，为什么？
我们最近实现了一个基于 nginx 的反向代理。
在调试访问日志时，我们看到大量状态代码 400 结果。
它们看起来像这样：
[07/Sep/2011:05:49:04 -0700] - "400" 0 "-" "-" "-"
我们已经启用了调试错误日志记录，它们通常对应于这样的内容：
2011/09/07 05:09:28 [info] 5937#0: *30904 client closed prematurely connection while reading client request line
我们已经尝试提高一些缓冲区，正如我们能够通过谷歌搜索到的几页所提到的那样。
http://www.ruby-forum.com/topic/173362
或
无济于事。
为什么会发生这种情况？
这是一个标准的 nginx 反向代理 ->阿帕奇后端服务器。
值得一提的是，我们网站上的独特内容类型相当少。我们已经使用许多浏览器对此进行了测试，并且个人并未收到这 400 个结果中的任何一个。
谢谢！
详细说明日志中类似条目的更多网址：
http:// blog.rayfoo.info/2009/10/weird-web-server-access-log-entries
We have recently implemented a nginx based reverse proxy.
While, debugging our access logs, we are seeing quite a bit of status code 400 results.
They look something like this:
[07/Sep/2011:05:49:04 -0700] - "400" 0 "-" "-" "-"
We have enabled debug error logging, and they usually correspond to something like this:
2011/09/07 05:09:28 [info] 5937#0: *30904 client closed prematurely connection while reading client request line
We have tried raising a number of the buffers, as mentioned by a few pages we were able to google up.
http://www.ruby-forum.com/topic/173362
or
To no avail.
Why is this happening?
This is a strandard nginx reverse proxy -> apache backend server.
Worth mentioning, the unique type of content on our site is fairly minimal. We have tested this using many browsers and are not personally receiving any of these 400 results.
Thanks!
Further urls detailing similar entries in their logs:
http://blog.rayfoo.info/2009/10/weird-web-server-access-log-entries
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现这是由使用
Chrome引起的，它显然偶尔会打开额外的连接而不发送任何数据。以下是更多信息：http://www.ruby-forum.com/topic/2953545
现在的问题是如何处理它们 - 提供的答案不是很令人满意。
I found this was caused by using
Chrome, which apparently opens extra connections occasionally without sending any data.Here's some more info: http://www.ruby-forum.com/topic/2953545
Now the question is what to do about them - the answer provided there wasn't very satisfying.
您正在处理 SSL 连接吗？您可以将
$ssl_cipher $ssl_protocol添加到您的访问日志格式中吗？Are you handling SSL connections? Can you add
$ssl_cipher $ssl_protocolto your access log format?首先，您的客户端很有可能发送带有非常大的 http 标头或 url 的请求。也许您的应用程序的旧版本设置了一些（可能很大）cookie，这些cookie现在未使用，并且一些客户端仍在尝试将它们发回。
我将标头缓冲区设置为一个非常大的值，并在应用程序端记录标头/请求的大小以及完整的请求（如果它们比平常大）。或者从链中完全取出 nginx，并以相同的条件记录标头/请求。如果可以的话，仅删除 400 错误来源的 IP/子网的 nginx。我想 nginx 可以记录这些 400 错误的源 IP。
First, it's fairly possible that your clients send request with really big http headers or urls. Maybe an older version of your application set some (probably big) cookies which are unused now and some clients are still trying send them back.
I'd set the header buffers to a really big value and on the application side log the size of the headers/requests and the complete request if they are bigger than usual. Or completely take out the nginx from the chain and log the header/request with the same conditions. If you can, take out the nginx for only those IPs/subnets where the 400 errors came from. I suppose nginx can log the source IP for these 400 errors.