ERR_QUIC_PROTOCOL_ERROR: Causes and the Fix

ERR_QUIC_PROTOCOL_ERROR is a failure in HTTP/3, the version of HTTP that runs over UDP instead of TCP. Because most networks are configured with TCP in mind, HTTP/3 is the first thing to break on a restrictive firewall or a badly behaved VPN - which is why this error tends to follow a person around one network and vanish on another.

Confirm the diagnosis in thirty seconds

Turn QUIC off and reload. If the page works, the diagnosis is settled and everything below is about deciding what to fix.

chrome://flags/#enable-quic   →  Disabled   →  Relaunch

Remember this is a diagnostic. Leaving it disabled fixes the browser in front of you and does nothing for anyone else visiting the same site.

If it is your own machine or network

Three causes cover nearly all client-side cases.

• A firewall blocking UDP 443. Corporate and campus networks often permit TCP 443 and drop UDP on the same port, either deliberately or because nobody thought about it. QUIC has no way to work through that, and Chrome does not always fall back cleanly.
• A VPN. Many VPN clients handle UDP poorly, and some encapsulate it in a way that breaks QUIC's path validation. Disconnect and retest - this is the single most common cause on a laptop.
• Consumer router firmware. Some routers apply aggressive UDP flood protection that treats a normal QUIC connection as suspicious. A firmware update, or turning off "DoS protection" for UDP, usually resolves it.

You can check whether UDP 443 gets out at all with a QUIC-capable curl:

curl --http3 -sSI https://cloudflare-quic.com/ | head -5

Failing there but succeeding without --http3 means the network, not any particular site, is the problem.

If it is a site you run

Visitors reporting this error means your server is advertising HTTP/3 and some of them cannot use it. That is worth fixing properly rather than telling people to change a browser flag.

Check what you are advertising

A server offers HTTP/3 through an Alt-Svc header. Look at what yours sends:

curl -sSI https://yourdomain.com | grep -i alt-svc

A header like alt-svc: h3=":443"; ma=86400 tells every Chrome visitor to retry over QUIC for the next day. If UDP 443 is not reliably reachable to your server, that header is actively causing the error - the browser is being told to use a path that does not work, and it caches that instruction.

Make sure UDP 443 is actually open

This is the most common server-side cause: HTTP/3 enabled in the web server, and the firewall only opened for TCP. Both need to be open.

ufw allow 443/udp
firewall-cmd --permanent --add-port=443/udp && firewall-cmd --reload
ss -ulnp | grep :443

On a cloud VPS, check the provider's own security group as well as the host firewall - they are separate layers and both must permit UDP.

Turn HTTP/3 off if you cannot make it reliable

There is no shame in this. A correctly working HTTP/2 site is better than an intermittently broken HTTP/3 one. In nginx, remove the quic and reuseport listeners and the Alt-Svc header. Behind Cloudflare, turn off HTTP/3 (with QUIC) under Network in the dashboard. Both changes take effect for new visitors immediately, though browsers that cached the Alt-Svc header will keep trying QUIC until it expires - which is why lowering ma before disabling is worth doing if you can plan ahead.

Why this error is getting more common

HTTP/3 is on by default in Chrome and enabled by default at most large CDNs, so far more connections attempt QUIC than did a few years ago. The networks in the middle have not all caught up. That combination - a protocol that is enabled everywhere and permitted unevenly - is the whole story behind this error, and it is why the fix so often turns out to be a firewall rule rather than anything about the website.