不会这些你敢说你会nginx?

港控/mmm° 2022-12-04 01:00 289阅读 0赞

一直以为自己很懂nginx，不就是配置一些负载一些路由嘛，直到这次需要自己进行调试部署时才发现依然存在好多概念不清的情况，比如location匹配的几种优先级，rewrite 阶段、access 阶段以及 content 阶段的运行顺序

因为工作需要，这里主要总结我们常用的server,location模块的一些信息

先来看一下nginx配置文件的大体分区  
![,text\_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw,size\_16,color\_FFFFFF,t\_70\#pic\_center)][text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center]  
**mian全局块**：影响nginx全局的配置模块，一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。  
**events模块**：

events{
      use epoll;
      worker_connections      65536;
    }

use epoll;use是个事件模块指令，用来指定Nginx的工作模式。Nginx支持的工作模式有select、poll、kqueue、epoll、rtsig和/dev/poll。其中select和poll都是标准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系统中。对于Linux系统，epoll工作模式是首选，在操作系统不支持这些高效模型时才使用select。

worker\_connections 65536;每一个worker进程能并发处理（发起）的最大连接数（包含与客户端或后端被代理服务器间等所有连接数）。nginx作为反向代理服务器，计算公式 最大连接数 = worker\_processes \* worker\_connections/4，所以这里客户端最大连接数是65536，这个可以增到到8192都没关系，看情况而定，但不能超过后面的worker\_rlimit\_nofile。当nginx作为http服务器时，计算公式里面是除以2。进程的最大连接数受Linux系统进程的最大打开文件数限制，在执行操作系统命令ulimit -n 65536后worker\_connections的设置才能生效。  
http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。

下面进入重点模块

## server块 ##

Server块： 一个server可以看作一个nginx的虚拟主机拷贝一份server段的文件如下

upstream backend {
    #    ip_hash;    #优先IP hash的规则
    #    backup: 备机IP，只有当主机都不可用时，才会走备机。主机恢复后，会走主机，但可#以配置slow_start配置主机缓慢加入时间
        server backend1.example.com       weight=5;
        server backend2.example.com:8080;
        server backup1.example.com:8080   backup;
        server backup2.example.com:8080   backup;
    }
    server {
            listen       9033;             #虚拟机监听的端口
            server_name  localhost;  #匹配的域名
            root /data/htdocs/www;  #服务器默认的网站根目录位置（html文件存放目录）
            index index.html index.htm index.php;  #默认访问的html名称   一般在root定义的路径下存放
            location /ftpFile {   #匹配方式见下方
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
       #         alias   /home/migu_nginx/ftpdata;
            }
    location /img/ {
        alias /var/www/image/;     #alias会直接覆盖上面的匹配内容/img，并替换成定义内容加上截取的后缀
    }
    location /img/ {
        root /var/www/image;   #root不会直接覆盖上面的匹配内容/img，并替换成定义内容加上截取的后缀
    }

### location匹配规则： ###

语法规则： location \[=||\*|^~\] /uri/ \{… \}首先匹配 =，其次匹配^~,其次是按文件中顺序的正则匹配，最后是交给 /通用匹配。当有匹配成功时候，停止匹配，按当前匹配规则处理请求。

<table> 
 <thead> 
  <tr> 
   <th>符号</th> 
   <th>匹配方式</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>=</td> 
   <td>精准匹配</td> 
  </tr> 
  <tr> 
   <td>^~</td> 
   <td>匹配以某某开头的，如果有一个uri匹配到了多个location，那么进入匹配最长的那个</td> 
  </tr> 
  <tr> 
   <td>~*</td> 
   <td>不区分大小写的正则匹配</td> 
  </tr> 
  <tr> 
   <td>~</td> 
   <td>区分大小写的正则匹配</td> 
  </tr> 
  <tr> 
   <td>/</td> 
   <td>通用匹配，能匹配任何请求</td> 
  </tr> 
 </tbody> 
</table>

值得注意的是，有一种暂不能理解的情况，但确实存在  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center]

### root和alias的区别 ###

配置一  
location /img/ \{  
alias /var/www/image/;  
\}  
\#若按照上述配置的话，则访问/img/目录里面的文件时，ningx会自动去/var/www/image/目录找文件  
配置一：  
location /img/ \{  
root /var/www/image;  
\}  
\#若按照这种配置的话，则访问/img/目录下的文件时，nginx会去/var/www/image/img/目录下找文件。\]比如访问链接为 /img/a/a.html则回去/var/www/image/img/a目录下找a.html

**set指令**  
set $task\_flag 0; 设置变量task\_flag为0

**反向代理 proxy\_pass**  
如果一个请求过来了，比如 http:/127.0.0.1/mg/123/2.html,如果是下面这种配置，那最后的路由地址是http://apimigu/mg/123/2.html  
location /mg\{  
proxy\_pass http://apimigu;  
\}  
若是下面带/的这种配置,那路由后得到的地址是http://apimigu/123/2.html  
location /mg\{  
proxy\_pass http://apimigu/;  
\}  
所以结尾有没有/符号很重要  
如果转发的和后台有多台服务器，我们可以定义一个upstream 负载均衡

location /mg{ 
     proxy_pass         http://apimigu/;
     }
    upstream apimigu{
    #    ip_hash;    #优先IP hash的规则
        server backend1.example.com       weight=5;
        server backend2.example.com:8080;
        server backup1.example.com:8080   backup;
        server backup2.example.com:8080   backup;
    }
    serve

### rewrite语法 ###

rewrite是实现URL重写重定向的重要指令，他根据regex(正则表达式)来匹配内容跳转到replacement，结尾是flag标记

配置语法：

Syntax： rewrite regex replacement [flag];

rewrite的含义：该指令是实现URL重写的指令。  
regex的含义：用于匹配URI的正则表达式。  
replacement：将regex正则匹配到的内容替换成 replacement。  
flag: flag标记。  
举个小例子

rewrite ^/(.*) http://www.baidu.com/ break;     # 匹配成功后跳转到百度

找了份正则表达式符号含义表，以供查询  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center 1]  
rewrite 的最后一项参数flag的作用，一般有四个  
值得一提的是，正常情况下nginx会收集所有的rewrite结果集，这和之后要介绍的nginx的三个级别有关

