【nginx】Nginx的499状态码是怎么回事？
一、问题背景
业务系用户侧报错，从nginx日志中跟踪相关接口请求，发现nginx响应客户端的响应码大量出现 499 。
# grep 'HTTP/1.1"######499######' access.log
172.16.15.7######-######-######[20/Jun/2023:17:15:29 +0800]######"POST /xxx HTTP/1.1"######499######0######"-"######"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36"######3.004######inner.example.com######86b21f7a273804704089a5da1cfda67f######172.16.15.8:12605, 172.16.15.6:12605######502, -######-######http######0.001, -######0######172.16.9.7######574
172.16.15.5######-######-######[20/Jun/2023:17:19:41 +0800]######"POST /xxx HTTP/1.1"######499######0######"-"######"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36"######3.003######inner.example.com######2aab931410309262fa6258e61debea1a######172.16.15.6:12605######-######-######http######-######0######172.16.9.7######574
二、 http_code 499 是什么？
499 Client Closed Request， 客户端主动断开连接。
一次http请求在客户端指定的时间内没有返回响应，此时，客户端会主动断开连接，此时表象为客户端无响应返回，而nginx的日志中会status code 为499。
/*
* HTTP does notdefine the code for the case when a client closed
* the connectionwhile we are processing its request so we introduce
* own code to logsuch situation when a client has closed the connection
* before we even tryto send the HTTP header to it
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST 499
这是nginx定义的一个状态码，用于表示这样的错误：服务器返回http头之前，客户端就提前关闭了http连接。
（1）upstream 在收到读写事件处理之前时，会检查连接是否可用，当连接错误时会返回499。
（2）server处理请求未结束，而client提前关闭了连接，此时也会返回499。
（3）在一个upstream出错，执行next_upstream时也会判断连接是否可用，不可用则返回499。
总之，这个错误的比例升高可能表明服务器upstream处理过慢，导致用户提前关闭连接，正常情况下有一个小比例是没问题的。
image.png
三、 为什么服务端处理时间过长 ？
检查服务端工程配置文件，发现会去调用第三方接口 https://www.example.com/xxx
# ping www.example.com 不通，应该网络链路有地方禁ping 了
# echo > /dev/tcp/www.example.com/443 通，但是明显很慢
$ time echo > /dev/tcp/www.example.com/443
real 0m3.034s
user 0m0.000s
sys 0m0.001s
耗时长达3s之多！！！
$ time nslookup www.example.com
;; Got recursion not available from 172.16.15.12, trying next server
Server: 172.16.12.11
Address: 172.16.12.11#53
real 0m2.012s
user 0m0.005s
sys 0m0.005s
可以发现，主要耗时在DNS解析上，通过服务端所在服务器的DNS服务器 172.16.12.11#53 解析 www.example.com
解决 DNS 解析慢的问题后再从nginx日志查看业务接口请求：
172.16.15.5######-######-######[20/Jun/2023:18:14:17 +0800]######"POST /xxx HTTP/1.1"######200######115######"-"######"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36"######0.125######inner.example.com######081632454b066d624202aeb65d3a29d5######172.16.15.8:12605######200######-######http######0.125######0######172.16.9.7######574
172.16.15.6######-######-######[20/Jun/2023:18:36:14 +0800]######"POST /xxx HTTP/1.1"######200######115######"-"######"Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.128 Safari/537.36; Qing/0.0.8; 4.1.5 (2305101556);lang:zh-CN;bno:4.1.5(2305101556);"######0.109######inner.example.com######7361ce58fc139ca9cd3e59133e577cfc######172.16.15.8:12605######200######-######http######0.109######0######172.16.15.5######636
四、参考
服务器排障 之 nginx 499 错误的解决
https://cloud.tencent.com/developer/article/1400600
http错误码原理及复现 - 499，500，502，504
https://www.jianshu.com/p/7f65a1f53d2c
HTTP 499 问题处理方法合集
https://juejin.cn/post/6867050579139493896
