docs: clarify Host header requirements wrt TLS

The previous documentation was clear on handling http->https proxying,
but not the other way round. They did not cover the case of proxying to
a unix socket, either. There are special considerations when proxying to
caddy in either of these cases, that should be mentioned.
This commit is contained in:
David Baynard 2025-03-10 10:41:24 +00:00
parent 07ac9dc70c
commit 1e0cd2e32d

View file

@ -487,6 +487,8 @@ reverse_proxy https://example.com {
The `X-Forwarded-Host` header is still passed [by default](#defaults), so the upstream may still use that if it needs to know the original `Host` header value. The `X-Forwarded-Host` header is still passed [by default](#defaults), so the upstream may still use that if it needs to know the original `Host` header value.
The same applies when terminating TLS in caddy and proxying via HTTP, whether to a port or a unix socket. Indeed, caddy itself must receive the correct Host, when it is the target of `reverse_proxy`. In the unix socket case, the `upstream_hostport` will be the socket path, and the Host must be set explicitly.
## Rewrites ## Rewrites