# ERR_QUIC_PROTOCOL_ERROR: what it means and how to fix it > ERR_QUIC_PROTOCOL_ERROR means the browser's HTTP/3 connection over QUIC failed. The quick fixes for visitors, and how site owners find the network or server cause and keep visitors on a working connection. Updated 2026-09-26 · Speed & Core Web Vitals · HTML version: https://getreport.app/guides/err-quic-protocol-error 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](https://getreport.app/guides/http2-and-http3). ## 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](https://getreport.app/tools/http2-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: 1. **Reload the page.** A one-off network hiccup can cause it. 2. **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. 3. **Turn off your VPN or proxy.** Many VPNs and proxies do not carry UDP traffic well, or block it. 4. **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. 5. **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. 6. **Update the browser.** Chrome menu → Help → About Google Chrome. 7. **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: 1. Go to `chrome://flags/#enable-quic`. 2. Set **Experimental QUIC protocol** to **Disabled**. 3. 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 > **Free tool:** [HTTP/3 test and HTTP/2 check for any website](https://getreport.app/tools/http2-test): Free HTTP/3 test and HTTP/2 check: see which protocol your server negotiates, whether HTTP/3 is advertised, and which files still load over HTTP/1.1. 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. > **Check: HTTP/3 is advertised via Alt-Svc.** HTTP/3 (QUIC) shortens the connection setup and copes better with flaky mobile networks. Servers announce it with an Alt-Svc header; without it browsers never try. > > 1. Enable HTTP/3 in your CDN or server (Cloudflare toggle, Caddy default, Nginx 1.25+ "listen 443 quic"). > 2. Make sure UDP port 443 is open in the firewall. > **Check: HTTP/2 server support.** Without HTTP/2 the browser opens up to six connections and queues everything else. Turning it on is a server or CDN setting and makes pages with many files load faster with no code change. > > 1. Enable HTTP/2 in your web server (nginx 1.25.1+: "http2 on;" in the server block, older: "listen 443 ssl http2"; Apache mod_http2) or put the site behind a CDN that speaks it. > 2. Check the host's control panel; on Cloudflare, Netlify, Vercel and most managed WordPress hosts it is already on. 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`): ```bash # 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: ```bash 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. > **Check: A CDN is in front of the site.** A CDN serves your files from a location near each visitor and absorbs traffic spikes. Without one, visitors far from your server wait longer for every file. > > 1. Put the site behind a CDN such as Cloudflare, Bunny or Fastly; the free tiers cover most small sites. > 2. At minimum, serve images and static files from a CDN hostname. ### 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](https://getreport.app/guides/http2-and-http3) has the settings to turn it back on for nginx, Caddy and Cloudflare. ## How to verify the fix 1. Run `curl --http3-only` from two different networks. Both should return the page. 2. In Chrome, load the site twice with the Network panel open. The second load shows `h3` in the Protocol column, and nothing fails. 3. 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. > **Check: Every request uses HTTP/2 or HTTP/3.** HTTP/2 and HTTP/3 load many files over one connection at once; HTTP/1.1 queues them six at a time. Switching usually makes a page with many images or scripts noticeably faster with no code change. > > 1. Turn on HTTP/2 or HTTP/3 in your hosting or CDN panel; on Cloudflare and most managed hosts it is a checkbox. > 2. Move assets that are still served over HTTP/1.1 (see the technical detail) to a host that supports HTTP/2. For the HTTP/2 counterpart of this error, which has different causes, see our guide to [ERR_HTTP2_PROTOCOL_ERROR](https://getreport.app/guides/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.