Apache ProxyPassReverse not forwarding location response

Apache ProxyPassReverse fails to rewrite redirect responses when the backend server returns absolute URLs that do not match the proxy's external path, or when multiple proxies in the chain interfere with header interpretation. This issue typically manifests as infinite loops, broken relative links, or clients receiving redirects pointing back to the internal Docker container IP instead of the public domain. The core mechanism of ProxyPassReverse is to inspect the Location, Content-Location, and URI headers in HTTP response codes 200, 301, 302, 303, 307, and 308. It then rewrites these values to match the URL structure exposed by the front-end Apache server. If this rewriting does not occur, it is usually because the backend is sending a URL that falls outside the scope defined by ProxyPass, or because intermediate network devices are stripping or altering headers before they reach the reverse proxy.

Verify Basic Proxy Configuration Syntax

Before diving into complex debugging, ensure that your mod_proxy configuration is syntactically correct and that the directives are scoped appropriately. A common mistake is placing ProxyPassReverse inside a block but having the corresponding ProxyPass directive defined elsewhere, such as in the main server context or a different virtual host. Apache processes these directives based on their order and location within the configuration hierarchy. You must define both ProxyPass and ProxyPassReverse for the same URL path. For example, if you are proxying requests from /app to a Docker container, the configuration should look like this:

<VirtualHost *:80>
    ServerName example.com
    
    ProxyPreserveHost On
    ProxyRequests Off
    
    <Location /app>
        ProxyPass http://localhost:8080/app
        ProxyPassReverse http://localhost:8080/app
    </Location>
</VirtualHost>

Notice that both directives use the exact same prefix (/app). If the backend application generates redirects using a different prefix, such as /backend, ProxyPassReverse will ignore them because they do not match the pattern it is watching. Ensure that the trailing slashes are consistent. ProxyPass /app/ http://backend/app/ requires matching trailing slashes to function correctly.

Check Backend Application Redirect Logic

The most frequent cause of this issue lies within the backend application itself, particularly when running inside Docker containers. Many web frameworks and servers (like Nginx, Tomcat, or Node.js apps) determine the base URL dynamically based on the incoming request headers. If the reverse proxy does not forward the original host header, the backend might assume it is being accessed via its internal IP address or port. Enable ProxyPreserveHost On in your Apache configuration. This ensures that the Host header sent by the client is passed through to the backend. Without this, the backend may generate redirects pointing to http://localhost:8080/login instead of https://example.com/login. Since ProxyPassReverse only rewrites URLs that start with the target URL specified in ProxyPass, a mismatch here causes the redirect to bypass rewriting entirely. If you are using a framework that supports it, explicitly configure the trusted proxy settings. For instance, in Django, set SECURE_PROXY_SSL_HEADER and ensure ALLOWED_HOSTS includes your domain. In Express.js, use trust proxy middleware. This forces the application to respect the headers provided by Apache rather than inferring them from the socket connection. For more details on routing traffic correctly to Docker containers, see Apache Reverse Proxy: Reroute URL to Docker Container in Local Network.

Inspect Response Headers with Curl

To diagnose whether Apache is receiving the correct headers from the backend, use curl to simulate a request directly to the backend service while mimicking the proxy environment. Run the following command against the backend container's internal IP or hostname:

curl -v -H "Host: example.com" http://localhost:8080/app/redirect

Examine the output for the HTTP/1.1 302 Found line and the subsequent Location header. If the Location header contains an absolute URL with the internal IP (e.g., http://172.17.0.2:8080/home), Apache's ProxyPassReverse will not rewrite it because it does not match the http://localhost:8080/app pattern defined in your config. If the header looks correct (pointing to /app/home) but the browser still sees the internal IP, the issue may be upstream. Check if there are other proxies between Apache and the client, such as a cloud load balancer or a CDN, which might be handling SSL termination and forwarding requests in a way that confuses the header parsing.

Handle Multiple Proxies and Nested Rewrites

In complex architectures involving multiple layers of proxies, standard ProxyPassReverse may fail if the URL has already been rewritten by a previous proxy. Apache provides ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath for cookie-specific issues, but for general URL rewriting, you may need to use mod_rewrite as a fallback. However, avoid using mod_rewrite for basic proxy redirection unless necessary, as it can lead to performance degradation and complex rule conflicts. If you must use it, apply it strictly after the proxy module has processed the request. Use the R flag carefully to prevent infinite loops. A safer alternative is to adjust the backend configuration to always return relative paths. Relative URLs (starting with / or ./) are generally unaffected by proxy layering issues because the browser resolves them against the current document location. If your backend allows configuring the root URL or base path, set it to a relative value or the specific mount point used by the proxy. See also Troubleshooting Nginx-proxy Ignoring Server Context for insights on how other proxy engines handle similar context mismatches.

Restart and Cache Clearing

After making changes to apache2.conf or site-specific configurations, you must restart the Apache service for changes to take effect. Use sudo systemctl restart apache2 on Debian-based systems or sudo apachectl restart on others. Before restarting, run apachectl configtest to validate syntax errors. If you are using caching modules like mod_cache, stale cached responses might serve old headers. Clear the cache directory or disable caching temporarily during debugging. Additionally, check browser developer tools under the Network tab to see the raw headers received by the client. This helps distinguish between server-side misconfiguration and client-side caching issues.

Frequently Asked Questions

Why does ProxyPassReverse work for some endpoints but not others?

ProxyPassReverse only rewrites URLs that exactly match the prefix defined in ProxyPass. If one endpoint uses /api/v1 and another uses /v2/api, you must define separate ProxyPass and ProxyPassReverse blocks for each path. Mismatched prefixes result in unrewritten headers.

Can I use mod_rewrite to fix broken redirects?

Yes, but it is less efficient than native proxy rewriting. You can use RewriteRule with the P flag to proxy requests, but for rewriting response headers, ProxyPassReverse is optimized and simpler. Use mod_rewrite only if you need conditional logic based on query strings or user agents that mod_proxy cannot handle.

What if my backend is behind a firewall that strips Host headers?

If the firewall strips headers, Apache cannot preserve the original host. You may need to configure the backend to accept a default host or use a TCP-level proxy that preserves headers. Alternatively, configure the backend to ignore the Host header and rely on the URI path for routing decisions.

Does ProxyPassReverse affect error pages generated by Apache?

No, ProxyPassReverse only affects headers returned by the backend server. Error pages generated locally by Apache (such as 404 or 503 errors) are not subject to this rewriting. To customize these, use ErrorDocument directives in your Apache configuration.

How do I debug ProxyPassReverse without restarting Apache?

Use curl -I to fetch headers without downloading the body. This allows rapid iteration. However, configuration changes always require a restart or reload. Use systemctl reload apache2 for a graceful reload that does not drop existing connections, though some strict configurations may require a full restart.