Fix ERR_SPDY_PROTOCOL_ERROR and ERR_HTTP2_PROTOCOL_ERROR

ERR_SPDY_PROTOCOL_ERROR is the retired name of a Chrome network error that is now shown as ERR_HTTP2_PROTOCOL_ERROR. Seeing the old SPDY label usually means an older page, bookmarked text, or an outdated error reference, because Chrome renamed the error in version 77 and dropped the SPDY protocol entirely years earlier. The fix is the same either way, and it is not the certificate.

What it is

Despite living alongside SSL errors, ERR_HTTP2_PROTOCOL_ERROR is not about the TLS handshake or the certificate. By the time this error appears, the secure connection has already succeeded. The error means Chrome received an HTTP/2 response it could not parse: a malformed frame, an invalid header, or a violation of the HTTP/2 rules for the connection.

It is essentially always a server-side problem, sometimes influenced by traffic-inspecting software in between. The valid triggers tend to group into a few causes:

• An origin or CDN sending invalid HTTP/2 frames or headers.
• A middlebox, anti-virus, or proxy that inspects traffic and corrupts the HTTP/2 stream.
• Oversized request header blocks, often from large cookies, that push a request over the server or CDN limit and cause a reset.

Why clearing the cache does not fix it

Reloads and cache clears rarely help because the error is not about cached content. The browser never finished parsing the current response, so there is no bad cached copy to remove. Clearing cached images and files changes nothing.

There is one exception that looks like a cache issue but is not: cookies. Clearing cookies for the specific site removes the large header blocks that may be causing the reset. This is why clearing site data in Chrome settings can restore access even though a normal reload cannot.

Fix the cause

The durable fix belongs on the server or in the software between the server and the visitor, not in the browser.

1. For the site owner: test whether the error disappears over HTTP/1.1. If it does, the origin or CDN is emitting broken HTTP/2 and needs a server, proxy, or CDN configuration fix. See ALPN and HTTP/2 negotiation for how the protocol is negotiated.
2. For the visitor: rule out local interception. Test in an incognito window, on a phone data connection, and with anti-virus or corporate proxy temporarily disabled. If the error only appears on one network or device, the middlebox is the cause.
3. For large-login problems: clear cookies for the exact site and check whether the site can reduce how much it stores in cookies, since large header blocks are a common trigger.

If the error is intermittent and network-dependent, HTTP/3, which runs over QUIC on UDP, can also reset in environments that mishandle UDP. Testing on a different network and disabling HTTP/3 temporarily is a valid diagnostic. See connection reset and the website error reference for the surrounding error family.