region2.v2.argotunnel.com UDP FAIL: QUIC Connection Failed

UDP Connectivity region2.v2.argotunnel.com FAIL QUIC connection failed means cloudflared’s startup pre-check could not finish a QUIC handshake over outbound UDP port 7844 to Cloudflare’s region2 edge. It is not fatal if the TCP row passes: the tunnel runs on HTTP/2 instead. Fix it by allowing UDP/7844 egress, or pin --protocol http2.

The line comes from the connectivity pre-check that cloudflared 2026.5.2 moved into the binary. It runs on every cloudflared tunnel run and cloudflared tunnel diag, checks DNS for the region1 and region2 endpoints, tests UDP (QUIC) and TCP (HTTP/2) on port 7844, checks the management API on TCP/443, and prints each result as Pass, Warn or Fail. The connector exits early only when DNS cannot resolve or when both UDP and TCP fail. One FAIL on a UDP row is a degraded tunnel, not a dead one.

What does the full pre-check table tell you?

Read the TCP row for the same region before you change anything. If TCP/7844 passes and UDP/7844 fails, the tunnel comes up over HTTP/2 and public hostnames keep working; you lost QUIC, not the tunnel. If both fail, cloudflared exits and, unless another replica is connected, hostnames behind it return an error 1033.

A community report from an Oracle Cloud deployment shows the degraded pattern, there on region1:

UDP Connectivity region1.v2.argotunnel.com FAIL QUIC connection failed
TCP Connectivity region1.v2.argotunnel.com PASS HTTP/2 connection successful
SUMMARY: Environment ready with degraded transport. cloudflared will proceed using 'http2'.

Cloudflare’s connectivity pre-checks guide maps the four combinations:

Why would only region2 fail?

When region1 passes and region2 fails, your egress path works and your allow-list is incomplete. The regions use different address blocks: region1 resolves to 198.41.192.x addresses and 2606:4700:a0::1 through ::10, region2 to 198.41.200.x and 2606:4700:a8::1 through ::10, per Cloudflare’s firewall reference. An alias built from one dig result, or one that only covers 198.41.192.0/24, passes half the check.

The second pattern is FQDN-based filtering. In cloudflared issue #922, tunnels behind VMware NSX-T FQDN rules degraded over time with dial tcp 198.41.200.233:7844: i/o timeout, a region2 address. The firewall’s learned IP set aged out with DNS TTLs; a manual nslookup or a service restart brought the tunnel back. For 20 published IPv4 addresses, a static IP alias is more predictable than a hostname object.

The third pattern is address family. cloudflared defaults to IPv4, per the run parameters reference. If someone set --edge-ip-version 6 or auto on a host whose IPv6 egress rules only cover TCP, UDP fails over v6 while the v4 rules you are reading look fine.

What else blocks QUIC on UDP/7844?

A plain deny on outbound UDP is the usual cause; after that come application-aware firewalls, SNI enforcement and a path MTU too small for QUIC’s 1200-byte Initial packets. RFC 9308, Applicability of the QUIC Transport Protocol, cites measurement studies showing 3% to 5% of networks block all UDP, and tells QUIC applications to either accept failure or fall back to TCP. Check these:

• Default-deny egress on a server VLAN. On OPNsense or pfSense, a rule set that passes TCP out but UDP only to 53 and 123 kills QUIC silently. A Kubernetes NetworkPolicy whose egress entry lists only protocol: TCP on port 7844 does the same thing inside the cluster.
• Application-aware firewalls. Cloudflare’s troubleshooting page documents that Palo Alto Networks App-ID database version 9128, released July 27, 2026, changed what is needed to permit tunnel traffic. The fix is a custom UDP/7844 service (Cloudflare names it cloudflared_7844_udp) plus a rule allowing both cloudflare-warp and quic-base, or temporarily reverting to App-ID 9127. Any app-control engine that classifies and blocks QUIC can produce the same symptom.
• SNI enforcement. If the firewall inspects SNI, allow quic.cftunnel.com, h2.cftunnel.com, cftunnel.com and _v2-origintunneld._tcp.argotunnel.com on 7844.
• Path MTU below QUIC’s floor. RFC 9000 requires clients to pad Initial packets to a UDP payload of at least 1200 bytes and says QUIC must not be used on a path that cannot carry that. A host behind stacked tunnels (WireGuard inside PPPoE inside a provider overlay) can fail the handshake while TCP, whose MSS can be clamped, still connects.

How do you test UDP/7844 from the connector host?

Run every test from the host or container that runs cloudflared, not from your laptop on another VLAN. Resolve region2 with two resolvers, probe 198.41.200.13 on UDP and TCP 7844, trace the UDP path with mtr, confirm a 1228-byte packet leaves unfragmented, then rerun cloudflared tunnel diag.

# DNS: both resolvers should return 198.41.200.x addresses
dig +short A region2.v2.argotunnel.com
nslookup region2.v2.argotunnel.com 1.1.1.1

# UDP and TCP probes against a documented region2 address
nc -uvz -w 3 198.41.200.13 7844
nc -vz -w 3 198.41.200.13 7844

# Where do UDP/7844 packets stop?
mtr -u -P 7844 -r -c 20 198.41.200.13

