电视错误代码499

1.

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

2.

Nginx 499错误的原因及解决方法 打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误,在百度搜索nginx 499错误,结果都是说客户端主动断开了连接。 但经过我的测试这显然不是客户端的问题,因为使用端口+IP直接访问后端服务器不存在此问题,后来测试nginx发现如果两次提交post过快就会出现499的情况,看来是nginx认为是不安全的连接,主动拒绝了客户端的连接. 但搜索相关问题一直找不到解决方法,最后终于在google上搜索到一英文论坛上有关于此错误的解决方法: 就是说要配置参数 proxy

查看更多

模拟499报错，nginx配置文件如下。

利用 sleep 停滞10秒（老板，服务器好慢啊，该加钱升级配置了！！！）。

curl 有个选项可以配置请求的超时时间，这样请求1秒后就会主动断开连接。

没看到499状态码甚至没有任何响应头部，但查看nginx访问日志有记录499状态码。

查看抓包内容，也没看到499，先是客户端主动断开连接，随后80也断开与9000端口的连接。

An error occurred.

Sorry, the page you are looking for is currently unavailable.

Please try again later.

If you are the system administrator of this resource then you should check theerror log for details.

Faithfully yours, nginx.

如上，刚老徐正打算上平台，写文章，出现如上错误，应该持续了几分钟～不知道有多少用户有感知，平台响应还不错，几分钟后已恢复正常～

一般nginx的此类报错，原因如下（当然，老徐对nginx了解不深，如下都是一些可能原因）

出现问题，首先是去分析nginx的日志，得到一些线索～

可能的常见原因：

／ 1 ／

很明显这是一个nginx的错误，查看nginx.conf的文件过程中分析可能是以下的问题，在nginx.xml中有如下配置：

标红的部分是很大的嫌疑，恰好应用中在提交数据的一瞬间和服务器有多次交互，这些交互都要过nginx。再加上用户IP来做key，假如多个用户访问在网上的最后一跳是同一个路由器，很显然会被服务器当成是一台电脑，从而出现判断错误。那么又一个新问题来了，出现503错误后为啥返回的是那个错误页面呢？

带着这个问题在nginx.conf中又发现了一段配置，如下图：

这个配置的意思是当出现500、502、503、504的错误时返回50x.html页面，这个页面在nginx安装目录的html文件夹下，内容如下：

这个页面经过浏览器解析就是开头第一幅图的样子。

分析到这里，就大概估计出原因了，把之前的rate值该大一点即可。那么到底改多大？这个要根据不同的业务而定，甚至去掉这个配置，所以这个是个经验值，通过多次试验可以得到一个相对于应用合理的值，这里就不说了。

实际nginx出现这个错误原因应该有很多，这里提供一种可能原因，以供网友参考。

／ 2 ／

日志记录中HTTP状态码出现499错误有多种情况，我遇到的一种情况是nginx反代到一个永远打不开的后端，就这样了，日志状态记录是499、发送字节数是0。

老是有用户反映网站系统时好时坏，因为线上的产品很长时间没有修改，所以前端程序的问题基本上可以排除，于是就想着是Get方式调用的接口不稳定，问了相关人员，说没有问题，为了拿到确切证据，于是我问相关人员要了nginx服务器的日志文件（awstats日志），分析后发现日志中很多错误码为499的错误，约占整个日志文件的1%，而它只占全部报错的70%左右（全部报错见下图），那么所有报错加起来就要超过1%了，这个量还是特别大的。

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”。这很有可能是因为服务器端处理的时间过长，客户端“不耐烦”了。

Nginx 499错误的原因及解决方法

打开Nginx的access.log发现在最后一次的提交是出现了HTTP1.1 499 0 -这样的错误，在百度搜索nginx 499错误，结果都是说客户端主动断开了连接。

但经过我的测试这显然不是客户端的问题，因为使用端口+IP直接访问后端服务器不存在此问题，后来测试nginx发现如果两次提交post过快就会出现499的情况，看来是nginx认为是不安全的连接，主动拒绝了客户端的连接.

但搜索相关问题一直找不到解决方法，最后终于在google上搜索到一英文论坛上有关于此错误的解决方法：

proxy_ignore_client_abort on

Don’t know if this is safe.

就是说要配置参数 proxy_ignore_client_abort on

表示代理服务端不要主要主动关闭客户端连接。

以此配置重启nginx,问题果然得到解决。只是安全方面稍有欠缺，但比总是出现找不到服务器好多了。

还有一种原因是 我后来测试发现 确实是客户端关闭了连接,或者说连接超时 ,无论你设置多少超时时间多没用 原来是php进程不够用了 改善一下php进程数 问题解决

／ 3 ／

今天网站突然出现如下错误：

The page you are looking for is temporarily unavailable.Please try again later.

很奇怪，我对服务器端的技术不是很熟悉，于是查询了下google，在https://wiki.archlinux.org/index.php/Nginx

上面的解决方法：

Error: The page you are looking for is temporarily unavailable. Please try again later.

This is because the FastCGI server has not been started.

如何解决呢？

刚开始我怀疑是不是nginx挂了，我首先通过 ps aux | grep nginx ，结果出现：

root      3769  0.0  0.0   5760   692 ?        Ss   Apr21   0:00 nginx: master process /usr/local/nginx/sbin/nginx

www       3770  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3771  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3772  0.0  0.1  18712 14276 ?        S    Apr21   0:03 nginx: worker process

www       3774  0.0  0.1  18680 14248 ?        S    Apr21   0:03 nginx: worker process

www       3776  0.0  0.1  18712 14240 ?        S    Apr21   0:03 nginx: worker process

www       3777  0.0  0.1  18680 14252 ?        S    Apr21   0:03 nginx: worker process

www       3778  0.0  0.1  18680 14232 ?        S    Apr21   0:02 nginx: worker process

root     24068  0.0  0.0   5196   756 pts/1    S+   14:33   0:00 grep nginx

可见nginx是正常的，本来打算重启nginx的：

/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf的，

突然觉得有没有其他方法，有同事提示先在一个目录下运行下test.html和test.php，结果html可以运行，php无法运行。

证实是php没有启动，我刚才也检测过php的进程，的确是没有php进程，这台服务器我不熟悉，同事帮忙查看了下

cd /etc/init.d，就是web管理员经常看的地方，是随着系统自动启动的服务，程序等。可以看看：

http://blog.wgzhao.com/2008/12/27/talk-about-rc-local.html的《 说说？ /etc/rc.d/rc.local 》

找到：

/usr/local/php/sbin/php-fpm start，首先什么是php-fpm呢？

就是FastCGI Process Manager，是一种可选的PHP FastGCI执行模式，有一点很有特点的应用，尤其是一个繁忙的网站中：

(1)可适应的进行再生(NEW!)

(2)基本的统计功能（Apache's mod_status)

(3)高级进程管理功能，能够优雅的停止/开始

(4)能够使用不同的工作用户和不同的php.ini

(5)输入，输出日志记录...

开启后，一切恢复正常！自己的服务器端技术还是有很多地方使用的不够。需要多学习使用！

总结：

1、试检查一下nginx.conf的设置，是不是有limit的设置，比如limit_zone、limit_conn，这些参数也是有影响的。

2、检查一下防火墙，是不是有相关的设置限制。

3、检查一下nginx.conf的设置，看看有没有valid_referers none blocked的防链设置。

4、看下访问静态文件是否正常，错误排除～

OK，如上只是一些猜测～

具体原因，具体分析～

越来越多的系统，采用nginx，大家有必要了解些nginx的知识～

---