记一次nginx配置自定义错误页面的麻瓜经历

其实很久没碰过nginx了，突然来了个任务就只能硬着头皮上了。
先说下背景：
我们业务采用的是容器的形式部署，nginx做反代的结构，当用户请求到达nginx服务器时，先判断nginx配置的根目录下是否存在对应的静态文件，不存在则进行转发。
在nginx中配置了error_page 404的跳转规则，预期效果是请求资源/路径不存在时，跳转到我们自定义的404页面，而不是那大大的还加粗了的冷冰冰的”404 Not found”。
具体配置段如下：刚开始的想法是，location已经有很多正确匹配到资源路径的处理规则，而优先级最低的location / {规则X}表示未能匹配到的资源按规则X处理。
好吧，那就直接return 404不就可以了?
结果还真的是可以，但是。。。正确页面加载不出来了，F12进入调试模式，发现页面中很多资源请求也成是404了，尴尬没考虑到这个问题，暂先放弃这个想法。现在问题是nginx服务器上的默认404页面文件已经被删掉了，而且仔细观察，发现更奇怪的是，下面的nginx版本号信息显示的是开发云主机域名1.13.0，而这个服务器的版本是1.12.2啊！

冷静，一定要冷静
行吧，看来问题已经可以基本定位了，此时是由nginx代理的backend集群里中某一台响应的404页面，而不是由我们所设想的那样，nginx-server直接响应自定义的404页面。
好吧原因找到了，就看看有没有相关方法能阻止一下了。。查各种资料后终于找到两个有关的参数,而且好巧不巧这两个参数默认是off的。
fastcgi_intercept_errors 和 proxy_intercept_errors 以下是官方介绍：友情链接:http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_intercept_errors友情链接：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_intercept_errors
嘛意思呢？大概就是当后端服务器的响应状态码大于等于300时，决定是否直接将响应发送给客户端，亦或将响应转发给nginx由error_page指令来处理。
当为on时，nginx会拦截error_page指令明确指定的错误状态码。如果来自被代理服务器的应答状态码不匹配error_page指令，应答会照常发送到客户端。开启后，check并reload下配置文件。再次测试，成功！而且正常页面也能访问。

相关推荐: linux保存vi编辑后的文件的方法

今天小编给大家分享的是linux保存vi编辑后的文件的方法，很多人都不太了解，今天小编为了让大家更加了解linux保存vi编辑后的文件，所以给大家总结了以下内容，一起往下看吧。一定会有所收获的哦。在vi中编辑后首先按ESC键回到命令模式，然后输入:w保存即可，…