nginx的配置
1,启动nginx
[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
从容停止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
[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)全局模式
#启动进程数,通常设置成和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)工作模式
#工作模式与连接数上限 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服务器
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连接数的时候需要使
设置允许客户端请求的最大的单个文件的字节数 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)负载均衡配置
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进行匹配.可以进行重定向或者进行新的代理 负载均衡
(5)虚拟主机的配置
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配置
语法规则: 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)自动索引及别名功能
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) } }
(8)控制站点访问
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的一样
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需要在编译的时候手动指定才可以使用
location /nginx_status { stub_status on; access_log off; } http://192.168.87.133/nginx_status
(11)nginx的日志自动切割
nginx没有apache类似的cronolog的功能支持,但是可以通过nginx信号控制能的脚本来实现日志的自动切割
#/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自动切换日志