Hello!

On Fri, Feb 12, 2016 at 11:04:19PM +0530, Vignesh VR wrote:

> Hi,
>
> I am trying to use Nginx as a reverse proxy and want to redirect to
> different upstream servers based on the URL. Looking to use the path prefix
> to distinguish the upstream servers to be used. But the issue is the path
> prefix gets sent to the upstream server which I don't want to.
>
> For eg., this is what I am trying to do:
>
> Nginx Server: nginx (External IP)
>
> upstream 1: upstream1 (Internal IP)
>
> upstream 2: upstream2 (Internal IP)
>
> Desired outcome:
> http://nginx/server1 --------------> http://upstream1
>
> http://nginx/server2 ----------------> http://upstream2
>
>
> The problem I am having is that http://nginx/server1 gets translated to
> http://upstream1/server1. I am not able to remove the path prefix when the
> traffic gets directed to the upstream servers.
>
> I have tried most of the suggestions on the net:
>
>
> location /server1/ {
> proxy_pass http://upstream1/;
> }

This is correct configuration for what you want, it will replace
"/server1/" with "/" in requests to upstream.

> (tried without slash)
> location /server1/ {
> proxy_pass http://upstream1;
> }

This is expected to preserve URI as is.

> (tried using regex)
> location /server1/ {
> rewrite ^/server1/(.*) /$1 break;
> proxy_pass http://upstream1/;
> }

This configuration is slightly more complicated than it should be,
though will also cause "/server1/" to be replaced with "/".

> All of the above results in varied behaviors but none gives the desired
> outcome. I am currently using a non-commercial version of nginx.
>
> And please note that I am using IP addresses everywhere and not hostnames.
> So name resolution issues anywhere here.
>
> Any guidance / help / pointers will be highly appreciated.

At least two of the above configurations are expected to result in
what you are asking for. So the problem is likely elsewhere.
Some things to check:

- If you are testing it right? Make sure to use low-level tools
like telnet or curl. Browsers tend to do much more than they
should and hide correct information even in developer tools. In
particular, browser caches often confuse users.

- Check if the configuration you change is actually used.
Sometimes people forgot to reload a configuration, or it's not
reloaded due to some syntax error, or they just try to change
wrong part of the configuration. Something like "return 200
ok;" in the appropriate location is a good way to check things.

- Check how your backends handle things. Note that if your
backend expects to be reacheable on certain path (or even
domain), it will use [wrong] full path in redirects, links to
various resources, or may even hardcode in binary objects like
flash. This will render the site unusable even if all proxying is
done correctly. Some trivial things like redirects can be fixed
by nginx itself (see http://nginx.org/r/proxy_redirect), but in
general you have to configure upstream servers to properly handle
this.

Note well that debugging log is known to be helpful while
debugging complex cases, see
http://nginx.org/en/docs/debugging_log.html.

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx