Skip to content
Web & Dev Tools 5 min read Updated

ERR_HTTP2_PROTOCOL_ERROR: What It Means and How to Fix It

The HTTP/2 connection broke mid-way: app error or timeout, full disk, invalid headers, CDN/proxy. How to narrow it down, plus ERR_QUIC_PROTOCOL_ERROR (HTTP/3).

On this page

ERR_HTTP2_PROTOCOL_ERROR: what it means

HTTP/2 is the modern way browsers and servers exchange pages over https: many files travel together, each in its own "channel" (stream), inside one connection. Its rules are strict. If a channel closes abruptly before the response is finished, or something arrives that the rules don't allow, Chrome stops with ERR_HTTP2_PROTOCOL_ERROR.

Think of a parcel that arrives half-empty or with the wrong label: the browser refuses it. The error can affect the whole page or just one of its files. In the second case the page opens "half-done" (missing images, styling or a feature) and the code net::ERR_HTTP2_PROTOCOL_ERROR only shows in the browser console (F12).

How it looks in Chrome, Edge, Firefox and Safari

BrowserWhat the page saysCode
ChromeIf the whole page fails: "This site can't be reached" with the generic message "The webpage at X might be temporarily down or it may have moved permanently to a new web address." If one file fails: a half-loaded page, with the code in the console (F12).ERR_HTTP2_PROTOCOL_ERROR (HTTP/2) or ERR_QUIC_PROTOCOL_ERROR (HTTP/3)
EdgeSame codes as Chrome (Edge is built on Chromium), with its own wording on the pageERR_HTTP2_PROTOCOL_ERROR
FirefoxNo exact equivalent. You usually see "Network Protocol Error", "The connection was interrupted" or simply a half-loaded page.—
SafariShows no equivalent code; usually the page doesn't open or opens half-loaded.—

If you are a visitor

  1. Reload the page, also with Ctrl+F5 (Cmd+Shift+R on a Mac) to bypass the cache. If it was a momentary server problem, it may clear.
  2. Try a private window. If it opens there, an extension (ad blocker, VPN extension) or stale cache and cookies are to blame. Disable extensions one by one and clear the cache and cookies for the site.
  3. Temporarily turn off your antivirus "HTTPS scanning". Some antivirus products "open up" https traffic to inspect it and can break the HTTP/2 connection.
  4. Try another browser or network (e.g. mobile data). If it fails everywhere, the site is at fault: send the owner the page address and the time you saw the error.

If you own the website: the usual causes

  1. The application crashes or stalls mid-response. A PHP fatal error, the time limit (max_execution_time) or running out of memory after the first bytes have already been sent cuts the response short. Over HTTP/1.1 this often passes as just a half-loaded page; over HTTP/2 Chrome reports it as an error.
  2. Full disk or temp directory. The web server or proxy temporarily writes large responses to disk; if they don't fit, the response is cut. Check free space and inodes.
  3. Proxy or CDN buffer limits and timeouts. A reverse proxy or CDN in front of the server may cut responses that are slow or very large. Compare its limits with the time and size of the page.
  4. Headers HTTP/2 doesn't accept. HTTP/1.1-only headers such as Connection, Upgrade or Transfer-Encoding are not allowed in HTTP/2. The same goes for oversized headers or cookies and values with invalid characters (e.g. a line break). Usually the application or a plugin adds them.
  5. Wrong Content-Length or double compression. If the application declares a Content-Length that doesn't match what it actually sends (often when both the application and the server compress), the browser rejects the response. Compress in one place only.
  6. A WAF or ModSecurity killing the response. A web application firewall may cut the connection mid-way instead of sending a clean error page. Check its logs for the same time.

How to narrow it down

  1. Check the logs at the exact time. Note the address and time of the error and open the server and application error logs for that minute.
  2. Compare HTTP/2 with HTTP/1.1. From a terminal run curl -sv --http2 -o /dev/null https://company.com/ and then curl -sv --http1.1 -o /dev/null https://company.com/, using the address of the failing page (on Windows use NUL instead of /dev/null). If HTTP/2 fails (e.g. "HTTP/2 stream 1 was not closed cleanly") while HTTP/1.1 completes, look at headers, the proxy and size limits. If both are cut off, the problem is in the application.
  3. Bypass the CDN. If you use a CDN, temporarily test the server directly to see whether the error comes from the CDN.

ERR_QUIC_PROTOCOL_ERROR: the same thing over HTTP/3

HTTP/3 is the newest version: instead of TCP it uses QUIC, over UDP port 443. A site "advertises" it with the Alt-Svc header or a DNS HTTPS record, and the browser tries it. Normally, if UDP is blocked, the browser falls back to HTTP/2 on its own. ERR_QUIC_PROTOCOL_ERROR usually appears when the QUIC connection starts but something on the path breaks it: a corporate firewall, antivirus or router that handles UDP badly.

  • Visitor: try another network. If it only happens on your work network, tell its administrator. As a temporary workaround in Chrome, open chrome://flags/#enable-quic, set "Experimental QUIC protocol" to Disabled and restart the browser; it will use HTTP/2.
  • Owner: if you advertise HTTP/3, make sure UDP port 443 is open in the server firewall. If you can't support it properly, stop advertising it (remove Alt-Svc and h3 from the DNS HTTPS record, or switch off the HTTP/3 option at your CDN). The site will keep working normally over HTTP/2.

See which layers sit in front of your site

The Security Headers Checker shows which HTTP version the server negotiates (e.g. HTTP/2), whether it advertises HTTP/3 (via Alt-Svc or a DNS HTTPS record), which CDN, proxy or cache layers sit in front (Cloudflare, LiteSpeed, Varnish and others) and all the response headers, so you can find which layer is responsible. The Uptime Checker shows whether the address answers from outside and with which status code.

→ Security Headers Checker → Uptime Checker

More: 5xx errors, ERR_CONNECTION_RESET, my website won't open and the security headers guide.

Common mistakes

  • Switching off HTTP/2 on the server as the "fix": it usually hides the real problem (a cut-off response), which will keep breaking pages.
  • Looking only at your own browser while the error affects every visitor.
  • Not checking the logs at the exact time of the error.
  • Forgetting there is a CDN or proxy in between: the error may come from there and not from your server.

FAQ

Is it my browser or the site?
If the error appears in a private window, in another browser and on another network, the site is at fault. If it goes away, an extension, the cache or your antivirus is the cause.
Why does the page load only halfway?
The error affects just one file of the page (an image, stylesheet or script). The page loads without it and the code shows in the browser console (F12).
How is ERR_QUIC_PROTOCOL_ERROR different?
It is the equivalent error for HTTP/3, which travels over UDP. Usually a firewall, antivirus or router breaking UDP on the way is to blame.
Should I disable HTTP/2 on the server?
Not as a first step. Find out from the logs why the response is cut off; otherwise the problem is only hidden.

Try it now

HTTP Headers & Security Security headers (HSTS, CSP…), HTTP/2-3, cache & all headers
Up or Down Checker Check if a site or server is online

Related guides

500, 502, 503, 504 Errors: What They Mean and Who Fixes Them ERR_CONNECTION_RESET: What It Means and How to Fix It My Website Won't Open — What to Check (No Tech Skills Needed) What Are HTTP Security Headers and How to Configure Them
All guides
Report a bug