ERR_HTTP2_PROTOCOL_ERROR in Chrome: Fix

Problem

Chrome fails to load the page with ERR_HTTP2_PROTOCOL_ERROR. The site was reachable, TLS connected, and then the request died mid-stream.

Symptoms

• Chrome shows ERR_HTTP2_PROTOCOL_ERROR; the page is blank or partially loaded.
• Some assets load and others don’t, or a reload sometimes works.
• The same URL loads fine in a client forced onto HTTP/1.1, or from a different network.

What This Error Actually Means

This is not a connection error and not a TLS error. By the time you see it, the TCP connection is open and the TLS handshake has completed — the certificate already validated. What broke is the HTTP/2 conversation running inside that encrypted tunnel.

HTTP/2 (RFC 9113, which replaced the original RFC 7540 in 2022) is a binary, multiplexed protocol with rules HTTP/1.1 never had. Header field names must be lowercase. A short list of connection-specific headers is forbidden. Frames have to arrive in valid states, and a request or response is “malformed” if it carries prohibited headers, is missing mandatory ones, or has a Content-Length that doesn’t match the body it actually sent. When an endpoint detects any of this, the spec says to treat it as a stream error of type PROTOCOL_ERROR and send a RST_STREAM — which is exactly what surfaces in Chrome as ERR_HTTP2_PROTOCOL_ERROR.

The practical translation: something is speaking HTTP/2 incorrectly. Usually the server. Sometimes a box in the middle.

Top 3 Causes

1. The server emits a malformed HTTP/2 response - An uppercase header name, an illegal character in a header value, or a Content-Length that disagrees with the bytes actually sent. HTTP/1.1 let this slide; HTTP/2 kills the stream. Buggy application code or an old server module is the usual source.
2. A broken or half-enabled HTTP/2 server config - The http2 directive is missing or misapplied (nginx listen 443 ssl without http2, Apache without mod_http2 / Protocols h2), or the module version has known framing bugs. The server advertises HTTP/2 but implements it incorrectly.
3. An intermediary re-frames the stream - A CDN, reverse proxy, corporate proxy, VPN, or TLS-inspecting antivirus rewrites headers or repackages frames in a way Chrome rejects. This is why the error can be network- or user-specific.

Diagnose with DechoNet

• HTTP Check to inspect the response headers and status the server actually returns — malformed or oversized headers and a Content-Length mismatch show up here.
• SSL Check to confirm TLS itself is healthy, ruling out the layer below HTTP/2.
• Port Check to confirm port 443 is reachable and the failure isn’t a connectivity problem.

Resolution Checklist

• Confirm it’s HTTP/2-specific: load the same URL over HTTP/1.1 (or disable HTTP/2 on the server for one test). If HTTP/1.1 works, the framing layer is the culprit.
• Run HTTP Check and look for uppercase header names, garbage in header values, or a Content-Length that doesn’t match the body — fix these in the application.
• Verify the server’s HTTP/2 is actually enabled and current (nginx listen 443 ssl http2 / Apache Protocols h2 http/1.1 with an up-to-date mod_http2).
• If a CDN or proxy sits in front, toggle its HTTP/2 setting and update it; a known-buggy edge version can corrupt frames.
• For user-specific failures, test with the VPN, corporate proxy, or TLS-inspecting antivirus disabled to isolate the intermediary.
• Re-run HTTP Check after the fix to confirm a clean response.

When to Escalate

• Escalate to your CDN or hosting provider if HTTP Check shows a clean origin response but the error only appears through their edge — the broken framing is on their side.
• If the malformed header comes from application code you don’t own (a framework or plugin), report the specific header to its maintainer rather than disabling HTTP/2 permanently, which trades the error for slower page loads.