Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of "how to solve a large number of http 400errors in the Linux server nginx access log". The editor shows you the operation process through an actual case. The method of operation is simple, fast and practical. I hope this article "how to solve a large number of http 400errors in the Linux server nginx access log" can help you solve the problem.

The error record in the server is similar to this:

124.65.133.242-- [27/oct/2014:14:30:51 + 0800] "-" 40000 "-"-"

124.65.133.242-- [27/oct/2014:14:31:45 + 0800] "-" 40000 "-"-"

124.65.133.242-- [27/oct/2014:14:31:45 + 0800] "-" 40000 "-"-"

124.65.133.242-- [27/oct/2014:14:31:45 + 0800] "-" 40000 "-"-"

Step on the spot

After analyzing the log file of nginx, it is found that there are several 400 errors after a normal visit, ranging from 1 to 6 in a row, and not every customer visit will produce 400 errors.

It is normal to observe the previous visit with 400 errors, 200 status codes, normal files, normal sources, normal user-agent. Everything is in harmony. Where did the 400 come from?

On closer inspection, it is found that all the previous visited user-agent that generated 400,000 errors were left by the google chrome browser, which means that the 400th error was generated by the chrome browser. However, after grabbing packets locally, it is found that chrome does not send abnormal requests or packets to the server.

In the packet capture analysis, it is found that chrome initiates more than one connection when accessing the server, generally ranging from 5 to 6, and if the requested resources do not need so many connections, chrome will close the unused connections. This technology is called pre-connection "pre-connection".

Usually, when we visit a website, the first thing we get is a html master file, which links other media resource files such as css, js, pictures, etc., while the general resource file and the main html file are in the same domain. To pre-connect is to establish a lot of tcp connections before getting the html, instead of waiting to get the html file before connecting to the server to get other files. Because it takes some time to connect to the server, this technique can greatly speed up the rendering of web pages.

If there are few resources for html links on a web page, or if the client has a cache and does not need a connection to download, then it is likely that only one of the 5-6 connections issued by the chrome browser is needed and the rest will have to be closed, resulting in a problem: connecting to the server without sending any requests. In this case, nginx is treated as a 400th error, but because the connection has been closed, the error message will not be sent to the client, which results in the error recorded in the log file and nothing can be seen in the packet analysis.

test

To verify the above analysis results is very simple, open the command line cmd.exe, type telnet serverip 80 inside, wait for the connection to be successful and then turn off cmd directly, then check the log file of nginx with an extra 400 error record.

A comment

The advantages of pre-connection have been clear, but it also has disadvantages. If the webmaster optimizes and uses cookie-free technology, or if the web page and static resources use different servers, then the css and js resources required by the web page are not in the same domain as the main html, or may not be on the same ip, then pre-connection is not only a chicken rib, but also an unnecessary burden on the main html server.

Other reasons

Many people have written related articles on the Internet, and most of them are due to the excessive size of header's head, which caused a response of 4000.This is bad request. But in fact, there is another possibility, like a port testing tool, just to check whether the port is alive. Things like lvs can also cause this problem, and then there will be a large number of 400 errors in the log.

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

This is the end of the content about "how to solve a large number of http 400s in the Linux server nginx access log". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.