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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
