Cloudflare Tunnel · Private DNS · Help

WARP: private DNS stops responding through the tunnel

Separate resolver reachability, DNS policy and UDP/TCP behaviour when WARP can no longer resolve internal names.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

A working SSH connection over WARP does not confirm a working DNS path. Query the same internal name at the intended resolver from both the connector environment and WARP client, separating UDP, TCP and normal system resolution. If only a direct resolver query works, investigate resolver selection next. Forcing HTTP/2 is not an equivalent replacement when the required traffic includes UDP.

Source basis: Q1 · Q2

Applies to
Covers private DNS resolvers reached through WARP and Cloudflare Tunnel. The 2026.9.3 versus 2026.5.0 comparison is an individual report, not a general outage finding.
How to verify the result
Direct resolver queries and normal name resolution return the expected answers, the application reaches its internal destination, and required UDP and TCP paths are verified.
Your first check

Does the same resolver answer the connector and the WARP device?

Query the same internal name at the intended resolver from both network contexts. Compare UDP and TCP separately.

Internal applications work by IP address, but their names no longer resolve on a WARP device. UDP DNS requests time out, or TCP requests are reset. A corresponding report names cloudflared 2026.9.3 and an earlier working version. That provides a useful comparison hypothesis, not proof of a universal defect in current installations. Q1

Why working SSH does not verify DNS

Reaching another service port does not verify the DNS listener or its policies. Private name resolution depends on the resolver route, name-selection rule and transport. Cloudflare documents these requirements, including QUIC for UDP traffic. Q2 Investigate a complete DNS exchange rather than relying on the tunnel's green status alone.

Compare the relevant paths

  1. Choose a known internal test name. Use a non-sensitive record with a predictable answer. Record the resolver IP and query type. A randomly nonexistent name would mix a normal negative response with the connectivity problem you are investigating.
  2. Start at the connector. Query the resolver from the network or container where cloudflared actually runs. If this already fails, begin with the DNS service, local route and access rules before investigating the client-side policy.
  3. Test the WARP client directly. Ask the same resolver the same question from the affected device. Repeat with TCP, using the DNS tool's appropriate option. A UDP timeout and TCP reset are separate findings and should remain separate in your notes.
  4. Compare ordinary resolution. Repeat without specifying a resolver address. If direct queries work but ordinary lookups do not, inspect the applicable resolver policy or Local Domain Fallback configuration and the domain scope it matches.
  5. Correlate policy and transport. Check the resolver-IP route, Split Tunnel exclusions, applied network rules and the tunnel's actual connected protocol. An HTTP/2 experiment for a web-only application is not equivalent to an experiment for a route that needs UDP DNS. Q2

Make an update comparison reproducible

Record connector and WARP versions, operating systems and startup parameters. A limited comparison using an approved test instance can examine a version-related hypothesis. Keep resolver configuration and policy unchanged during that comparison; otherwise, a successful outcome will not identify which change mattered.

For handoff, prepare the comparison results, precise timestamps and relevant policy logs. Redact internal names consistently where necessary, preserving which observations concern the same name. After a correction, verify direct queries, ordinary name resolution and actual application access. All three provide different evidence about the repaired path.

Frequently asked questions

Can DNS fail while the tunnel is Healthy?

Yes. That status does not automatically verify every private route and resolver policy.

Should I simply replace UDP with TCP?

A TCP comparison is useful evidence. It does not by itself replace the transports required by your intended DNS setup.

Describe your case

Support with this issue

We can inspect resolver routing, WARP policies and connector behaviour with controlled DNS queries.

Describe your case →Related service: Data & improvements

Sources