Will this work, is it the best way?

Steve Wilson lists-nginx at swsystem.co.uk
Sun Feb 1 00:29:20 UTC 2015


To add a bit more information.

Server1 is hosted, has both IPv4 and 6.
Server2 is on the end of an adsl line within a RFC1918 network where the
external port 80 points to another server which cannot be changed.
Another complication is that internet access from some client locations
is heavily restricted, so using an alternative port may not work.
The LAN has full IPv6 capability and there's some video streaming done
on server2 so direct LAN access is preferred.

I managed to get it working with the below config on server2.

        server {
                listen [::]:80;
                server_name ~^(?<subdomain>\w+)\.example\.com$;
                set $upstream "http://$subdomain";
                location / {
                        proxy_set_header Host       $host;
                        proxy_pass $upstream;
                }
        }
        upstream netflow {
                server 127.0.0.1:8080;
        }
        upstream ntop {
                server 127.0.0.1:3000;
        }
        upstream wifi {
                server 127.0.0.1:8443;
        }

I was initially tripped up by the proxy_pass line, I did not get the
desired effect when using 'proxy_pass http://$subdomain;'

Steve.

On 31/01/15 16:21, Lloyd Chang wrote:
> Hello Steve,
>
> • Best answer is try and see if it meets your expectations; thanks
>
> • While reading your snippet, my initial questions are — Why 2
> servers? Why not simplify?
>
> • In your proposal: server1, listen to ?? TCP port(s) on public IPv4,
> and IPv6 to proxy_pass to server2, then server2 listen
> on public IPv6, and IPv4 to proxy_pass to subdomain, with upstream
> (perhaps for load balance and/or failover?) — As you agree, this is
> slightly complicated
>
> • Why not simplify? — Reconfigure DNS for cname-server1 to
> server2, for IPv4 and IPv6
>
> • In your snippet, server2 supports IPv4 and IPv6 if you expect it to
> upstream via private IPv4 127.0.0.1:[…]
>
> • I don't fully understand why server2 upstream isn't IPv6 ::1:[…]
> considering your primary intent for server2 is IPv6 usage
>
> • Perhaps you meant upstream localhost:[…] to try both IPv4 and IPv6?
> Thanks
>
> Cheers,
> Lloyd
>
> On Friday, January 30, 2015, Steve Wilson <lists-nginx at swsystem.co.uk
> <mailto:lists-nginx at swsystem.co.uk>> wrote:
>
>     Hi,
>
>     Slightly complicated setup with 2 nginx servers.
>
>     server1 has a public ipv4 address using proxy_pass to server2 over
>     ipv6 which only has a public ipv6, this then has various upstreams
>     for each subdomain.
>
>     ipv6 capable browsers connect directly to server2, those with only
>     ipv4 will connect via server1.
>
>     I'm currently considering something like the below config.
>
>
>     server1 - proxy all subdomain requests to upstream ipv6 server:
>
>     http {
>      server_name *.example.com <http://example.com>;
>      location / {
>       proxy_pass http://fe80::1337;
>      }
>     }
>
>     server2:
>
>     http {
>      server_name ~^(?<subdomain>\w+)\.example\.com$;
>      location / {
>       proxy_pass http://$subdomain
>      }
>
>      upstream subdomain1 {
>       server 127.0.0.1:1234 <http://127.0.0.1:1234>;
>      }
>     }
>
>     The theory here is that each subdomain and upstream would match,
>     meaning that when adding another upstream it would just need the
>     upstream{} block configuring and automatically work.
>
>     I realise there's dns stuff etc but that's out of scope for this
>     list and I can deal with that.
>
>     Does this seem sound? It's not going to see major usage but
>     hopefully this will reduce work when adding new upstreams.
>
>     If you've a better way to achieve this please let me know.
>
>     Steve.
>
>     _______________________________________________
>     nginx mailing list
>     nginx at nginx.org
>     http://mailman.nginx.org/mailman/listinfo/nginx
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150201/ad2e404d/attachment.html>


More information about the nginx mailing list