Is macOS WARP client working for anyone with split tunnel configuration?

I’ve configured WARP client configurations (default WARP mode) using the include rules (private subnets and domains with no overlap with local devices) for split tunnel.

It works as expected for iOS and Linux clients. But on my mac (m1) using the current release (2022.12.593.0 (20230118.6)), whenever I toggled the protect switch, all http/https access with domain names (not just “included” domains) stops working completely. Explicit IP access to my included subnets actually work! The UI said “Your DNS queries and included routes are protected”.

When the switch is on in the preference general tab shows:
Connection: NA
DNS protocol: off
Colocation center:
Public IP:

I’ve tried the “beta” build (2023.3.165.1 (2023314.13)), which fails to even to connect (UI: Unabled to Connect, Connectivity check failed) when I toggle the switch, in WARP mode.

I also tried “Proxy” mode (DNS off, routes protected, beta build connects fine), where the UI displays “Proxied traffic is protected”, which seems to work as expected if I use localhost:40000 as the SOCKS v5 proxy in clients. iOS client however insists to be in WARP mode.

I guess that we’ll just use the proxy mode with a little more hassle (mitigated with browse extensions like SwitchyOmega) then.

I’m also experiencing issues with the warp client and split tunnels in include mode on macOS. It ends up stuck in state “Connecting”. Restarting the warp service with sudo launchctl kickstart -k system/com.cloudflare.1dot1dot1dot1.macos.warp.daemon kicks it back into a good state.

Logs in /Library/Application Support/Cloudflare/cfwarp_service_log.txt indicates that when it reconnects it almost immediately ends up in a conn_error state, without recovering.

2023-03-17T10:34:53.780Z DEBUG main_loop: warp::warp_service: Entering main loop arm arm="status_change"
2023-03-17T10:34:53.780Z  INFO main_loop: warp::warp_service: WARP status: Connecting
2023-03-17T10:34:53.780Z DEBUG main_loop: warp::warp_service::ipc_handlers: Sending IPC status update: Connecting
2023-03-17T10:34:53.780Z DEBUG main_loop: warp::warp_service::ipc_handlers: Ipc Broadcast ResponseStatus: Connecting
2023-03-17T10:34:53.780Z DEBUG main_loop: warp::warp_service: Entering main loop arm arm="conn_error"
  • Which Cloudflare specific domains and IPs do you have in your include rules?

Following the split tunnel docs, reading the logs and a few posts on community.cloudflare.com I have the following domains in the split tunnel include list:

*.cloudflareaccess.com
*.clouflareclient.com
*.cloudflare-gateway.com
edge.browser.run

Could this simply be buggy behaviour on macOS or are the rules not up to date you think? Its simple to reproduce by first restarting the daemon, then manually toggling the switch which puts warp in an endless connecting state.

According to the docs, CF domains should be on the exclude list, which is also one of the reasons to use the include mode for private domains/CIDRs. The fact iOS and Linux clients work fine should indicate CF side configure appears to be correct.

You mean the CF domains should be omitted from the include list, or is it possible to set exclude and include rules simultaneously? How do you set that up, can you use multiple policies applied to the same client? I am also seeing linux clients getting stuck in the same disconnect loop.

Yes. Include list would only contain your remote private domains and CIDRs. The include mode implies that everything else is excluded.

Happy to report the latest macOS beta build ( 2023.3.267.1 (20230322.12)) is working as expected in the WARP mode!