请选择 进入手机版 | 继续访问电脑版

Nginx配置说明

2018-10-11 09:06
800
#定义Nginx运行的用户及用户组  
user  userName userGroupName;  
#工作进程数目,根据硬件调整,通常等于CPU数量或者2倍于CPU  
worker_processes  1;  
#错误日志路径与级别,级别选项:debug|info|notice|warn|error|crit|alert|emerg  
error_log  logs/error.log debug;  
#pid(进程标识符)存放路径  
pid  logs/nginx.pid;  
events {  
   #每个工作进程的最大连接数量  
   worker_connections  1024;  
   #连接超时时间,这里指的是http层面的keep-alive并非tcp的keepalive  
   keepalive_timeout  60;  
   #指定IO模型,linux建议epoll,FreeBSD建议采用kqueue,window下不指定  
   use epoll;  
}  
#设置http服务器  
http {  
   #文件扩展名与文件类型映射表  
   include mime.types;  
   #默认文件类型  
   default_type  text/html;  
   #日志格式设置,main为日志格式的名称可在后文中引用  
   log_format main  '$remote_addr - $remote_user[$time_local] "$request" '  
                     '$status $body_bytes_sent"$http_referer" '  
                    '"$http_user_agent" "$http_x_forwarded_for"';  
   #访问日志路径、格式     
   access_log logs/access.log  main;         
   #sendfile指令指定 nginx是否调用sendfile 函数(zero copy 方式)来输出文件,对于普通应用,必须设为on。     
   #如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络IO处理速度,降低系统uptime。     
   sendfile on;   
   #允许或禁止使用socket的TCP_CORK的选项,此选项仅在使用sendfile的时候使用     
   tcp_nopush on;     
   #超时时间     
   keepalive_timeout  65;     
   #是否开启gzip压缩     
   #gzip on;  
   #虚拟主机配置,下可以有多个location用来表示不同的反向代理         
   server {      
            #监听端口         
            listen  80;        
            #主机名,默认为本机         
            server_name  127.0.0.1;     
            #编码        
            charset utf-8;      
            #访问日志         
            access_log  logs/host.access.log  main;      
            #根路径“/” 的访问规则         
            location / {      
               #网站根目录            
               root   html;         
               #默认网页            
               index  index.html index.htm index.php;         
            }  
            #发生404错误时跳转到/404.html页面         
            error_page  404 /404.html;  
            #配置名为“static_file_server”的主机,按照权重负载均衡  
            upstream static_file_server {  
               server 192.168.2.1:8080 weight=1;  
               server 192.168.2.2:8080 weight=2;  
               server 192.168.2.3:8080 weight=3;      
            }  
            #正则表达式,配置以“.js”、“.css”结尾的路径的访问规则  
            location ~ .*\.(js|css)?$ {  
               #将该类请求转发至static_file_server  
               proxy_pass http://static_file_server/  
               #设置浏览器缓存过期时间      
               expires  600;  
               #关闭重定向         
               proxy_redirect  off;            
               #以下三行,目的是将代理服务器收到的用户的信息传到真实服务器上        
               proxy_set_header  Host $host;      
               proxy_set_header  X-Real-IP $remote_addr;           
               proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;  
               #拒绝的ip  
               deny  127.0.0.1;  
               #允许的ip  
               allow  172.18.5.54;   
            }  
   }  
}  

3.1 内置变量

在log_format配置项当中,使用了很多Nginx的内置变量,一些变量代表了客户端请求头部的一些字段,如:$http_user_agent,$http_cookie等等,由于这些变量会在请求中定义,所以可能无法保证他们是存在的或者说可以定义到一些别的地方(例如遵循一定的规范)。
常用变量如下:
Nginx配置说明-1.jpg
例:http://localhost:88/test1/test2/test.php
$host:localhost
$server_port:88
$request_uri:http://localhost:88/test1/test2/test.php
$document_uri:/test1/test2/test.php
$document_root:/var/www/html
$request_filename:/var/www/html/test1/test2/test.php

3.2 负载均衡配置

upstream用于配置负载均衡。Nginx的upstream目前支持4种方式的分配:
l   轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。
l   weight
指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。
例如:
[plain] view plain copy
upstream bakend{  
   server 192.168.0.14 weight=10;  
   server 192.168.0.15 weight=10;  
}  

l   ip_hash
每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。
例如:
[plain] view plain copy
upstream bakend{  
   ip_hash;  
   server 192.168.0.14:88;  
   server 192.168.0.15:80;  
}  

