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-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又不影响呢?

这样就可以了

  

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:



经测试,这个Nginx的七层代理感觉还是比Lvs差一点,压力测试时这块儿还是有点卡:


二)如nginx暴露出域名反向代理到一台tomcat的以IP指向的8080端口:

——————————————————————————————————————————


只要在希望成为后备的服务器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
分页: 1/5 第一页 1 2 3 4 5 下页 最后页 [ 显示模式: 摘要 | 列表 ]