Proxying a site with absolute paths in location nginx?

Question

Nginx

There is a server with nginx that looks at the Internet at proxy.domain.tld
AND a site on the local network that lives at web.local.tld You
need to expose the site from the local network at proxy.domain.tld/web , but the problem is, that the markup of the internal site uses absolute paths of the form: As a result, all links point to the root of the proxy, which knows nothing about them. Is it possible to bypass this on nginx and how?
<a href="/some/page/">...</a>

Answer 1

Not quite universal, but without modifying the code of the proxied application, this is done using sub module hacks . Unfortunately, you can set only one replacement (for example, src="/ to src="/web/), but this is bypassed by nesting requests (also a kind of hack)

Answer 2

You might want to think about the next option. When serving content from web.local.tld, nginx sets a separate cookie, which is a flag that the user is in /web.
On a subsequent request, analyze the presence of this cookie. And if it is present, then all requests are either redirected or rewritten to web.local.tld.
The solution has some drawbacks (in particular, if the user starts looking at /web/, then he will no longer get to the main site, because the cookie has already been set). But theoretically they can be bypassed.

Answer 3

Can.
If you go simple (but you should understand that this is not for high-load), then:
location / {
error_page 404 = @fallback;
}
location @fallback {
rewrite ^/(.*) proxy.domain.tld/web/ $1 permanent;
proxy_pass backend;
}
location /web {
proxy_pass blablabla and everything else;
}
And on the receiving web server, do:
location /web {
rewrite ^/web(.*) web.local.tld/ $1 last;
}
Should earn. In any case, dig in the direction of such an algorithm:
1) check if there is such a page.
2) if not, add /web/ and proxy to web.local
3) on the receiving side, we do last-rewrite, removing the web and giving the page.
You can skip the third point by moving your site to /web on web.local if that doesn't hurt users.
In general, with such questions, it is better to go to the nginx forum or go to their mailing list.