Nginx之配置

作者: 冰河winner | 来源:发表于2020-06-12 23:36 被阅读0次

    一个简单的配置文件如下:

    #定义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;  
                }
            }
    }
    

    1、 内置变量

    在log_format配置项当中,使用了很多Nginx的内置变量,一些变量代表了客户端请求头部的一些字段,如:$http_user_agent, $http_cookie等等,由于这些变量会在请求中定义,所以可能无法保证他们是存在的或者说可以定义到一些别的地方(例如遵循一定的规范)。

    常用变量如下:

    变量名 说明
    $args 请求行中的参数,同$query_string
    $content_length 请求头中的Content-length字段
    $content_type 请求头中的Content-Type字段
    $document_root 当前请求在root指令中指定的值
    $document_uri 不带请求参数的当前URI,不包含主机名,同$uri
    $host 请求中的主机头字段,如果请求中的主机头不可用,则为服务器处理请求的服务器名称
    $http_user_agent 客户浏览器信息
    $http_cookie 客户端cookie信息
    $remote_addr 客户端的IP地址
    $remote_port 客户端的端口
    $remote_user 经过Auth Basic Module验证的用户名
    $request_file_name 当前请求的文件路径,由root或alias指令与URI请求生成
    $request_method 这个变量是客户端请求的动作,通常为GET或POST
    $request_uri 包含请求参数的原始URI,不包含主机名
    $server_addr 服务器地址
    $server_name 服务器名称
    $server_port 请求到达服务器的端口号
    $server_protocol 请求使用的协议,通常是HTTP/1.0或HTTP/1.1
    $scheme HTTP方法(如http,https)

    例如,对于URL:http://localhost:88/test1/test2/test.php

    • $host:localhost
    • $server_port:88
    • $request_urihttp://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

    2、 负载均衡配置

    upstream用于配置负载均衡。Nginx的upstream目前支持4种方式的分配:

    • 轮询(默认)

    每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器down掉,能自动剔除。

    • weight

    指定轮询几率,weight和访问比率成正比,用于后端服务器性能不均的情况。

    例如:

    upstream bakend {
        server 192.168.0.14 weight=10;
        server 192.168.0.15 weight=10;
    }
    
    • ip_hash

    每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器,可以解决session的问题。

    例如:

    upstream bakend {
        ip_hash;
        server 192.168.0.14:88;
        server 192.168.0.15:80;
    }
    
    • fair(第三方)

    按后端服务器的响应时间来分配请求,响应时间短的优先分配。

    upstream backend {
        server server1;
        server server2;
        fair;
    }
    
    • 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;
    }
    

    此外,在负载机器的IP可以附带状态参数,例如

    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;
    }
    

    每个设备的状态设置为:

    • down:表示单前的server暂时不参与负载
    • weight:该值越大,负载的权重就越大。
    • backup:其它所有的非backup机器down或者忙的时候,请求backup机器。所以这台机器压力会最轻。

    3、 正则匹配

    正则匹配规则:

    • =开头表示精确匹配

    • ^~ 开头表示uri以某个常规字符串开头,不是正则匹配

    • ~ 开头表示区分大小写的正则匹配

    • ~* 开头表示不区分大小写的正则匹配

    • $结尾表示以某字符串结尾的正则匹配

    • !~!~分别为区分大小写不匹配及不区分大小写不匹配 的正则

    • / 通用匹配,任何请求都会匹配到

    看几个实例:

    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 ] 
    }
    

    配置的优先级遵循以下规则:

    (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

    所以实际使用中,有三个匹配规则定义可作参考:

    • 规则1

    直接匹配网站根,通过域名访问网站首页比较频繁,使用这个会加速处理,官网如是说。这里是直接转发给后端应用服务器了,也可以是一个静态首页

    location = / {
      proxy_pass http://tomcat:8080/index
    }
    
    • 规则2

    处理静态文件请求是nginx作为http服务器的强项,有两种配置模式,目录匹配或后缀匹配,任选其一或搭配使用:

    location ^~ /static/ {
      root /webroot/static/;
    }
    
    location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ {
      root /webroot/res/;
    }
    
    • 规则3

    通用规则,用来转发动态请求到后端应用服务器,非静态文件请求就默认是动态请求,自己根据实际把握

    location / {
      proxy_pass http://tomcat:8080/
    }
    

    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里,它们的执行顺序是:

    • 执行server块的rewrite指令

    • 执行location匹配

    • 执行选定的location中的rewrite指令

    如果其中某步URI被重写,则重新循环执行1-3,直到找到真实存在的文件;循环超过10次,则返回500 Internal Server Error错误。

    flag标志位用法如下:

    • last : 相当于Apache的[L]标记,表示完成rewrite

    • break : 停止执行当前虚拟主机的后续rewrite指令集

    • redirect : 返回302临时重定向,地址栏会显示跳转后的地址

    • 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)可以是如下任何内容:

    • 当表达式只是一个变量时,如果值为空或任何以0开头的字符串都会当做false

    • 直接比较变量和内容时,使用=或!=

    • 正则表达式匹配,*不区分大小写的匹配,!~区分大小写的不匹配

      • -f和!-f用来判断是否存在文件
      • -d和!-d用来判断是否存在目录
      • -e和!-e用来判断是否存在文件或目录
      • -x和!-x用来判断文件是否可执行

    例如:

    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(Method not 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 ^ http://example.com/ permanent;
    } //如果query string中包含"post=140",永久重定向到example.com
    
    location ~* \.(gif|jpg|png|swf|flv)$ {
      valid_referers none blocked www.jefflei.com www.leizhenfang.com;
      if ($invalid_referer) {
        return 404;
      } //防盗链
    }
    

    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将返回的数据发送给客户端。

    1.png

    以下为Nginx支持PHP的配置示例:

    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参数配置文件包含了进来。

    相关文章

      网友评论

        本文标题:Nginx之配置

        本文链接:https://www.haomeiwen.com/subject/mxpotktx.html