向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除|赢在IT，Playin' with IT,Focus on Killer Application,Marketing Meets Technology.

netstat -s | egrep "listen|LISTEN"
Fri May  5 15:39:59 CST 2017
1641906 times the listen queue of a socket overflowed
1641906 SYNs to LISTEN sockets ignored


ss -lnt
State       Recv-Q Send-Q                              Local Address:Port                                             Peer Address:Port              
LISTEN      0      300                                             *:3307                                                        *:*                  
LISTEN      0      511                                             *:80                                                          *:*        


ss -lnt
Recv-Q Send-Q Local Address:Port  Peer Address:Port
0        50               *:3306             *:*
上面看到的第二列Send-Q 表示第三列的listen端口上的全连接队列最大为50，第一列Recv-Q为全连接队列当前使用了多少

全连接队列的大小取决于：min(backlog, somaxconn) . backlog是在socket创建的时候传入的，somaxconn是一个os级别的系统参数

半连接队列的大小取决于：max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。 不同版本的os会有些差异


来自：https://blog.csdn.net/Tanswer_/article/details/78375317

TimeWait过多时，两个方面做处理：
1）打开：
cat /etc/sysctl.conf|grep  -Eri "reuse|timestamps|local_port_range"
net.ipv4.ip_local_port_range = 2000 65000   #CS模型的C端端口范围增大到65000
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_tw_reuse  = 1   #这个是重用客户端的四元里的二元，这个容易和tcp_tw_recycle 记混，下面这个tcp_tw_recycle这个项最好关掉，容易出现并引发疑难问题。
如果是安全可控制，可以复用处于TIME_WAIT的套接字为新的连接所用。1）只适用于连接发起方。 也就是CS模型的客户端。2）对应TIME_WAIT状态的连接创建超过1秒才可以被复用。所以，上面这个net.ipv4.tcp_timestamps = 1 ，也就是是打开对TCP时间戳的支持，默认即为1秒。

net.ipv4.ip_local_port_range = 1024 65535   #调大

2）关闭：
不要开启：net.ipv4.tcp_tw_recycle = 1   #不关容易出现并引发疑难问题
cat /etc/sysctl.conf|grep  -Eri "tcp_tw_recycle"                    
net.ipv4.tcp_tw_recycle = 1

=======================================================================
出现在redis在PHP里主动关闭高并发时候，redis在php-fpm请求完关了，可能是php主动关了，被动方认为有错误发生。
taimwait主要是把本地发起请求的端口范围给占满了，出现client不可用新端口client到server。

假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

摘自：https://blog.csdn.net/huangyimo/article/details/81505558


参数调整：
CentOS 大量的TIME_WAIT解决方法:
TIME_WAIT状态的连接，通过调整内核参数解决，

vi /etc/sysctl.conf 编辑文件，加入以下内容：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30 然后执行

/sbin/sysctl -p让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

修改之后，再用

netstat -n -p -t发现大量的TIME_WAIT 已不存在，网站访问正常！


来自：https://www.bbsmax.com/A/ZOJPgOYyzv/

背景：发现Nginx启动时都会去创建/usr/lcoal/nginx/logs下面的文件，且越写越大，而能不能去掉或不写入日志，乃至放别的非nginx 的安装目录呢，说是不能，也有说能的。
禁用错误日志的语法是可以的，但是文档声明在读取配置之前使用默认日志文件。（这似乎是合理的，因为它会如何告诉你你的配置有错误）
mkdir /usr/local/nginx/logs/  #先让它启动起来，但是经过下面配置后不会再写入日志了。
nginx.conf里：
user www;                  
worker_processes 3;

worker_rlimit_nofile 51200;
error_log /dev/null crit;
http {
      access_log off;
}

