18

I'm using nginx as a reverse proxy and I would like it to wait some number of seconds and retry a request if the upstream server isn't responding. This way I can restart my upstream server and instead of users seeing 502 bad gateway, their browsers just hang for a few seconds (the restart process takes 3 or 4 seconds). I've tried a couple things, I put this in my server block: 

proxy_connect_timeout 60;
proxy_send_timeout 15;
proxy_read_timeout 20;

but it didn't seem to do anything. I also tried adding this to the upstream block:

server 127.0.0.1:3001 fail_timeout=10s;

again, not what I wanted.

Is this possible? What am I missing?

Improve this question

2 Answers 2

Reset to default
2

As stated in another answer, there is no built-in way to make nginx do this. A possible solution is to use a load-balancing setup consisting of your current server, and a backup server that does the following for all requests:

  • poll your current server until it's back online
  • then respond with a 302 or other redirect so the browser tries again

This server would be marked with the 'backup' flag so that it's only tried when all other servers are offline (HTTP Load Balancing > Server Weights).

Improve this answer
1

The directives you tried are meant for different things than what you wish. Read their documentation.

The upstream directive documentation explains thoroughly how an upstream block works:

If an error occurs during communication with a server, the request will be passed to the next server, and so on until all of the functioning servers will be tried. If a successful response could not be obtained from any of the servers, the client will receive the result of the communication with the last server.

Everything said there.

However you might be able to process the returned error code from backend by intercepting it with proxy_intercept_errors and then send the $request_uri to a special script dealing with it on the behalf of the original client.

The baseline is: you need some code/application logic to retry client-side (or frontend-side).

Improve this answer
3
  • 3
    I would not tell anyone to read documentation in an answer. I'm not even sure I want to read the rest of the answer even if it might be helpful.
    – parity3
    Commented Mar 9, 2021 at 1:40
  • 1
    And why would you do that? Ill-placed emotions? It does not transpire from the question the documentation had been read, as things seem to be tried somewhat randomly. Documentation shall always be the first place to look for answers. Only if/when things are still unclear than other locations (friends, fora like StackExchange, Mailing Lists, instant messaging like IRC, etc.) shall be used, in order to avoid the same questions being asked again and again. I would advise quoting documentation in questions, showing you did read it and allowing answers to be the most precise possible.
    – Bernard Rosset
    Commented Jun 5, 2021 at 16:19
  • 1
    It's an emotional reaction. May not be representative of the average SO reader. Was assuming that everyone who posts a question on SO has been scratching their head for at least an hour, looking up forums, documentation, google searches, experimenting with settings. SO shines when the docs have been insufficient or raw experience suggests pitfalls to stay away from or better alternatives. Sounds like a petty nit now; your answer would be totally fine without the "Read their documentation" and instead "The documentation says".
    – parity3
    Commented Jun 20, 2021 at 16:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .