ERR_HTTP2_PROTOCOL_ERROR: causes and fixes

What ERR_HTTP2_PROTOCOL_ERROR means

HTTP/2 sends requests and responses as binary frames over a single connection, with strict rules about frame size, header encoding (HPACK), and stream state. A server, proxy, or CDN that sends a malformed frame, an oversized header, or a frame for a stream that is already closed breaks those rules, and the client tears down the connection rather than guess at what was meant. Because the failure can originate at the app server, an intermediate proxy, a CDN edge, or the browser's own network stack, this error covers a wider range of root causes than most others in this list.

How the error appears

Chrome and Edge show "This page isn't working - ERR_HTTP2_PROTOCOL_ERROR", sometimes only on some page loads and not others, which is a hint the fault is intermittent rather than a fixed misconfiguration. Firefox usually shows a generic connection error rather than naming the protocol.

curl can force HTTP/2 and show exactly which frame the connection failed on:

curl --http2 -v https://example.com/ 2>&1 | tail -20
...
* Recv failure: Connection reset by peer
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Comparing that against an HTTP/1.1 request to the same URL isolates whether the problem is protocol-specific:

curl --http1.1 -sI https://example.com/

If the HTTP/1.1 request succeeds and the HTTP/2 one fails, the fault is in how something in the chain implements HTTP/2, not in the application itself.

What causes ERR_HTTP2_PROTOCOL_ERROR

• Malformed or oversized headers from the application or a proxy. A very long cookie, an oversized set of response headers, or a header value containing characters HPACK cannot encode will violate the frame size the server or client expects.
• A reverse proxy or load balancer with a buggy or outdated HTTP/2 implementation. Some older nginx, Apache, or embedded-device HTTP/2 stacks have known issues with specific frame sequences under load.
• A CDN edge bug or an edge-to-origin protocol mismatch. The browser-to-edge leg and the edge-to-origin leg can use different protocols; a bug translating between them occasionally produces this error only for certain request shapes.
• Antivirus software or a browser extension that intercepts HTTPS traffic. The same class of software that causes SSL handshake failures can also break a healthy HTTP/2 stream if its interception layer does not speak HTTP/2 correctly.
• An outdated browser with an old HTTP/2 implementation, or a corrupted browser network cache.
• A Content-Length mismatch behind a reverse proxy. If nginx (or another proxy) forwards a response whose declared Content-Length does not match the bytes actually sent, downstream HTTP/2 framing can break partway through.

How to tell whose fault it is

Run an HTTP check from several locations: if the failure is consistent everywhere, the server or CDN's HTTP/2 handling is at fault. If it only fails for you, it is much more likely to be local, a browser, an antivirus, or a network device between you and the site.

How to fix ERR_HTTP2_PROTOCOL_ERROR

If you are a visitor

1. Reload the page. Since the cause is often a single malformed frame rather than a persistent misconfiguration, a fresh connection frequently succeeds.
2. Clear the browser cache at chrome://settings/clearBrowserData, since a corrupted cached resource can trigger this on reload.
3. Disable antivirus HTTPS/SSL scanning temporarily and retry; this class of software is a common and often-overlooked cause.
4. Try an incognito window to rule out an extension.
5. Update the browser to the latest version, since older HTTP/2 client implementations had known bugs.

If you run the site

1. Compare HTTP/2 against HTTP/1.1 with the curl commands above. If only HTTP/2 fails, the problem is in a proxy or CDN's HTTP/2 layer, not the application.
2. Raise nginx's header size limits if large cookies or headers are involved:

   http2_max_field_size 16k;
   http2_max_header_size 32k;
   large_client_header_buffers 4 16k;

   Restart or reload nginx after the change and retest.
3. Check for a Content-Length mismatch between what the application sends and what the proxy forwards; enable proxy buffering (proxy_buffering on;) so nginx can read the full response before framing it for HTTP/2.
4. Update nginx, Apache, or any load balancer to a current version; HTTP/2 frame-handling bugs are the kind of thing that gets fixed in point releases.
5. Disable HTTP/2 as a diagnostic test, not a permanent fix: drop http2 from the nginx listen directive temporarily. If the errors stop, the fault is confirmed to be in the HTTP/2 layer specifically, and you can re-enable it once the header or buffering fix above is in place.
6. Check CDN-side logs if one sits in front of the origin; most CDNs surface HTTP/2 framing errors in their edge logs with more detail than the browser ever shows.

Related errors

• ERR_SSL_PROTOCOL_ERROR looks similar but fails earlier, during the TLS handshake, before any HTTP/2 frame is exchanged at all.
• 5xx server error codes cover cases where the connection and protocol work fine but the application itself fails.

One detail worth separating out: an HTTP/2 protocol error is not the same as an HTTP/2 stream that was cleanly reset by the application, for example when a client cancels a request mid-flight. Browser developer tools and server access logs sometimes label both as "reset," but only a genuine framing violation produces ERR_HTTP2_PROTOCOL_ERROR in the browser; an intentionally cancelled stream simply stops without an error page.

How to prevent ERR_HTTP2_PROTOCOL_ERROR

Because this error is often intermittent, tied to specific header sizes or specific proxy versions, it can affect a fraction of visitors for weeks before anyone notices a pattern. An HTTP check running on a schedule from multiple locations catches a rising failure rate right after a deploy, a CDN change, or a proxy upgrade, instead of relying on scattered user reports. HostTracker alerts by email, SMS, voice call, Slack, Telegram and more as soon as a check starts failing.

Frequently asked questions

Is ERR_HTTP2_PROTOCOL_ERROR the same as an SSL error?

No. This error happens after TLS succeeds, at the HTTP/2 framing layer. An SSL error means the encrypted connection itself never formed.

Why does the error only appear sometimes, not on every page load?

Most causes here are triggered by specific conditions, a header that grows past a limit, a race in a proxy under load, a particular cached resource, rather than a fixed misconfiguration that fails every time.

Will disabling HTTP/2 on my server hurt performance?

HTTP/2 offers real benefits (multiplexing, header compression), so treat disabling it as a temporary diagnostic step, not a permanent fix. Fix the underlying header size or buffering issue and re-enable it.

Can a CDN cause this even if my origin server is fine?

Yes. The CDN edge and the origin can use different protocols on each leg of the connection, and a bug or misconfiguration in how the CDN translates between them can produce this error independent of the origin's own health.

Does this happen on HTTP/1.1 sites?

No, ERR_HTTP2_PROTOCOL_ERROR is specific to connections that negotiated HTTP/2. A site serving only HTTP/1.1 cannot produce this particular error, though it can have its own connection problems.