Routing by hostname: a new option for Cloudflare Tunnel connections

Cloudflare Tunnel now supports routing traffic based on a hostname or domain, rather than requiring an IP address or CIDR range. The update lets administrators build zero-trust and egress policies for private and public web applications without tracking the underlying IP addresses of those resources.

The change continues Cloudflare's push toward hostname- and domain-based policies across its Cloudflare One SASE platform. For organizations juggling dynamic cloud infrastructure, it removes a persistent source of fragility from access control configuration.

Why hostname-based policies matter for zero trust

NIST Special Publication 800-207 encourages organizations to replace the "castle-and-moat" model—where network location determines trust—with Zero Trust principles that verify every access request. In practice, that means per-resource authorization: granting users access only to the specific applications they need rather than broad network segments.

Consider the difference in policy granularity:

  • Only employees in the "SRE" group running a managed device can access admin.core-router3-sjc.acme.local.
  • Only employees in the "finance" group located in Canada can access canada-payroll-server.acme.local.
  • All employees located in New York can access printer1.nyc.acme.local.

These policies all reference a resource's private hostname, not its IP. Hostname-based routing in Cloudflare Tunnel makes that approach viable.

IP-based rules are inherently unstable

A server's IP address is often the least persistent attribute in modern cloud environments. Several common scenarios illustrate the problem:

  • Cloud instances: When launching compute instances in environments like AWS, you control the hostname but not necessarily the IP address.
  • Load balancers: Services behind cloud load balancers can have IPs that change dynamically in response to traffic shifts.
  • Ephemeral infrastructure: Autoscaling groups, Kubernetes pods, and other "cattle, not pets" resources are created and destroyed frequently. They keep stable hostnames but their IPs change on every restart.

Organizations have built scripts to maintain dynamic IP Lists that map hostnames to current addresses. Those lists are brittle and error-prone; a single mistake can lock employees out of critical systems. Hostname-based routing eliminates the need for this workaround.

Securing a private server by hostname

To protect a private server such as canada-payroll-server.acme.local without touching an IP address:

Step 1: Connect your private network

Install the cloudflared agent in the same LAN as the target server to create a secure Cloudflare Tunnel. You can create the tunnel with cloudflared tunnel create <TUNNEL-NAME> or through the Zero Trust dashboard.

Step 2: Route the hostname to the tunnel

In the Zero Trust dashboard, create a route that binds the hostname canada-payroll-server.acme.local directly to that tunnel. Previously, only IP addresses (10.4.4.4) or subnets (10.4.4.0/24) could be routed. The new capability also supports entire domains: routing acme.local to a tunnel covers *.acme.local.

For this routing to function, the private network's subnet (e.g., 10.0.0.0/8) and 100.64.0.0/10 must be removed from the Split Tunnels Exclude list. Additionally, remove .local from the Local Domain Fallback configuration.

Step 3: Write your zero trust policy

Once routing is configured, apply access controls based on the hostname:

  • Cloudflare Access (HTTPS applications): Create an Access policy granting the "finance" group access to the private hostname canada-payroll-server.acme.local, ideal for HTTPS services on port 443.
  • Cloudflare Gateway (HTTPS applications): Write a Gateway network policy that allows the "finance" group to reach the SNI canada-payroll-server.acme.local. This works for HTTPS services on any port.
  • Cloudflare Gateway (non-HTTP applications): Create a Gateway policy that blocks DNS resolution of canada-payroll-server.acme.local for all employees except the "finance" group.

A true Zero Trust deployment should pair these allow policies with a default Gateway policy denying all access to internal IP ranges. That foundational deny rule keeps every door to the private network locked unless explicitly opened for a specific user or group.

Controlling egress to third-party applications

Hostname-based routing also addresses a common egress challenge: third-party services that require traffic to originate from a dedicated public source IP. For example, a banking portal at bank.example.com might only accept connections from your company's source IP 203.0.113.9. Security policies based on the bank's destination IP are impractical since you don't control that address and it can change.

Two options exist. If the dedicated source IP was purchased from Cloudflare, the previously announced "egress policy by hostname" feature applies. If the IP belongs to the organization or is leased from another cloud provider, hostname-based routing solves the problem:

  1. Force traffic through your dedicated IP: Deploy a Cloudflare Tunnel in the network that owns the dedicated IP (for instance, a primary VPC). Traffic sent through this tunnel exits to the Internet with 203.0.113.9 as its source address.
  2. Route the banking app to that tunnel: Create a hostname route in the Zero Trust dashboard so that traffic destined for bank.example.com sends through this specific tunnel.
  3. Apply user policies: In Cloudflare Gateway, create a low-priority network policy blocking access to the SNI bank.example.com for everyone, then a higher-priority policy explicitly allowing users in the "finance" group to reach it.

When finance team members access the portal, their traffic exits through the tunnel with the expected source IP. Unauthorized employees are blocked at Gateway before their traffic reaches the tunnel. The result is a precise, user-based zero trust policy for a third-party service, enforced entirely through its public hostname.

How hostname-based routing actually works

Routing by hostname presents a fundamental networking challenge: Cloudflare Gateway operates at Layer 4, making routing decisions the moment the first IP packet arrives. At that point, only the destination IP address is visible—the hostname lives in Layer 7 data like TLS SNI or HTTP Host headers, which isn’t available until after the connection is already established.

