Origin Rules: Route Traffic Without Code

When a client sends an HTTP request, the host header tells the receiving origin which website or application is being requested. The origin checks this header against its configured applications and routes the request accordingly. If there is no match, the request fails.

In simple deployments, this works without issue: all traffic for example.com goes to one origin, which sees the matching host header and returns the correct content. But modern architectures are rarely that simple. SaaS platforms and S3-compatible storage endpoints use the host header to route requests to the right instance or bucket, which means the header must be rewritten somewhere in the path before the request lands on the backend. Similarly, applications that listen on non-standard ports — say, port 8001 instead of 443 — require the destination port to be rewritten mid-flow.

Historically, these jobs demanded custom code, such as a Cloudflare Worker or Spectrum application, or running a reverse proxy on the origin. Cloudflare is introducing Origin Rules to handle these cases natively: a no-code rule engine that lets you override the host header, Server Name Indication (SNI), destination port, and DNS resolution of matching HTTP requests.

One Hostname, Many Backends

Cloudflare's standard model maps a hostname to a single origin IP. The web server at that IP relies on the host header to decide which of several websites to serve. But this model breaks when different URL paths need to be served by different origins, such as an ecommerce SaaS provider for /shop and a support-desk SaaS for everything else.

The traditional workaround was to run your own reverse proxy: point example.com at the proxy's IP, and let it inspect the host header and URI path to decide where to forward traffic. This adds an unnecessary hop, increasing latency, and forces you to maintain a server whose only job is routing—something that feels increasingly out of place as workloads move to managed SaaS.

Origin Rules lets you skip the proxy. You can tell Cloudflare: "send all traffic for www.example.com to 98.51.100.12, but if the URI starts with /shop, send it to 203.0.113.34." This is called a resolve override — effectively a DNS-level reroute.

There is a catch: when requests get rerouted to the second IP, the host header still says www.example.com, and the ecommerce platform doesn't recognize it. You also need a host header override to rewrite that value to shop.example.com before the request reaches the new origin. Origin Rules bundles both actions into one rule.

These overrides are governed by a ruleset engine, so you aren't limited to URL-based conditions. Routing decisions can be based on the visitor's country, IP address, HTTP request headers, cookies, or any combination of fields available in the rules language.

Beyond URL-Based Routing

This is a marked improvement over Page Rules, Cloudflare's existing "If This Then That" tool, which limits conditions to the requested URL. Page Rules are still widely used — over one million were created in the past three months — but they can't express conditions like "if the request contains a tracking cookie, send it to a staging backend." Origin Rules can.

Consider a static-assets workload backed by cloud storage. With Origin Rules, you could write a rule that sends all requests for example.net/*.jpg to a publicly accessible S3-compatible bucket, while all other traffic stays on your normal origin.

Two actions are required. First, a resolve override that points to a DNS record on your zone, which resolves to the storage provider's URL. Second, a host header override that changes the header from example.net to the bucket name (e.g., bucket.example.net) so the provider can route the request correctly.

The ruleset engine opens up more sophisticated scenarios:

  • Use the http.request.cookies field to A/B test a new storage provider or bucket, directing only cookie-bearing requests to the candidate backend before cutover.
  • Use the ip.geoip.country field to route users from different regions to the nearest storage instance, reducing latency.

Destination Port Override

Cloudflare accepts traffic on 13 network ports — seven for HTTP, six for HTTPS. A standard HTTPS request on port 443 gets forwarded to the origin on port 443. But if your backend application listens on 8001, something has to perform the translation.

Previously, that meant either a reverse proxy on the origin or a Cloudflare Worker that rewrote the destination port before the request left Cloudflare's edge. Origin Rules turns this into a configuration task. You specify the new destination port in a rule, using the same field conditions available elsewhere in the ruleset. You can change the port based on URL, URI path, a specific request header, or almost any other field.

Server Name Indication Override

Server Name Indication is part of the TLS handshake. It lets the client state which domain it's trying to reach, which is important for origins that host multiple domains behind a single IP — or for Cloudflare for SaaS customers who point millions of hostnames at one Cloudflare edge. The trouble comes when the origin doesn't hold a certificate for every hostname that hits it.

"Custom origins" in SSL for SaaS has handled this on a per-hostname basis. But for Enterprise customers not using that setup, there was no way to solve it.

Origin Rules for Enterprise accounts changes that. You can override the SNI value as long as it matches another zone in your account. This removes the need to manage certificates for every hostname on the origin, and it eliminates the choice between certificate sprawl and unencrypted origin connections.

Availability

Origin Rules is available now in the Cloudflare dashboard, via API, and via Terraform. Documentation is available on the Cloudflare Developers site. Destination port rewriting is included for all customers; resolve override, host header override, and SNI override are Enterprise features.