How to solve a large number of http 400 errors in the Linux server nginx access log

The error record 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 “-” “-”

看点

After analyzing the nginx log file, it was found that several 400 errors were generated after a normal access. Each time There may be 1-6 consecutive occurrences, and not every customer visit will generate a 400 error.

It is normal to observe the previous access that generated the 400 error. The 200 status code, the normal file, the normal source, the normal user-agent... everything is harmonious, so why is the 400 error coming? What about?

Through careful observation, we found that all the user-agent of the previous visit that generated 400 errors were left by the Google Chrome browser, which means that the 400 errors were generated by the Chrome browser. However, after local packet capture, it was found that Chrome did not send abnormal requests or data packets to the server.

In the packet capture analysis, it was found that chrome initiated more than one connection when accessing the server, usually ranging from 5 to 6. If the requested resource does not require so many connections, chrome will close the unused connection. The connection used is called pre-connection.

Usually when we visit a website, the first thing we get is an html master file, which links to other media resource files such as css, js, pictures, etc. required for the web page. The general resource file and the main html The file is under a domain. Pre-connection means establishing a lot of tcp connections before getting the html, instead of waiting to get the html file and then connecting to the server to get other files. Because connecting to the server takes some time, so This technology can speed up the rendering of web pages to a great extent.

If the resource of the web page HTML link is relatively small, or the client has a cache and does not need to connect to download, then it is likely that only one of the 5-6 connections issued by the Chrome browser is needed, and the others have to be Close it, which creates a problem: the server is connected without sending any requests. In this case, nginx handles it as a 400 error, but because the connection has been closed, the error message will not be sent to the client. This results in the error being recorded in the log file, but nothing can be seen in the packet capture analysis. The phenomenon.

Test
It is very simple to verify the above analysis results. Open the command line cmd.exe, enter telnet serverip 80 in it, wait for the connection to be successful, and then close cmd directly. At this time Check the nginx log file and there is an additional 400 error record.

One comment
The advantages of pre-connection are already very clear, but it also has shortcomings. If the webmaster has optimized it and used cookie-free technology, or the web page If you use a different server than static resources, then the css and js resources required by the web page are not in the same domain as the main html, and may not be on the same IP. Then pre-connection is not only useless, but also will cause inconvenience to the main html server. necessary burden.

Other reasons

Many people on the Internet have written related articles. Most of the reasons are because the header size exceeds the size, causing a response of 400, telling it to be bad. request. But there is actually another possibility, which is like a port testing tool, which just checks whether the port is alive. Things like lvs can also cause this kind of problem, and then a lot of 400 errors will appear in the logs.

For the above problem, you can increase both client_header_buffer_size and large_client_header_buffers in nginx.conf to alleviate this problem.

The above is the detailed content of How to solve a large number of http 400 errors in the Linux server nginx access log. For more information, please follow other related articles on the PHP Chinese website!