l   fair(第三方)
按后端服务器的响应时间来分配请求,响应时间短的优先分配。
[plain] view plain copy
upstream backend{  
   server server1;  
   server server2;  
   fair;  
}  

l   url_hash(第三方)
按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。
例:在upstream中加入hash语句,server语句中不能写入weight等其他的参数,hash_method是使用的hash算法
[plain] view plain copy
upstream backend{  
   server squid1:3128;  
   server squid2:3128;   
   hash $request_uri;  
   hash_method crc32;  
}  
此外,在负载机器的IP可以附带状态参数,例如
[plain] view plain copy
upstream bakend{  
   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;  
}  

每个设备的状态设置为:
l   down表示单前的server暂时不参与负载
l   weight为weight越大,负载的权重就越大。
l   backup: 其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

3.3 正则匹配

正则匹配规则:
l   =开头表示精确匹配
l   ^~ 开头表示uri以某个常规字符串开头,不是正则匹配
l   ~ 开头表示区分大小写的正则匹配
l   ~* 开头表示不区分大小写的正则匹配
l   $结尾表示以某字符串结尾的正则匹配
看几个实例:
[plain] view plain copy
location  = / {  
#通用匹配, 如果没有其它匹配,任何请求都会匹配到  
[ configuration A ]  
}  
location  / {  
# 因为所有的地址都以 / 开头,所以这条规则将匹配到所有请求  
# 但是正则和最长字符串会优先匹配  
[ configuration B ]  
}  
location/documents/ {  
# 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索  
# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条  
[ configuration C ]  
}  
location ~/documents/Abc {  
# 匹配任何以 /documents/ 开头的地址,匹配符合以后,还要继续往下搜索  
# 只有后面的正则表达式没有匹配到时,这一条才会采用这一条  
[ configuration CC ]  
}  
location ^~/images/ {  
# 匹配任何以 /images/ 开头的地址,匹配符合以后,停止往下搜索正则,采用这一条。  
[ configuration D ]  
}  
location ~*\.(gif|jpg|jpeg)$ {  
# 匹配所有以 gif,jpg或jpeg 结尾的请求  
# 然而,所有请求 /images/ 下的图片会被 config D 处理,因为 ^~ 到达不了这一条正则  
[ configuration E ]  
}  
location/images/ {  
# 字符匹配到 /images/,继续往下,会发现 ^~ 存在  
[ configuration F ]  
}  
location/images/abc {  
# 最长字符匹配到 /images/abc,继续往下,会发现 ^~ 存在  
# F与G的放置顺序是没有关系的  
[ configuration G ]  
}  
location ~/images/abc/ {  
# 只有去掉 config D 才有效:先最长匹配 config G 开头的地址,继续往下搜索,匹配到这一条正则,采用  
   [ configuration H ]  
}  
顺序 no优先级: (location =) > (location 完整路径) >(location ^~ 路径) > (location ~,~* 正则顺序) > (location 部分起始路径) > (/)
上面的匹配结果 按照上面的location写法,以下的匹配示例成立:
/ -> config A
精确完全匹配,即使/index.html也匹配不了
/downloads/download.html-> config B
匹配B以后,往下没有任何匹配,采用B
/images/1.gif-> configuration D
匹配到F,往下匹配到D,停止往下
/images/abc/def-> config D
最长匹配到G,往下匹配D,停止往下
你可以看到 任何以/images/开头的都会匹配到D并停止,FG写在这里是没有任何意义的,H是永远轮不到的,这里只是为了说明匹配顺序
/documents/document.html-> config C
匹配到C,往下没有任何匹配,采用C
/documents/1.jpg-> configuration E
匹配到C,往下正则匹配到E
/documents/Abc.jpg-> config CC
最长匹配到C,往下正则顺序匹配到CC,不会往下到E
所以实际使用中,有三个匹配规则定义可作参考:
[plain] view plain copy
#直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。  
#这里是直接转发给后端应用服务器了,也可以是一个静态首页  
# 第一个必选规则  
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/;  
}  
#第三个规则就是通用规则,用来转发动态请求到后端应用服务器  
#非静态文件请求就默认是动态请求,自己根据实际把握  
location / {  
   proxy_pass http://tomcat:8080/
}  

3.4 rewrite配置

