nginx的配置

1,启动nginx

1
2
3
4
5
6
7
[root@centos6 nginx-1.2.9]# /usr/sbin/nginx -c /etc/nginx/nginx.conf   启动nginx
[root@centos6 nginx-1.2.9]# ps -ef|grep nginx   查看进程
root   5479   1 0 04:15 ?    00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx   5480 5479 0 04:15 ?    00:00:00 nginx: worker process  
root   5534 2377 0 04:22 pts/1  00:00:00 grep nginx
[root@centos6 nginx-1.2.9]# netstat -tulnp|grep nginx     查看nginx监听的端口
tcp    0   0 0.0.0.0:80         0.0.0.0:*          LISTEN   5479/nginx.conf


2,停止nginx

1
2
3
4
5
6
从容停止nginx
[root@centos6 ~]# kill -QUIT $(cat /var/run/nginx/nginx.pid)
快速停止nginx
[root@centos6 ~]# kill -TERM $(cat /var/run/nginx/nginx.pid)
 强制停止所有的nginx
[root@centos6 ~]# kill -9 nginx


3,重启nginx

1
2
3
4
5
[root@centos6 ~]# kill -HUP $(cat /var/run/nginx/nginx.pid)
 检测nginx的配置文件的正确性
[root@centos6 ~]# /usr/sbin/nginx -t -c /etc/nginx/nginx.conf
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful


4,nginx的配置

[root@centos6 rc0.d]# vim /usr/local/nginx/conf/nginx.conf

(1)全局模式

1
2
3
4
5
6
7
8
9
10
#启动进程数,通常设置成和cpu的数量相等
worker_processes 1;
#全局错误日志定义类型,[ debug | info | notice | warn | error | crit ]
error_log  logs/error.log info;
#进程文件
pid logs/nginx.pid;
worker_rlimit_nofile65535;
这个指令是指当一个nginx 进程打开的最多文件描述符数目,理论值应该是最多打开文
件数(ulimit -n)与nginx 进程数相除,但是nginx 分配请求并不是那么均匀,所以最好与ulimit -n的值保持一致。
现在在linux2.6内核下开启文件打开数为65535,worker_rlimit_nofile就相应应该填写65535


(2)工作模式

1
2
3
4
5
6
7
8
9
#工作模式与连接数上限
events
{
#参考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ];
epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型。
use epoll;
#单个进程最大连接数(最大连接数=连接数*进程数)
worker_connections 65535;
}

进程的最大连接数受系统最大打开文件数的限制,在执行操作系统命令 ulimit -n 65535之后

worker_connections才会生效


(3)设定http服务器


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
include mime.types; #文件扩展名与文件类型映射表
default_type application/octet-stream; #默认文件类型
#charset utf-8; #默认编码
server_names_hash_bucket_size 128; #服务器名字的hash表大小
client_header_buffer_size 32k; #上传文件大小限制
large_client_header_buffers 4 64k; #设定请求缓
client_max_body_size 8m; #设定请求缓
sendfile on; #开启高效文件传输模式,sendfile指令指定nginx是否调用sendfile函数来输出文件,对于普通应用设为 on,如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络I/O处理速度,降低系统的负载。注意:如果图片显示不正常把这个改成off。
autoindex on; #开启目录列表访问,合适下载服务器,默认关闭。
tcp_nopush on; #防止网络阻塞
tcp_nodelay on; #防止网络阻塞
keepalive_timeout 120; #长连接超时时间,单位是秒
#FastCGI相关参数是为了改善网站的性能:减少资源占用,提高访问速度。下面参数看字面意思都能理解。
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
#gzip模块设置
gzip on; #开启gzip压缩输出
gzip_min_length 1k; #最小压缩文件大小
gzip_buffers 4 16k; #压缩缓冲区
gzip_http_version 1.0; #压缩版本(默认1.1,前端如果是squid2.5请使用1.0
gzip_comp_level 2; #压缩等级
gzip_types text/plain application/x-javascript text/css application/xml;
#压缩类型,默认就已经包含textml,所以下面就不用再写了,写上去也不会有问题,但是会有一个warn。
gzip_vary on;
#limit_zone crawler $binary_remote_addr 10m; #开启限制IP连接数的时候需要使

