Remove path prefix during proxy_pass

[Maxim Dounin]

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/