结果：
du -sh /usr/local/nginx/logs/*
4.0K    /usr/local/nginx/logs/access.log
4.0K    /usr/local/nginx/logs/error.log

来自：https://cloud.tencent.com/developer/ask/54829


我在启动nginx时使用-p参数解决了这个问题，例如：

/home/ubuntu/nginx/sbin/nginx -c /home/ubuntu/nginx/conf/nginx.conf -p /data/logs/nginx
这将在配置中指定的任何日志路径前面加上前缀目录。

这个能指向别的目录，但是Nginx会加个 logs/error.log 这样的log,如：
/data/logs/nginx/logs/error.log

来自：https://cloud.tencent.com/developer/ask/54829

实践来自：https://mp.weixin.qq.com/s/TFRv2wfaNpje_5rrELBEgA

定义
==============================================================================================
502，Bad Gateway，网关错误，它往往表示网关从上游服务器中接收到的响应是无效的，主要是PHP执行时间大于PHP超时，于是给Nginx返回为空引起的。
502并不是指网关本身出了问题，而是
1）从上游接收响应出了问题，比如由于上游服务自身超时导致不能产生响应数据，
2）或者上游不按照协议约定来返回数据导致网关不能正常解析。


情况1：关掉PHP-FPM进程：
"123.115.119.90" "up.levoo.com" "-" "[30/Nov/2018:22:51:52 +0800]" "GET /hello.php HTTP/1.1" "502" "552" "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" "0.000" "0.000"
2018/11/30 22:51:52 [crit] 29084#0: *124 connect() to unix:/dev/shm/php-fcgi.sock failed (2: No such file or directory) while connecting to upstream, client: 123.115.119.90, server: up.levoo.com, request: "GET /hello.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:", host: "up.levoo.com"

情况2：
<?php sleep(7); echo 'hello world'; ?>
php-fpm.conf配置：

request_terminate_timeout=5
nginx配置：
fastcgi_read_timeout 10;

php-fpm.conf设置的最大执行时间是5s，但是php脚本需要的执行时间大于7s，所以php-fpm进程执行5s时就回退出，此时php脚本没有正常执行完，返回给网关Nginx的数据为空，于是导致502。
502日志：
"123.115.119.90" "up.levoo.com" "-" "[30/Nov/2018:22:53:14 +0800]" "GET /hello.php HTTP/1.1" "502" "552" "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" "5.287" "5.288"
2018/11/30 22:53:14 [error] 29084#0: *188 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 123.115.119.90, server: up.levoo.com, request: "GET /hello.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:", host: "up.levoo.com"

在实际的实践中发现当在EasySwoole里传大于设置的图片也会出现 Nginx的代理机上出现104: Connection reset by peer的情况。

==============================================================================================

504:nginx则以为上游php-fpm没有按照设置时间超过Nginx的等待时间，返回响应数据就会返回504。
504，Gateway Timeout，网关超时。

它表示网关没有从上游及时获取响应数据。注意它和502在超时场景下的区别，502是指上游php-fpm因为超过自身允许的执行时间而不能正常生成响应数据，而504是指在php-fpm还未执行完成的某一时刻，由于超过了nginx自身的超时时间，nginx则以为上游php-fpm没有按照设置时间返回响应数据就会返回504， 此时对于php-fpm而言还会继续执行下去，直到执行完成。

<?php

sleep(7);

echo 'hello world';

error_log("hello", 3, "/tmp/hello.log");

?>

vi php-fpm.d/www.conf
request_terminate_timeout = 30s

vi nginx.conf
fastcgi_read_timeout         5s;


504 Gateway Time-out
nginx

"123.115.119.90" "up.levoo.com" "-" "[30/Nov/2018:23:52:04 +0800]" "GET /hello.php HTTP/1.1" "504" "562" "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" "5.005" "5.005"
2018/11/30 23:52:0


==============================================================================================
499, Client Closed Request， 客户端主动断开连接。
是指一次http请求在客户端指定的时间内没有返回响应，此时，客户端会主动断开连接，此时表象为客户端无响应返回，而nginx的日志中会status code 为499。

此状态码在浏览器请求时几乎不可见，因为浏览器默认的超时时间会很长。多见于服务之间的调用，在业务架构中常常会分层设计，拆分为不同的子系统或者微服务，这样系统之间就会常常通过http方式来请求，并且会设置每次请求的超时时间，当请求在请求时间内所调用的上游服务无返回，则会主动关闭连接，上游服务日志中会记录一条499。

php代码

<?php

sleep(7);

echo 'hello world';

error_log("hello", 3, "/tmp/hello.log");

?>
php-fpm.conf配置：

request_terminate_timeout=30
nginx配置：

fastcgi_read_timeout 5;
我们在linux终端使用curl命令来请求，-m 表示超时时间，单位为秒

curl -i -m 3 http://127.0.0.1/hello.php
返回为：

curl: (28) Operation timed out after 3004 milliseconds with 0 bytes received
nginx的access日志的code为499，如下：

"HEAD /hello.php HTTP/1.1" 499 0


#curl -I -m 3 http://up.levoo.com/hello.php
curl: (28) Operation timed out after 3022 milliseconds with 0 bytes received
Nginx日志：
"47.94.88.237" "up.levoo.com" "-" "[30/Nov/2018:23:55:38 +0800]" "GET /hello.php HTTP/1.1" "499" "0" "-" "curl/7.55.1" "2.888" "-"

==============================================================================================
500
500, Internal Server Error , 服务器内部错误，服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。

日常开发中500错误几乎都是由于php脚本语法出现错误导致php-fpm无法正常执行。

复现路径
php代码:

<?php
echo 'hello '
echo ' world';
?>
由于php代码语法错误，php-fpm执行失败，然后告诉nginx这一结果，nginx则返回500。
该网页无法正常运作 up.levoo.com 目前无法处理此请求。
HTTP ERROR 500

Nginx错误日志：
"123.115.119.90" "up.levoo.com" "-" "[30/Nov/2018:23:57:42 +0800]" "GET /hello.php HTTP/1.1" "500" "5" "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" "0.022" "0.022"

php错误日志：
hello.php on line 3

用Win+R 打开运行界面，输入mmc：
点击在新窗口中浏览此图片
在打开的控制台界面，从菜单中选择“文件”-“添加或删除管理单元”，然后从“可用的管理单元”添加“远程桌面”到“所选的管理单元”中，点击“确定”：
点击在新窗口中浏览此图片
最后，右键点击“远程桌面”-“添加新连接”，输入需管理的客户端IP地址即可访问。
=======================================================================================

背景：10台Windows Server 2012上面装上盗版的Loadrunner，想假装很专业的做一下接口测试。要根据自己的32位还是64位下载安装后，那个控制面板里的打开和关闭Windows功能才有角色管理工具->远程桌面服务工具。

对于远程管理Windows 机器来说，远程连接可能是用得最频繁的。过去，我总是把远程连接保存为.rdp 文件，以方便双击后自动连接。如果有多台机器需要管理，可以放在某个目录中，但总觉得这样的方式很笨。直到今天，在客户现场，无意中发现MMC 中是可以加入“远程管理”功能的。回来找资料看了一下，觉得还不错，特适用于同时连接多台机器的情况。

一、界面
描述前，先给个使用界面看看吧：
点击在新窗口中浏览此图片
对于【附件】中的【远程桌面连接】（即mstsc.exe）来说，主要是管理更方便了，只需一个.msc 文件即能轻松打开管理窗口，并在多个连接窗口之间切换。屏幕分辨率可设定，但似乎没有提供全屏的功能。

二、安装及配置
该MMC 使用的远程桌面组件，实际上是服务器平台提供的功能，所以，在默认的桌面系统中是没有提供的，需要独立安装。以Windows 7为例，步骤有：
1、下载组件
从下面的连接中下载“Windows 7 远程服务器管理工具”：
点击：http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d#filelist

下载前，请留意页面中的说明，包括：
引用
a、仅可以安装在运行企业版、专业版或旗舰版 Windows 7 的计算机上；
b、安装管理工具包的计算机上 Administrators 组的成员；
c、根据运行版本不同，下载适用于x86或x86_64 平台的程；
d、下载后的包，后缀名为.msu，双击即可安装（若使用第三方工具下载，后缀名可能会被修改）。

2、远程桌面功能
安装完毕后，依次打开：“控制面板”-“程序和功能”-“打开或关闭Windows功能”-“远程服务器管理工具”-“角色管理工具”，勾选下面的“远程桌面服务工具”：
点击在新窗口中浏览此图片

3、在MMC中添加远程管理组件
用Win+R 打开运行界面，输入mmc：
点击在新窗口中浏览此图片
在打开的控制台界面，从菜单中选择“文件”-“添加或删除管理单元”，然后从“可用的管理单元”添加“远程桌面”到“所选的管理单元”中，点击“确定”：
点击在新窗口中浏览此图片
最后，右键点击“远程桌面”-“添加新连接”，输入需管理的客户端IP地址即可访问。

4、分辨率问题
创建连接后，右键点击该连接，选择“属性”，在“屏幕选项”中可设置分别率：
点击在新窗口中浏览此图片
建议使用“填充MMC 结果窗格”，确定后，通过工具栏上的图标，关闭多余的显示窗口：
点击在新窗口中浏览此图片
关闭MMC （保存为.msc 文件）。重新打开，即可满屏显示远程终端窗口。


摘自 ：http://www.linuxfly.org/read.php?561

内容：
curl -XGET http://baidu.com

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 03:56:42 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: '51-47cf7e6ee8400'
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 03:56:42 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv='refresh' content='0;url=http://www.baidu.com/'>
</html>



curl -XPOST http://baidu.com


POST / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 03:59:50 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: '51-47cf7e6ee8400'
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 03:59:50 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv='refresh' content='0;url=http://www.baidu.com/'>
</html>



Post加个参数：
curl -XPOST http://baidu.com -d'say=hello'

POST / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*
Content-Length: 9
Content-Type: application/x-www-form-urlencoded

say=helloHTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 04:03:47 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: '51-47cf7e6ee8400'
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 04:03:47 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv='refresh' content='0;url=http://www.baidu.com/'>
</html>



Get里加个参数：
curl -XGET http://baidu.com?say=hello

GET /?say=hello HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 04:05:06 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: '51-47cf7e6ee8400'
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 04:05:06 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv='refresh' content='0;url=http://www.baidu.com/'>
</html>

内容：
curl -XGET http://baidu.com

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 03:56:42 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 03:56:42 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>



curl -XPOST http://baidu.com


POST / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 03:59:50 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 03:59:50 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>



Post加个参数：
curl -XPOST http://baidu.com -d"say=hello"

POST / HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*
Content-Length: 9
Content-Type: application/x-www-form-urlencoded

say=helloHTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 04:03:47 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 04:03:47 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>



Get里加个参数：
curl -XGET http://baidu.com?say=hello

GET /?say=hello HTTP/1.1
User-Agent: curl/7.29.0
Host: baidu.com
Accept: */*

