How to Control the Host Header Apache Sends to a Backend Proxy

When Apache httpd reverse-proxies a request, it deliberately builds a new Host header from the backend URL in your ProxyPass directive, and it does so after the request-header stage that RequestHeader operates in. That is why RequestHeader set Host ... appears to have no effect: mod_proxy overwrites the value when it constructs the outgoing request. The built-in way to control this behavior is the ProxyPreserveHost directive, which forwards the client's original Host header to the backend instead of the backend hostname.

Why the Host header changes in the first place

By design, mod_proxy treats the target in ProxyPass / http://localhost:3002/ as authoritative for the connection. The request is rewritten to be "for" that origin: the Host header becomes localhost:3002, the request line targets that server, and any header manipulation you performed earlier is superseded. This default protects you from accidentally leaking a client-supplied Host value to a backend that may use it for routing or cache keying.

It also explains the symptoms you typically observe in the backend's request log: the Host line shows the backend address, while headers like X-Forwarded-Host and X-Forwarded-Server correctly carry the public hostname. Apache is not dropping your configuration; it is running two different mechanisms at two different times, and the proxy-rewrite stage wins.

The fix: ProxyPreserveHost

Enable host preservation inside the same virtual host that contains your proxy rules:

<VirtualHost *:80>
    ServerName subdomain.example.com

    ProxyPreserveHost On
    ProxyPass        /  http://localhost:3002/
    ProxyPassReverse /  http://localhost:3002/
</VirtualHost>

With ProxyPreserveHost On, the Host: line received from the client is passed through verbatim. If the visitor requested subdomain.example.com/actor, the Node application now sees request.headers.host equal to subdomain.example.com and can build its URL-based hashes correctly.

Note that this forwards whatever the client sent. In a properly configured virtual host with a matching ServerName, that is the public hostname you want. It is not, however, a way to force an arbitrary fixed hostname unrelated to what the client requested.

What if you need a fixed Host value, not the client's?

Sometimes the backend must see one specific hostname regardless of which alias the client used, or you proxy from a host whose public name differs from the backend's expectation. ProxyPreserveHost cannot inject a value it never received. Two approaches work:

• Separate virtual hosts. Give each public hostname its own <VirtualHost> block with the correct ServerName and its own ProxyPass. With ProxyPreserveHost On in each block, the backend receives the appropriate name per vhost.
• Backend-side override. Let Apache forward standard headers (X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-For) and have the application reconstruct its URLs from those forwarded values instead of the raw Host header. Many frameworks, including Node/Express behind a trusted proxy, support this with a single trust setting.

As a last resort, some administrators use mod_rewrite's proxy flag with a forced host, but this is fragile and bypasses the cleaner mod_proxy configuration surface. Prefer the two options above.

Diagnosing header problems behind a proxy

When a proxied application misbehaves, confirm what it actually receives before changing configuration:

1. Log the raw request in the backend. In Node, dump req.headers for one request; in a PHP or generic backend, point ProxyPass temporarily at a script that echoes all headers.
2. Compare the Host line with X-Forwarded-Host. If they differ and the app reads Host, you have the scenario described here.
3. Check that HTTPS is accounted for: if you terminate TLS at Apache, the backend sees plain HTTP. Add RequestHeader set X-Forwarded-Proto "https" so URL construction does not produce http:// links.
4. Reload Apache (apachectl configtest followed by a graceful restart) after editing, and clear any application-level caching that may keep stale hashes.

Security and operational caveats

Preserving the client's Host header means the backend trusts a client-controlled value. Consequences to weigh:

• If the backend generates absolute URLs, sets cookies, or builds cache keys from Host, an attacker-supplied Host could poison those outputs. A correctly matched ServerName in the vhost limits exposure, because Apache only reaches that vhost for the names it serves.
• Name-based backends that rely on Host for routing (for example, multiple apps behind one Node process) will now route by the public hostname, which may be exactly what you want or may break local testing.
• Health checks and direct-to-backend requests that bypass Apache will still show the backend's own address; do not expect uniform Host values from every path.

Preventing the problem in future deployments

Treat proxy header behavior as part of the proxy contract, not an afterthought. Standardize a template virtual host that sets ProxyPreserveHost On, forwards the X-Forwarded-* family, and documents which header the application must read for URL construction. When onboarding a new backend, run one test request through the proxy and verify the Host line before the application ever goes live; this catches the mismatch in minutes rather than during integration debugging.

Frequently Asked Questions

Why did RequestHeader set Host have no effect?

mod_proxy constructs the outgoing request, including the Host header, after the RequestHeader processing stage. Your directive runs, but its value is then overwritten by the backend hostname from ProxyPass.

Can I set Host to a specific fixed value for all clients?

Not directly with mod_proxy core. ProxyPreserveHost forwards the client's value; to force one hostname, use separate virtual hosts with correct ServerName entries, or make the backend derive its hostname from X-Forwarded-Host.

Is ProxyPreserveHost safe to enable?

Yes, when your virtual host's ServerName matches the names you actually serve, so only legitimate requests carry that Host. Avoid it on catch-all proxies that accept arbitrary Host values, since the backend would then trust attacker-controlled input.

Does ProxyPreserveHost affect HTTPS backends?

It only changes the Host header, not TLS behavior. SNI and certificate validation use the backend hostname from ProxyPass; if you proxy to an HTTPS backend, make sure certificate checking still targets that hostname.

My app still builds wrong URLs. What else should I check?

Verify the scheme: TLS terminates at Apache, so the backend sees HTTP unless you forward X-Forwarded-Proto and the app honors it. Also confirm the app reads the header you are actually controlling.

Do I need ProxyPassReverse when changing the Host handling?

ProxyPassReverse rewrites Location and related headers in responses; it is independent of Host preservation but should be present so redirects from the backend point at your public URL rather than the internal one.