<table> 
 <thead> 
  <tr> 
   <th>参数</th> 
   <th>代表意义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>break</td> 
   <td>停止rewrite检查【如果没有匹配到，则不再向下匹配，直接返回结果404】</td> 
  </tr> 
  <tr> 
   <td>last</td> 
   <td>停止rewrite检查【如果没有匹配到，会继续向下匹配】</td> 
  </tr> 
  <tr> 
   <td>redirect</td> 
   <td>临时重定向。请求日志中的状态码为302</td> 
  </tr> 
  <tr> 
   <td>permanent</td> 
   <td>永久重定向。请求日志中的状态码为301</td> 
  </tr> 
 </tbody> 
</table>

对于临时重定向和永久重定向的区别，这里着重说明以下  
首先客户端浏览器的URL都会改变；

302重定向是暂时的重定向，搜索引擎会抓取新的内容而保留旧的地址。因为服务器返回302，所以搜索引擎会认为新的网址是暂时的；

301重定向是永久的重定向，搜索引擎会抓取新的内容的同时将旧的地址替换为重定向后的网址；

**nginx中 $1,$2 的含义**，有个博客讲的很简单易懂，这里直接拷贝

Nginx中，set $para $1，$1表示路径中正则表达式匹配的第一个参数。  
以下是一个示例，用以实验$1,$2。  
如：location ~/yxl/(.*)/(.*) \{  
set $para1 $1  
set $para2 $2  
content\_by\_lua\_block \{  
ngx.say(ngx.var.para1)  
ngx.say(ngx.var.para2)  
\}

\}  
此时，若访问路径为localhost:8080/yxl/qwe/asd时，则浏览器会输出  
qwe  
asd

[原文链接][Link 1]

## nginx请求执行的几大阶段 ##

详细分的话一共有11个阶段，这里着重介绍rewrite 、access 以及 content 三大阶段

不按代码顺序执行，是按阶段执行，顺序如下：  
先执行命中的所有rewrite层指令（下面的set），  
再执行access，再执行content（下面的echo）

举个例子  
语法：

location  = / { 
           set $a 32;      
             echo $a;       
               set $a 64;   
               eho $a;
               }

因为是先收集结果，最后再content，所以最后两个打印都是64

[text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/d78eb0954e4d4ed29595d115dcd3c3cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221123/d74a2044eb274f598703296a99bccc3f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNzAwMDMw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221123/c0df4c9423dc47fab1178e28ea2cbd98.png
[Link 1]: https://blog.csdn.net/yxl0011/article/details/72818409?utm_source=blogxgwz4&utm_medium=distribute.pc_relevant.none-task-blog-title-3&spm=1001.2101.3001.4242