HTTP/1.1 200 OK
Date: Fri, 31 Mar 2017 04:05:06 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Sat, 01 Apr 2017 04:05:06 GMT
Connection: Keep-Alive
Content-Type: text/html

<html>
<meta http-equiv="refresh" content="0;url=http://www.baidu.com/">
</html>

DownLoad:https://github.com/openresty/set-misc-nginx-module/
    最近公司运营提出需求，需要使从公司网站上下载的资料文件显示为中文名称，研发部问道我们有没有好的实现方法，php应该有这样的功能，研发回复说，之前就是这样实现过，但太消耗内存，不做考虑了，才有现在下载资料文件，显示中文名称没有实现。想了想，记起前段时间看agentzh（章亦春）大牛关于nginx的大作以及他写的nginx的模块，似乎有实现此类功能的模块，找了一下果然有：http://wiki.nginx.org/HttpSetMiscModule#Installation
利用其中 set_decode_base64 以及nginx 的 add_header 添加一个http头：Content-Disposition ，配合php代码实现。
nginx 添加模块重新编译
下载需要的模块：
到 https://github.com/agentzh/ 下载模块
agentzh-echo-nginx-module-v0.41-1-gb3ad5c1.tar.gz
agentzh-set-misc-nginx-module-v0.22rc8-5-ge79e7f0.tar.gz
simpl-ngx_devel_kit-v0.2.17-10-g4192ba6.tar.gz
解压到对应目录
安装：
./configure  --user=www --group=www --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/usr/local/nginx_module/ngx_devel_kit --add-module=/usr/local/nginx_module/misc-nginx --add-module=/usr/local/nginx_module/echo-nginx

