Cloudflare WARP / One Client diagnosis — reading the diagnostic bundle

Transcribed from a training slide shown on 2026-09-29: a suggested order for working through the files in a Cloudflare One Client (WARP) diagnostic bundle. Words in [square brackets] were obscured on the photographed slide and have been reconstructed.

Reading order

1. In the daemon.log file, find the second-to-last "initialize connection" event. Why second-to-last? Because when users report a pro[blem], they almost always toggle the client off and back on before calling support, so the very last initialization is that toggle. The second-to-la[st is the] initialization that was running when the problem actually occurred.
2. From that initialization event, walk backwards through the tunnel's story: DNS initialization, tunnel initialization, protocol handshake, posture check. Each of these steps is logged with timestamps, and if any of them failed or timed out, you'll see the error inline. This reading order, from the initialization backwards, gives you the "story of the tunnel" in the order things actually happened.
3. If DNS resolution is the suspected problem, switch to the daemon_dns.log file. This shows every DNS query the local proxy handled, including failures and timeouts. Cross-reference the timestamps with what you saw in daemon.log to confirm whether the DNS proxy was running and resolving correctly during the time window of the reported issue.
4. Check the warp-settings file. This confirms the active mode, protocol (MASQUE or WireGuard), split-tunnel configuration, and profile ID. If a customer says "I'm on Gateway with WARP" but the warp-settings file says proxy mode, the Managed Network detection switched the profile and the customer doesn't know it.
5. Check bound-dns-ports.txt. This shows which process is binding port 53 on the device. If it says mDNSResponder (common on macOS) or AnyConnect, that's your DNS conflict, because the Cloudflare One Client couldn't bind its DNS proxy since another process got there first.
6. Check local-policy-redacted. This is the active MDM file content, and it tells you whether the MDM's overriding dashboard settings. If the customer changed something in the dashboard and it's not taking effect, this file shows you why.
7. Check alternate-networks. This shows the Managed Network / TLS endpoint detection state, so you can confirm whether the device thinks it's in the office or remote and which profile it switched to.
8. Check connectivity.txt. This file runs reachability tests against engageclientcloudflare.com both inside the tunnel and outside the tunnel. If the inside-tunnel check fails but the outside-tunnel check succeeds, the tunnel is not passing traffic even though the internet's working, and if both fail, the device has no internet connectivity at all.

Transcription notes

• Item 8's hostname is transcribed as shown on the slide (engageclientcloudflare.com). Cloudflare's documented connectivity-check host is usually written engage.cloudflareclient.com — verify against the actual connectivity.txt before relying on it.

Related

• Cloudflare One and SASE fundamentals — background, including a link to Cloudflare's WARP overview course.

• INFORMATION — parent index.