Comparative explanation of 499 status code in HTTP and 499 error under nginx

There are many situations where a 499 error appears in the HTTP status code in the log. One situation I encountered was that nginx reversed to a backend that could never be opened. That was it. The log status record was 499. Send word The number of sections is 0.

There are always users reporting that the website system is up and down. Because the online products have not been modified for a long time, the problem with the front-end program can basically be eliminated, so I thought that the interface called by the Get method is not correct. It was stable. I asked the relevant personnel and they said there was no problem. In order to get definite evidence, I asked the relevant personnel for the log file of the nginx server (awstats log). After analysis, I found that there were many errors with error code 499 in the log, accounting for about the entire 1% of the log files, but it only accounts for about 70% of all error reports (see the figure below for all error reports), then the total of all error reports will exceed 1%, which is still a very large amount.

What is the 499 error? Let's take a look at the definition in the source code of NGINX:

ngx_string(ngx_http_error_495_page), /* 495, https certificate error */

ngx_string(ngx_http_error_496_page), /* 496, https no certificate * /

ngx_string(ngx_http_error_497_page), /* 497, http to https */

ngx_string(ngx_http_error_404_page), /* 498, canceled */

ngx_null_string,                                             /* 499 , client has closed connection */

You can see that 499 corresponds to "client has closed connection". This is most likely because the server-side processing time is too long and the client is "impatient".

Causes and solutions of Nginx 499 error

Open Nginx's access.log and find that HTTP1.1 499 0 appeared in the last submission - such an error, search nginx 499 on Baidu Error, the result is that the client actively disconnected.

But after my test, this is obviously not a client problem, because using port + IP to directly access the back-end server does not have this problem. Later, when testing nginx, I found that if the post is submitted twice too quickly, 499 will appear. , it seems that nginx thinks it is an unsafe connection and actively rejects the client's connection.

But I can't find a solution when searching for related problems. Finally, I searched on Google and found an English forum about this. Wrong solution:

proxy_ignore_client_abort on;

Don't know if this is safe.

means to configure the parameter proxy_ignore_client_abort on;

means The proxy server should not actively close the client connection.

Restart nginx with this configuration, and the problem is indeed solved. It's just a little lacking in security, but it's much better than always being unable to find the server.

Another reason is that I later tested and found that the client has indeed closed the connection, or the connection has timed out. No matter how much timeout you set, it is useless. It turns out that there are not enough PHP processes. Please improve the problem of the number of PHP processes. To solve the problem, only 5 child processes are opened in the default test environment.

The above is the detailed content of Comparative explanation of 499 status code in HTTP and 499 error under nginx. For more information, please follow other related articles on the PHP Chinese website!