172

I have a running web-application at http://example.com/, and want to "mount" another application, on a separate server on http://example.com/en. Upstream servers and proxy_pass seem to work, but for one issue:

upstream luscious {
 server lixxxx.members.linode.com:9001;
}

server {
  root /var/www/example.com/current/public/;
  server_name example.com;

  location /en {
    proxy_pass http://luscious;
  }
}

When opening example.com/en, my upstream application returns 404 not found /en. This makes sense, as the upstream does not have the path /en.

Is proxy_path the right solution? Should I rewrite "upstream" so it listens to /en instead, as it root path? Or is there a directive that allows me to rewrite the path passed along to upstream?

1

5 Answers 5

320

This is likely the most efficient way to do what you want, without the use of any regular expressions:

location = /en {
    return 302 /en/;
}
location /en/ {
    proxy_pass http://luscious/;  # note the trailing slash here, it matters!
}
23
  • 23
    @berkes, no, it won't -- the trailing slash in proxy_pass is what makes a difference. Also, this answer is more correct than the one you came up with, because it also ensures that proxy_redirect stays at default, so, you could still use 302 et al within your backend, and have it work correctly everywhere.
    – cnst
    Dec 21, 2013 at 18:27
  • 8
    Ah, I was missing the trailing slash :(
    – Vanuan
    May 2, 2016 at 23:54
  • 15
    AAARGH! TRAILING SLASH !
    – barrymac
    May 26, 2017 at 16:27
  • 11
    3 hours of searching, and yeah... It was the trailing slash. Thanks mate!
    – Lucas P.
    Oct 15, 2018 at 16:09
  • 4
    @TheGuywithTheHat it just specifies that there's a path specified for the mapping; otherwise, no mapping is assumed, and paths are passed as-is.
    – cnst
    Apr 29, 2019 at 20:07
22

I'd like to address a newer regex-based answer that's been rising in popularity.

location ~ ^/en(/?)(.*)$ {  # OOPS!
  proxy_pass http://luscious/$2$is_args$args;  # OOPS!
}

The solution may seem more cute at first glance, but it's wrong for multiple reasons.

  • The above regex would match a request uri of /enjoy, redirecting it to /joy upstream. Is this really intended?

  • A request for /en will not result in any redirects, directly serving a / from the upstream (almost as if a request for /en/ was made instead, but not quite). If you use relative URIs within your root page upstream (otherwise, why wouldn't you have the /en/ prefix right there within the upstream URIs?), e.g. src="style.css" (which might reference a language-specific url("menu.png"), for example), then the browser will request that as /style.css instead of /en/style.css. (Or even if you use absolute URIs everywhere, what if someone references an obscure semi-optional resource relatively?) Oops, suddenly the site may not work, but only sometimes or in edge cases.

  • As per my earlier advice at another question already mentioned by the OP's own answer, using regular expressions prevents the proxy_redirect directive from having the default value of default, turning it down to off instead. This means that if the upstream replies with Location: http://127.0.0.1:8080/en/dir/ when a request for /en/dir is made, then that's what the client will see, which obviously won't work correctly. (Which would have been especially ironic for a /en request which prompts regex use in the first place, yet this specific implementation instead suffers from another problem as already mentioned above.) Plus, if you're already using the upstream directive, then it might get extra ugly if you just try to go with a custom one, especially if you may have more than one upstream server — how do you have a separate proxy_redirect for each one of those? You could use regular expressions within proxy_redirect, too, maybe even to match any host, but then what if you decide to give a cross-domain redirect in the future?

To try to address some of the above points with a single regex-based location, we could do the following (note that in proxy_pass we also had to drop the reference to a server from an upstream-based directive, to make proxy_redirect more straightforward):

location ~ ^/en/?((?<=/).*)?$ {
  location = /en { return 302 /en/; }
  proxy_pass http://127.0.0.1:8080/$1$is_args$args;
  proxy_redirect http://127.0.0.1:8080/ /en/;
}

So, if you ask me, the original solution with the two sibling top-level locations would still be a better idea than digging yourself into a rabbit hole by going the regex route instead.

4
  • 1
    This causes an exception: nginx: [emerg] location "/en" is outside location "^/en/?((?<=/).*
    – Athlan
    Jul 5, 2016 at 11:41
  • 1
    @Athlan, that's because you shouldn't really be using that in the first place! If you still want to, you can put that location outside of the regexp.
    – cnst
    Jul 5, 2016 at 11:59
  • puting localation = /en outside works really fine! thanks Jan 12, 2018 at 13:16
  • Also wrong when you have spaces in your URLs, $2 will not re-encode a space as + or %20 and the upstream will get a real space in the URL which is invalid. I filed this as a bug but the NGINX maintainer disagrees.
    – Marc
    Feb 22, 2022 at 11:58
10

So, I found the answer on stackoverflow:

upstream luscious {
 server lixxxx.members.linode.com:9001;
}

server {
  root /var/www/example.com/current/public/;
  server_name example.com;

  location ~ ^/en(/?)(.*) {
    proxy_pass http://luscious/$2;
  }
}

Basically: passing a regex into location and passing the backref along to the proxy_pass url.

4
  • I think "proxy_pass luscious/$;" should be "proxy_pass luscious/$2"
    – Zafer
    Mar 19, 2018 at 12:51
  • 1
    @Zafer is right, the above answer was giving me an error
    – franck
    Sep 28, 2018 at 10:50
  • I've changed the answer, but don't have a server at hand where I can try this, ATM, so it is not verified.
    – berkes
    Oct 2, 2018 at 8:09
  • This would seem to proxy /english to http://luscious/glish which doesn't seem desirable. Jun 19, 2020 at 15:04
6

Accounting to Nginx documents

To pass a request to an HTTP proxied server, the proxy_pass directive is specified inside a location. For example:

location /some/path/ {
    proxy_pass http://www.example.com/link/;
}

This example configuration results in passing all requests processed in this location to the proxied server at the specified address. This address can be specified as a domain name or an IP address. The address may also include a port:

location ~ \.php {
    proxy_pass http://127.0.0.1:8000;
}

Note that in the first example above, the address of the proxied server is followed by a URI, /link/. If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the /some/path/page.html URI will be proxied to http://www.example.com/link/page.html. If the address is specified without a URI, or it is not possible to determine the part of URI to be replaced, the full request URI is passed (possibly, modified).

1
  • 1
    Why isn't this the correct answer? It provides the correct approach using the built-in tools of nginx instead of clumsy regex patterns
    – Teodoro
    Aug 14, 2021 at 3:14
0

I had a play with the accepted solution above but found it was causing dodgy redirects for all the CSS and JS assets. In the end, I found inspiration from the way that the LinuxServer SWAG Nginx configurations are done. You can find them here. Take a look at pihole.subfolder.conf.sample.

As such, my solution looks like this:

location /en {
    return 302 $scheme://$host/en/;
}

location ^~ /en/ {
    set $upstream_app lixxxx.members.linode.com;
    set $upstream_port 9001;
    set $upstream_proto http;
    proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    rewrite /en(.*) $1 break;
}

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .