499 errors in the HTTP status code in logging there are a number of situations, I encountered a situation is nginx back to a never open back end, so that the log status record is 499, the number of bytes sent is 0.
Always have users reflect the site system when bad, because the product on the line is not modified for a long time, so the problem of the front-end program can basically be ruled out, and then think is get the interface of the call is not stable, asked the relevant personnel, said no problem, in order to get the exact evidence, So I asked the relevant personnel to the Nginx server log file (Awstats log), the analysis found that many errors in the log error code 499, about 1% of the entire log file, and it only accounted for the total error of about 70% (all error see), then all the error add up to more than 1%, This volume is still very large.
What is the 499 error? Let's look at the definition of Nginx in the 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 because the server-side processing time is too long, the client "impatient".
The cause and solution of Nginx 499 error
Open Nginx Access.log found in the last commit is a HTTP1.1 499 0-such error, in Baidu search Nginx 499 error, the result is that the client actively disconnected the connection.
But after my test this is obviously not a client problem, because using the port +ip direct access to the backend server does not exist this problem, and later test Nginx found that if two commits post too fast will appear 499 of the situation, it appears that Nginx is considered to be an insecure connection, actively refused the client connection.
But search-related problems have been unable to find a solution, and finally found on Google on the English Forum on the resolution on this error:
proxy_ignore_client_abort on;
Don ' t know if this is safe.
This means to configure the parameter proxy_ignore_client_abort on;
indicates that the proxy service side does not primarily actively shut down client connections.
With this configuration to restart Nginx, the problem is resolved.just a slight lack of security, but more than always appear to find the server much better.
Another reason is that I later test found that the client is actually shutting down the connection, or the connection time-out, no matter how many times you set the time-out is useless the PHP process is not enough to improve the number of PHP processes to solve the default test environment to open 5 sub-processes. |
