这个问题早就应该已经有了答案，但是尽pipe看了很多常见的答案，我还是无法弄清楚，有人能指出为什么我的configuration不起作用吗？
目标：当上游server_apiclosures（例如，其工作进程崩溃），我想nginx显示我的自定义错误页面。
我的configuration：
location @server { proxy_pass http://server_api; proxy_redirect off; ... proxy_intercept_errors on; error_page 502 /error-502.html; } error_page 502 /error-502.html; location = /error-502.html { internal; root /srv/my-server/html; } 我的步骤：
/srv/my-server/html/error-502.html准备好了静态错误页面，与其他静态资源相同的权限和所有者。 [error] 2359#0: *25 connect() failed (111: Connection refused) while connecting to upstream出现在日志中，看到[error] 2359#0: *25 connect() failed (111: Connection refused) while connecting to upstream 。 server或location块中设置error_page 。 error_page与location或server块proxy_intercept_errors on的proxy_intercept_errors on ; 他们似乎都没有说服nginx显示我的错误页面。 为什么不？ 我错过了什么？
感谢贾斯汀和迈克尔指引我正确的方向，确实是一个位置块，造成我的麻烦，特别是：
location / { try_files $uri $uri/ @server; error_page 403 = @server; }
基本上，我试图很聪明，并抓住$uri/ error（403尝试访问存在的文件夹，但没有索引文件或自动索引），并将其redirect到@server块。
但不是try_files $uri $uri/ @server; 单独够了？
假设你试图访问http://example.com/会说，这个文件夹存在（这是你的root ），但没有find索引，并抛出403，而不是传递到@server块。
因此，我的403解决scheme，但我没有意识到它带来了一个代价：这意味着nginx已经发现了一个错误，并使用error_page在同一个location块来处理它（通过传递给@server ）。
再加上我在这个问题中的testing，它表明nginx（v1.7.x）会在这一点上忽略更多的error_page指令，而使用默认的502。
有趣的部分：我们如何解决这个问题？
我的解决scheme是build立一个完全匹配的根路由，现在在根上捕获403是不必要的， error_page按预期工作。
error_page 502 /error-502.html; location = /error-502.html { internal; root /srv/example.com/html; } location = / { try_files $uri @server; } location / { try_files $uri $uri/ @server; }
很难确定没有看到你的整个configuration，因为这对我来说没有任何额外的措施。 我首先尝试了所有的configuration，然后逐个去掉一些比特，看看是否有任何改变。
应该没有必要使用proxy_intercept_errors，因为502在连接到后端时由nginx自己生成。 我证实了这一点对我来说是有效的。
所有我已经添加，在我的服务器块内：
error_page 502 /error-502.html; location = /error-502.html { internal; root /srv/www/errors; }
在我的设置中，我的静态错误页面在/ srv / www / errors中，但没有别的不同。
您必须在服务器范围内或在您的服务器块中的其他地方configuration干扰或覆盖。 注意位置的优先规则，这可能是一个因素。