Remove path prefix during proxy_pass

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/;
}

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

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

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.

Thanks
Vigs.

Hello!

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

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 D.
http://nginx.org/

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs