Connect a private hostname

cloudflared can route to HTTP and non-HTTP applications on your private network using their private hostname (for example, wiki.internal.local). Private hostname routes are especially useful when the application has an unknown or ephemeral IP, which often occurs when infrastructure is provisioned by a third-party cloud provider.

Only available on Enterprise plans

Hostname routes currently require Gateway resolver policies, an Enterprise-only feature. If you are on a Free or Pay-as-you-go plan, you will need to connect the application using IP routes.

How private hostname routing works

Private hostname routing with Cloudflare Tunnel consists of three main components:

• The WARP client installs on the user device and forwards network and DNS traffic from the device to Cloudflare Gateway.
• Gateway resolver policies instruct Gateway to resolve the private hostname using your internal DNS resolver instead of the default public resolver.
• cloudflared installs on a host machine in your private network and proxies traffic from Cloudflare to your internal DNS resolver and internal applications.

Figures 1 and 2 illustrate the flow of DNS and network traffic when a user connects to a private hostname (wiki.internal.local):

Figure 1: DNS resolution for private hostname

1. The WARP client sends the DNS query to the Gateway resolver for resolution.

2. Based on the configured resolver policies, Gateway determines that wiki.internal.local should be resolved by a custom DNS resolver.

3. Gateway does a DNS lookup for wiki.internal.local through Cloudflare Tunnel, and the custom DNS resolver returns the origin IP (10.0.0.5).

4. Rather than responding to the DNS query with the actual origin IP, Gateway responds with a random IP address from the following CGNAT range:

   • IPv4: 100.80.0.0/16
   • IPv6: 2606:4700:0cf1:4000::/64

   The selected CGNAT IP is called the initial resolved IP.

5. Gateway's network engine stores the mapping between the private hostname (wiki.internal.local), initial resolved IP (100.80.0.1), and the actual IP (10.0.0.5).

6. The WARP client receives the initial resolved IP (100.80.0.1) in the DNS response. Each WARP device will receive a unique, ephemeral initial resolved IP.

As shown in Figure 2 below, the WARP client will now send wiki.internal.local traffic to the initial resolved IP.

Figure 2: Network traffic flow for a private hostname route

The initial resolved IP mechanism is required because Gateway's network engine operates at L3/L4 and can only see IPs (not hostnames) when processing the connection. Because the packet's destination IP falls within the designated CGNAT range, Gateway knows that it corresponds to a hostname route and can apply hostname-based policies. Traffic that passes your Gateway policies will route through Cloudflare Tunnel to the application's actual origin IP. When the initial resolved IP expires, WARP will send a new DNS request (Figure 1) to refresh the initial resolved IP.

To learn more about hostname routing, refer to the Cloudflare blog.

Connect to a private hostname

This section covers how to enable remote access to a private hostname application using cloudflared and WARP.

1. Connect the application to Cloudflare

1. Log in to Zero Trust ↗ and go to Networks > Tunnels.

2. Select Create a tunnel.

3. Choose Cloudflared for the connector type and select Next.

4. Enter a name for your tunnel. We suggest choosing a name that reflects the type of resources you want to connect through this tunnel (for example, enterprise-VPC-01).

5. Select Save tunnel.

6. Next, you will need to install cloudflared and run it. To do so, check that the environment under Choose an environment reflects the operating system on your machine, then copy the command in the box below and paste it into a terminal window. Run the command.

7. Once the command has finished running, your connector will appear in Zero Trust.

   

8. Select Next.

9. In the Hostname routes tab, enter the fully qualified domain name (FDQN) that represents your application (for example, wiki.internal.local).

   Hostname format restrictions

   • Less than 255 characters
   • Leading wildcards (*) and dots (.) are allowed but trimmed off. For example, *.internal.local becomes internal.local.
   • Ending dots (.) are allowed but trimmed off.
   • No wildcards (*) in the middle. For example, foo*bar.internal.local is not allowed.

10. Select Complete setup.

2. Connect the DNS server to Cloudflare

To route your internal DNS resolver through Cloudflare Tunnel:

1. Go to Networks > Routes > CIDR.

2. Select Create CIDR route.

3. In CIDR, enter the private IP address of your internal DNS resolver.

4. For Tunnel, select the Cloudflare Tunnel that is being used to connect the private network to Cloudflare.

5. Select Create route.

3. Create a resolver policy

Configure Gateway to resolve the private hostname using your internal DNS resolver:

1. Create a Gateway resolver policy that matches the private hostname for which you are establishing the route:

   Selector	Operator	Value
   Host	in	wiki.internal.local

2. Under Configure custom DNS resolvers, enter the IPv4 and/or IPv6 address of your internal DNS resolver. The dropdown menu will not populate until you type in the full IP address.

3. From the dropdown menu, select the - Private routing option and the virtual network where the DNS resolver is located.

4. Set up the client

Feature availability

WARP modes	Zero Trust plans ↗
Gateway with WARP	Enterprise

