HTTP headers · Request header
Host
Host names the site the client wants to reach; it is what makes virtual hosting possible.
Key facts
| Type | Request header |
|---|---|
| Syntax | <code>Host: example.com:8080</code> |
| Required | Exactly one in HTTP/1.1 |
| Port | Included only when non-default |
| IPv6 | <code>[2001:db8::1]:8080</code> |
| HTTP/2 | Carried as <code>:authority</code> |
| Standard | RFC 9110 §7.2 |
The header that selects a site
One IP address can serve thousands of sites. Host tells the server which one the client wants, and the server matches it against configured virtual hosts. Without it, HTTP/1.1 cannot route the request; HTTP/2 carries the same value in the :authority pseudo-header.
Host is not authentication. A client can send any value, so a server must validate it against an allowlist before using it to build URLs, cache keys or password-reset links. An unchecked Host is the basis of host-header injection.
Ports, IPv6 and proxies
The port is included only when it differs from the default for the scheme: example.com means port 80 on HTTP and 443 on HTTPS. IPv6 literals are bracketed, as in [2001:db8::1]:8080. A reverse proxy usually preserves the original host and passes it upstream, often with X-Forwarded-Host as additional context.
TLS chooses the certificate before HTTP exists, so the server needs a separate signal: SNI. It carries the hostname during the handshake, and the Host header should agree with it or the request may be rejected.
Frequently asked questions
Can a request have more than one Host header?
No. HTTP/1.1 requires exactly one; duplicates must be rejected because the routing decision becomes ambiguous.
Is Host the same as the domain in the URL?
Usually, but not always: proxies and internal services may rewrite it. Security decisions should rely on the validated public host, not on whatever arrived.