Linux Server Nginx Access log has a large number of HTTP 400 error request analysis _linux

Error logging in the server is similar to this:

124.65.133.242––[27/oct/2014:14:30:51 +0800] "-" 400 0 "-" "-"
124.65.133.242––[27/oct/2014:14:31:45 +0800] "-" 400 0 "-" "-"
124.65.133.242––[27/oct/2014:14:31:45 +0800] "-" 400 0 "-" "-"
124.65.133.242––[27/oct/2014:14:31:45 +0800] "-" 400 0 "-" "-"

Casing

After analyzing the log files of Nginx, it is found that a number of 400 errors are generated after a normal visit, each of which is about 1-6 consecutive occurrences, and not every time a client accesses a 400 error.

It is normal to observe the previous visit that produces 400 errors, 200 status code, normal files, normal antecedents, normal user-agent ... Everything is harmonious, that 400 is swollen?

Careful observation found that all the previous visits to the 400 error user-agent were left by Google Chrome, which means that 400 errors were generated by chrome browsers. But after a local grab, it was found that Chrome did not send an exception request or packet to the server.

In the packet analysis, it was found that when Chrome accesses the server, it initiates more than one connection, typically ranging from 5 to 6, and if the requested resource does not require so many connections, chrome closes the unused connection, a technique called pre-connection "pre-connect."

Usually when we visit a website, the first to get an HTML main file, and the inside link to the page required CSS, JS, pictures and other media resource files, while the general resource file and the main HTML file is in a domain, the advance connection is to get HTML before the establishment of a lot of TCP connections, Instead of waiting until you get the HTML file to connect to the server to get other files, because it takes some time to connect to the server, this technology can greatly speed up the rendering of the Web page.

If the Web page HTML link resources are less, or the client has a cache, do not need to download the connection, then the 5-6 connections made by the Chrome browser are likely to be only 1 are needed, the others have to shut down, which creates a problem: Connect the server, without sending any requests. In this case, the nginx is handled as a 400 error, but because the connection is turned off, the error message is not sent to the client, which results in an error recorded in the log file, and nothing is seen in the grab packet analysis.

Test
to verify the results of the above analysis is very simple, open the command line Cmd.exe, in which the input Telnet ServerIP 80, waiting for the connection to be successful after the direct switch off cmd, then to view the Nginx log file in a more than a 400 error record.

A remark
Pre-connection's advantages have been very clear, but it is also flawed, if the webmaster did the optimization, the use of Cookie-free technology, or Web pages and static resources using a different server, then the page needs CSS, JS Resources and the main HTML is not in the same domain, may not be the same IP, then pre-connection is not only a chicken, but also to the main HTML server will have an unnecessary burden.

Other reasons

Many people on the internet wrote related articles, the majority of people because the header size is too large, causing response 400 is bad request. But there is another possibility, just like the port test tool, is to check if the port is alive. such as LVS, and so on, will cause this problem, and then there will be a large number of 400 errors in the log.

You can mitigate this problem by nginx.conf the client_header_buffer_size and large_client_header_buffers for the above issues.