make -j2

make install
php 实现部分我也不是太懂，就不贴出来了。
nginx 相关配置段

最终效果，上图


各位童鞋注意啦：该种方式在使用CDN的网站中也可以生效的。
从该功能上线以来看，效果还不错，agentzh（章亦春）写的nginx模块那是杠杠的
参考：http://wiki.nginx.org/HttpSetMiscModule#Installation
来自：http://longzhiyi.blog.51cto.com/350171/964677

背景：发现并没有压缩，查来查去是这个配置有问题写成1000k了，也就是下面这些列表都不符合条件，不给gzip压缩，gzip_min_length   1k; 不压缩临界值，大于1K的才压缩，一般不用改,被修改成1000k了，于是没有压缩，查了老半天content-type，都写了，呵呵。
修改后，在这儿测试了一下，果然压缩了：
http://pagespeed.webkaka.com/youhua/gzip/

网址 http://www.jackxiang.com/template/trielegant/styles.css 的检测结果：
是否压缩  是
压缩类型  gzip
原文件大小  8704 字节
压缩后文件大小  4275 字节
压缩率  50.88%

图片是否需要启用GZip压缩？

无意间看到有网友提及，图片不用GZip压缩的。图片尽量不要使用gzip,因为gif,png等图片本身就是被压缩过的，
开启和关闭图片GZip压缩后，网页的总体积是不同的，令人惊讶的是开启图片GZip压缩后，网页总体积竟然变大了。而耗时也相应的增多了。
===========================================
1、Vim打开Nginx配置文件

vim /usr/local/nginx/conf/nginx.conf

2、找到如下一段，进行修改

gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
#gzip_http_version 1.0;
gzip_comp_level 2;
gzip_types text/plain application/x-javascript text/css application/xml text/javascript application/x-httpd-php image/jpeg image/gif image/png;
gzip_vary off;
gzip_disable "MSIE [1-6]\.";

3、解释一下

第1行：开启Gzip

第2行：不压缩临界值，大于1K的才压缩，一般不用改

第3行：buffer，就是，嗯，算了不解释了，不用改

第4行：用了反向代理的话，末端通信是HTTP/1.0，有需求的应该也不用看我这科普文了；有这句的话注释了就行了，默认是HTTP/1.1

第5行：压缩级别，1-10，数字越大压缩的越好，时间也越长，看心情随便改吧

