nginx客户端返回499错误代码问题分析

我们的服务器客户端总是有一个返回错误代码499的日志。之前觉得比例不高，没仔细查。最近有个领导问了这个问题。为什么只用了0.0秒？为什么还是499？最近几天，我跟踪定位了这个问题。这是一份记录。

网络架构和背景

我们的服务架构和错误代码如上。上游服务日志中没有记录，无法确定孔连接和请求上游服务的详细情况。

孔上的log RSP _ Cost:0.041 RSP _ Length:0 RSP _ Status:499 UPS _ RSP _ Cost:-UPS _ RSP _ Length:0 UPS _ RSP _ Status:-log RSP _ Cost on WAF:1.045 RSP _ Length:0 RSP _ Length Cost:-UPS _ RSP _ Length:0 UPS _ RSP _ Status:-看日志，两种负载均衡现象是一样的。孔上游连接的是web服务，不确定是上游环节还是读写数据的问题，还是孔自己的问题。根本没有上游服务的反向代理。

上游服务抓取包。我打算在上游服务上抢包，看看是不是请求在孔上出了问题，根本没到上游服务，还是已经到了上游服务，上游服务出了问题。

83是孔的ip，82是上游服务的ip。大家可以看到，83先发了一个fin包，表示要断开，然后82也回复了fin的ack包。之后82还是发了包。大约过了0.18秒，82才向83发送fin ack数据包，表示可以断开连接。这时，因为83断开得早，所以在这个中间包中，83回复了RST，我们使用了长链路。83断开后，新的连接已经重用了这个TCP连接，此时83只能回复RST。大概就是这个过程。

孔为什么会断线？因为我们用上游作为长链接，所以猜测了很多可能性。

Keepalive_requests将在超过keepalive_requests后关闭长链接keepalive_time。如果keepalive_time超过keepalive _ time，就会关闭长链接keepalive_timeout。打开上游服务超时，如果连接超过keepalive_timeout，则认为上游服务不可用，直接排除该参数。Grabber已经看到请求到达了上游服务，最终放弃了这个配置，认为Nginx应该在keepalive _ requests keepalive _ time的限制下，在关闭连接之前处理请求。不可能把请求处理一半然后直接主动关闭连接。还有一个原因。我们的Nginx版本是1.13，没有这种可以修改的配置。

负载均衡的问题？最后，我怀疑waf上有问题。waf上要求太多，我就没去waf机抢包了。我猜测waf抢到和孔结果一样的包，然后我猜测waf为什么断网，猜测客户端是否断网。如果是这样，我看到的所有日志现象都是有联系的。为了验证这个猜测，我们在测试环境中模拟了客户端的主动断开。我们在的上游服务上模拟了一个耗时的请求，然后在没有结果返回时主动断开请求。

类TestController扩展了base controller { public function action test(){ sleep(3)；return $ this -& gt；response->成功(array("test "，" geekbang "，" es "))；}}然后我们在终端上使用curl请求接口，三秒钟内取消请求。Curl取消请求，然后查看waf和kong的日志，这与生产中的499错误代码相同。基本上确定是客户端主动断开。

修改Nginx的配置，看看proxy_ignore_client_abort的描述。

语法:proxy _ ignore _ client _ abort on | off；默认值:proxy _ ignore _ client _ abort off确定当客户端不等待响应就关闭连接时，应何时关闭与代理服务器的连接。确定当客户端不等待响应就关闭连接时，是否应关闭与代理服务器的连接。当客户端不等待响应就关闭连接时，它将默认关闭与代理服务器的连接。将它更改为on意味着在代理服务器处理请求之前，代理服务器不会关闭。修改kong上proxy_ignore_client_abort的配置。经过一天的观察，确定是因为这个配置。换了两台机器后，499的错误代码没有再出现。修改这个配置后，虽然错误代码消失了，但是无效请求会增加上游服务的压力。本来这个请求是没有意义的，被客户端关闭了，然后上游服务关闭了。打开后，上游服务直到请求被处理后才会关闭。有利有弊，需要权衡选择。

关于nginx客户端返回的499错误代码的这篇文章到此为止。关于nginx返回的499错误代码的更多信息，请搜索主机频道zhujipindao之前的文章。或者继续浏览下面的相关文章。希望大家支持主机频道zhujipindao。未来的com！