ERR_QUIC_PROTOCOL_ERROR

Error ERR_QUIC_PROTOCOL_ERROR appears in Chromium browsers when a connection over QUIC — the transport protocol behind HTTP/3 — fails at the protocol level. The browser tried to reach the site using HTTP/3 over UDP, the handshake or the data exchange did not do what QUIC requires, and the browser reported the failure. It is usually not a fault in your device: HTTP/3 is an optional optimisation, and a network that does not carry it cleanly will trigger this error.

What it means

QUIC is a transport built on UDP that carries HTTP/3. It bundles its own encryption with TLS 1.3, multiplexes several streams over one connection, and avoids the head-of-line blocking that older HTTP versions suffered. Modern Chrome and Edge will happily try QUIC first, on UDP port 443, and fall back to HTTP/2 over TCP if it does not work.

This error means something along the path interfered with the UDP flow. A firewall, NAT device, VPN or proxy that does not understand or does not allow UDP 443 can drop or rewrite the packets, so the QUIC handshake fails. Because QUIC has no in-band way to recover from a middlebox that silently changes its packets, the browser gives up on that attempt and reports the error.

In practice the error is often harmless — the browser retries over TCP and the page still loads — but it can block a site entirely if the fallback also fails, or if the server offers only HTTP/3 for that request. The good news is that QUIC is optional, so turning it off removes the error at the cost of a small performance optimisation.

Common causes

• A firewall, router or VPN on the path blocks outbound UDP port 443, so QUIC packets never get through.
• An out-of-date browser or a buggy server or CDN-edge QUIC implementation that breaks the handshake.
• A proxy or security suite that inspects traffic but does not correctly handle UDP.
• A corporate or guest network that permits only TCP for web traffic.
• A stale browser profile or cached state that keeps retrying a broken HTTP/3 session.

How to fix it

1. Disable QUIC in the browser. This is the reliable fix because it forces HTTP/2 over TCP. Open chrome://flags/#enable-quic in Chrome or Edge, set it to Disabled, and restart the browser. The error stops because the browser no longer attempts HTTP/3.
2. Update the browser. Old builds carry QUIC bugs that newer versions fix. Update to the latest stable release and restart.
3. Test from another network. Load the site on a phone hotspot. If it works there, your local network is blocking or mangling UDP, which confirms the cause.
4. Relax VPN and security software. Disconnect the VPN or pause the security suite for a test. If the page loads, allow outbound UDP port 443 rather than blocking all UDP.
5. For site owners, check HTTP/3 at the edge. If a CDN offers buggy HTTP/3, disable HTTP/3 (QUIC) in the CDN settings while keeping HTTP/2 on. Test with:

   curl -I --http3 https://example.com/

How to prevent it

Keep the browser on the latest stable channel. QUIC implementations change quickly, and most ERR_QUIC_PROTOCOL_ERROR reports fade after an update because the failing handshake logic has been fixed. If you run a managed fleet, push updates on a regular cadence rather than leaving long-lived versions in place.

Be deliberate about UDP on your network. If you block UDP by default, know that you are also disabling HTTP/3 and accept that browsers will fall back to TCP; otherwise allow outbound UDP 443 so QUIC can work as intended. Re-check firewall and VPN rules after any upgrade, because vendor defaults and protocol sets do change between versions.

For site owners, treat HTTP/3 as an optional win, not a requirement. Keep HTTP/2 enabled as a dependable baseline, test HTTP/3 from several networks after you enable it, and be ready to switch it off at the CDN if edge implementations misbehave. That way a QUIC problem never becomes a site outage.