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模式

参考：

HTML5 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的请求都会匹配到

所以这几个的优先级为：

 =(精确匹配) > ^~(普通字符匹配) > ~*(正则匹配) > 完全路径 > /

---

人生漫漫路，坚持一起学~