如何修复nginx在任何标头测试工具上抛出400个错误的请求标头？

Question

我的网站正在使用nginx,测试网站使用标头测试工具,例如http://www.webconfs.com/http-header-check.php,但每次下面说400次错误请求都是工具的输出.虽然我的所有页面在浏览器中都可以很好地加载,但是当我在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;

同样的结果仍然存在.

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

Answer 1

正如Maxim Dounin在上述评论中所述:

当nginx返回400(错误请求)时,它会将原因记录到错误日志中,位于"info"级别.因此,找出正在发生的事情的一个明显方法是配置 error_log 以在"info"级别记录消息,并在测试时查看错误日志.

Answer 2

是的,正如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_CONFIGS修复了问题:)

        ALLOWED_HOSTS = ['www.mysite.local']

Answer 3

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

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

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

Answer 4

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

Answer 5

只是为了澄清，在/etc/nginx/nginx.conf中，您可以在文件的开头放置以下行：

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

然后重启nginx：

sudo service nginx restart

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