Nice, hadn’t noticed the port range capability.

The proxy_pass and just directly referencing the ip would make it nice and
concise. Unfortunately I am wanting to balance across multiple backends,
but this is all good to know come different requirements.

Cheers

On Mon, Mar 2, 2020 at 2:02 PM Reinis Rozitis <r@roze.lv> wrote:

> > I get that the NGINX listen statement works on an individual port basis,
> so the equivalent of what's below in NGINX would at the very least require
> 300 listen statements.
>
> You can listen on a port range (see below).
>
>
>
> > FYI I've tried referencing my own declared variables from within the
> upstream as well as referencing $server_port but of course these don't
> appear to be in scope.
>
> Depends if you want nginx to perform any active healthchecks and what kind
> of backends those are.
>
> If it is http and you just need to redirect traffic instead of defining
> upstreams a configuration with (way) less lines could be:
>
> server {
> listen 10.1.0.1:2000-2299;
> location / { proxy_pass http://127.0.0.1:$server_port; }
> }
>
>
> A fallback to another proxy could be configured via error_page (502).
> Something like:
>
> error_page 502 @fallback;
> location @fallback { proxy_pass http://10.1.0.2:$server_port; }
>
> But I don't think there is a way (at least in the base vanilla) nginx to
> configure upstreams in a dynamic way with port ranges as in upstream {}
> doesn't support variables for the server definitions.
>
> rr
>
>
>
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx