ERR_QUIC_PROTOCOL_ERROR: how to fix it: getReport

ERR_QUIC_PROTOCOL_ERROR is the message Chrome, Edge and other Chromium browsers show when a connection over QUIC, the transport under HTTP/3, fails and the page cannot load. QUIC runs over UDP instead of TCP, so the usual cause is something between the browser and the site that blocks, limits or alters UDP traffic on port 443: a firewall, a VPN, antivirus software or a company network. Less often, the site's server or CDN advertises HTTP/3 but does not handle it properly. This guide gives the quick fixes for visitors first, then the site-owner diagnosis. For how HTTP/3 and QUIC work, see our guide to HTTP/2 and HTTP/3.

Quick answer

Visitor: reload, then try another network (for example mobile data). If that works, your network blocks or disturbs QUIC.
Visitor: turn off VPN, proxy and antivirus web protection to test; update the browser; try a private window to rule out extensions.
Visitor, last resort: chrome://flags/#enable-quic → Disabled turns QUIC off in Chrome. Use it to confirm the cause, then switch it back.
Site owner: run the free HTTP/2 and HTTP/3 test to see whether HTTP/3 is advertised and whether the page loads over HTTP/2.
Site owner: check that UDP port 443 is open to every server that answers for the domain, and that the Alt-Svc header matches what really listens.
Site owner: if you cannot find the cause quickly, turn HTTP/3 off at the CDN or server. Browsers use HTTP/2 and the error stops.

What ERR_QUIC_PROTOCOL_ERROR means

HTTP/3 does not use TCP. It runs over QUIC (RFC 9000), a transport built on UDP with TLS 1.3 inside it. A browser learns that a site supports HTTP/3 from the Alt-Svc response header, for example Alt-Svc: h3=":443"; ma=86400, and tries QUIC on its next connection to that site.

When a QUIC connection cannot be set up, Chrome normally falls back to HTTP/2 over TCP quietly, and the visitor never notices. ERR_QUIC_PROTOCOL_ERROR appears when the QUIC connection fails in a way Chrome does not recover from: packets altered or dropped partway, a handshake that half-completes, or a connection that breaks after it started. The page then fails to load instead of falling back.

That is why the error so often depends on the network. The same site works at home and fails at the office, or works on mobile data and fails on a hotel Wi-Fi, because one network treats UDP differently from the other.

If you're a visitor: how to fix ERR_QUIC_PROTOCOL_ERROR

Try these in order and reload the page after each:

Reload the page. A one-off network hiccup can cause it.
Try another network. Switch from Wi-Fi to mobile data, or the other way round. If the site works there, the problem is your network, not the site.
Turn off your VPN or proxy. Many VPNs and proxies do not carry UDP traffic well, or block it.
Pause antivirus web protection. Features called "web shield", "HTTPS scanning" or "secure web browsing" inspect traffic and some of them break QUIC. If pausing helps, update the antivirus or add an exception for the site.
Open a private or incognito window to rule out extensions, then turn extensions off one at a time in a normal window if that works.
Update the browser. Chrome menu → Help → About Google Chrome.
Restart your router, or check its firewall settings for rules that block or rate-limit UDP.

Turning QUIC off in Chrome

If nothing else helps, you can switch QUIC off in Chrome:

Go to chrome://flags/#enable-quic.
Set Experimental QUIC protocol to Disabled.
Click Relaunch.