1
2
3
4
5
6
7
8
9
10
11
12
设置允许客户端请求的最大的单个文件的字节数
   client_max_body_size 20m;
设置客户端的请求头的header buffer的大小。对于大多数请求,1kb的的大小就够了。如果自定义了消息头或者有更大的cookie,那么就可以增加其大小了
    client_header_buffer_size 32k;
用来指定客户端请求中较大的消息头缓存的最大数量和大小,这里的意思是4为个数,32k为大小 
 large_client_header_buffers 4 32k;
设置客户端请求头的读取超时时间   超过这个时间就会返回408
    client_header_timeout 10;
设置客户端请求主体读取超时时间  超过这个时间就会返回408
    client_body_timeout 10;
指定响应客户端的超时时间。这个时间仅仅限于两个连接活动之间的时间,如果超过这个时间,客户端没有任何活动,nginx就会关闭连接
    send_timeout  10;


(4)负载均衡配置

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
nginx 的upstream目前支持4种方式的分配
1、轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器 ,如果后端服务器down掉,能自动剔除。
2、weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
例如:
    upstream bakend {
         server 192.168.0.14 weight=10;
         server 192.168.0.15 weight=10;
    }
2、ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session 的问题。
例如:
    upstream bakend {
         ip_hash;
         server 192.168.0.14:88;
         server 192.168.0.15:80;
    }
3、fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
upstream backend {
    server server1;
    server server2;
    fair;
}
4、url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法
upstream backend {
    server squid1:3128;
    server squid2:3128;
    hash   $request_uri;
    hash_method crc32;
}
tips:
upstream bakend{#定义负载均衡 设备的Ip及设备状态
ip_hash;
    server 127.0.0.1:9090 down;
    server 127.0.0.1:8080 weight=2;
    server 127.0.0.1:6060;
    server 127.0.0.1:7070 backup;
}
在需要使用负载均衡的server中增加
proxy_pass http://bakend/ ;
每个设备的状态设置为:
1.down 表示单前的server暂时不参与负载
2.weight 默认为1.weight越大,负载的权重就越大。
3.max_fails :允许请求失败的次数默认为1.当超过最大次数时,返回proxy_next_upstream 模块定义的错误
4.fail_timeout:max_fails次失败后,暂停的时间。
5.backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。
nginx支持同时设置多组的负载均衡,用来给不用的server来使用。
client_body_in_file_only 设置为On 可以讲client post过来的数据记录到文件中用来做debug
client_body_temp_path 设置记录文件的目录 可以设置最多3层目录
location 对URL进行匹配.可以进行重定向或者进行新的代理 负载均衡
1
 


(5)虚拟主机的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
server {
 listen 80 default_server;
 server_name 192.168.87.133;
 root /usr/html/www1;
 index index.html;
 }
