499是nginx的Web服务器软件扩展的4xx错误，只是用于记录的目的，没有实际的响应。Nginx 499代表服务端请求还未返回时客户端主动断开连接；还有一种情况就是有人攻击，故意消耗服务端资源。例如我们请求一个费时的python请求，但是客户端等不了，直接把浏览器关了，就会报这个错。不算是特别需要处理的错，单独出现可以不用在意。如果大量出现可以分析下是不是某个请求最近请求时间异常高，适当优化工具/原料morenginx方法/步骤:1/5分步阅读

proxy_ignore_client_abort的含义。确定在客户端关闭连接时是否应关闭与代理服务器的连接，而不在等待响应。

2/5

默认 proxy_ignore_client_abort 是关闭的。此时在请求过程中如果客户端主动关闭请求、客户端网络断开，那么 Nginx 会记录 499。

3/5

如果使用了proxy_ignore_client_abort on。那么客户端主动断掉连接之后，Nginx 会等待后端服务器处理完(或者超时)，然后记录“后端的返回信息”到日志。因此，如果后端返回200，就记录200 ；如果后端返回5XX ，那么就记录 5XX。如果超时(默认60s，可以用 proxy_read_timeout 和proxy_send_timeout设置)，Nginx 会主动断开连接，记录504。

4/5

怎么在配置增加proxy_ignore_client_abort on。首先找到配置文件，然后打开它，找到http下的server下的location,把它加进去。配置文件路径（当你执行 nginx -t 的时候，nginx会去测试你的配置文件语法，并告诉你配置文件是否写得正确，同时也告诉了你配置文件的路径)

5/5

注：不建议使用proxy_ignore_client_abort 来处理这个错误。因为这样当有大量瞬间断开的请求时，后端会默默地全部处理，比较浪费资源，而且并发压力比较大时，用这种方法将压垮机器。这个事情交给 php-fpm 自己来处理其实挺合适。因为 PHP 默认当用户断开请求了会中断请求，如果不想自动中断请求，使用ignore_user_abort()就好了。

方法/步骤2：1/2

尽管NGINX配置了，但60秒后HTTP499错误。Nginx上的超时都设置了很大的值（远远超过60秒）。这可能是云服务器设置问题，以AWS为例。如果部署在AWS上时，60秒后连接不断被丢弃，Nginx访问日志中是499。当将错误日志设置为调试模式时，您将看到类似下面的内容。 不清楚为什么客户端删除连接。

2/2

解决方案。在AWS上有一个负载均衡器（load balancer），你大部分都用了默认的配置，因此它将在60秒后删除连接。将其更改去配合您的Nginx配置。

NGINX代理服务器WEB服务器