Skip to content
Cloudflare Docs

Host selectors

Feature availability
WARP modesZero Trust plans ↗
Traffic and DNS modeEnterprise
SystemAvailabilityMinimum 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

When Gateway receives a DNS query for hostname covered by the Application, Content Categories, Domain, and Host selectors in an Egress policy, Gateway initially resolves DNS to an IP in the 100.80.0.0/16 or 2606:4700:0cf1:4000::/64 range. This process allows Gateway to map a destination IP with a hostname at layer 4 ↗ (where Gateway evaluates Egress policies). The destination IP for a hostname is not usually known at layer 4. Prior to evaluating Egress policies, the initially resolved IP is overwritten with the correct destination IP.

Example egress policy flow

Additional configuration is required when using policies with these selectors.

Turn on Host selectors

To turn on the selectors for your account:

  1. In Cloudflare One ↗, go to Traffic policies > Traffic settings.
  2. In Policy settings, turn on Allow egress policy host selectors.

Prerequisites

Traffic must be on-ramped to Gateway with the following methods:

On-ramp methodCompatibility
WARP✅
PAC files✅
Browser Isolation✅
WARP Connector❌
Cloudflare WAN✅

Unsupported traffic will be resolved with your default Gateway settings. If you use DNS locations to send a DNS query to Gateway with IPv4, IPv6, DoT, or DoH, Gateway will not return the initial resolved IP for supported traffic nor resolve unsupported traffic.

Configuration changes

To configure your Zero Trust organization to use Host selectors with Egress policies:

  1. Make sure you deploy the following version of WARP on your users' devices:

    If you need to support devices running prior versions of WARP, add and deploy the following key-value pair to your devices' WARP configuration file (mdm.xml on Windows and Linux or com.cloudflare.warp.plist on macOS):

    <array>
      <dict>
        <key>doh_in_tunnel</key>
        <true/>
      </dict>
    </array>

  1. In your WARP device profile, configure Split Tunnels such that the initial resolved IPs route through the WARP tunnel. Configuration depends on your Split Tunnels mode:

    • Exclude mode: Delete 100.64.0.0/10 from your Split Tunnels list. We recommend adding back the IP ranges that are not explicitly used for Cloudflare One services. This reduces the risk of conflicts with existing private network configurations that may use the CGNAT address space.
    • Include mode: Add Split Tunnel entries for the following IP addresses:
      • IPv4: 100.80.0.0/16
      • IPv6: 2606:4700:0cf1:4000::/64

The WARP client must be set to Traffic and DNS mode mode for traffic affected by these selectors to route correctly.

Known issues

Google Chrome restricts local network access

Starting with Chrome 142 ↗, the browser restricts requests from websites to local IP addresses, including the Gateway initial resolved IP CGNAT range (100.80.0.0/16). Because this range falls within 100.64.0.0/10, Chrome categorizes these addresses as belonging to a local network. When a website loaded from a public IP makes subrequests to a domain resolved through an initial resolved IP, Chrome treats this as a public-to-local network request and displays a prompt asking the user to allow access to devices on the local network. Chrome will block requests to these domains until the user accepts this prompt.

This commonly occurs when an Egress policy matches broadly used domains (such as cloudfront.net or github.com), causing subrequests from public pages to resolve to the 100.80.0.0/16 range.

Iframes

If the affected request originates from within an iframe (for example, an application embedded in a third-party portal), the iframe must declare the local-network-access permission for the browser prompt to appear in the parent frame:

  • Chrome 142-144: Use the allow="local-network-access" attribute on the iframe element.
  • Chrome 145+: The permission was split into allow="local-network" and allow="loopback-network".

If iframes are nested, every iframe in the chain must include the appropriate attribute. Since third-party applications control their own iframe attributes, this may not be configurable by the end user.

Workarounds

To avoid this issue, choose one of the following options:

  • Override IP address space classification (Chrome 146+): Use the LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome Enterprise policy to reclassify the 100.80.0.0/16 range as public. This is the most targeted fix because it only changes the classification for the initial resolved IP range rather than disabling security checks entirely.
  • Allow specific URLs (Chrome 140+): Use the LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise policy to exempt specific websites from Local Network Access checks. Note that https://* is a valid entry to disable checks for all URLs.
  • Allow specific URLs (Chrome 146+): Use the LocalNetworkAllowedForUrls ↗ Chrome Enterprise policy, which replaces LocalNetworkAccessAllowedForUrls starting in Chrome 146.
  • Opt out of Local Network Access restrictions (Chrome 142-152): Use the LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise policy to completely opt out of Local Network Access restrictions. This is a temporary policy and will be removed after Chrome 152.
  • Disable the Chrome feature flag: Go to chrome://flags and set the Local Network Access Checks flag to Disabled. This approach is suitable for individual users but not for enterprise-wide deployment.