Connect a private hostname

Instead of managing static IP lists and routes, you can connect users to private HTTP and non-HTTP applications using their hostnames (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.

When a user requests a private hostname, Cloudflare Gateway assigns an initial resolved IP from a CGNAT range to route the traffic through your tunnel to the correct private IP address. For a deep dive into the architecture and packet flow, refer to our announcement blog post ↗.

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	Minimum version
cloudflared	✅	2025.7.0
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
• DNS queries for your private hostname

Configuration steps vary depending on your device on-ramp:

WARP clients

1. In your WARP device profile, configure Split Tunnels such that the initial resolved IPs route through the WARP tunnel. Refer to the steps below for your Split Tunnels mode:

   Exclude IPs and domains

   1. Remove the route to the IP address 100.64.0.0/10 from your Split Tunnel exclude list.

   2. We recommend adding back the IPs that are not being used for Zero Trust services. For example, if you are using initial resolved IPs alongside WARP-to-WARP connectivity, add routes to exclude the following IP addresses:

      • 100.64.0.0/12
      • 100.81.0.0/16
      • 100.82.0.0/15
      • 100.84.0.0/14
      • 100.88.0.0/13
      • 100.112.0.0/12
   Include IPs and domains
   1. Add the required Zero Trust domains or IP addresses to your Split Tunnel include list.
   2. Add routes to include the following IP addresses:
      • IPv4: 100.80.0.0/16
      • IPv6: 2606:4700:0cf1:4000::/64
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 initial resolved IP 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 initial resolved IP 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 Cloudflare One ↗ and go to Networks > Connectors > Cloudflare 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 Cloudflare One.

   

8. Select Next.

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

   Hostname format restrictions

   • Character limit: Must be less than 255 characters.
   • Supported wildcards: A single wildcard (*) is allowed, and it must represent a full DNS label. Examples: *.internal.local, foo.*.internal.local
   • Unsupported wildcards: The following wildcard formats are not supported:
     • Partial wildcards such as *-dev.internal.local or dev-*.internal.local.
     • Wildcards in the middle of a label, such as foo*bar.internal.local.
     • Multiple wildcards in the hostname, such as *.*.internal.local.
   • Wildcard trimming: Leading wildcards (*) are trimmed off and an implicit dot (.) is assumed. For example, *.internal.local is saved as internal.local but will match all subdomains at the wildcard level (covers foo.internal.local but not foo.bar.internal.local).
   • Dot trimming: Leading and ending dots (.) are allowed but trimmed off.

10. Select Complete setup.

2. Configure DNS resolution

When Gateway receives a request for your private hostname, it must resolve the hostname to a private IP address. There are two ways to configure this, depending on your network topology.

Scenario A: Use the system resolver (Default)

By default, cloudflared uses the private DNS resolver configured on its host machine (for example, in /etc/resolv.conf on Linux).

If the machine running cloudflared can already resolve wiki.internal.local to its private IP using the local system resolver, no further configuration is required. You can skip to Step 3.

Scenario B: Use a specific private DNS server (Advanced)

If you need cloudflared to use a specific internal DNS server that is different from the host's default resolver (for example, if you are routing DNS traffic through a separate tunnel for split-horizon DNS), you must explicitly connect that DNS server to Cloudflare via an IP/CIDR route. You will also need to configure a Gateway resolver policy to route queries to this specific private DNS server.

1. To create an IP/CIDR route for the DNS server:

   1. Go to Networks > Routes > CIDR.
   2. Select Create CIDR route.
   3. Enter the private IP address of your internal DNS resolver.
   4. Select the Cloudflare Tunnel that connects to the network where this DNS server resides.
   5. Select Create route.

2. To create a resolver policy:

   1. Go to Gateway > Resolver policies.
   2. Select Create a policy.
   3. Create an expression that matches the private hostname:

      Selector	Operator	Value
      Host	in	wiki.internal.local

   4. Under Configure custom DNS resolvers, enter the private IP address of your internal DNS server.
   5. From the dropdown menu, select the - Private routing option and the virtual network assigned to the tunnel you selected in the previous step.
   6. Select Create policy.

3. (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 Traffic policies > Traffic settings.
2. In Proxy and inspection, turn on Allow Secure Web Gateway to proxy traffic.
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 Gateway block policy for your private IP space. You can then layer on higher priority Allow policies (in either Access or Gateway) which grant users access to specific applications or IPs.

Option 1: Access application (recommended)

You can create an Access self-hosted application for your private hostname and configure Access policies within that application. This option allows you to manage user access alongside your SaaS and other web apps.

Option 2: Gateway firewall policies

If you prefer to secure the application using a traditional firewall model, you can 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

SNI selector limitations

By default, SNI selectors only apply to HTTPS traffic on port 443. To inspect traffic on every port, turn on protocol detection and choose to inspect on all ports.

Additionally, SNI selectors will only apply to WARP client traffic. If your users will be connecting from other on-ramps, you can allow or block network traffic using the Destination IP selector instead of SNI.

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

   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.

2. 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](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.