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.

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 resolves 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. 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.

Supported on-ramps/off-ramps

The table below summarizes the Cloudflare One products that are compatible with private hostname routing. Refer to the table legend for guidance on interpreting the table.

✅ Product works with no caveats
🚧 Product can be used with some caveats
❌ Product cannot be used

Device connectivity

End users can connect to private hostnames using the following traffic on-ramps:

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

WARP feature availability

WARP modes
Gateway with WARP

System	Availability	Minimum WARP version
Windows	✅	2025.4.929.0
macOS	✅	2025.4.929.0
Linux	✅	2025.4.929.0
iOS	✅	1.11
Android	✅	2.4.2
ChromeOS	✅	2.4.2

Footnotes

1. Not compatible with ECMP routing. For hostname-based routing to work, DNS queries and the resulting network traffic must reach Cloudflare over the same Magic WAN tunnel.
   ↩

Private network connectivity

Private hostname routing only works for applications connected with cloudflared. Other traffic off-ramps require IP-based routes.

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

Connect a private hostname

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

Prerequisites

To connect to private hostnames, your devices must forward the following traffic to Cloudflare:

Initial resolved IPs

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

Private network CIDR where the application is located Internal DNS resolver IP DNS queries for your private hostname

Configuration steps vary depending on your device on-ramp:

WARP clients

1. In Split Tunnels, ensure that the IPs listed above route through the WARP tunnel. For example, if you are using the default Split Tunnels Exclude configuration and your application and DNS resolver have private IPs in the range 10.0.0.0/8, delete 100.64.0.0/10 and 10.0.0.0/8 from the Split Tunnels list. We recommend adding back the IPs that are not explicitly used by your network — refer to our Split Tunnels calculator for details.
2. In Local Domain Fallback, delete the top-level domain for your private hostname. This configures WARP to send the DNS query to Cloudflare Gateway for resolution.

WARP Connector

1. In your WARP Connector device profile, ensure that the IPs listed above route through the WARP tunnel.
2. Depending on where you installed WARP Connector, you may also need to route those destination IPs through WARP Connector and point your DNS resolver to Cloudflare Gateway. Refer to Route traffic from subnet to WARP Connector.

Magic WAN

1. Ensure that the IPs listed above route through Magic WAN to Cloudflare.
2. Point the DNS resolver for your Magic WAN network to Cloudflare Gateway.

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. (Optional) Create a resolver policy

Note

Only available on Enterprise plans

Gateway will automatically resolve DNS queries using your internal DNS server as long as the DNS server is behind the same Cloudflare Tunnel as your application. If your DNS server is behind a different Cloudflare Tunnel (for example, if you separated DNS traffic into its own tunnel for high availability), then you need to point Gateway to the correct tunnel and DNS server.

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 server. 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 server is located.

4. (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

5. Test the connection

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

Troubleshooting

You can run the following tests to check if private hostname routing is properly configured.

1. From the WARP device, confirm that you can successfully resolve the private hostname using your internal DNS server:

   nslookup wiki.internal.local 10.0.0.1

   Server:    10.0.0.1
   Address:  10.0.0.1#53
   
   Name:  wiki.internal.local
   Address: 10.0.0.5

   If the DNS lookup fails, it means that WARP cannot connect to your internal DNS server through cloudflared. Check that you have a tunnel route for the internal DNS server IP. Also, confirm that the DNS server IP routes through the WARP tunnel.

   For a general WARP-to-Tunnel troubleshooting procedure, refer to Troubleshoot private network connectivity.

2. Run a standard nslookup for the private hostname:

   nslookup wiki.internal.local

   Server:    127.0.2.2
   Address:  127.0.2.2#53
   
   Non-authoritative answer:
   Name:  wiki.internal.local
   Address: 100.80.200.48

   The query should resolve using WARP's DNS proxy and return a Gateway initial resolved IP. If the query fails to resolve or returns a different IP, check your Local Domain Fallback configuration and Gateway resolver policies.

3. When you connect to the application using its private hostname, the device should make a connection to the initial resolved IP:

   curl -v4 http://wiki.internal.local

   *   Trying 100.80.200.48:80...
   * Connected to wiki.internal.local (100.80.200.48) port 80
   ...

   If the request fails, confirm that the initial resolved IP routes through the WARP tunnel. You can also check your tunnel logs to confirm that requests are routing to the application's private IP.