第6行：进行压缩的文件类型，缺啥补啥就行了，JavaScript有两种写法，最好都写上吧，总有人抱怨js文件没有压缩，其实多写一种格式就行了

第7行：跟Squid等缓存服务有关，on的话会在Header里增加"Vary: Accept-Encoding"，我不需要这玩意，自己对照情况看着办吧

第8行：IE6对Gzip不怎么友好，不给它Gzip了

上面摘自：http://www.veryhuo.com/a/view/51706.html

http://www.webkaka.com/blog/archives/how-to-set-gzip-for-js-in-Nginx.html
https://segmentfault.com/q/1010000000585128

查询是否被zip压缩:
http://pagespeed.webkaka.com/youhua/gzip/

输入：
http://www.jackxiang.com/images/js/common.js?jsver=2.1.1.3626.3


=======================================
启用Gzip  可减少 54.2 KB 启用服务器Gzip，可以减少传输字节数。更多  -3分
未启用Gzip的资源有：
http://www.jackxiang.com/template/trielegant/styles.css （大小： 8.5 KB 预计可减少 5.9 KB ）
http://www.jackxiang.com/images/js/common.js?jsver=2.1.1.3626.3 （大小： 20.3 KB 预计可减少 14.8 KB ）
http://www.jackxiang.com/lang/zh-cn/jslang.js?jsver=2.1.1.3626.3 （大小： 3.7 KB 预计可减少 2.1 KB ）
http://www.jackxiang.com/images/js/ajax.js?jsver=2.1.1.3626.3 （大小： 7.4 KB 预计可减少 6.0 KB ）
http://www.jackxiang.com/images/js/swfobject.js?jsver=2.1.1.3626.3 （大小： 6.4 KB 预计可减少 4.2 KB ）
http://www.jackxiang.com/images/css/SyntaxHighlighter.css （大小： 3.6 KB 预计可减少 2.5 KB ）
http://jackxiang.com/favicon.jpg （大小： 1.9 KB 预计可减少 793 B ）
http://js.users.51.la/4950674.js （大小： 1.9 KB 预计可减少 1.1 KB ）
http://www.jackxiang.com/images/hl/shCore.js （大小： 9.5 KB 预计可减少 5.7 KB ）
http://www.jackxiang.com/images/hl/shBrushPhp.js （大小： 3.7 KB 预计可减少 2.1 KB ）
http://www.jackxiang.com/images/hl/shBrushJScript.js （大小： 937 B 预计可减少 437 B ）
http://www.jackxiang.com/images/hl/shBrushJava.js （大小： 1.0 KB 预计可减少 494 B ）
http://www.jackxiang.com/images/hl/shBrushSql.js （大小： 1.9 KB 预计可减少 964 B ）
http://www.jackxiang.com/images/hl/shBrushCss.js （大小： 4.0 KB 预计可减少 2.2 KB ）
http://www.jackxiang.com/images/hl/shBrushCpp.js （大小： 2.7 KB 预计可减少 1.4 KB ）
http://www.jackxiang.com/images/hl/shBrushPython.js （大小： 4.7 KB 预计可减少 2.5 KB ）
http://www.jackxiang.com/template/trielegant/images/logo_header.png （大小： 5.6 KB 预计可减少 237 B ）
http://www.jackxiang.com/template/trielegant/images/long.gif （大小： 924 B 预计可减少 358 B ）
http://jackxiang.com/template/trielegant/images/bridge-banner-eleven.jpg （大小： 18.9 KB 预计可减少 354 B ）
http://icon.51.la/icon_0.gif （大小： 846 B 预计可减少 101 B ）
http://eiv.baidu.com/hmt/icon/21.gif （大小： 1.1 KB 预计可减少 69 B ）

背景：Nginx直接连接redis，不用php的扩展连接，一定程序上提高了redis性能，但是在程序逻辑的可控制上会弱一点，用来做一些单纯的高并发登录没有问题，逻辑重点这种玩法并不能带来很大的提升。
需要下载第三方模块ngx_http_redis-0.3.2.tar.gz，并需要重新编译nginx。
注意要注释掉ngx_http_redis_module.c文件的145行
/*static ngx_str_t  ngx_http_redis_db  = ngx_string("redis_db");*/
否则会报错，意思是这个定义的redis_db在程序里没有使用，算是个警告报错，注释掉安装即可

./configure --user=nginx --group=nginx  --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --add-module=/software/module/ngx_http_redis-0.3.2


配置
location / {
    set $redis_key $uri;

    redis_pass     name:6379;
    default_type   text/html;
    error_page     404 = /fallback;
  }

