Why do relative mod_rewrite substitutions redirect differently behind a production reverse proxy than on localhost?

Answer the question first

When you use a relative substitution in a VirtualHost (e.g. RewriteRule ^(.*)$ /app/$1), Apache resolves that substitution against the request URI that the backend sees. On a local setup the backend receives the client’s original URI, so the rewrite works as expected. In production the reverse proxy (typically ProxyPass/ProxyPassReverse) rewrites the path before forwarding the request to the backend, so the backend receives a different URI. The relative substitution is then evaluated against that altered URI, producing wrong redirects or loops.

How the context is chosen

• Per‑server (VirtualHost) context – the substitution is resolved relative to the backend’s request URI, which may have been prefixed or stripped by the proxy.
• Per‑directory (.htaccess, Directory, Location) context – the substitution is resolved relative to the directory or location prefix. Here RewriteBase can override the implicit base.
• RewriteBase only has an effect inside per‑directory contexts; it does not influence per‑server rewrites.

Does the proxy change the resolution?

Yes. The proxy may add a path prefix (e.g. /app) or strip one before sending the request to the backend. Because the backend sees a different initial URI, a relative substitution that was correct for the original URI will now target a different path. The proxy’s ProxyPassReverse rewrites Location headers in responses, but it does not affect the internal rewrite that the backend performs.

Practical steps to achieve consistency

1. Inspect the proxy configuration – note the ProxyPass and ProxyPassReverse directives. What prefix does the proxy add to the request that reaches the backend?
2. Align the backend rewrite – if the proxy adds /app, the backend should see that path. Either:
   • Use an absolute substitution that starts with a slash and does not depend on the current URI, e.g. RewriteRule ^(.*)$ /app/$1 [L,R=302].
   • Or place the rewrite in a Directory or Location block that matches the proxy prefix and set RewriteBase /app/.
3. Test with rewrite tracing – enable LogLevel rewrite:trace6 for the VirtualHost, make a request, and compare the logs for localhost and proxied requests. Look for the RewriteRule that is applied and the resulting Location header.
4. Verify the response – after the change, request a URL that triggers the rewrite and check that the Location header contains the correct path and that no redirect loop occurs.
5. Deploy to staging first – changing RewriteBase or the substitution can affect other rules. Verify that unrelated rewrites still function.

When to avoid relative substitutions

In environments where a reverse proxy modifies the path, it is safest to use absolute substitutions (starting with /) or to include the full scheme and host when a client‑visible redirect is required. If you must use a relative substitution, ensure that the backend’s request URI is identical to what the client sent, which usually means disabling path changes in the proxy.

Missing diagnostic detail

Could you share the ProxyPass and ProxyPassReverse directives that are used in production? Knowing the exact path prefix added by the proxy will help fine‑tune the RewriteBase or substitution.