[后端]nginx配置文件详解

1、nginx配置概览

概览

一个典型的nginx配置文件是由一系列的server块组成。而每个server块是有一系列的location块组成。server块是nginx从逻辑上划分出来的一个个的虚拟服务器，可以从逻辑上认为你的服务器变成多个了。block块定义了一个url路径该如何定位到正式的文件。总体来说，nginx处理一个请求的时候，先根据(ip地址，port端口，domain域名)来确定下由哪一个server块来进行处理，然后server块再根据请求的地址来进行location块的挑选，location块内部的规则最终确定下这个请求怎么返回（直接返回文件内容，还是映射成其他请求，还是传给其他服务执行）。

例子

server {
        listen 123.123.123.123:80;

        server_name lab.example.com;

        root /var/www/html;
        index index.html;

        location /eg {
                 try_files $uri $uri/ =404;
        }

        location /cs {
                 try_files $uri $uri/ =404;
        }
}

server {
        listen 123.123.123.123:80;

        server_name visit.example.com;

        root /var/www/visit;
        index index.html;

        location = /test {
                 try_files $uri $uri/ =404;
        }

        location ^~ /lalal {
                 try_files $uri $uri/ =404;
        }
}

如果我们访问链接http://lab.example.com:80/cs/image.jpg那么就会由第一个server的第二个location来处理。流程是什么样的呢：

• step 1 挑选server
• 检查ip和port
  nginx发现请求的ip:port为123.123.123.123:80，对了一下自己的server列表，发现两个server都满足。于是要进行下一步的检查
• 检查domain域名
  nginx发现请求的域名为lab.example.com，这下只有第一个server满足了，就指派了第一个server进行处理。
• step 2 挑选location
  请求的location为/cs/image.jpg，第一个location是匹配以/eg开头的地址不满足匹配，第二个location是匹配以/cs开头的地址，成功匹配。所以就选了第二个block进行处理。
• step3 具体处理
  具体处理中是try_files $uri $uri/=404，这里$uri=cs/image.jpg，也就是查看cs/image.jpg这个文件在/var/www/html目录下是否存在（全路径为/var/www/html/cs/image.jpg），如果存在就当做文件返回内容，如果不存在那么就返回404.

这样就完成了一个完整的链接请求。

2、server块详解

server块最重要的两个属性是listen和server_name。当请求来临时，listen属性先用来匹配，如果匹配到唯一server块那么就是这个server块进行服务（就不用考虑server_name是否匹配上了）；如果匹配不是唯一的，那么就继续使用server_name进行匹配。

属性	含义
listen	定义了该虚拟服务器监听的ip和port对，只有当ip和port同时匹配的时候才进行下一步匹配
server_name	定义了该虚拟服务器监听的主机名，用于当ip和port无法确定唯一server块时启用，进行进一步区分

listen属性详解

• 属性格式

形式	描述	例子	默认补全
ip地址+port端口	完整形式	listen 123.123.123.123:23	listen 123.123.123.123:23
只有ip	会自动加上80的web监听端口	listen 2.2.2.2	listen 2.2.2.2:80
只有ip	会自动加上0.0.0.0的全监听地址	listen 45	listen 0.0.0.0:45

• 匹配规则
  第一步 当nginx匹配的时候，会将缩写的格式补全
  第二步 匹配描述的最精确的(缩写的没有完整的格式准确)
  第三步 如果第二步的情况下还有多个，那么listen就判断不出来了，交给server_name判断

server_name属性详解

• 属性格式

形式	例子
不带有通配符*	www.example.com
带有前缀通配符*	*.example.com
带有后缀通配符*	www.example.*

• 匹配规则
  优先匹配不带通配符的完整表达
  接着匹配带有前缀通配符的表达
  最后匹配带有后缀通配符的表达

当两个表达带通配符的形式相同的时候，匹配最长的那个。

3、location块详解

• 语法

location optional_modifier location_match { 
   ...
}  

语法中的optional_modifier是描述符，location_match是具体匹配的串形式，如果描述符是正则的一种，那么就会以正则的方式来对待location_match，否则以普通方式用location_match来当前缀匹配。

• optional_modifier

|类型|含义|匹配方式|优先级|例子|
|:--|:--|:--|:--|
|(none)|最普通的前缀匹配|前缀方式匹配|4|location / {}|
|=|要求绝对相等|前缀方式匹配|1|location = /image {}|
|~|区分大小写的正则匹配|正则方式匹配|3|location ~ .(jpe?g)$ {}|
|~|不区分大小写的正则匹配|正则方式匹配|3|location ~ .(jpe?g)$ {}|
|^~|高优先级的前缀匹配|前缀方式匹配|2|location ^~ /page {}|

• 匹配规则

• 最高优先级的是=，这个只能完全相等才能匹配上，如果找到符合条件的那么完成匹配。

• 接着在^{~和(none)中找到一个能够匹配出最长串的¹规则，如果这个规则是属于}~的，那么完成匹配。

• 否则如果上一步中规则是属于(none)的，则还需要给正则表达式验证一下。这时候按照location定义的顺序一个一个地检测_*和规则，如果发现一个满足的，那么就用这条正则规则。

• 最后如果正则规则中没有符合条件的，那么就用刚才属于(none)的规则，如果刚才连各最长串都没有，那就跳到默认location去了。

• 注释1例子

server {
  location = /abc {...}
  location / {...}
  location ^~ /big/middle {...}
  location /big/middle/small {...}
  location ~ 123+\.jpg {...}
  location ~* a+\.jpg {...}
}

如果我们要匹配\big\middle\small的话，是不会匹配到location ^~ \big\middle {...}这条规则的，因为当=规则匹配结束没找到之后，就回去找(none)和^~中匹配最长的一条，这时候最长的是(none)的location \big\middle\small {...}，然后在进行正则匹配，发现没有满足的，于是就取(none)的这一条了。这一点要注意。

4、目录配置

在上述步骤后，我们知道一个请求具体定位到location的过程，现在来继续探究location之后的相应处理。首先是location中的资源应该对应在哪一个服务器目录中呢？这就需要root属性来指定了。
root属性可以定义在server块中，也可以定义在location块中。如果声明在server块中那么所有的location都会继承这个定义。同时若location中也定义了root属性，那么以location中的定义为主。
举个例子

server {
  ...
  root /var/www/html

  location /cs {
     root /share/usr
     try_files $uri $uri/ =404;
  }

  location /eg {
     try_files $uri $uri/ =404;
  }
}

如果访问/cs/vr/audio.mp3，那么就会对应到服务器上的/share/usr/cs/vr/audio.mp3的资源
如果访问/eg/file/new.pdf，那么就会对应到服务器上的/var/www/html/eg/file/new.pdf的资源

再比如用nginx上架设codeigniter框架，我们需要重写url那么我们这样

server {
        listen       80 ;
        listen       [::]:80;
        server_name  ci.example.com;
        root /var/www/example;

        location / {
                rewrite ^(.*)$ /index.php?$1 last;
        }

        location ~ \.php$ {
                fastcgi_pass   127.0.0.1:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                include        fastcgi_params;
        }

        error_page 404 /404.html;
        location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
        }
}

那么这样，对于一个非.php的文件，都为在第一个location中重写成/index.php?$uri的形式重写进行一次搜索。这时候必然被第二个location接收（前缀匹配的更长嘛），这样就完成了codeigniter的定位。
比如我们访问ci.example.com/hello就会被重定向到访问var/www/example/index.php?hello同时被pass给php的cgi进行处理。

参考材料

Understanding Nginx Server and Location Block Selection Algorithms
how-to-configure-nginx