Fix URL paths behind an Apache reverse proxy

When an application is exposed at /app1/, its redirects, assets, links, and cookies must agree with that public base path. Configure the application's external URL and trusted-proxy settings first. ProxyPassReverse fixes selected response headers; it does not rewrite the HTML body.

Mapping a public prefix to the backend root is valid. It does not automatically break every relative URL: images/logo.png resolves relative to the current document, while /images/logo.png starts at the public origin root. A page at /app1/ and one at /app1 also have different relative-URL bases.

Prefer a base-path-aware application

If the application actually serves /app1/ internally:

<VirtualHost *:80>
    ServerName example.com
    ProxyRequests Off
    ProxyPass "/app1/" "http://internal:8080/app1/"
    ProxyPassReverse "/app1/" "http://internal:8080/app1/"
</VirtualHost>

If it serves its internal root, use this mapping instead and configure its public base URL as supported by the application:

ProxyPass "/app1/" "http://internal:8080/"
ProxyPassReverse "/app1/" "http://internal:8080/"
ProxyPassReverseCookiePath "/" "/app1/"

Keep trailing slashes consistent on the two ProxyPass arguments. Arrange a deliberate redirect from /app1 to /app1/ if the application requires it. Cookie-path rewriting is needed only when the backend's cookie scope differs from the public path; inspect cookie Domain attributes separately.

ProxyPassReverse adjusts matching Location, Content-Location, and URI response headers. It maps a matching internal redirect back to the public address; it does not guarantee that every redirect becomes a path-only URL or that an unrelated root-relative redirect is corrected.

Rewrite HTML only when the application cannot cooperate

For suitable HTML responses, mod_proxy_html can rewrite URL attributes:

<Location "/app1/">
    ProxyHTMLEnable On
    ProxyHTMLURLMap "http://internal:8080/" "/app1/"
    ProxyHTMLURLMap "/" "/app1/"
</Location>

Load the proxy HTML module and its required dependencies according to the distribution. Check the resulting HTML, including already-prefixed URLs, external links, and any <base> element. This is not a complete solution for JavaScript-generated URLs, JSON, CSS, or application APIs.

mod_substitute can perform narrow text substitutions, but simple replacements of href="/ or src="/ miss single quotes and other URL forms, can corrupt protocol-relative URLs such as //cdn.example.com, and can add a prefix twice. Use it only for a known response format with regression coverage. Compressed responses and filter order also matter.

HTTPS and WebSockets

An HTTPS backend requires mod_ssl and SSLProxyEngine On, not a module named ssl_proxy. Configure a trusted CA and certificate verification for the backend rather than disabling verification to make it connect.

Apache 2.4.47 and later can handle WebSocket upgrades through mod_proxy_http, for example with an appropriate ProxyPass route and upgrade=websocket. Older installations may require mod_proxy_wstunnel. Place specific routes before broader mappings and follow the documentation for the deployed version.

Verify the complete request path

Inspect redirects, asset requests, login flows, cookie scope, and WebSocket connections in the browser. Compare failed request paths and status codes with access logs. In Guance, collect the logs and parse those fields before investigating recurring 404s; request logs alone cannot show every client-side URL-generation error.

References

• Apache mod_proxy
• Apache mod_proxy_html
• Apache mod_ssl proxy settings