Change the status code that Nginx returns when upstream unicorn is busy

Question

I am using Nginx in front of unicorn. When the application is under high load and all the unicorn workers are busy nginx will return a 502 response saying that the gateway is misconfigured. I'm ok with this behavior, but in this condition I want nginx to return a 503 response code (server busy, try again later) which is a much more appropriate response.

I saw this answer: Is it possible to change the HTTP status code returned when proxy_pass gateway is down in nginx?

which describes how to rewrite some status codes returned from the upstream proxy:

location / {
    proxy_pass http://backend;
    proxy_intercept_errors on;
    error_page 502 503 504 =503 @proxyisdown; # always reply with 503
}

location @proxyisdown {
    add_header Retry-After 500;
    index my_pretty_error_page.html; 
}

But there are 2 issues with this:

The upstream application does sometimes return 502 response codes for valid situations that should be retained
I'm not convinced that the upstream proxy is actually returning this erronous status code, more likely nginx can't place the item on the (tcp?) buffer and then nginx returns the misleading status code.

Is there any way I can control the status code returned by nginx in this situation so that it is a 503 instead of a 502?

Why do you set proxy_intercept_errors on; if you don't want to intercept errors from proxy? And why do you think that "nginx returns the misleading status code"? — VBart
The code example if from the referenced question inside my question, not my code. I think that nginx returns a misleading status code because a 502 is returned when the upstream web server doesn't have any additional capacity. The server isn't misconfigured, it's just busy, that should be a 503. — Macdiesel
How nginx can know that the server is busy if it doesn't respond properly? — VBart
If upstream is just busy then it must return 503 by itself. There's no way to know is it temporary error or permanent if it doesn't respond properly. You should use the limit_conn directive to protect your upstreams from overload. — VBart
I just wanted to comment that we rewrote our application in node.js and this issue with unicorn is no longer of concern. — Macdiesel

Mark Stosberg Mark Stosberg · Accepted Answer · 2012-06-12T15:08:31

Have you considered addressing this with the backend server? Tune-down the number of clients that the backend server accepts, so that the requests to it generally succeed or fail, and don't get stuck in the molasses state that returns 503. Ideally, you'll be able to tune the backend server to return 503 when it runs out of available clients, and Nginx will continue to return 502 when the backend server is actually down.

Change the status code that Nginx returns when upstream unicorn is busy

1 Answers