ERR_SPDY_PROTOCOL_ERROR: Fix Chrome's HTTP/2 Connection Failures

ERR_SPDY_PROTOCOL_ERROR is a Chrome and Edge error that reports a problem with an HTTP/2 connection. The name is historical: SPDY was Google's experimental predecessor to HTTP/2, and Chromium kept the SPDY prefix in many internal error names after HTTP/2 replaced it. In practice you should read it as "the HTTP/2 session broke."

You see "This site can't be reached. The webpage at https://example.com/ might be temporarily down or it may have moved permanently to a new web address. ERR_SPDY_PROTOCOL_ERROR." This page covers the SPDY-named variant; the closely related ERR_HTTP2_PROTOCOL_ERROR has its own page, and many of the same fixes apply. This one focuses on session-level failures, stale connections and local interference.

What goes wrong in an HTTP/2 session

HTTP/2 multiplexes many requests over one TCP connection using binary frames. Errors arise when:

• A peer sends a malformed frame, an invalid header, or violates flow control.
• A header block is too large for the receiver's limits.
• The server or intermediary closes the connection abruptly (a GOAWAY or a reset) while streams are active.
• A proxy or antivirus that does not fully speak HTTP/2 corrupts the stream.
• A stale pooled connection is reused after the server dropped it.

Chrome often reports the exact HTTP/2 error code (for example PROTOCOL_ERROR, FLOW_CONTROL_ERROR, COMPRESSION_ERROR, REFUSED_STREAM) in the DevTools console or in chrome://net-export.

Fix it as a visitor

1. Reload, then hard reload. A stale pooled connection is the most common cause and goes away on retry.
2. Flush sockets. Open chrome://net-internals/#sockets and click Flush socket pools, then reload.
3. Clear cookies for the site. Oversized cookies can push request headers over the server limit. See request header or cookie too large.
4. Try a private window or another browser. If another browser works, an extension or profile issue is likely.
5. Turn off VPN, proxy and antivirus HTTPS scanning temporarily.
6. Update the browser. Old builds had HTTP/2 bugs fixed in later releases.
7. Restart the router if the problem appears on one network only.

Fix it as the site owner

Confirm HTTP/2 is the problem

Compare HTTP/2 and HTTP/1.1 requests:

curl -sS -o /dev/null -w "%{http_version} %{http_code}\n" --http2 https://example.com/
curl -sS -o /dev/null -w "%{http_version} %{http_code}\n" --http1.1 https://example.com/

If HTTP/1.1 works and HTTP/2 fails, the fault is in the HTTP/2 layer. The HTTP/2 and HTTP/3 Checker shows what the server negotiates, and the CDN डिटेक्टर identifies proxies in front.

Header size limits

Large Set-Cookie, Link, Content-Security-Policy or custom headers can exceed buffer limits. nginx controls it with large_client_header_buffers and, for proxy responses, proxy_buffer_size:

large_client_header_buffers 4 16k;
proxy_buffer_size 16k;
proxy_buffers 8 16k;

When upstream response headers are too big, see upstream sent too big header.

Proxy chain that mishandles HTTP/2

A load balancer speaking HTTP/2 to clients and a different protocol to the backend should translate cleanly. Problems arise with outdated middleboxes, mismatched timeouts, or a backend that sends Connection: keep-alive or Transfer-Encoding headers that are illegal in HTTP/2. Send traffic straight to the origin to isolate the layer.

Crashing or restarting backends

If a worker is killed while serving a stream, the server resets it. Check the application and web server error logs for crashes, memory kills, and reloads that coincide with the failures. Graceful reloads should not drop live connections, but restarts will.

Idle timeouts

An HTTP/2 connection can live a long time. If a load balancer closes idle connections sooner than the server expects, the browser may reuse a dead connection. Align keep-alive and idle timeouts. See keep-alive और load balancer health checks.

Disable HTTP/2 as a stopgap

In nginx, remove http2 from the listen or the http2 on; directive for the affected server block. In Apache, remove h2 from Protocols. The site will work over HTTP/1.1 while you investigate, at some cost to performance. Do this only after confirming with curl that the problem is HTTP/2-specific.

Verify

1. Reload the page in a clean browser profile.
2. Check the Protocol column in DevTools, Network tab. h2 means HTTP/2 is working.
3. Run the HTTP/2 checker again and confirm repeated requests succeed.
4. Keep an अपटाइम मॉनिटर on the page to catch regressions after config changes.

अगले कदम

• Read HTTP/2 and HTTP/3 explained.
• Compare ERR_QUIC_PROTOCOL_ERROR, the HTTP/3 equivalent.
• Learn about ALPN, which selects the protocol during the TLS handshake.
• Check the page with the HTTP स्टेटस चेकर.

सामान्य प्रश्न

Is SPDY still used?

No. SPDY was superseded by HTTP/2 and removed from browsers. The name survives only in some internal error names.

Is ERR_SPDY_PROTOCOL_ERROR the same as ERR_HTTP2_PROTOCOL_ERROR?

They are closely related and mean the HTTP/2 session failed. The exact name depends on where Chrome detected the problem.

Will turning off HTTP/2 hurt my site?

It can reduce speed on pages that load many resources, but HTTP/1.1 is universally supported and is a safe fallback.

Can an ad blocker cause it?

Rarely, but extensions that rewrite requests can. Test in a private window with extensions disabled.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.