从「简书」平台的服务器故障，谈Nginx An error occurred异常～
上一篇 / 下一篇 2016-09-27 17:06:12 / 个人分类：linux
09.26简书平台的短暂异常
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的错误页面，无任何转向处理，是非常严重的事故～至于，具体原因，老徐不得而知～如下是老徐的一些猜测，正在继续老徐近期的服务器部署系列文章～
今天，刚老徐正打算上简书平台，写文章；突然，出现如上错误（本着tester从业者的严谨度，老徐再三确认不是我电脑的问题，是真的发生故障了），应该持续了几分钟～
不知道有多少用户有感知，好在平台响应速度还算不错，几分钟后已恢复正常～
一般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管理员经常看的地方，是随着系统自动启动的服务，程序等。
找到：
/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的基础知识～
相关阅读:
- Linux 3.10 kernel bridge转发逻辑 (zaza9084, 2016-9-14)
- Linux useradd命令基本用法 (zaza9084, 2016-9-19)
- LoadRunner监控Linux (vs_dev, 2016-9-19)
- Linux下的静态库、动态库和动态加载库 (zaza9084, 2016-9-20)
- 自制简易Linux系统 (zaza9084, 2016-9-21)
- Linux服务器/tmp目录的自动清理 (zaza9084, 2016-9-22)
- Linux快速配置集群SSH互信 (zaza9084, 2016-9-23)
- linux内核(kernel)版本号的意义 (xuquan, 2016-9-24)
- Linux安全机制与加密工具使用 (zaza9084, 2016-9-26)
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | 3 | 4 | 5 | 6 | ||||
| 7 | 8 | 9 | 10 | 11 | 12 | 13 | |||
| 14 | 15 | 16 | 17 | 18 | 19 | 20 | |||
| 21 | 22 | 23 | 24 | 25 | 26 | 27 | |||
| 28 | 29 | 30 | |||||||
我的存档
数据统计
- 访问量: 912072
- 日志数: 427
- 建立时间: 2012-06-04
- 更新时间: 2022-02-23
