ERR_QUIC_PROTOCOL_ERROR: How to Fix the HTTP/3 (QUIC) Error

ERR_QUIC_PROTOCOL_ERROR is Chromium net error -356, "There is a QUIC protocol error." QUIC (RFC 9000) is the UDP-based transport under HTTP/3 (RFC 9114), with TLS 1.3 built into its handshake. Chrome learns that a site offers HTTP/3 from an Alt-Svc: h3=":443" response header, then races QUIC against a normal TCP connection on later requests.

Chrome hides most QUIC failures. If the QUIC session fails before response headers arrive, Chrome marks the HTTP/3 endpoint as broken and silently retries the request over TCP. The error reaches the page when the session dies after headers were received (mid-download) or when retries are exhausted. Any QUIC connection close at that moment, whether an idle timeout, a peer error or UDP packets that stopped arriving, is reported to the request as this code. It is not a DNS failure and not a certificate error: certificate problems produce ERR_CERT_* codes instead.

On the network side, the usual triggers are firewalls, VPN clients and security products that let the first UDP packets through and then drop or rate-limit the flow, and tunnels with a small MTU. RFC 9000 requires paths to carry UDP datagrams of at least 1200 bytes; a path that cannot breaks QUIC while TCP keeps working.

On the server side: a QUIC listener behind a load balancer that sends packets of one connection to different backends, a server that advertises h3 in Alt-Svc on a port where QUIC is not reachable, or an experimental HTTP/3 stack that closes connections on valid traffic. Because Chrome remembers the advertisement for the ma lifetime, a broken HTTP/3 endpoint can keep producing errors after you change other settings.

With Cloudflare, HTTP/3 only covers the hop between the visitor and Cloudflare; Cloudflare does not use HTTP/3 to your origin. The toggle is in Speed > Settings > Protocol Optimization > HTTP/3 (with QUIC). If visitors on certain networks report this error, switching it off is a valid test: Cloudflare then stops advertising HTTP/3 and browsers use HTTP/2.

On your own nginx (1.25.0 or later, built with --with-http_v3_module), QUIC needs a UDP listener next to the TCP one and an explicit advertisement:

server {
    listen 443 quic reuseport;     # UDP, HTTP/3
    listen 443 ssl;                # TCP, HTTP/1.1 and HTTP/2
    http2 on;
    server_name example.com;

    ssl_certificate     /etc/nginx/certs/example.com.crt;
    ssl_certificate_key /etc/nginx/certs/example.com.key;

    # Advertise HTTP/3 only after UDP 443 is reachable from outside
    add_header Alt-Svc 'h3=":443"; ma=86400';
}

Open UDP 443 in every layer: host firewall (ufw allow 443/udp or firewall-cmd --permanent --add-port=443/udp), cloud security group and any hardware firewall. If you enable quic_retry, set quic_host_key as well; without it nginx generates a new key on every reload and rejects tokens issued with the old one. A UDP load balancer in front of several QUIC servers must keep each connection on one backend.

1. Check the advertisement. curl -sI https://example.com/ | grep -i alt-svc. Every port listed after h3= must accept QUIC from the public internet.
2. Test HTTP/3 directly. curl --http3-only -sv -o /dev/null https://example.com/ (needs a curl build with HTTP/3). Compare with curl --http2 -sv -o /dev/null https://example.com/.
3. Test from more than one network. A failure only from one office or mobile carrier points to UDP filtering on that path, not to your server.
4. Log the protocol. Add the $http3 variable to the nginx access log format, as the nginx documentation example does, to see which requests arrive over h3 and which clients stay on TCP.
5. Capture a NetLog. Record with chrome://net-export; the QUIC_SESSION_CLOSED event names the QUIC error code, such as QUIC_NETWORK_IDLE_TIMEOUT or QUIC_TOO_MANY_RTOS.
6. Roll back cleanly if needed. Send Alt-Svc: clear for a while instead of just removing the header, so browsers drop the cached HTTP/3 endpoint without waiting for ma to expire.

Reload once: Chrome often marks the QUIC endpoint as broken and the retry goes over TCP. If the error comes back, try another network or disconnect the VPN, and pause the web-protection feature of your antivirus, since these are the most common things that interfere with UDP. As a diagnostic, set chrome://flags/#enable-quic ("Experimental QUIC protocol") to Disabled and relaunch; if the site then works, QUIC on your path is the problem. In Firefox the equivalent switch is network.http.http3.enable in about:config. Managed Chrome installs can be controlled with the QuicAllowed policy.

Clearing the cache does not help; the error is not cached. If the site fails on every network and device, the server's HTTP/3 setup is at fault and only the owner can fix it.

curl --http3-only -sv -o /dev/null https://example.com/
# expect: < HTTP/3 200
curl -sI https://example.com/ | grep -i alt-svc

In Chrome DevTools, add the Protocol column in the Network panel and check that requests show h3 without failures. To see from outside which protocols the server negotiates and what it advertises, use the HTTP/2 and HTTP/3 protocol test.

• ERR_QUIC_HANDSHAKE_FAILED
• ERR_HTTP2_PROTOCOL_ERROR
• ERR_CONNECTION_RESET
• ERR_QUIC_PROTOCOL_ERROR troubleshooting guide
• HTTP/2 and HTTP/3 compared