关于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 请求,如果下游的服务不够稳定,这种状态码一般很多。
上游要保证,在连接等待的时候,必须有合理的超时时间,不能因为下游服务挂掉了,而拖垮自己,导致
整个服务雪崩。
 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章