There are many cases where the HTTP status code has 499 error in the log record. One of the cases I encountered was that nginx was inversioned to a back end that could never be opened, and that’s it. The log status record was 499 and the number of sent bytes was 0.
Always have users reflect system and downs, because online products for a long time did not change, so the front-end application problem basically can be ruled out, so I think about is how Get call interface is not stable, ask the relevant staff, said there is no problem, in order to get exact evidence, so I asked the relevant personnel to nginx server log file (awstats log), after analysis found in the log many error error code is 499, accounts for about 1% of all the log files, and it accounts for only about 70% of the total error (see below) all error, so the correct all add up to more than 1%, This quantity is still extremely large.
499 what is the error? Let’s look at the definition in NGINX’s source code:
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 */
As you can see, 499 corresponds to “client has closed connection”. This is most likely due to long processing time on the server side and “impatience” on the client side.
Nginx 499 error cause and resolution
When I opened access.log of Nginx, I found that in the last submission, there was HTTP1.1499 0 - such an error. When I searched nginx 499 on baidu, the result was that the client was actively disconnected.
However, after my test, this is obviously not a problem of the client, because there is no such problem when using port +IP to directly access the back-end server. Later, when testing nginx, it is found that if post is submitted twice too soon, there will be 499. It seems that nginx believes that the connection is not safe, and actively refused the connection of the client.
However, no solution could be found after searching for relevant problem 1. Finally, a solution about this error was found on the English forum of 1 on google:
proxy_ignore_client_abort on; Don’t know if this is safe.
That is to configure the proxy_ignore_client_abort on;
Indicates that the proxy server should not actively close the client connection primarily.
Restart nginx with this configuration and the problem was solved. It’s just a little bit less secure, but it’s a lot better than always not being able to find a server.
Another reason is that I later found out in my tests that it was indeed the client that closed the connection, or that the connection timed out, no matter how much timeout time you set, it didn’t matter that the php process was not enough to improve the number of php processes by 1 to solve the problem of the default test environment before opening 5 child processes.