Nginx的alias/root/try_files实战
项目背景
前端Vue项目,同时支撑PC网站、手机M站和手机App,在项目构建之后会有三个子目录作为路由分别对应m站、PC和APP,但是该项目作为一个服务对外提供服务需要一个统一的请求入口,比如
location /xx {
root /data/website;
}
而不是在每个域名下各自己配置不同的入口,比如
# pc 域名下配置
location /xx/pc {
root /data/website/pc;
}
# m站域名下配置
location /xx/m {
root /data/website/pc;
}
# app域名下配置
location /xx/app {
root /data/website/pc;
}
这样的配置虽然从实现是没有问题的,但是从运维维护成本上来说很大,如果它以后要支撑不同的渠道,那就是在N多配置文件中添加N多类似的配置
当前项目的目录结构如下
|-- website
|---- pm-live-m
|------ index.html
|---- pm-live-pc
|------ index.html
|---- pm-live-app
|------ index.html
|---- a.js
|---- b.css
遇到问题
因为是前端资源,还涉及到静态资源问题,前端项目为了统一标准,一般都会有个识别的前缀,比如,不管是从PC还是APP过来的请求,/view/
都是请求到对应的前端资源的。所以刚开始的配置
location /view/ {
alias /data/website/;
}
那么如下请求是没有问题的
curl 'https://www.colinspace-demo.com/view/pm-live-m/'
curl 'https://www.colinspace-demo.com/view/pm-live-pc/'
curl 'https://www.colinspace-demo.com/view/pm-live-app/'
但是如果请求上带上参数的,一般都是通过 ?param=xxx
的方式,但是开发说,这样的请求不优雅,好吧,那就实现优雅的方式,其实就是URL的伪静态实现
有时候叫 History模式
参考:
所有上面的配置变为
location ~ /view/(.*)/ {
alias /data/website/;
try_files $uri $uri/ /$1/index.html;
}
但是结果却未出人意外,请求404报错,提示文件不存在,但是文件自己确认是存在,那就是配置的问题。
最终分析和查阅资料才发现是try_files的问题,
知识点1: Nginx的 alias 和try_files 两个之间存在互斥,不能同时配置。
问题分析解决
1、既然不能共存,但是要实现优雅的URL,请求不存在的时候转发到指定的HTML页面,但是try_files是必须的
2、既然try_files得用,除了alias之外,就只能用 root了
至于alias和root的区别,简单来说:
- root 指令只是将搜索的根设置为 root 设定的目录,即不会截断 uri,而是使用原始 uri 跳转该目录下查找文件
- alias 指令则会截断匹配的 uri,然后使用 alias 设定的路径加上剩余的 uri 作为子路径进行查找,支持正则表达式
附加知识点: Nginx中root和alias导致的URI的截取
3、但是如果使用 root,根据其作用,知道 location就不能使用view了,同时前端规范静态资源请求还是需要view的,那么view的配置还是需要保留,然后做静态资源请求
4、既然view保留做静态资源,那么路由就需要另外的路由入口,和开发协商,项目产生物结构变更为如下:
|-- website
|---- pm-live
|------ pm-live-m
|-------- index.html
|------ pm-live-pc
|-------- index.html
|------ pm-live-app
|-------- index.html
|---- a.js
|---- b.css
pm-live作为入口路由,Nginx的配置如下
location ~ /pm-live/(.*)/ {
root /data/website/;
try_files $uri $uri/ /$1/index.html;
}
又遇到问题 rewrite or internal redirection cycle while internally redirecting to
, 根据报错提示出现循环重定向,为啥会这样呢
原因在于try_files 会按照顺序就检索对应的Uri是否存在,不存在就查找下一个。这里第三个参数(或者最后一个参数)为动态URI中取值,就会导致重定向去去查找
,如果第三个值唯一确定的值就会默认到这个确定的值。
既然找到问题,上面的配置会导致循环重定向,那就想办法让他跳出‘循环’,再结合 伪静态实际最终也是要转原生URL的,肯定会用到rewrite,所以进行如下配置变更
# 保留做静态资源
location /view/ {
alias /data/project/pm-live-front/dist/;
}
# 统一路由入口,最后默认到一个采用 @ 实现Nginx内部跳转
location ~* /pm-live/(.*)/ {
root /data/project/pm-live-front/dist/;
try_files $uri $uri/ @pmliverewrite;
}
# 跳转到这里之后执行URL重写到默认的页面就行
location @pmliverewrite {
rewrite ^(/pm-live/[^/]+)/ $1/index.html last;
}
最终验证实现开发需要的需求
curl 'https://www.colinspace-demo.com/pm-live/pm-live-m/'
# 伪静态路由
curl 'https://www.colinspace-demo.com/pm-live/pm-live-m/livem/100/'
总结
通过上面的案例我们学习到以下知识点
1、root和alias对uri的处理有区别,alias会截取
2、Nginx的 alias 和try_files 两个之间存在互斥,不能同时配置
3、一般实现伪静态采用 root+try_files 就够了
4、但是存在动态URL的时候,需要用 root+try_files+单独带@的location的rewrite
5、凡是涉及到Nginx的location配置,那就需要了解Nginx location的几种方式及其优先级
6、另外就是Nginx URL的正则匹配,在实现rewrite重写的时候尤为重要
附加
Nginx location类型及优先级
精准匹配
- location = /uri 表示精准匹配,只要完全匹配上才能生效。记住只会匹配一个。
字符串匹配
最长匹配原则
- location /uri 不带任何修饰符,表示前缀匹配,忽略大小写。但是优先级在正则匹配之后
- location ^~ /uri 开头对URL路径进行前缀匹配,并且在正则之前。一旦匹配到最长匹配,则不再查找其他匹配项
正则匹配
- location ~ pattern 开头表示区分大小写的正则匹配
- location ~* pattern 开头表示不区分大小写的正则匹配,如果有多个location匹配,则选择匹配最长的那个
通用匹配
- location / 通用匹配,任何未匹配到其他location的请求都会匹配到
所以这几个的优先级为:
=(精确匹配)
> ^~(普通字符匹配)
> ~*(正则匹配)
> 完全路径
> /
人生漫漫路,坚持一起学~