# Does a 1228-byte IPv4 packet leave unfragmented? (1200 + 8 ICMP + 20 IP)
ping -M do -s 1200 -c 3 1.1.1.1

# Rerun cloudflared's built-in pre-checks
cloudflared tunnel diag

Treat nc -u with suspicion. UDP has no handshake, so “succeeded” usually means nothing sent back an ICMP rejection within three seconds, and a firewall that drops silently looks identical. The pre-check’s QUIC row is a real handshake and the better signal. For ground truth, run sudo tcpdump -ni any udp port 7844 while cloudflared starts. Outbound packets with no replies from 198.41.200.x mean the drop sits upstream of the host.

Then read the connector’s log. If you installed it as a service following the Ubuntu systemd setup, run journalctl -u cloudflared -b | grep -Ei "initial protocol|quic|fallback". Cloudflare’s troubleshooting page says a UDP block produces failed to dial to edge with quic: timeout: handshake did not complete in time, retries with backoff of 2, 4, 8, 16, 32 and up to 64 seconds, then logs Switching to fallback protocol http2.

Ignore failed to sufficiently increase receive buffer size here. Cloudflare says it can be safely ignored, and raising net.core.rmem_max is a throughput tune, not a connectivity fix.

What egress rules does cloudflared actually need?

Outbound UDP/7844 and TCP/7844 to the 20 documented region1 and region2 IPv4 addresses, plus optional TCP/443 for the management API and updates, all placed above any broad UDP block on the connector’s interface. Example for a connector at 10.20.0.15 on a server VLAN, with an alias CF_TUNNEL_V4 holding those addresses:

The pfSense rule methodology is explicit that rules are processed until a match is found, and that floating rules are evaluated before interface rules. A floating “block UDP except DNS and NTP” rule therefore shadows rule 1 no matter how correct rule 1 is. If you run IPv6 egress, mirror rules 1 and 2 for the 2606:4700:a0:: and 2606:4700:a8:: addresses.

Should you just pin --protocol http2?

Pin HTTP/2 when UDP egress is out of your control and you only publish HTTP hostnames. Keep QUIC whenever you can open UDP/7844: Cloudflare’s troubleshooting docs recommend QUIC for performance, and two features depend on it.

What you give up on HTTP/2:

• Private network UDP. Cloudflare’s private DNS guide says the tunnel must use QUIC so cloudflared can proxy UDP traffic, which resolving DNS requires in most cases. If WARP clients resolve private names through the tunnel, HTTP/2 can break that resolution.
• Post-quantum key agreement. The run parameters reference states post-quantum key agreements are not supported over http2.
• Startup time. On auto, a blocked UDP path burns through the backoff sequence before the fallback kicks in.

Do not rely on the SUMMARY line’s promise. The Oracle Cloud report above found the connector kept retrying QUIC after the pre-check said it would proceed with HTTP/2. Pin the protocol in whichever layer launches the connector:

# CLI: tunnel-level flags go before "run"
cloudflared tunnel --protocol http2 run <UUID or NAME>

# systemd drop-in, via: sudo systemctl edit cloudflared
[Service]
Environment=TUNNEL_TRANSPORT_PROTOCOL=http2

# config.yml for a locally managed tunnel
protocol: http2

HTTP/2 still needs outbound TCP/7844. When UDP opens later, remove the pin; a forgotten http2 is how private DNS breaks six months after the firewall ticket closed. If you are building the connector from scratch, the first tunnel walkthrough covers the prerequisites and both setup paths.

FAQ

which ip addresses does region2.v2.argotunnel.com resolve to

Cloudflare documents ten IPv4 addresses for region2: 198.41.200.13, .193, .33, .233, .53, .63, .113, .73, .43 and .23. The IPv6 set is 2606:4700:a8::1 through 2606:4700:a8::10. All use port 7844 over UDP for QUIC and TCP for HTTP/2. Region1 sits separately in 198.41.192.x, so an allow-list needs both blocks.

how do i force cloudflared to use http2 in docker

Pass the environment variable TUNNEL_TRANSPORT_PROTOCOL=http2 to the container, for example with -e on docker run or under environment: in Compose. Alternatively, put --protocol http2 before run in the container command. Restart the container, then confirm the log no longer shows repeated QUIC dial attempts.

why does the cloudflared precheck pass but quic still disconnects

A pass only proves the handshake worked at startup. In cloudflared issue #1728, an Azure Container Apps deployment passed both UDP rows, then saw established QUIC connections drop with “timeout: no recent network activity.” Idle UDP state timeouts on NAT or platform load balancers are worth checking; the issue lists no confirmed fix.

can cloudflare tunnel use port 443 instead of 7844

No, Cloudflare documents port 7844 as the tunnel transport port for both QUIC and HTTP/2. Outbound 443 is optional, used for software updates, the management API, Access token validation and post-quantum reporting. A network that only permits 443 outbound has no documented way to carry the tunnel, so request a 7844 exception.

Related across the network

• OPNsense WireGuard Setup Problems: Handshake, NAT, MTU — opnsenserouter.com
• How to Set Up WireGuard VPN on pfSense: Step-by-Step Guide — pfsenselab.com