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)中找到一个能够匹配出最长串的<sup>1</sup>规则，如果这个规则是属于~的，那么完成匹配。
否则如果上一步中规则是属于(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