http://192.168.87.133 就可以访问/usr/html/www1
server
{
#监听端口
listen 80;
#域名可以有多个,用空格隔开
server_name www.ha97.com ha97.com;
index index.html index.htm index.php;
root /usr/html/ha97;

#定义本虚拟主机的访问日志

access_log /var/log/loginx/ha97access.log access;


(6) URL配置

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
语法规则: location [=|~|~*|^~] /uri/ { … }
= 开头表示精确匹配
^~ 开头表示uri以某个常规字符串开头,理解为匹配url路径即可。nginx不对url做编码,因此请求为/static/20%/aa,可以被规则^~ /static//aa匹配到(注意是空格)。
~ 开头表示区分大小写的正则匹配
~* 开头表示不区分大小写的正则匹配
!~和!~*分别为区分大小写不匹配及不区分大小写不匹配 的正则
/ 通用匹配,任何请求都会匹配到。
多个location配置的情况下匹配顺序为(参考资料而来,还未实际验证,试试就知道了,不必拘泥,仅供参考):
首先匹配 =,其次匹配^~, 其次是按文件中顺序的正则匹配,最后是交给 /通用匹配。当有匹配成功时候,停止匹配,按当前匹配规则处理请求。
例子,有如下匹配规则:
location = / {
#规则A
}
location = /login {
#规则B
}
location ^~ /static/ {
#规则C
}
location ~ \.(gif|jpg|png|js|css)$ {
#规则D
}
location ~* \.png$ {
#规则E
}
location !~ \.xhtml$ {
#规则F
}
location !~* \.xhtml$ {
#规则G
}
location / {
#规则H
}
那么产生的效果如下:
访问根目录/, 比如http://localhost/将匹配规则A
访问 http://localhost/login将匹配规则B,http://localhost/register则匹配规则H
访问 http://localhost/static/a.html将匹配规则C
访问 http://localhost/a.gif, http://localhost/b.jpg将匹配规则D和规则E,但是规则D顺序优先,规则E不起作用,而 http://localhost/static/c.png则优先匹配到规则C
访问 http://localhost/a.PNG则匹配规则E,而不会匹配规则D,因为规则E不区分大小写。
访问 http://localhost/a.xhtml不会匹配规则F和规则G,http://localhost/a.XHTML不会匹配规则G,因为不区分大小写。规则F,规则G属于排除法,符合匹配规则但是不会匹配到,所以想想看实际应用中哪里会用到。
访问 http://localhost/category/id/1111则最终匹配到规则H,因为以上规则都不匹配,这个时候应该是nginx转发请求给后端应用服务器,比如FastCGI(php),tomcat(jsp),nginx作为方向代理服务器存在。
所以实际使用中,个人觉得至少有三个匹配规则定义,如下:
#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。
#这里是直接转发给后端应用服务器了,也可以是一个静态首页
# 第一个必选规则
location = / {
proxy_pass http://tomcat:8080/index
}
# 第二个必选规则是处理静态文件请求,这是nginx作为http服务器的强项
# 有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用
location ^~ /static/ {
 root /webroot/static/;
}
location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
 root /webroot/res/;
}
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器
#非静态文件请求就默认是动态请求,自己根据实际把握
#毕竟目前的一些框架的流行,带.php,.jsp后缀的情况很少了
location / {
proxy_pass http://tomcat:8080/
}


(7)自动索引及别名功能

1
2
3
4
5
6
7
8
9
10
11
12
server {
 listen 80 default_server;
 server_name 192.168.87.133;
 root /usr/html;
 index index.html;
 location /www1 {
  autoindex on;  (如果有index.html文件会优先访问)
  }
 location /i/ {
  alias /etc/; (当访问http://192.168.87.133/i/的时候其实是访问/etc)
  }
 }


212628371.jpg


(8)控制站点访问

1
2
3
4
5
6
7
8
9
10
11
12
13
14
server {
listen 80 default_server;
server_name 192.168.87.133;
root /usr/html;
index index.html;
location /www1 {
 autoindex on;
 deny 192.168.87.1;
 allow 192.168.87.133 ; 当拒绝和允许冲突的话,按照次序生效,最前面的生效
 }
location /i/ {
 alias /etc/;
 }
}


(9)身份验证

nginx的身份验证和apache的一样

1
2
3
4
5
6
7
8
9
10
11
location = / {
        index  index.html index.htm;
        auth_basic     "nginx_auth";
        auth_basic_user_file /usr/local/nginx/conf/htpassword;
        }
[root@test4 nginx]# which htpasswd
/usr/bin/htpasswd
[root@test4 nginx]# htpasswd -c /usr/local/nginx/conf/htpassword webadmin
New password:
Re-type new password:
Adding password for user webadmin



(10)状态检查

模块stubstatus需要在编译的时候手动指定才可以使用

1
2
3
4
5
location /nginx_status {
  stub_status on;
  access_log off;
  }
http://192.168.87.133/nginx_status

214134207.jpg


(11)nginx的日志自动切割

nginx没有apache类似的cronolog的功能支持,但是可以通过nginx信号控制能的脚本来实现日志的自动切割

1
2
3
4
5
6
7
8
#/bin/bash
mkdir -p /home/nginx/logs
savepath_log='/home/nginx/logs'
nginx_log='/usr/local/nginx/logs'
mkdir -p $savepath_log/$(date +%Y)/(date +%m)
mv $nginx_log/access.log  $savepath_log/$(date +%Y)/(date +%m)/access.$(date +%F).log
mv $nginx_log/error.log  $savepath_log/$(date +%Y)/(date +%m)/error.$(date +%F).log
kill -USER1 `cat /usrlocal/nginx/logs/nginx.pid`


USER1信号是使nginx自动切换日志