Nginx使用try_files遇到的问题及解决

背景

root /some/path;
location / {
	try_files $uri $uri/ /dist/index.html;
}

使用React之类的的库来开发前端页面的时候，因为是单页应用所以需要上面的Nginx配置，用来在找不到html文件的时候内部重定向到/dist/index.html文件。

服务器上的目录结构是/some/path/dist/assetes网站的静态资源都是存在/some/path/dist/下的，而服务器的根目录是/some/path/。

域名：localhost.abc.com

现象：访问localhost.abc.com/dist/正常访问，访问localhost.abc.com/dist/xxx等都正常，而直接通过域名localhost.abc.com访问页面则出现403错误。

当访问域名会被location /块捕获，这是毋庸置疑的，匹配到之后，try_files 会尝试第一个参数 / （当前的$uri是 / ）也就是/app/app/下只有一个文件夹dist，也没有index.html或者index.htm文件，所以找不到，应该是404，然后继续找 // （这个 // 会被如何解析不得而知）也找不到404，所以最后会知道 /some/path/dist/index.html 这个文件是存在的，所以不应该出现403错误，应该正常展示才对。

遇到上面的问题主要是因为Nginx的匹配流程不熟悉导致的，在访问文件夹的时候，如果没有找到index配置的文件，例如index.html之类的，那么会继续调用autoIndex模块，autoIndex模块的值默认是false，所以就报没有权限查看这个文件夹的异常，异常码是403。

try_files 是不会处理403这个异常的，try_files处理的是异常码404，所以403这个异常就被直接返回出去了，也就是说在第一步匹配 / 的时候就直接返回了。

解决

即使开启autoIndex对于单页应用来说也是十分奇怪的。所以我们可以设置root: /some/path/dist/这样，即使访问的是/那么第一个匹配的也是 /some/path/dist/index.html，就不会出现访问域名直接报错的尴尬情况。

但是这个问题其实没有解决，例如/some/path/dist/xxx/这个目录通过域名访问还是存在上面说的问题，/dist/xxx/这个访问还是会报403但是这也无法避免，这其实是我们配置导致的（如上所述）。

除了修改root值的解决方案，我们还可以捕获403这个错误，然后再重定向到我们的目标文件/some/path/dist/index.html。这就从根本解决了这个问题，但是我们网站也没有了403错误，这样解决是否合适，有待商榷。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论