System	Availability	Minimum WARP version
Windows	✅	2025.4.929.0
macOS	✅	2025.4.929.0
Linux	✅	2025.4.929.0
iOS	✅	1.10
Android	✅	2.4
ChromeOS	✅	2.4

To connect your devices to Cloudflare:

1. Deploy the WARP client on your devices in Gateway with WARP mode or generate a proxy endpoint and deploy a PAC file.
2. Create device enrollment rules to determine which devices can enroll to your Zero Trust organization.

5. Route traffic through WARP

In your device profiles, configure Split Tunnels so that the following IPs route through the WARP tunnel:

• Initial resolved IP CGNAT range:
  • IPv4: 100.80.0.0/16
  • IPv6: 2606:4700:0cf1:4000::/64
• Private network CIDR where the application is located (for example, 10.0.0.0/8)
• Internal DNS resolver IP

For more details on configuring Split Tunnels, refer to Route private network IPs through WARP.

6. (Recommended) Filter network traffic with Gateway

By default, all WARP devices enrolled in your Zero Trust organization can connect to your private network through Cloudflare Tunnel. You can configure Gateway to inspect your network traffic and either block or allow access based on user identity and device posture. To learn more about policy design, refer to Secure your first application.

Enable the Gateway proxy

To start logging and filtering network traffic, turn on the Gateway proxy:

Dashboard

1. Go to Settings > Network.
2. In Firewall, turn on Proxy.
3. Select TCP.
4. (Recommended) To proxy traffic to internal DNS resolvers, select UDP.
5. (Recommended) To proxy traffic for diagnostic tools such as ping and traceroute, select ICMP. You may also need to update your system to allow ICMP traffic through cloudflared.

Terraform (v5)

1. Add the following permission to your cloudflare_api_token ↗:

   • Zero Trust Write

2. Turn on the TCP and/or UDP proxy using the cloudflare_zero_trust_device_settings ↗ resource:

   resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
     account_id            = var.cloudflare_account_id
     gateway_proxy_enabled = true
     gateway_udp_proxy_enabled = true
   }

Cloudflare will now proxy traffic from enrolled devices, except for the traffic excluded in your split tunnel settings. For more information on how Gateway forwards traffic, refer to Gateway proxy.

Zero Trust policies

To prevent WARP users from accessing your entire private network, we recommend creating a catch-all block policy for your private IP space. You can then layer on higher priority Allow policies which grant users access to specific applications or IPs.

HTTPS applications

If your private hostname points to an HTTPS application on port 443, you can secure it using either Access or Gateway policies:

• Option 1 (Recommended): Create an Access self-hosted private app to manage user access alongside your SaaS and other web apps.

• Option 2: If you prefer to secure the application using a traditional firewall model, build Gateway network policies using the SNI or SNI Domain selector. For an additional layer of protection, add a Gateway DNS policy to allow or block the Host or Domain from resolving.

  Example network policies

  The following example consists of two policies: the first allows specific users to reach your application, and the second blocks all other traffic.

  1. Allow company employees

     Selector	Operator	Value	Logic	Action
     SNI	in	wiki.internal.local	And	Allow
     User Email	matches regex	.*@example.com

  2. Catch-all block policy

     Selector	Operator	Value	Action
     Destination IP	in	10.0.0.0/8	Block

  Example DNS policy

  Selector	Operator	Value	Logic	Action
  Host	in	wiki.internal.local	And	Allow
  User Email	matches regex	.*@example.com

Non-HTTPS applications

Access policies and Gateway network policies only support hostname-based filtering for applications on port 443. If your application runs on a non-443 port, you will need to allow or block network traffic using the Destination IP selector. Then, add a Gateway DNS policy to allow or block the Host or Domain from resolving.

Example network policies

The following example consists of two policies: the first allows specific users to reach your application, and the second blocks all other traffic.

1. Allow company employees

   Selector	Operator	Value	Logic	Action
   Destination IP	in	10.0.0.0/8	And	Allow
   User Email	matches regex	.*@example.com

2. Catch-all block policy

   Selector	Operator	Value	Action
   Destination IP	in	10.0.0.0/8	Block

Example DNS policy

Selector	Operator	Value	Logic	Action
Host	in	wiki.internal.local	And	Allow
User Email	matches regex	.*@example.com

7. Test the connection

End users can now reach the application by going to its private hostname. For example, to test an HTTP application, open a browser and go to wiki.internal.local.

If you enabled the Gateway proxy, you can view the traffic in your Gateway activity logs.

Troubleshooting

For a step-by-step troubleshooting procedure, refer to Troubleshoot private network connectivity.

Supported on-ramps/off-ramps

Device connectivity

End users can connect to private hostnames from the following device on-ramps:

On-ramp method	Compatibility
WARP	✅
PAC files	✅
Browser Isolation	✅
Magic WAN	❌
WARP Connector	❌

Private network connectivity

To route to private applications using hostnames instead of IPs, connect your infrastructure to Cloudflare using a supported traffic off-ramp:

Connector	Compatibility
cloudflared	✅
WARP-to-WARP	❌
WARP Connector	❌
Magic WAN	❌