ERR_QUIC_PROTOCOL_ERROR: Meaning & Fix in Chrome and Edge

What Is ERR_QUIC_PROTOCOL_ERROR?

ERR_QUIC_PROTOCOL_ERROR means Chrome's QUIC connection to the website broke, usually after the site had started sending the page. QUIC is the UDP-based transport behind HTTP/3. Chrome shows its generic "This site can't be reached" page ("The webpage at … might be temporarily down or it may have moved permanently to a new web address") with the code underneath; Chromium defines it as error -356, "There is a QUIC protocol error".

Chrome normally recovers by itself: when a QUIC request fails, it retries the request over an ordinary TCP connection, unless the server had already started answering (http_network_transaction.cc). So a network that blocks QUIC completely doesn't cause this error; a network, VPN or server that lets QUIC start and then breaks it does.

It appears only in Chromium-based browsers: Chrome, Edge, Opera, Brave and Vivaldi. It's a different failure from ERR_SSL_PROTOCOL_ERROR (a broken TLS handshake) and ERR_NETWORK_CHANGED (your connection switched). Reload first, since the retry often works; if the error keeps coming back, the fixes below start with the most reliable one, turning QUIC off, then work through each cause.

What Is QUIC and Why Does Chrome Use It?

QUIC was developed by Google, first announced in 2013, and standardized by the IETF as RFC 9000 in 2021. It replaces TCP + TLS with a single encrypted protocol on top of UDP, and it's the transport behind HTTP/3 (Android's Private DNS also uses it for DNS over HTTP/3: see what is private DNS).

A TCP + TLS 1.3 connection needs two round trips before the first request; QUIC needs one, and can resume in zero. On 7 October 2020 Google announced that 25% of Chrome Stable users were already on IETF QUIC (draft h3-29). Google measured Search latency down over 2%, YouTube rebuffering down over 9%, and throughput up over 3% on desktop and 7% on mobile (Chromium Blog).

Chrome only uses QUIC when a site advertises it, in an Alt-Svc header or a DNS HTTPS record. We checked 20 of the most-visited sites on 26 October 2026: 10 advertise HTTP/3 in their Alt-Svc header (Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare and OpenAI).

What Causes ERR_QUIC_PROTOCOL_ERROR?

Every cause is the same pattern: QUIC got started, then something broke it.

• A network that lets QUIC start, then breaks it — firewalls, routers or ISP equipment that drop or time out UDP traffic partway through a transfer. (A network that blocks UDP 443 completely just makes Chrome use TCP, with no error.)
• A VPN that drops UDP mid-connection — when a VPN reconnects, switches server or route, or times out quiet UDP flows, an open QUIC connection dies. (A path too small for QUIC fails during the handshake instead, where Chrome just uses TCP.)
• Security software that inspects traffic — antivirus or firewall "web protection" that intercepts connections can break QUIC streams.
• An unstable connection — weak Wi-Fi, or switching networks in the middle of a download.
• The website's HTTP/3 setup — a server or CDN that advertises HTTP/3 but whose QUIC stack fails mid-response. Then everyone sees the error on that one site, on every network: the Website Down Checker shows whether it fails for others too.
• Not a cause: a proxy — Chrome only uses QUIC on direct connections, so with a proxy set, every request goes over TCP.

Fix 1: Disable the QUIC Protocol in Chrome

The most reliable fix: with QUIC off, Chrome uses HTTP/2 (or HTTP/1.1) over TCP for every site. Pages still load; you give up QUIC's speed gains, which Google measured at around 2% faster Search and 9% less YouTube rebuffering.

For IT admins: the Chrome and Edge policy QuicAllowed set to false turns QUIC off on managed devices, without touching chrome://flags.

Disable QUIC in Google Chrome

Follow these steps to disable QUIC in Chrome on Windows, Mac, or Linux.

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Disable QUIC in Microsoft Edge

Since Edge is Chromium-based, the process is almost identical.

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

Disable QUIC in Opera & Brave

Opera and Brave use the same Chromium flags system.

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

Fix 2: Reset Chrome's Connections

Clearing data rarely fixes this, but resetting open connections can: Chrome then starts fresh QUIC (or TCP) connections to the site.

Flush Connections, Then Clear the Cache

Start with Flush socket pools (see the note below). If the error survives, clear the cache:

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

Fix 3: Disable Browser Extensions

