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自动切换日志