Chrome then uses HTTP/2 over TCP for every site. It is a diagnosis, not a fix: HTTP/3 is often faster on mobile and unstable networks, so switch the flag back to Default once you know the cause or the site has fixed it. On managed company computers the setting may be controlled by the IT department (Chrome's QuicAllowed policy); ask them rather than changing it.

If the site fails on every network and device, the problem is on the website's side. Contact the site owner with the page address and the time it happened.

If you run the site: find the cause

1. Check what the site advertises

The HTTP/2 and HTTP/3 test records which protocol your server negotiates over TCP and reads the Alt-Svc header of the page response to see whether HTTP/3 is advertised. It then loads the page in Chromium and counts every response by protocol. If the test negotiates h2 and loads the page, your TCP path works; the question is whether the QUIC path does too.

The test reports the first visit, which uses TCP. A browser that has already seen the Alt-Svc header uses QUIC on its next connection, which is where this error happens.

2. Test HTTP/3 directly

With a curl build that supports HTTP/3 (check with curl --version; the features list must include HTTP3):

Shell

# Try HTTP/3 only, no fallback
curl -sv --http3-only -o /dev/null https://example.com/

# Compare with HTTP/2
curl -sv --http2 -o /dev/null https://example.com/

If HTTP/2 works and HTTP/3 fails or hangs, the QUIC path is broken somewhere between you and the server. Run the HTTP/3 request from more than one network, for example from the server itself and from a laptop on mobile data, to see whether the failure follows the network or the site.

In Chrome, the developer tools' Network panel shows the protocol per request (add the Protocol column): h3 means HTTP/3. chrome://net-export records a network log with the QUIC error details for the NetLog viewer.

Common server-side causes and fixes

UDP port 443 blocked on the server

HTTP/3 needs UDP 443 open in every firewall in front of the server, including the host's cloud firewall or security group, not only TCP 443. On a server with ufw:

Shell

sudo ufw allow 443/udp

If the server advertises HTTP/3 but UDP is blocked, most browsers fall back to HTTP/2 after a delay, which makes the site slower for everyone, and some connections end in this error. Either open the port or stop advertising HTTP/3.

Alt-Svc advertised by servers that do not speak QUIC

The Alt-Svc header must only come from servers that really answer HTTP/3. Common mismatches:

A load balancer or several origin servers, only some of which listen for QUIC, or a load balancer that passes TCP but not UDP.
An Alt-Svc header set in the application or copied from another setup, while the web server has no HTTP/3 support.
A different port in Alt-Svc than the one the server listens on.

Remove the header where QUIC is not served, or make every server behind the name speak it.

UDP load balancing that splits a connection

QUIC connections are identified by connection IDs, not only by IP address and port, so that they can survive a network change. A load balancer that spreads UDP packets across servers without understanding QUIC can send packets of one connection to a server that does not know it, and the connection breaks. Use a load balancer with QUIC support, or keep HTTP/3 on a single edge such as the CDN.

Network paths that drop large UDP packets

QUIC requires UDP datagrams of at least 1,200 bytes to get through (RFC 9000, section 14). Tunnels, VPNs and some networks with a smaller maximum packet size drop or fragment them, and the connection fails. This is usually on the visitor's side, but also check tunnels or overlays in your own hosting setup.

A server or CDN bug

HTTP/3 support is younger than HTTP/2 support, and nginx still labels its HTTP/3 module experimental. Keep the web server and its TLS library up to date, read its error log at the time of the failures, and check your CDN's status page.

Turning HTTP/3 off

If you cannot find the cause quickly, switch HTTP/3 off. Browsers then use HTTP/2, which works everywhere HTTPS does.

Cloudflare: dashboard → your site → Speed → Settings → Protocol Optimization → HTTP/3 → Off.
nginx: remove the listen 443 quic line and the Alt-Svc header, then reload.
Caddy: HTTP/3 is on by default; add protocols h1 h2 inside a servers block in the global options, then reload.

Browsers remember the Alt-Svc hint for the number of seconds in ma (max-age), so some keep trying QUIC for a while after you stop advertising it and fall back when it fails. If you plan changes to HTTP/3, lower ma beforehand, for example to 3600, so browsers pick up the change sooner. The HTTP/2 and HTTP/3 guide has the settings to turn it back on for nginx, Caddy and Cloudflare.

How to verify the fix

Run curl --http3-only from two different networks. Both should return the page.
In Chrome, load the site twice with the Network panel open. The second load shows h3 in the Protocol column, and nothing fails.
Run the HTTP/2 and HTTP/3 test again. HTTP/2 is negotiated, the page loads, and Alt-Svc shows h3 only if you kept HTTP/3 on.

For the HTTP/2 counterpart of this error, which has different causes, see our guide to ERR_HTTP2_PROTOCOL_ERROR.

Questions people ask

Is it safe to disable QUIC in Chrome?

Yes. Disabling QUIC at chrome://flags/#enable-quic makes Chrome use HTTP/2 over TCP, which every HTTPS site supports and which is just as secure. You lose HTTP/3's faster connections, which help most on mobile and unstable networks. Treat it as a test or a temporary workaround, and set the flag back to Default once the cause is fixed.

Why does ERR_QUIC_PROTOCOL_ERROR only happen on one network?

Because QUIC uses UDP, and networks handle UDP differently. A company firewall, a VPN, a hotel Wi-Fi or an antivirus product may block, rate-limit or alter UDP traffic on port 443, while TCP gets through. If a site works on mobile data but not on a particular Wi-Fi, the network is the cause, not the site.

Can a website fix ERR_QUIC_PROTOCOL_ERROR for its visitors?

Partly. A site owner can make sure UDP 443 is open, that only servers speaking HTTP/3 send an Alt-Svc header, and that the load balancer supports QUIC. For visitors on networks that break UDP, the owner cannot change their network, but turning HTTP/3 off at the CDN or server makes every browser use HTTP/2 instead.

Does ERR_QUIC_PROTOCOL_ERROR mean the website is down?

Usually not. The site often works fine over HTTP/2; only the HTTP/3 connection over QUIC failed. Try another network or turn off your VPN, and the page will often load. If it fails on every network and device, the site's HTTP/3 setup may be broken, and the owner can switch HTTP/3 off to restore access while fixing it.

Is ERR_QUIC_PROTOCOL_ERROR a virus or a hack?

No. It is a network error, not a sign of malware. It means the browser's QUIC connection failed, usually because a firewall, VPN, antivirus or router interferes with UDP traffic, or because the site's HTTP/3 setup has a fault. If it appears on many unrelated sites, check your security software and network settings rather than looking for an infection.

ERR_QUIC_PROTOCOL_ERROR: what it means and how to fix it