Rarely the cause: extensions can't change QUIC itself, and "VPN" extensions in desktop Chrome are really proxies, which stop Chrome from using QUIC at all.

Open the site in an Incognito window (Ctrl+Shift+N), where extensions are off unless you allowed them. If it loads there, turn your extensions off one by one at chrome://extensions/ to find the one responsible.

Fix 4: Check Firewall and Antivirus Settings

A firewall that blocks UDP port 443 outright doesn't cause this error: Chrome simply uses TCP. The trouble is a firewall or security suite that lets QUIC start and then drops or inspects it.

Either allow outbound UDP 443 fully, or block it fully. Here's how to check the common setups.

Windows Firewall

Windows Defender Firewall allows outbound traffic by default, and a block rule always beats an allow rule, so look for a block rule someone added and turn it off. Run PowerShell as Administrator:

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

macOS Firewall

macOS's built-in firewall only controls incoming connections, so it can't block QUIC. If you run an outbound firewall such as Little Snitch or LuLu, check its rules for Chrome's UDP traffic to port 443.

Router-Level Firewalls

The quickest test: connect to your phone's mobile hotspot and load the site. If the error disappears, your router, ISP equipment or office firewall is the cause.

Then look in the router's admin page (usually 192.168.1.1 or 192.168.0.1) for firewall, "SPI" or security settings that limit UDP, and update its firmware.

Fix 5: Check Your VPN

A VPN tunnels all your traffic, UDP included, so QUIC normally passes through it. Trouble starts when the tunnel itself is unstable: a reconnect, a server or route change, or a VPN that times out quiet UDP flows kills open QUIC connections.

Disconnect the VPN and reload. If the error goes, try these:

• Switch the VPN server or protocol — a more stable server or another protocol often stops the drops
• Corporate VPNs — many company networks block QUIC on purpose so they can inspect HTTPS; follow IT's setup and turn QUIC off if errors persist
• Leave QUIC off while on the VPN — Fix 1 works with every VPN, because Chrome then uses TCP

Fix 6: Look for a Hidden Proxy or Traffic Filter

A proxy setting doesn't cause this error: Chrome only uses QUIC on direct connections, so with a proxy every request goes over TCP. What can look like a proxy, though, is security or VPN software that filters traffic at the network level without a proxy setting.

If the error appears on every network but only on this computer, turn off such software ("web shield", "network protection", a VPN app that runs in the background) one at a time and reload.

Fix 7: Update Chrome to the Latest Version

Chrome's QUIC code is updated regularly, and updates fix bugs in Chrome's side of the connection. Update Chrome (or Edge, Opera, Brave) before you change anything else on a computer that's been offline for a while.

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

Server-Side QUIC Issues (For Website Owners)

If you are a website owner and your visitors report ERR_QUIC_PROTOCOL_ERROR, the issue may be on your server. Here are the most common server-side causes.

• Cloudflare HTTP/3 setting — if visitors report the error and you use Cloudflare, check Speed > Settings > Protocol Optimization > HTTP/3 and test with it off for a while
• Your own server's HTTP/3 — nginx has had HTTP/3 since 1.25.0 (listen 443 quic reuseport; plus an Alt-Svc header); LiteSpeed and Caddy support it too. Make sure the UDP listener on port 443 is reachable and your QUIC stack is up to date. QUIC always uses TLS 1.3: the SSL Checker shows whether your server offers it
• Load balancers that don't forward UDP — application load balancers such as AWS ALB only carry TCP. If you advertise h3 in Alt-Svc without forwarding UDP 443, Chrome marks QUIC as broken for your site for 5 minutes, then retries, doubling the wait up to 2 days, and races TCP each time: remove the header or use a UDP-capable (layer 4) balancer

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

Should You Keep QUIC Enabled or Disable It?

Turning QUIC off is a safe fix, but on a healthy network you give up real speed. A practical way to decide:

Keep QUIC on at home, on mobile data and on any network where the error doesn't appear. Google's own data shows faster Search, less video rebuffering and higher throughput with it, and QUIC keeps connections alive when your phone switches from Wi-Fi to mobile data.

Turn QUIC off on a network or VPN where the error keeps coming back. Chrome then uses HTTP/2 (or HTTP/1.1) over TCP, which every network handles; most people won't notice the difference on a good broadband line.

When the same kind of failure happens over HTTP/2 instead of QUIC, Chrome shows ERR_HTTP2_PROTOCOL_ERROR, which has its own causes and fixes.