rewrite功能就是,使用nginx提供的全局变量或自己设置的变量,结合正则表达式和标志位实现url重写以及重定向。rewrite只能放在server{},location{},if{}中,并且只能对域名后边的除传递参数外的字符串起作用,例如 http://seanlook.com/a/we/index.php?id=1&u=str 只对/a/we/index.php重写。语法:
rewrite regex replacement [flag]
如果想对域名或参数字符串起作用,可以使用全局变量匹配,也可以使用proxy_pass反向代理。
表面看rewrite和location功能有点像,都能实现跳转,主要区别在于rewrite是在同一域名内更改获取资源的路径,而location是对一类路径做控制访问或反向代理,可以proxy_pass到其他机器。很多情况下rewrite也会写在location里,它们的执行顺序是:
(1)执行server块的rewrite指令
(2)执行location匹配
(3)执行选定的location中的rewrite指令
如果其中某步URI被重写,则重新循环执行1-3,直到找到真实存在的文件;循环超过10次,则返回500 Internal Server Error错误。
flag标志位用法如下:
l   last : 相当于Apache的[L]标记,表示完成rewrite
l   break : 停止执行当前虚拟主机的后续rewrite指令集
l   redirect : 返回302临时重定向,地址栏会显示跳转后的地址
l   permanent : 返回301永久重定向,地址栏会显示跳转后的地址
因为301和302不能简单的只返回状态码,还必须有重定向的URL,这就是return指令无法返回301,302的原因了。这里 last 和 break 区别有点难以理解:last一般写在server和if中,而break一般使用在location中; last不终止重写后的url匹配,即新的url会再从server走一遍匹配流程,而break终止重写后的匹配;break和last都能组织继续执行后面的rewrite指令。
还有一个if指令,非常有用,语法为
if(condition){
...
}
对给定的条件condition进行判断。如果为真,大括号内的rewrite指令将被执行,if条件(conditon)可以是如下任何内容:
l   当表达式只是一个变量时,如果值为空或任何以0开头的字符串都会当做false
l   直接比较变量和内容时,使用=或!=
l   ~正则表达式匹配,~*不区分大小写的匹配,!~区分大小写的不匹配
-f和!-f用来判断是否存在文件
-d和!-d用来判断是否存在目录
-e和!-e用来判断是否存在文件或目录
-x和!-x用来判断文件是否可执行
例如:
[plain] view plain copy
if($http_user_agent ~ MSIE) {  
   rewrite ^(.*)$ /msie/$1 break;  
} //如果UA包含"MSIE",rewrite请求到/msid/目录下  
if ($http_cookie~* "id=([^;]+)(?:;|$)") {  
   set $id $1;  
} //如果cookie匹配正则,设置变量$id等于正则引用部分  
if($request_method = POST) {  
   return 405;  
} //如果提交方法为POST,则返回状态405(Methodnot allowed)。return不能返回301,302  
if ($slow) {  
   limit_rate 10k;  
} //限速,$slow可以通过 set 指令设置  
if (!-f$request_filename){  
   break;  
   proxy_pass http://127.0.0.1;  
} //如果请求的文件名不存在,则反向代理到localhost 。这里的break也是停止rewrite检查  
if ($args ~post=140){  
   rewrite ^ Example Domain permanent;  
} //如果query string中包含"post=140",永久重定向到example.com
location ~*\.(gif|jpg|png|swf|flv)$ {  
   valid_referers none blocked www.jefflei.comwww.leizhenfang.com;  
   if ($invalid_referer) {  
       return 404;  
   } //防盗链  
}  
3.5 FastCGI配置

Nginx本身是不支持对外部程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket,(这个socket可以是文件socket,也可以是ip socket)。为了调用CGI程序,还需要一个FastCGI的wrapper(wrapper可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接纳到请求,然后派生出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据发送给客户端。
以下为Nginx支持PHP的配置示例:
[plain] view plain copy
location ~\.php$ {  
   root           html;  
   fastcgi_pass   127.0.0.1:9000;  
   fastcgi_index  index.php;  
   fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;  
   include        fastcgi_params;  
}  
通过location指令,将所有以php为后缀的文件都交给127.0.0.1:9000来处理,而这里的IP地址和端口就是FastCGI进程监听的IP地址和端口。 fastcgi_param指令指定放置PHP动态程序的主目录,也就是$fastcgi_script_name前面指定的路径,建议将这个目录与Nginx虚拟主机指定的根目录保持一致,当然也可以不一致。 fastcgi_params文件是FastCGI进程的一个参数配置文件,在安装Nginx后,会默认生成一个这样的文件,这里通过include指令将FastCGI参数配置文件包含了进来。
分享到 :
0 人收藏
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Archiver|手机版|小黑屋|翁笔

© 2001-2018 Wengbi.com

返回顶部