ERR_HTTP2_PROTOCOL_ERROR: What It Means and How to Fix It

What ERR_HTTP2_PROTOCOL_ERROR Means Technically

HTTP/2 is a binary protocol that multiplexes multiple request-response exchanges simultaneously over a single TLS connection, using a structured framing layer. Each request and response travels as a sequence of typed binary frames — HEADERS frames, DATA frames, SETTINGS frames, and others — each tagged with a stream ID that identifies which request it belongs to. When either the browser or the server receives a frame that violates the HTTP/2 specification — wrong frame type for the current stream state, an invalid stream ID, a payload that exceeds negotiated size limits, or a frame that arrives out of sequence — the receiving side terminates the connection. The termination is signaled with either a RST_STREAM frame (closing a single stream) or a GOAWAY frame (closing the entire connection and indicating the last successfully processed stream ID). Chrome surfaces either of these as ERR_HTTP2_PROTOCOL_ERROR.

Specific HTTP/2 Error Types

The HTTP/2 specification defines several error codes that appear in RST_STREAM and GOAWAY frames. The most commonly encountered:

• PROTOCOL_ERROR (0x1): A generic framing violation — the most common code and the one behind most ERR_HTTP2_PROTOCOL_ERROR occurrences.
• INTERNAL_ERROR (0x2): The server encountered an implementation error; the connection cannot continue. Usually a server-side bug.
• FLOW_CONTROL_ERROR (0x3): A peer sent more data than the flow control window allows — a sign of a buggy HTTP/2 implementation on either side.
• SETTINGS_TIMEOUT (0x4): The remote peer did not acknowledge a SETTINGS frame within the timeout period — typically a server or proxy that does not fully implement HTTP/2 settings negotiation.

Most Likely Causes

1. Antivirus or corporate proxy performing TLS/SSL inspection that mangles HTTP/2 binary frames
2. Server-side HTTP/2 misconfiguration — nginx, Apache, or a CDN sending frames that violate the spec
3. A load balancer stripping required HTTP/2 headers or mishandling stream multiplexing
4. ALPN (Application-Layer Protocol Negotiation) mismatch — client and server negotiate different protocols during the TLS handshake
5. Stale HTTP/2 connection reused from Chrome's socket pool after the server closed it
6. Chrome update tightening HTTP/2 spec compliance, rejecting frames that older versions silently accepted

How TLS Inspection Causes This Error

Corporate firewalls and some consumer antivirus products perform SSL inspection (also called MITM or deep packet inspection) by intercepting your HTTPS connections, decrypting them, scanning the content, re-encrypting, and forwarding. This process works adequately for HTTP/1.1 because each request is a simple text exchange. HTTP/2's binary framing is far less tolerant — if the inspection software does not correctly implement the HTTP/2 framing layer when re-encrypting and forwarding frames, the browser receives malformed frames and terminates with ERR_HTTP2_PROTOCOL_ERROR. Antivirus products known to have caused this include older versions of Avast, Kaspersky, ESET, and Bitdefender when HTTPS scanning is enabled.

How to Diagnose the Problem

Before fixing, determine whether this is a client-side or server-side issue:

• Open Chrome DevTools (F12) → Network tab → right-click the column headers and enable the Protocol column. A working HTTP/2 connection shows "h2"; HTTP/1.1 shows "http/1.1"; HTTP/3 over QUIC shows "h3".
• Run curl --http2 -v https://example.com in a terminal. The verbose output shows the TLS ALPN negotiation and whether HTTP/2 was successfully established. Look for "Using HTTP2" in the output.
• Try navigating to chrome://flags/#enable-quic and disabling QUIC, then retry the site. If it loads, the issue was with HTTP/3 over QUIC rather than HTTP/2.
• Test the same URL in Firefox or Safari. If it loads in other browsers but not Chrome, the issue is Chrome-specific (socket pool, HSTS, or Chrome's stricter HTTP/2 parsing).

How to Fix ERR_HTTP2_PROTOCOL_ERROR

Step 1: Clear cache and cookies

Press Ctrl+Shift+Delete (Windows) or Cmd+Shift+Delete (macOS) → Advanced → check Cookies and site data + Cached images and files → Clear data. Restart Chrome.

Step 2: Flush Chrome's socket pools

Go to chrome://net-internals/#sockets and click Flush socket pools. This discards all cached HTTP/2 connections that Chrome may be attempting to reuse after the server has closed them.

Step 3: Clear HSTS data for the domain

Go to chrome://net-internals/#hsts. Under Delete domain security policies, enter the domain name (e.g. example.com) and click Delete. Stale HSTS pinning can force connection parameters that conflict with the server's current configuration.

Step 4: Disable antivirus HTTPS scanning

In your antivirus or security software, find "HTTPS scanning", "SSL inspection", or "Web Shield" and disable it temporarily. Retry the site. If it loads, the antivirus is producing malformed HTTP/2 responses. Update the antivirus to its latest version — most vendors have patched HTTP/2 handling — or add the affected site to the exclusion list.

Step 5: Test with HTTP/2 disabled

Launch Chrome from the command line with --disable-http2. On Windows: chrome.exe --disable-http2. On macOS: /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-http2. If the site loads, the problem is definitively in the HTTP/2 implementation — either on the server or in a middlebox. Report it to the site operator with the information that the site fails over HTTP/2 but succeeds over HTTP/1.1.

ERR_HTTP2_PROTOCOL_ERROR vs ERR_QUIC_PROTOCOL_ERROR

These are related but distinct errors. ERR_HTTP2_PROTOCOL_ERROR involves HTTP/2, which runs over TCP with TLS. ERR_QUIC_PROTOCOL_ERROR involves HTTP/3, which runs over QUIC — a UDP-based transport protocol developed by Google. QUIC multiplexes streams similarly to HTTP/2 but handles packet loss differently (individual stream loss does not block other streams). If you see ERR_QUIC_PROTOCOL_ERROR, try disabling QUIC at chrome://flags/#enable-quic — Chrome will fall back to HTTP/2 or HTTP/1.1 over TCP. If the site then loads successfully, the problem is in the server's QUIC implementation, not HTTP/2.

Frequently Asked Questions

Is this a server problem or my problem?

Usually the server's problem or a middlebox interfering with HTTP/2. If one site fails and others work, it is the server or CDN. If many sites suddenly fail after installing security software or connecting to a corporate network, a local SSL inspection tool is the likely cause.

Why did this start after a Chrome update?

Chrome sometimes tightens HTTP/2 compliance, rejecting frames that older versions silently accepted. Sites with slightly non-compliant HTTP/2 implementations break after such updates. Clearing sockets and cache is the only client-side workaround — the server needs updating.