Why the Host header breaks third-party origins

Load balancing is conceptually simple: spread incoming requests across origin servers so no single machine gets crushed, and run health checks to make sure every origin is alive. But once applications grow and start leaning on third-party platforms — Google Compute Cloud, Google App Engine, Heroku, Amazon S3 — the Host header turns into a point of friction.

Every HTTP request carries a Host header that tells the receiving infrastructure which site the client actually wants. Type example.com into a browser and the request goes out with Host: example.com; the origin that owns that host serves the response. If the header doesn't match what the destination expects, the request fails — a mechanism that also prevents requests from being silently hijacked by a similarly named but malicious domain.

The problem appears when an application moves from example.com to something like example.herokuapp.com. The load balancer forwards traffic toward the correct IP, but the Host header still says example.com, and the third-party platform rejects it. Large customers were left choosing between load balancing and the platforms they wanted to build on. That's the gap this feature closes.

Per-origin Host header override

Cloudflare's Load Balancing solution now supports overriding the Host header per origin, not per pool or per load balancer. That granularity matters because different origins can host different segments of an application — or entirely separate applications — and each may expect a different Host value.

When you configure an origin, you can set a custom Host header with a simple click. The load balancer reads that value instead of the default and routes requests correctly. If the origin also has a health monitor attached, the override is automatically applied there too — no extra configuration step. When editing a health monitor, a new table shows you which origins already have an override, so you can see at a glance what the monitor will actually send.

Useful in places beyond third-party hosting. If you run multiple domains on a shared web server behind a single IP — say example-grocery.com, example-furniture.com, and example-perfume.com — a Host header override makes sure traffic for one domain lands on the right virtual host instead of the server's default. Setting the override also enforces a strict HTTPS/TLS connection, because the Server Name Indicator (SNI) is validated to confirm the request reaches the intended website.

How it fits the existing architecture

Before this feature, customers on Enterprise plans could handle this with Page Rules, but only if all origins expected the same Host header. When different origins needed different headers, there was no way to express that. The per-origin override replaces that coarse workaround with something configurable directly in the Traffic tab.

Once you save a Host header override, it takes precedence over any Host header override configured at the monitor level. Safety checks run before the configuration is accepted, and the settings propagate to all 200+ Cloudflare edge locations. When a request arrives, the edge looks up the load balancing config and the health monitor status for the origin, then applies both the Host header override and the SNI value before forwarding.

Restrictions on override values

To keep the feature safe, the domain you set as the Host header override must meet these limits:

  • Only the Host header is allowed — no other HTTP headers.
  • Only one Host header per origin; no duplicates, line wraps, or indented headers with spaces.
  • No ports can be included in the Host header.
  • The value must be an FQDN or IP address resolvable by public DNS.
  • The FQDN must be a subdomain of a zone associated with the account — this applies to partial zones and secondary zones as well.

These rules ensure you're only directing traffic to domains you control. The restrictions may be relaxed in future releases, but for now they keep the override from being misused.