关于nginx日志的HTTP 499状态码

499错误是什么？让我们看看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 */

可以看到，499对应的是 “client has closed connection”。这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

499：客户端关闭连接 这个乍一看，是客户端的锅，是它先“动手”，关闭连接的。从标准的 RFC2616 协议中，是没有 499 状态码，
是 nginx 自己定义的。

根据字面的意思，这种情况是客户端主动断开连接，或许是服务端在客户端最大等待时间内，没有返回结果，导致客户端等不及。
这次我们在终端试试（在写的时候，已用浏览器测试，奈何浏览器作为客户端，等待时间太长了，复现不了）。

在网站根目录添加test.php：

<?php

sleep(10);

echo "hello world";

在终端执行如下命令后直接Ctrl+c停止请求，

curl https://example.com/test.php

从nginx的access.log日志中可以发现状态码为499：

39.101.223.212 - - [13/Apr/2020:10:39:14 +0800] "GET /test.php HTTP/1.1" 499 0 "-" "curl/7.29.0" "-" "39.101.223.212"127.0.0.1:9000 2.524 2.525 - 

因为客户端主动断开，在下游的 nginx 就会有一条 499 的日志。在普通的 web 应用中很少见，但是
在微服务下，跨部门跨组之间的调用，都是 http 请求，如果下游的服务不够稳定，这种状态码一般很多。
上游要保证，在连接等待的时候，必须有合理的超时时间，不能因为下游服务挂掉了，而拖垮自己，导致
整个服务雪崩。