The solution leverages the fact that Gateway is also a DNS resolver. Because Gateway sees the user’s DNS query before application traffic, it can tag the traffic stream in advance using a synthetic IP address.

BLOG-2992 Image 7

Here’s the flow:

  1. DNS query. The user’s device queries the Gateway resolver for canada-payroll-server.acme.local.
  2. Private resolution. Gateway asks the cloudflared agent in your private network to resolve the real IP. The agent returns the actual private address, e.g., 10.4.4.4.
  3. Synthetic response. Instead of returning 10.4.4.4 to the user, Gateway assigns a temporary “initial resolved IP” from a reserved Carrier-Grade NAT (CGNAT) range (e.g., 100.80.10.10). This synthetic address tags the traffic as destined for that specific hostname. The reserved ranges are:
  • IPv4: 100.80.0.0/16
  • IPv6: 2606:4700:0cf1:4000::/64
  1. Traffic arrives. The user’s device sends application traffic to the synthetic IP (100.80.10.10).
  2. Routing and rewriting. Gateway recognizes the synthetic destination IP, maps it to canada-payroll-server.acme.local, rewrites the destination back to the real private IP (10.4.4.4), and sends it through the correct Tunnel.

The entire exchange is transparent to the user. By intercepting DNS, Gateway tags the traffic stream so Layer 4 routing decisions can be made without ever inspecting Layer 7 payloads.

Separating DNS resolution from application routing

Complex network topologies sometimes require DNS and application traffic to take different paths. Say your private DNS resolvers for acme.local sit in a core datacenter reachable via tunnel-1, but the webserver canada-payroll-server.acme.local is hosted in a cloud VPC reachable only via tunnel-2. Gateway Resolver Policies let you split these paths.

BLOG-2992 Image 8

Route DNS queries via tunnel-1:

  1. In Networks > Tunnels, create an IP route for the DNS server’s address (e.g., 10.131.0.5/32) pointing to tunnel-1.
BLOG-2992 Image 9
  1. In Gateway -> Resolver Policies, create a policy: If the query is for acme.local, then resolve using the DNS server at 10.131.0.5.
BLOG-2992 Image 10

Route application traffic via tunnel-2:

Create a hostname route binding canada-payroll-server.acme.local to tunnel-2. Any HTTP, SSH, or TCP/UDP traffic for that hostname will be sent through this tunnel to the cloud VPC.

BLOG-2992 Image 11

As with the simpler setup, remove your private subnet (e.g., 10.0.0.0/8) and 100.64.0.0/10 from Split Tunnels Exclude, and remove .local from Local Domain Fallback.

The complete flow:

  1. The user requests canada-payroll-server.acme.local; their device sends a DNS query to the Gateway resolver.
  2. The Resolver Policy matches, forwarding the query through tunnel-1 to the private DNS server at 10.131.0.5.
  3. The DNS server responds with the real destination IP 10.4.4.4.
  4. Gateway generates a synthetic IP (100.80.10.10) and returns it to the user’s device.
  5. The device sends application traffic to 100.80.10.10.
  6. Gateway maps the synthetic IP back to the hostname.
  7. The Hostname Route matches; Gateway sends traffic through tunnel-2 and rewrites the destination to 10.4.4.4.
  8. The cloudflared agent at the end of tunnel-2 forwards traffic to the application on the local network.

DNS and application traffic traverse entirely separate network paths, while the user experiences a single seamless connection. This enables split-horizon DNS environments and other advanced architectures with declarative policies.

Supported on-ramps and off-ramps

Hostname routing relies on the synthetic IP mechanism, which requires specific Cloudflare One components for both ends of the connection.

User connectivity (on-ramps)

Out of the box, the feature works with WARP Client, agentless PAC files, and Browser Isolation.

Users behind Magic WAN (active-passive mode only) or WARP Connector require extra routing configuration. You must update routing tables to send traffic through Gateway for:

  • The initially resolved IP ranges: 100.80.0.0/16 (IPv4) and 2606:4700:0cf1:4000::/64 (IPv6)
  • The private network CIDR where the application lives (e.g., 10.0.0.0/8)
  • The IP of your internal DNS resolver
  • The Gateway DNS resolver IPs: 172.64.36.1 and 172.64.36.2

Magic WAN customers must also point their DNS resolver to the Gateway resolver IPs and ensure tunnels operate in active-passive mode. DNS queries and resulting traffic must reach Cloudflare over the same Magic WAN tunnel; hostname routing fails if multiple tunnels are actively transiting traffic simultaneously.

Private network connectivity (off-ramps)

Cloudflare Tunnel (cloudflared) is currently the only supported off-ramp for hostname-based routing. IP-based routing continues to work with Magic WAN, WARP Connector, and WARP-to-WARP as off-ramps, but these are not yet compatible with the hostname-based feature.

Hostname routing is available today within Cloudflare Tunnel at no additional cost for all Cloudflare One customers. It eliminates the need to track changing IP addresses in policies, allowing per-resource authorization based on the service name itself—a core step toward practical zero trust architecture. Configuration instructions are available in the developer documentation.