nginx 配置文件的匹配规则

引出

之前在对php-fpm 进行nginx代理时, 为了对后台限定 IP 访问, 添加了如下配置:

location ^~ /admin {allow 127.0.0.1;deny all;
}

结果呢? 所有admin路径下的php文件, 全都没有解析, 变成文件下载了. 当时我不知道是什么问题, 不过将这段配置去掉之后, 问题就消失了. 所以, 我可以肯定的是, 一定是这段路径匹配的问题, 导致没有走php-fpm的解析.

探究

为了探究原因, 我查找资料并做了尝试. 如果想直接看结果, 可以跳过这一 part.

在上方出现问题的场景中, nginx的配置文件大体如下:

server {listen      80;server_name localhost;root  /var/www/html;index index.php;location / {try_files $uri $uri/ /index.php?$args;}location ~ \.php$ {try_files                 $uri =404;//...此处省略 fpm 配置}location ^~ /admin {allow 127.0.0.1;deny all;}
}

经过思考, 当我访问localhost/admin/test.php的时候, nginx没有执行第二个匹配规则, 没有将文件交由php-fpm解析器执行, 进而导致其作为静态文件直接下载.

接下来, 就是验证这个想法了. 最简单的验证方法, 就是在nginx匹配规则中, 直接返回 HTTP 响应吗. 这样用curl看一下响应码, 就知道执行了哪个规则了.

说干就干, 修改配置文件如下:

server {listen      80;server_name localhost;location / {return 300;}location ~ \.php$ {return 200;}location ^~ /admin {return 100;}
}

和猜想的一样, 即使匹配规则在前面, 但是仍然先匹配到了规则^~. 也就是说规则 ^~ 比规则 ~的匹配优先级更高.

不过还有一点无法确定, 即使先匹配到了后面的规则, 那也不能说明前面的规则就不走了啊. nginx也有可能是按照顺序依次进行匹配的.

为了验证, 我们将第三个配置规则中的return 100删掉. 此时, 如果能够匹配到php的规则, 那么就会返回响应码200, 如果不能, 应该提示找不到文件. 测试一下.

至此说明匹配到 ^~ 规则的时候, 就会直接执行而不进行后续的匹配了. 那问了, 有可能是因为两个匹配规则的优先级不同, 故而忽略了优先级低的匹配规则.

为了验证nginx对于相同优先级的匹配规则, 是否会进行后续匹配, 再次进行实验. 修改配置文件如下:

server {listen      80;server_name localhost;location ~ hp$ {return 400;}location ~ php$ {return 500;}
}

配置文件中两个正则匹配, 我的想法是这样的, 此时访问, 会返回响应吗 400, 说明匹配了第一个规则, 然后我将第一个规则中的return 400删除, 如果返回了 500, 就说明nginx在匹配了第一个规则之后, 继续执行了下一个匹配. 很严谨. 先访问一下:

image-20210624230115890.png (1246×308)

很好, 符合预期, 然后将第一个规则中的return删除, 再次访问:

这次返回了 404, 这说明, nginx在执行到第一个匹配的时候, 就停止匹配, 不再进行后续匹配了.

至此, nginx的匹配规则基本上已经复现出来了.

按照优先级从高到低的顺序进行匹配
相同优先级的, 按照配置文件中的顺序进行匹配
当匹配到一条规则之后, 停止后续匹配.

匹配规则

接下来整理一下nginx路径的匹配规则, 以下优先级按照从高到底排序:

location = /xxx: 路径精确匹配
location ^~ /xxx: 路径前缀匹配
location ~ xxx: 路径正则匹配
location ~* xxx: 路径正则匹配, 不区分大小写, 与正则匹配的优先级相同
location /xxx : 路径前缀匹配
location / : 通用匹配, 当其他都没有匹配的时候, 会走到这里.

nginx会按照优先级从高到低依次进行匹配, 在第一个匹配成功的时候执行操作并停止匹配.

回顾

匹配规则看上去很简洁. 现在可以回头看一下我们最初遇到的问题了.

我们想让某后台地址限定 IP 访问, 故而添加了这样的配置:

location ~ \.php${//...
}
location ^~ /admin {allow 127.0.0.1;deny all;
}

现在应该很清楚了吧, 所有admin下的路径, 因为规则^~的优先级更高, 故而解析到了后面的规则, 而没有执行php的解析操作. 又因为没有解析操作, 故而 php 文件都当做资源文件返回了.

那么问题来了, 如果我想对admin路径下的路径执行访问限制, 改怎么办呢?

将规则^~改成~ ? 不行, 因为优先级相同, 先匹配到前面的 php 正则匹配, 后面的限制没有效果
将规则^~改成~并提到前面? 不行, 因为优先级相同, 先匹配到限制, 如果通过不会进行后面的 php 解析.

这不陷入死循环了么? 我又想对某个路径执行限制, 如果限制通过的话, 又需要能够正常解析. 怎么破? 这里我探索出来的思路是, 他不是不认识php文件么, 我让他认识认识不就完了么. 直接将匹配的解析过程嵌套写入, 配置文件大体如下:

    location ^~ /admin{deny all;location ~ \.php$ {//...}}

这样的话, 就可以达到在执行 IP 限制的前提下, 又能够正常解析php-fpm.

那么一个新的问题来了, 这不就相当于将 php 的解析复制了一遍么? 也太不优雅了. 我想到的方案是, 通过nginx的include命令. 通过将php文件的解析配置单独放到一个配置文件php-fpm.conf.common文件中, 内容如下:

location ~ \.php${// ...
}

这样, 原本的配置文件就可以改写成如下形式了:

location ^~ /admin {allow 127.0.0.1;deny all;# 这里因为相对路径使用的是 nginx.conf 的路径, 所以需要再走一层include ./conf.d/php-fpm.conf.comon
}
include ./conf.d/php-fpm.conf.common