我要评论背景
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错误，这样解决是否合适，有待商榷。
总结
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论