CDN HTTP/3 Slower or Unreachable for Some Users? Troubleshooting QUIC, UDP 443, and Fallback

After HTTP/3 is enabled on a CDN, most visitors may see no problem while a smaller group reports slow first loads, connection timeouts, or a site that does not open at all. These failures usually involve the UDP 443 path used by QUIC, HTTP/3 discovery information, cached browser state, or an incomplete HTTP/2 fallback path.

The first step is to confirm whether the affected request actually uses h3 or h2. Then determine whether the fault sits at the CDN edge, on the client network, or in the UDP configuration of a self-hosted HTTP/3 server.

Confirm That the Failure Is Specific to HTTP/3

HTTP/3 carries HTTP semantics over QUIC, and QUIC normally uses UDP. This is a different transport path from HTTP/2 over TCP. A network that permits TCP 443 does not necessarily permit UDP 443.

Run two tests against the same hostname from the same device. The local curl build must support HTTP/3, so check it first:

curl -V

If the output includes HTTP3, compare HTTP/3 and HTTP/2:

curl --http3 -sS -o /dev/null -D - \
  -w 'http_version=%{http_version}\n' \
  https://www.example.com/

curl --http2 -sS -o /dev/null -D - \
  -w 'http_version=%{http_version}\n' \
  https://www.example.com/

The --http3 option allows curl to fall back when HTTP/3 is unavailable, which resembles the behavior of a normal client. To test whether a connection can succeed using HTTP/3 alone, use:

curl --http3-only -I https://www.example.com/

If HTTP/2 works but --http3-only fails, the likely scope has narrowed to QUIC, UDP 443, HTTP/3 discovery, or client support. If both protocols fail, continue checking DNS, certificates, hostname bindings, CDN configuration, and origin health instead of assigning the entire incident to HTTP/3.

A browser can provide another useful signal. Open Developer Tools, show the Protocol column in the Network panel, reload the page, and inspect whether the main document and static resources use h3, h2, or http/1.1. A control-panel switch that says HTTP/3 is enabled does not prove that a particular request used h3.

When Only Some Networks Fail, Check UDP 443

A site that works on home broadband but fails on corporate Wi-Fi, a campus network, or a VPN often has a UDP path problem. Enterprise firewalls, VPN gateways, guest networks, carrier equipment, and older NAT devices may drop, rate-limit, or mishandle UDP 443.

When a QUIC packet receives no response, a browser may wait before retrying over HTTP/2 on TCP 443. The visitor experiences that delay as a slow first request even though the eventual fallback succeeds.

Retest from the same device through home broadband, a mobile hotspot, the affected corporate network, and a VPN. If the problem appears and disappears as the network changes, the browser and application code are usually not the first suspects. Review egress firewall policy, web access controls, VPN split-tunneling rules, and UDP session timeout settings.

Treat a UDP port scan only as a clue. QUIC does not perform a TCP-style three-way handshake, and some scanners report a silent result as open|filtered. More useful evidence comes from real HTTP/3 requests, CDN edge logs, packet captures, and comparisons across multiple networks.

Managed CDN and Self-Hosted HTTP/3 Require Different Checks

With a managed CDN, HTTP/3 normally terminates at the CDN edge. Visitors connect to the edge over QUIC, while the CDN may still connect to the origin over HTTP/2 or HTTP/1.1. Opening UDP 443 in the origin security group usually does not fix a visitor-side HTTP/3 failure and can unnecessarily expand the origin's exposure.

For a managed CDN, verify:

HTTP/3 is active for the exact hostname and distribution configuration in use.
The certificate, SNI configuration, and hostname binding cover that hostname.
The edge still serves HTTP/2 or HTTP/1.1 over TCP 443.
Edge monitoring shows no abnormal UDP traffic, QUIC handshake failures, or fallback behavior.
Recent changes have propagated to all relevant edge locations.