$redis_db
The number of redis database (required for < 0.3.2).
For ngx_http_redis >= 0.3.2 is not obligatory, default value is "0" if not defined.
这个$redis_db可以不配，默认是0database。
更多官方的资料请参考：http://wiki.nginx.org/HttpRedis2Module

更多参考之Keepalived+nginx+redis主从+tomcat一机多实例实现会话共享：
http://lovelace.blog.51cto.com/1028430/1550198
https://www.nginx.com/resources/wiki/modules/redis2/

背景：阿里云没备案会不让配置host访问的，被拦截，直接用ip访问呢？应该没啥吧。
   比如我服务器ip是192.168.1.1，两个域名为user.a.com，manage.a.com都映射到了该ip上。nginx里如何配置，当我用ip访问时默认打开user.a.com;而另一个域名manage.a.com又不影响呢？

这样就可以了

  
server {     listen 80;     server_name 192.168.1.1 user.a.com;     root  /tmp/www/user.a.com/webroot;     include  /tmp/conf/nginx.location.conf;     access_log /tmp/log/nginx-user.a.com.log; }
nginx.conf里写：
include vhosts/*.conf;

ls /usr/local/nginx/conf/vhosts/
10.70.37.2*.conf  default.conf
———————————————
10.70.37.2*.conf
server_name 10.70.37.24;//写成IP

default.conf
server_name 127.0.0.1;

来自：http://www.dewen.io/q/2760

背景：看一个nginx的404里有<!-- a padding to disable MSIE and Chrome friendly error page -->。
配置：upload_cleanup 400 404 499 500-505;
源码：在nginx源码里有配置位置和定义如下：
./src/http/ngx_http_special_response.c:"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
static u_char ngx_http_msie_padding[] =
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
"<!-- a padding to disable MSIE and Chrome friendly error page -->" CRLF
;
输出：
<html>
<head><title>413 Request Entity Too Large</title></head>
<body bgcolor="white">
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx</center>
</body>
</html>
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
————————————————————————————————————————————————————————
nginx自定义页面非常简单，两条指令就可以搞定
1. 在http{}段加入红色指令，如下
http {
...
        fastcgi_intercept_errors on;        
        error_page  404              /404.html;
...
}

2. 把404页面放到根目录(root指令定义的目录下)，默认是安装目录的html目录下。

3.测试配置是否正确
/usr/local/nginx/nginx -t

4.重新载入配置
kill -HUP `cat /usr/local/nginx/nginx.pid`

注：
自定义的404.html的内容必须大于512字节，否则ie下会显示默认404错误页面，不能显示自定义的404页面。
如果你的404内容小于512字节，可以再404.html的<html>标签后面加入一下内容，可以屏蔽浏览器默认错误提示。
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->
<!-- a padding to disable MSIE and Chrome friendly error page -->

来自：http://www.2cto.com/os/201212/176562.html

背景：Nginx代理PHP9000端口的接口里发现一些499........[23/Dec/2015:10:21:59 +0800] "POST /videoupload.php HTTP/1.1" 499 0 "-" "Mozilla/5.0 (compatible; KoPHP v3.0 +http://kophp.com/)" - "5.005"
日志记录中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进程数 问题解决 默认测试环境才开5个子进程。

来自：http://wmcxy.iteye.com/blog/2026835?&from=androidqq

背景：想测试android的pad浏览器屏幕的显示情况，而测试机没有网络，如果用wifi热点作fiddler2的代理也成，可是不是人人都有代理，最好是修改一下host文件。
最近在做的项目要通过域名调用内网的服务器，因为android模拟器host文件无法修改，导致无法通过域名使用http方法调用内网服务，因此从网上大量转载的一种方法，这种方法:

    1. 通过emulator -avd avdName -partition-size 128 启动模拟器

    2.通过adb root 和 adb remount 命令获得root权限。

    3.通过 adb pull /system/etc/hosts 命令将hosts文件转移到PC上，手动修改hosts，并且通过adb push将hosts文件再推送回去。

     这个问题是因为linux中的换行符和window中的回车换行不一致引起的，网上大部分方法是让利用ultraedit等编辑器直接修改，但是我复制到编辑器上依然无法修改。上贴中的malbers回复说，利用echo命令，可以直接通过命令将需要修改的内容添加到hosts文件中，试了一下，果然可行。

     首先键入 adb shell 命令（新版本的sdk adb命令被转移到了platform-tools目录中），然后echo 192.168.0.246 www.aaa.com>>/system/etc/hosts，敲入上面这条命令后，再使用 cat /system/etc/hosts查看hosts文件修改情况，发现hosts果然已经被修改，但是问题是依然没有换行，貌似只有换行了以后才能被识别，

因此再次利用echo命令加入了换行符，问题解决。具体操作如下：

     前面几个步骤不变，但是不需要将hosts文件pull到电脑上，如果你已经修改了但是无效，可以先pull出来，还原到原始状态，不要有任何换行，并替换掉

模拟器上已经修改的hosts，使它回复到原始状态。即只有127.0.0.1 localhost。

    然后进入adb shell ， 使用 echo -e \\n >> /system/etc/hosts 为hosts文件加入换行符。

    再次使用 echo 192.168.0.246 www.aaa.com >> /system/etc/hosts 。

    这样就完整解决了换行问题。再次在浏览器中敲入www.aaa.com,熟悉的页面也出现了。
转自：http://blog.csdn.net/landen11/article/details/7022376


首先请确认你修改的是文件是 /system/etc/hosts ，如果不是，那你即使改了也无效。

其次，如果你是在windows下修改hosts文件，那就必须注意换行符的问题，以及hosts文件格式的问题：

android下的hosts文件必须像以下这样写：

IP 域名

注意：

在IP和域名之间保留一个空格 每行只能有一个域名，不能一个IP后面跟多个域名。
android上的换行符(也就是回车)是LF，也就是\n，而windows上的换行符是CR LF，也就是\r\n
所以在windows下用记事本之类的软件编辑了hosts文件，放到手机上肯定认不出来的！解决的办法就是用NotePad++之类的文本编辑器，再使用“查找替换”，将“\r\n”替换成“\n”（注意要在notepad++里把查找模式设置为扩展模式，才能识别转义字符\r\n）
如果是在windows下编辑hosts，要保证最后一行结尾也是“\n”


终于搞掂！！！

转自：https://plus.google.com/105237252862440264277/posts/CF9F42e4axj

背景：有时在做一些Nginx的Proxy时，如从80端口请求后代码到其它web服务器如tomcat的8080端口，需要一些主备的思想，也就是万一主服务器挂了怎么办？用备机了，这块Nginx支持这样一个功能的。
一）nginx从前端域名支向代理并负载均衡代理到其他ip并配置了域名的机器，这儿得有proxy_set_header Host $host;相当于以域名访问IP:
    upstream backend_jackxiang {//均衡负载+备机         server   16.76.39.28:80 weight=1 max_fails=2 fail_timeout=5s;         server   16.76.39.29:80 weight=1 max_fails=2 fail_timeout=5s;         server   16.76.39.20:80 weight=1 max_fails=2 fail_timeout=5s;         server   16.76.39.21:80 weight=1 max_fails=2 fail_timeout=5s;         server   10.70.56.65:81 backup;         server   10.70.56.66:81 backup;         server   10.70.56.67:81 backup;         server   10.70.56.68:81 backup;     } {         listen       80;         server_name  jackxiang.jackxiang.com;         index index.html index.htm index.php;         location / {             proxy_set_header Host $host;             proxy_set_header X-Real-IP $remote_addr;             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;             proxy_pass http://backend_jackxiang;             client_body_buffer_size  512k;             proxy_connect_timeout    30;             proxy_read_timeout       60;             proxy_send_timeout       30;             proxy_buffer_size        256k;             proxy_buffers            4 256k;             proxy_busy_buffers_size 256k;


经测试，这个Nginx的七层代理感觉还是比Lvs差一点，压力测试时这块儿还是有点卡：
upstream lua {     server 10.70.**.1** weight=1;     #server 10.70.**.134 weight=1;     #server 10.70.**.135 weight=1;     #server 10.70.**.136 weight=1;     #server 10.70.**.137 weight=1;     #server 10.70.**.138 weight=1;     #server 10.70.**.139 weight=1; } server {     listen 80 default_server;     server_name 10.7*.6*.102;     location / {         proxy_pass                 http://lua;         proxy_next_upstream        http_502 http_504 error timeout invalid_header;         proxy_connect_timeout      60;         proxy_read_timeout         3600;         proxy_send_timeout         3600;         proxy_temp_file_write_size 64k;         proxy_redirect             off;         #proxy_set_header           Host $host;         proxy_set_header           X-Forwarded-For $remote_addr;     }     access_log /data/logs/nginx/access.log main; }

二）如nginx暴露出域名反向代理到一台tomcat的以IP指向的8080端口：
    upstream backend_tomcat {//8080 一般是tomcat服务器，这儿没有暴露出域名而是直接物理机IP，以权重进行负载。（特别是有些业务要落全落一台的，这样配置才行，否则散开了会出现数据不完整：28，29，30，31各放sqllite数据库分别记录如果不权重分开在调用时会出现业务逻辑问题）         server   16.76.39.28:8080 weight=100 max_fails=2 fail_timeout=5s;         server   16.76.39.29:8080 weight=90 max_fails=2 fail_timeout=5s;         server   16.76.39.30:8080 weight=80 max_fails=2 fail_timeout=5s;         server   10.120.0.31:8080 weight=70 max_fails=2 fail_timeout=5s; }     server     {         listen       80;         server_name  upload.jackxiang.com;         index index.html;         # Max file size         client_max_body_size 1048m;         location / {             proxy_set_header Host $host;             proxy_set_header X-Real-IP $remote_addr;             proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;             proxy_pass http://backend_tomcat;         }         access_log /data/logs/pcupload.log;     }
——————————————————————————————————————————
upstream  testproxy  {         server   127.0.0.1:8080;         server   192.168.1.15:8080 backup; }

只要在希望成为后备的服务器ip后面多添加一个backup参数，这台服务器就会成为备份服务器。
在平时不使用，nginx不会给它转发任何请求。只有当其他节点全部无法连接的时候，nginx才会启用这个节点。
一旦有可用的节点恢复服务，该节点则不再使用，又进入后备状态。

可以两台机子互为热备，平时各自负责各自的服务。在做上线更新的时候，关闭一台服务器的tomcat后，nginx自动把流量切换到另外一台服务的后备机子上，从而实现无痛更新，保持服务的持续性，提高服务的可靠性。

关于这个参数的官档说明：
http://wiki.nginx.org/NginxHttpUpstreamModule
backup - (0.6.7 or later) only uses this server if the non-backup servers are all down or busy (cannot be used with the directive ip_hash)

摘自：http://hillside.iteye.com/blog/703281

http://chattool.sinaapp.com/?p=1063

Hint: Some lines were ellipsized, use -l to show in full. systemctl status slapd  -l ,'journalctl -xn' for details. 看不清换行，先journalctl -xn > out.log,再vim看。
一）那个Service XXX start时，也是装入了内存活它的Service系统的，而用chkconfig -add memcached  就是装入这个Service系统，完全类似centos7 的systemctl daemon-reload,也就是说你改了/etc/init.d/memcached  如果不chkconfig -add memcached，service memcached start执行的还是旧的（尽管你替换了那个/etc/init.d/memcached文件）， 同理/lib/systemd/system/memcached.service,也是一样的道理，修改后得 systemctl daemon-reload才会生效，直接运行systemctl start memcached会提示你systemctl daemon-reload,不让你运行，也就是说它会监控/etc/systemd/system/*.service外，发现它还会监控centos6的/etc/init.d/* 的修改。
二）在CentOS7里面，只有运行了service memcached start后，这个systemctl才行被注入，一上来就运行systemctl start memcached , 它是不认识这个memcached  的，再就是如果自己Kill掉，没有用 service memcached stop,这个sytemctl 也是不知道它关了，想用systemctl start memcached也无法启动的，因为systemctl 认为它还运行着呢，于是得用systemctl stop memcached 后，再运行systemctl start memcached，也就成功了,否则即使systemctl start memcached啥也不输出就退出了，但是那个进程还是没有启动，说白了，在CentOS7里面，那个启动和停止最好是经过service或systemctl,连service 也是被systemctl接管了的，都得向systemctl注册！！！，艹。


背景：conf里面有一个ssl的conf，scp过来抄时忘记删除，但nginx下的nginx.conf下是include *.conf，于是出问题了，但nginx不报这个conf有问题，而是说没有找到ssl的crt文件，怎么办？主要是学会看日志 cat /var/log/messages | grep nginx ，看日志才发现是多了一个conf文件。

service nginx reload
Reloading nginx configuration (via systemctl):  Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.
——————————————————————————————————————————————————————————————————————

启动apache服务出现，或启动nginx时出现：
Starting nginx (via systemctl): Job for nginx.service failed. See 'systemctl status nginx.service' and 'journalctl -xn' for details.
查看错误提示

主要是学会看日志 cat /var/log/messages | grep nginx
Oct 10 14:34:12 iZ251vfc84kZ nginx: nginx: [emerg] BIO_new_file("/usr/local/nginx/conf/ssl/svn.justwinit.crt") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('/usr/local/nginx/conf/ssl/svn.justwinit.crt','r') error:2006D080:BIO routines:BIO_new_file:no such file)
Oct 10 14:34:12 iZ251vfc84kZ nginx: nginx: configuration file /usr/local/nginx/conf/nginx.conf test failed
Oct 10 14:34:12 iZ251vfc84kZ systemd: nginx.service: control process exited, code=exited status=1
[root@iZ251vfc84kZ vhost]# grep -r "svn.justwinit.crt" ./
./svn.justwinit.conf:        ssl_certificate     ssl/svn.justwinit.crt;
[root@iZ251vfc84kZ vhost]# rm -Rf svn.justwinit.conf


来自：http://wangsheng1.blog.51cto.com/29473/1550655

阅读全文