blocks|key|482679|text|原因可能是URL请求中的无效编码。例如%25未编码地传递。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|482680|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

A cause can be invalid encoding in the URL request. Such as % being passed un-encoded.

blocks|key|482725|text|通常，Maxim+Donnie的方法可以找到原因。但我遇到了一个400坏的请求将不会记录到err_log。我在tcpdump的帮助下找到了原因|type|unstyled|depth|inlineStyleRanges|entityRanges|data|482726|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

normally, Maxim Donnie's method can find the reason. But I encountered one 400 bad request will not log to err_log. I found the reason with the help with tcpdump

blocks|key|482803|text|是，按照Emmanuel+Joubaud的建议更改站点调试级别(编辑/etc/nginx/+error_to+-enabled/default+)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|482804|++++++++error_log+/var/log/nginx/error.log+debug;|code-block|syntax|javascript|482805|然后，在使用uwsgi重启nginx之后，我得到了Python应用程序的错误日志：|482806|++++++++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)|482807|然后我看了看我的uwsgi日志，发现：|482808|++++++++Invalid+HTTP_HOST+header:+'www.mysite.local'.+You+may+need+to+add+u'www.mysite.local'+to+ALLOWED_HOSTS.
++++++++[pid:+10903%7Capp:+0%7Creq:+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)|482809|向settings.py+ALLOWED_HOSTS添加www.mysite.local解决了此问题:)|offset|length|482810|++++++++ALLOWED_HOSTS+=+['www.mysite.local']|482811|entityMap|0|LINK|mutability|MUTABLE|url|http://www.mysite.local/^0|0|0|0|0|0|0|S|G|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|13|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|14|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|15|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|17|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|18|8|@]|9|@$Q|19|R|1A|1|1B]]|A|$]]|$1|S|3|T|5|D|7|1C|8|@]|9|@]|A|$E|F]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

Yes changing the error_to debug level as Emmanuel Joubaud suggested worked out (edit /etc/nginx/sites-enabled/default ):
<pre><code> error_log /var/log/nginx/error.log debug;
</code></pre>
Then after restaring nginx I got in the error log with my Python application using uwsgi:
<pre><code> 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, &quot;/?&quot; 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: &quot;/?&quot;
 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream check client, write event:1, &quot;/&quot;
 2017/02/08 22:32:24 [debug] 1322#1322: *1 http upstream recv(): -1 (11: Resource temporarily unavailable)
</code></pre>
Then I took a look to my uwsgi log and found out that:
<pre><code> 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 / =&gt; generated 54098 bytes in 55 msecs (HTTP/1.1 400) 4 headers in 135 bytes (1 switches on core 0)
</code></pre>
And adding <a href="http://www.mysite.local" rel="noreferrer">www.mysite.local</a> to the settings.py ALLOWED_HOSTS fixed the
issue :)
<pre><code> ALLOWED_HOSTS = ['www.mysite.local']
</code></pre>

blocks|key|482873|text|当nginx返回400(错误请求)时，它会在"info“级别将原因记录到错误日志中，并在测试时查看错误日志。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|482874|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

When nginx returns 400(bad request) it will log the reason into error log, at "info" level and take a look into error log when testing.

blocks|key|482945|text|我遇到了同样的问题，并尝试了所有方法。此400发生在上游代理上。调试记录完全没有显示任何内容。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|482946|问题出在duplicate+proxy_set_header+Host+$http_host指令中，我最初没有注意到这一点。删除重复的一个立即解决了问题。我希望nginx在这个场景中说的不是400，因为nginx+-t根本没有抱怨。|482947|附注:从旧的nginx+1.10迁移到新的1.19时发生了这种情况。在它被明显容忍之前。|482948|entityMap^0|K|3|0|E|W|28|5|2N|3|2T|8|0|C|4|L|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@$9|Y|A|Z|B|C]|$9|10|A|11|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|K|$]]

I had the same issue and tried everything. This <code>400</code> happened for an upstream proxy.
Debug logged showed absolutely nothing.
The problem was in duplicate <code>proxy_set_header Host $http_host</code> directive, which I didn't notice initially.
Removing duplicate one solved the issue immediately.
I wish <code>nginx</code> was saying something other than <code>400</code> in this scenario, as <code>nginx -t</code> didn't complain at all.
P.S. this happened while migrating from older nginx <code>1.10</code> to the newer <code>1.19</code>. Before it was tolerated apparently.

blocks|key|266064|text|在我的例子中，问题是端口443没有在路由器中打开|type|unstyled|depth|inlineStyleRanges|entityRanges|data|266065|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

In my case, the issue was that port 443 wasn´t opened in the router

I have my site which is using nginx, and testing site with header testing tools e.g. <a href="http://www.webconfs.com/http-header-check.php" rel="noreferrer">http://www.webconfs.com/http-header-check.php</a> but every time it says 400 bad request below is the out put from the tool. Though all my pages load perfectly fine in browser and when I see in chrome console it says status code 200OK.

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

I really don't understand what is the problem with my server config?

A bit of googling suggests to increase the buffer size using, and I increased it to following:

<pre><code>large_client_header_buffers 4 16k;
</code></pre>

The same results persist. 

Can some one guide me to the right direction?

How to fix nginx throws 400 bad request headers on any header testing tools?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有我的网站，这是使用nginx，测试网站与头测试工具，如，但每次它说400个坏的请求下面是从工具输出。虽然我所有的页面在浏览器中都加载得很好，但当我在chrome控制台中看到它时，它会显示状态代码200OK。HTTP/1.1 400 Bad Request => Server => nginxDate => Fri,...

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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