ERR_QUIC_PROTOCOL_ERROR shows up when Chrome tries to connect using QUIC, its faster UDP-based connection method, and something between your computer and the site breaks the handshake partway through. Most of the time, that something is a firewall, VPN, antivirus tool, or a Chrome extension that filters network traffic. The fastest fix for most people is turning off the Experimental QUIC protocol flag and relaunching Chrome. If that does not clear it, the block is happening on your network, not inside Chrome itself.
Before you start
Applies to: Google Chrome. Not version-specific. No sign-in or specific account type is required for this fix. You’ll need access to Chrome’s settings, and possibly your router or security software if the problem turns out to be network-side.
Why ERR_QUIC_PROTOCOL_ERROR happens
QUIC runs over UDP instead of the older TCP that most web traffic still uses. Some networks and security tools are set up to inspect or allow TCP traffic but not UDP, so when Chrome tries QUIC first, the connection stalls or gets reset, and Chrome reports it as ERR_QUIC_PROTOCOL_ERROR instead of quietly falling back. One person on the Google Chrome Community described it this way after two days of the error not going away: “No matter what I do, this error won’t go away. I’ve had this problem for two days.” Another reported it persisting even after a full reinstall of Chrome, on a site that loaded fine in Edge, which is a strong clue the problem was not the Chrome installation itself.
There are four common causes, and each leaves a different clue:
- A firewall, antivirus, VPN, or managed network blocks UDP traffic. Signal: the error shows up on many different sites, and switching to a different browser or network fixes it immediately.
- One website’s server has a broken QUIC setup. Signal: only one site, or a small handful of related sites, ever throws this error, while everything else in Chrome loads normally.
- A Chrome extension is intercepting or rewriting requests. Signal: the error disappears in an Incognito window, where extensions are off by default.
- Your router or ISP mishandles UDP on port 443. Signal: the same site fails on every device on your home network, but loads fine over mobile data.
How to fix ERR_QUIC_PROTOCOL_ERROR
If the error shows up on many sites (network or security software)
Changing browser flags affects how Chrome behaves on every site until you change it back. This is a safe, reversible setting, but it is still an experimental flag rather than a normal preference, so only change the one described below.
- Open a new tab and type chrome://flags in the address bar, then press Enter.
- Type quic into the search box at the top of the page. Typing the search term is faster than scrolling, since the flag is not near the top of the alphabetical list.
- Find Experimental QUIC protocol and change its dropdown from Default to Disabled.
- Click Relaunch at the bottom of the page to apply the change.
- Reload the site that was failing.
If you’re on a work, school, or public network, also try turning off any VPN temporarily and reloading. If the site loads instantly without the VPN, the VPN’s own firewall rules are the actual block, and the QUIC flag change is only a workaround, not the real fix.
If the error only happens on one or two sites
Open the same site in an Incognito window with QUIC still enabled. If it still fails there too, the problem is most likely on that site’s server, not your setup, and there is nothing to fix locally. You can confirm this by trying the same URL from a different network, like mobile data. If it fails everywhere you test it, the fix has to happen on the site’s end.
If the error disappears in Incognito (extension conflict)
- Go to Settings > Extensions (or type chrome://extensions in the address bar).
- Turn off all extensions.
- Reload the site that was failing. If it loads, turn extensions back on one at a time, reloading the site after each one, until the error returns.
- Remove or update the extension that triggered it.
If it’s the same site failing on every device at home
Try the site on mobile data instead of Wi-Fi. If it works there, the block is on your router or your ISP’s side. Restarting the router sometimes clears a stuck UDP rule, but if the problem returns, you’ll likely need to check your router’s firewall settings for anything blocking outbound UDP on port 443, or contact your ISP.
What does not fix this
A few fixes get recommended often but don’t reliably work, because they don’t touch the actual cause:
- Reinstalling Chrome. One user tried a full reinstall, and the error came right back, because the block was happening on the network path or in a security tool outside the Chrome application folder entirely, not in Chrome’s files.
- Clearing cache and cookies. This clears stored site data, not the network path Chrome uses to negotiate a connection, so it has no effect on a QUIC handshake failing.
- Simply restarting your computer. This can coincidentally clear a stuck network state, but it is not addressing the firewall rule, extension, or server issue causing it, so the error usually comes back.
Frequently asked questions
Why do I get ERR_QUIC_PROTOCOL_ERROR and ERR_SSL_PROTOCOL_ERROR together?
When a QUIC connection fails, Chrome normally falls back to a standard TLS connection over TCP without you noticing. If that fallback path is also being blocked or misconfigured, for example by the same firewall or security software, you can see both errors on the same site in close succession. One Google Chrome Community thread shows exactly this pattern, with the original poster reporting ERR_SSL_PROTOCOL_ERROR appearing right after ERR_QUIC_PROTOCOL_ERROR on the same day. Treat it as one network-level block, not two separate bugs.
Does disabling the QUIC flag slow down my browsing?
The difference is small. Chrome falls back to TCP and TLS, which is what most of the web already runs on. You may lose a small speed advantage on sites that lean heavily on QUIC, but it won’t be noticeable for typical browsing.
Is this the same as ERR_QUIC_PROTOCOL_ERROR.QUIC_NETWORK_IDLE_TIMEOUT?
It’s a specific variant. The idle timeout suffix means the QUIC connection was established but then went quiet for too long and Chrome gave up on it, which usually points more toward an unstable network connection than a hard block. The same diagnosis steps above still apply: check whether it’s one site, all sites, or one network.
ERR_QUIC_PROTOCOL_ERROR is almost always a network or extension conflict rather than a broken Chrome install, which is why reinstalling rarely helps. Narrow it down with the incognito and mobile-data checks above before you change any settings, and you’ll fix the right thing on the first try.
