use a secondary upstream as backup

[Sébastien Rebecchi]

Hi Sergey, Liam!

Thank you for your answers, they are really helpful!
I did not think of such kinds of solutions, they should both work fine for
my use case.

Have a great day

Sébastien

Le mer. 23 avr. 2025 à 15:44, Liam Crilly via nginx <nginx at nginx.org> a
écrit :

> Alternative approach would be to use error_page to catch the 5xx response
> (502 I think)
> when there are no available upstream servers and then, from a named
> location, proxy_pass
> with HTTPS to the same upstream group.
>
> Modifying the original sample config below.
> There is a blog post for similar use case here[1] but it is quite old ;)
>
> Cheers,
> Liam.
>
> [1] https://blog.nginx.org/blog/capturing-5xx-errors-debug-server
>
> ---
>
> upstream main_upstream {
>   server <ip here>:80
>   server <ip here>:80
>   <etc>
> }
>
> upstream secondary_upstream {
>   server <ip here>:443
>   server <ip here>:443
>   <etc>
> }
>
> location / {
>   proxy_pass http://main_upstream;
>   error_page 502 @try_secondary;
>   <etc>
> }
>
> location @try_secondary {
>   proxy_pass https://secondary_upstream;
>   <etc>
> }
>
> ________________________________________
> From: nginx <nginx-bounces at nginx.org> on behalf of Sergey A. Osokin <
> osa at freebsd.org.ru>
> Sent: 23 April 2025 14:26
> To: Sébastien Rebecchi <srebecchi at kameleoon.com>
> Cc: nginx mailing list <nginx at nginx.org>
> Subject: Re: use a secondary upstream as backup
>
> CAUTION: This email has been sent from an external source. Do not click
> links, open attachments, or provide sensitive business information unless
> you can verify the sender’s legitimacy.
>
>
> Hi Sébastien,
> hope you're doing well.
>
> Thanks for the question.
>
> On Wed, Apr 23, 2025 at 12:07:21PM +0200, Sébastien Rebecchi via nginx
> wrote:
> > backup, meaning NGINX will only use them if all primary servers fail.
> >
> > In my case, I have some servers running over HTTP and would like to
> > configure HTTPS servers as backups. However, since an upstream can only
> use
> > one protocol, this setup isn't currently possible.
>
> [...]
>
> The solution you may help and you may want to try to implement is "double"
> proxy, where:
> - at first, nginx is proxy to the loopback upstream, i.e. to itself
> - on the second step nginx proxies from loopback to an original upstream
>
> So, the original upstream block will look like this:
>
> upstream insecure {
>     server A.B.C.D:80;    # http server
>     server 127.0.0.1:8999;
>
>     <other directives here>
> }
>
> upstream secure {
>     server E.F.G.H:443;    # https
>
>     <other directives here>
> }
>
> <other servers here>
>
> server {
>     listen 127.0.0.1:8999;
>
>     location / {
>         proxy_pass https://secure;
>
>         <other directives here>
>     }
> }
>
> > Is there a feature like this planned, or one that could be considered for
> > future development?
>
> I don't think such feature is planned at the moment, just because all
> servers defined in the same upstream should be configured equally.
>
> Hope that helps.
> Thank you.
>
> --
> Sergey A. Osokin
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> https://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20250423/c71c8afd/attachment-0001.htm>