其实很久没碰过nginx了，突然来了个任务就只能硬着头皮上了。
先说下背景：
我们业务采用的是容器的形式部署，nginx做反代的结构，当用户请求到达nginx服务器时，先判断nginx配置的根目录下是否存在对应的静态文件，不存在则进行转发。
在nginx中配置了error_page 404的跳转规则，预期效果是请求资源/路径不存在时，跳转到我们自定义的404页面，而不是那大大的还加粗了的冷冰冰的"404 Not found"。
具体配置段如下：

为隆安等地区用户提供了全套网页设计制作服务，及隆安网站建设行业解决方案。主营业务为做网站、网站制作、隆安网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！

error_page 404 500 /404.html; #定义状态码为404 500时的展示页面
location = /404.html{
    root /usr/share/nginx/html;#此资源的位置
}

刚开始的想法是，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

以下是官方介绍：

Syntax: fastcgi_intercept_errors on | off;
Default:    
fastcgi_intercept_errors off;
Context:    http, server, location
Determines whether FastCGI server responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

友情链接:http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_intercept_errors

Syntax: proxy_intercept_errors on | off;
Default:    
proxy_intercept_errors off;
Context:    http, server, location
Determines whether proxied responses with codes greater than or equal to 300 should be passed to a client or be intercepted and redirected to nginx for processing with the error_page directive.

友情链接：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下配置文件。再次测试，成功！而且正常页面也能访问。