40

我有我的网站正在使用 nginx，并使用标头测试工具测试网站，例如http://www.webconfs.com/http-header-check.php但每次它说下面的 400 bad request 都是该工具的输出. 虽然我所有的页面在浏览器中加载都非常好，当我在 chrome 控制台中看到它时显示状态代码 200OK。

HTTP/1.1 400 Bad Request => 
Server => nginx
Date => Fri, 07 Sep 2012 09:40:09 GMT
Content-Type => text/html
Content-Length => 166
Connection => close

我真的不明白我的服务器配置有什么问题？

一些谷歌搜索建议使用增加缓冲区大小，我将其增加到以下内容：

large_client_header_buffers 4 16k;

同样的结果仍然存在。

有人可以引导我走向正确的方向吗？

4

8 回答 8

78

正如 Maxim Dounin 在上述评论中所说：

当 nginx 返回 400（错误请求）时，它会将原因记录到“信息”级别的错误日志中。因此，找出正在发生的事情的一个明显方法是配置 error_log 以在“信息”级别记录消息，并在测试时查看错误日志。

于 2013-06-25T05:31:36.540 回答
22

是的，按照 Emmanuel Joubaud 的建议更改 error_to 调试级别（编辑 /etc/nginx/sites-enabled/default ）：

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

然后在重新启动 nginx 后，我使用 uwsgi 进入了我的 Python 应用程序的错误日志：

        2017/02/08 22:32:24 [debug] 1322#1322: *1 connect to unix:///run/uwsgi/app/socket, fd:20 #2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 connected
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream connect: 0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 posix_memalign: 0000560E1F25A2A0:128 @16
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream send request body
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer buf fl:0 s:454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer in: 0000560E1F2A0928
        2017/02/08 22:32:24 [debug] 1322#1322: *1 writev: 454 of 454
        2017/02/08 22:32:24 [debug] 1322#1322: *1 chain writer out: 0000000000000000
        2017/02/08 22:32:24 [debug] 1322#1322: *1 event timer add: 20: 60000:1486593204249
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http finalize request: -4, "/?" a:1, c:2
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http request count:2 blk:0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 post event 0000560E1F2E5E40
        2017/02/08 22:32:24 [debug] 1322#1322: *1 delete posted event 0000560E1F2E5DE0
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http run request: "/?"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream check client, write event:1, "/"
        2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream recv(): -1 (11: Resource temporarily unavailable)

然后我查看了我的 uwsgi 日志，发现：

        Invalid HTTP_HOST header: 'www.mysite.local'. You may need to add u'www.mysite.local' to ALLOWED_HOSTS.
        [pid: 10903|app: 0|req: 2/4] 192.168.221.2 () {38 vars in 450 bytes} [Wed Feb  8 22:32:24 2017] GET / => generated 54098 bytes in 55 msecs (HTTP/1.1 400) 4 headers in 135 bytes (1 switches on core 0)

并将www.mysite.local添加到 settings.py ALLOWED_HOSTS 解决了这个问题:)

        ALLOWED_HOSTS = ['www.mysite.local']
于 2017-02-08T22:50:40.623 回答
12

我有同样的问题并尝试了一切。这400发生在上游代理上。调试记录显示完全没有。

问题出在重复proxy_set_header Host $http_host指令中，我最初没有注意到。删除重复项立即解决了问题。我希望nginx说的不是400这种情况，因为nginx -t根本没有抱怨。

PS 这发生在从较旧的 nginx 迁移到1.10较新的 nginx 时1.19。在它显然被容忍之前。

于 2020-09-29T19:21:08.337 回答
7

只是为了清楚起见，在/etc/nginx/nginx.conf中，您可以在文件的开头放置该行

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

然后重启nginx：

sudo service nginx restart

这样你就可以详细说明 nginx 在做什么以及为什么它返回状态码 400。

于 2017-10-24T15:34:59.070 回答
6

原因可能是 URL 请求中的无效编码。例如 % 未编码传递。

于 2015-07-08T03:08:03.183 回答
2

当 nginx 返回 400（错误请求）时，它会将原因记录到错误日志中，在“信息”级别，并在测试时查看错误日志。

于 2020-03-23T12:37:30.687 回答
0

就我而言，问题是路由器中未打开端口 443

于 2021-10-27T13:59:10.280 回答
-1

通常，Maxim Donnie 的方法可以找到原因。但是我遇到了一个 400 bad request 不会记录到 err_log。我在 tcpdump 的帮助下找到了原因

于 2016-09-07T15:42:19.123 回答