If Nginx, Caddy, Envoy, HAProxy, or another gateway terminates HTTP/3 directly on your own server, the scope also includes cloud security groups, the host firewall, load balancers, NAT, and container port mappings. TCP 443 and UDP 443 are separate rules; allowing one does not allow the other. Save the current rule set before changing it, restrict access to the hosts that actually provide the service, and do not replace precise rules with a blanket allow for all UDP traffic.

Check Alt-Svc and DNS HTTPS Records Advertising h3

Clients need a way to discover that a site supports HTTP/3. Common methods include an Alt-Svc response header and protocol parameters in DNS HTTPS records. For example, an HTTP/2 response may include:

Alt-Svc: h3=:443; ma=86400

The ma value controls how long the alternative service information can be cached. If HTTP/3 has been disabled but the site keeps advertising h3, or if clients retain an older Alt-Svc entry, they may repeatedly try an unreachable QUIC endpoint. The reverse can also happen: the CDN dashboard shows HTTP/3 as enabled, but the response and DNS records do not advertise a usable h3 service, so clients continue using h2.

Start with a known-good HTTP/2 request, save the complete response headers, and inspect Alt-Svc:

curl --http2 -sS -D - -o /dev/null https://www.example.com/

Query the hostname's HTTPS record as well. Check whether alpn, the target hostname, and the port match the current deployment:

dig HTTPS example.com

When changing an HTTP/3 port, edge hostname, or DNS configuration, account for the lifetime of old advertisements. If HTTP/3 must be disabled temporarily, stop publishing the invalid h3 endpoint while keeping TCP 443 available. Changing only the server listener, without correcting Alt-Svc or the HTTPS record, can leave clients trying the old route until cached information expires.

An Incomplete Fallback Turns a Delay Into an Outage

A normal deployment should provide HTTP/3 alongside HTTP/2 or HTTP/1.1 over TCP. When UDP 443 is blocked, the client should still be able to complete the request over TCP 443. HTTP/3 can be the preferred route, but it should not be the site's only usable transport.

If affected users cannot open the site at all, check for these conditions:

TCP 443 was closed accidentally, leaving only UDP 443.
HTTP/2 and HTTP/1.1 were disabled at the edge.
TCP and UDP point to different load balancers, and one path has stale configuration.
The two paths use different certificates, SNI settings, or virtual host configuration.
A firewall silently drops UDP, significantly extending the client's fallback delay.
The primary hostname can fall back, but a required API, font, image, or third-party subdomain has no working TCP path.

During recovery, you can temporarily stop advertising h3 so that new connections consistently use h2. Preserve the current configuration so it can be rolled back. After confirming that the TCP path is healthy, repair UDP 443 and re-enable HTTP/3 gradually. Do not hide a protocol configuration problem by disabling TLS verification or opening every firewall rule.

Validate the Fix Across Protocols and Networks

One successful page load is not enough to close the incident. Keep evidence for at least these four checks:

An HTTP/3-only request succeeds and reports HTTP/3 as the negotiated protocol.
An HTTP/2 request succeeds with the expected certificate, status code, and content.
A test network where UDP 443 is restricted can still load the site over h2.
Home broadband, a mobile hotspot, the affected corporate network, and a VPN no longer show an obvious first-connection timeout.

Test the main document, important APIs, and critical static resources rather than checking only the home page. Browser developer tools, curl output, CDN edge logs, and firewall logs should support the same conclusion.

For ongoing monitoring, separate h3 and h2 request volume, handshake failures, connection setup time, and fallback rates. Enabling HTTP/3 is not itself proof of an optimization. UDP 443 must be reachable, h3 discovery information must be accurate, and the TCP 443 fallback must remain healthy. All three conditions are necessary to prevent a transport upgrade from locking a small group of users out of the site.

References

IETF RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
IETF RFC 9114: HTTP/3
IETF RFC 9460: Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)
curl documentation: HTTP/3
Cloudflare Developers: HTTP/3 (with QUIC)

Sources verified on September 30, 2026.