Cloudflare Tunnel · QUIC · Help

cloudflared: QUIC CRYPTO_ERROR 0x178 without fallback

Distinguish UDP reachability from a successful QUIC handshake and run a limited HTTP/2 comparison where appropriate.

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

Quick answer

In the documented case, “CRYPTO_ERROR 0x178” with “no application protocol” occurs during QUIC setup between the connector and Cloudflare. An accessible UDP port does not prove a successful handshake. Check actual connection registration and compare only permitted network paths. A limited HTTP/2 comparison may help diagnosis, but does not replace verification of required services or provide an equivalent transport for required UDP traffic.

Source basis: Q1 · Q2 · Q3

Applies to
Covers connector-to-Cloudflare transport. The report concerns cloudflared 2026.7.2 on macOS; its missing automatic fallback was not established as a universal behavior.
How to verify the result
The tunnel connection registers successfully and carries the affected application request, while all required transport types and other affected routes remain usable.
Your first check

Is a tunnel connection registered, or does QUIC only keep retrying?

Look for successful registration in the same interval as CRYPTO_ERROR 0x178. A passing UDP precheck does not establish a completed handshake.

cloudflared repeatedly attempts QUIC and logs CRYPTO_ERROR 0x178 with tls: no application protocol. Even with --protocol auto, no usable connection appears. The original report describes this on a particular macOS installation. It does not establish that all QUIC errors share one cause or that every version fails to fall back automatically. Q1

Distinguish reachability from negotiation

A UDP reachability check and a completed QUIC handshake are different observations. Cloudflare documents auto, quic and http2 as transport choices between the connector and Cloudflare. Q2 This setting is separate from whether the connector uses HTTP/2 to contact your origin service.

Run an interpretable comparison

  1. Capture the first failure. Record cloudflared version, operating system, startup parameters and time. Look for an actual registered connection, rather than treating repeated retry lines as progress. Remove tunnel tokens before sharing logs.
  2. Identify network changes. Check recent changes to a VPN, corporate firewall, security product or network connection. A comparison over another approved network may reveal whether the failure is tied to a particular path.
  3. List required tunnel functions. Establish which services the tunnel carries. Private UDP services have different requirements from a published HTTP application. Cloudflare documents QUIC as necessary for UDP transport. Q3
  4. Plan a limited HTTP/2 test. Where the required functions allow it, use a separate or controlled test instance with the documented transport setting. Keep the origin, hostname and access controls unchanged. Observe both registration and a harmless application request.
  5. Interpret the result cautiously. HTTP/2 success under otherwise identical conditions narrows the failure to the QUIC path. It does not identify which network device or implementation rejected the handshake. If both transports fail, investigate shared requirements such as DNS and outbound connectivity.

Turn the test into an operational decision

A working alternative transport may provide a limited operating option if it supports all required functions. Review effects on other routes before making it permanent. Treat a version change as another controlled comparison; a report from somebody else's installation is not sufficient reason to run an arbitrary older version indefinitely.

For handoff, prepare sanitised startup logs, results for both transports, any network comparison and the service types that must remain supported. After a change, verify the tunnel connection and the actual application. A running process alone does not establish that users can reach their service.

Frequently asked questions

Why is a passing UDP test insufficient?

It does not establish that the subsequent protocol negotiation completes successfully.

Can I always force http2?

Only after reviewing the tunnel's required functions. Needed UDP traffic can make that an unsuitable replacement.

Describe your case

Support with this issue

We can investigate tunnel transport, the network path and a bounded protocol comparison.

Describe your case →Related service: Data & improvements

Sources