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.

Availability

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 its IP address and configure Local Domain Fallback to resolve its private hostname.

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.

As shown in Figure 2 below, the WARP client will now send wiki.internal.local traffic to the initial resolved IP. 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.

Figure 1: Network traffic flow for a private hostname route

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.
   • Hostnames with non-Latin characters must be Punycode encoded and include the ACE prefix ↗. For example, to represent 例.internal.local, enter xn--fsq.internal.local.

10. Select Complete setup.

2. Connect the DNS server to Cloudflare

--------to do------ Route the IP address of your internal DNS resolver through the tunnel.

3. Create a resolver policy

To resolve the private hostname through Cloudflare:

1. Create a Gateway resolver policy that matches the following traffic:

   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	❌
Android	❌
ChromeOS	❌

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 private network IPs through WARP

--------to do------

• Initial resolved IP CGNAT range: 100.80.0.0/16
• Private network CIDR where the application is located, e.g. 10.0.0.0/8. (Still need to know the IP range of the network. Do not need to know the specific IP of the application)
• Internal DNS resolver IP

6. (Recommended) Filter network traffic with Gateway

--------to do------

Enable 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)

Proxy settings are not currently supported by the Terraform v5 provider (as of version 5.3.0). To turn on the Gateway proxy, use the dashboard or API.

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 do------

If you're running a private app on port 443:

Option 1: create an Access self-hosted private app https://developers.cloudflare.com/cloudflare-one/applications/non-http/self-hosted-private-app/ ↗

Option 2: create a Gateway network policy using the SNI selector https://developers.cloudflare.com/cloudflare-one/policies/gateway/network-policies/#sni ↗

Self-hosted private apps and Gateway network policies are not currently supported for services on non-443 ports. You can only create a Gateway DNS policy.

7. Connect as a user

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

---- what's a good example for a non-HTTP app?---

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 client	✅
PAC files	✅
Browser Isolation	✅
WARP Connector	❌
Magic WAN	❌

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	❌