Serving default error pages with 'proxy_intercept_errors on'

Maxim Dounin mdounin at
Sat Dec 28 12:19:43 UTC 2013


On Fri, Dec 27, 2013 at 03:47:51PM -0500, Maxim Khitrov wrote:

> Hello,
> I'm running nginx v1.4.1 on OpenBSD 5.4 and I'd like to use
> 'proxy_intercept_errors on' directive without providing my own error
> pages. In other words, instead of forwarding page content from the
> backend server, just use the error pages that nginx generates by
> default.
> This isn't supported normally, however the following configuration
> seems to achieve the desired result (though you have to list the error
> codes explicitly):
> error_page 403 404 ... @error;
> location @error { return 444; }
> I didn't actually know what this would do until I tried it. I assume
> that when a matching error code is received from the backend server,
> nginx closes the proxy connection without reading the body and creates
> a new internal request to @error, which is immediately closed without
> a response. Thus, there is no body to send to the client, so it falls
> back to the default behavior.

Not really.

What you see works because currently "return <4xx>" doesn't 
override error code previously set, thus for 404 error code 
originally returned by a proxied server

    location @error { return 4xx; }

is effectively equivalent to 

    location @error { return 404; }

which is documented to return "status code of the last occurred 
error", see

> The question is whether this behavior is an accident and may change in
> a future version, or if it's an acceptable way of intercepting errors
> without providing custom error pages?

I wouldn't recommend relaying on this.  Current behaviour of 
"return", which effectively uses previous error code set, is 
somewhat questionable, and may change in the future.

Maxim Dounin

More information about the nginx mailing list