ERR_HTTP2_PING_FAILED in Chrome: Fix

Problem

Chrome fails to load the page or an asset with ERR_HTTP2_PING_FAILED, sometimes after the page was working a moment ago. The connection was open, requests were flowing, and then everything on it stalled and died at once.

Symptoms

• Chrome (or Edge) shows net::ERR_HTTP2_PING_FAILED, often in the console for individual resources rather than a full-page interstitial.
• The failure is intermittent — a reload frequently recovers, then it happens again later.
• It clusters under load, or on a specific network (office, VPN, mobile, satellite) while other networks are fine.
• Multiple resources fail together, because they shared one HTTP/2 connection.

What This Error Actually Means

HTTP/2 runs many requests over a single long-lived connection, and Chrome reuses that connection for as long as it believes it’s healthy. To avoid sending requests into a connection that has silently died — a half-open TCP socket after a network change, a NAT that dropped its mapping, a server that stopped reading its socket — Chrome periodically sends an HTTP/2 PING frame (RFC 9113 §6.7). A PING is a cheap control frame; the peer must answer it with a PING ACK, and answering is supposed to be near-instant because it doesn’t require any application work.

When Chrome sends that ping and the ACK doesn’t come back within its timeout, Chrome stops trusting the connection. It tears it down and reports ERR_HTTP2_PING_FAILED, taking every in-flight request on that connection with it. So the error doesn’t mean “your app is slow to respond to a request.” It means something couldn’t even echo back a two-byte heartbeat — the connection is dead, stuck, or being interfered with.

The practical translation: the connection went silent, and the silence is either at the server or somewhere on the path.

Top 3 Causes

1. The server is too saturated to answer the ping - The PING frame is trivial, but if the server’s HTTP/2 event loop or worker threads are fully blocked — a thread-pool exhausted by slow backends, a stalled reverse proxy, a GC pause — even the heartbeat goes unanswered. A concrete example: a Tomcat bug where the PING frame handler threw on a null parent stream, killing ping handling under specific conditions until it was patched. Saturation and framing bugs both look the same to Chrome: no ACK.
2. A middlebox or flaky path drops the connection - A corporate proxy, a VPN, TLS-inspecting antivirus, or a lossy mobile/satellite link can silently drop or stop forwarding the long-lived HTTP/2 connection. The server never even sees the ping. This is why the error is often network-specific — the same site is fine from a clean connection.
3. Idle-connection reuse racing an idle timeout - Chrome reuses a connection it believes is alive, but the origin, a load balancer, or a CDN edge already closed it because its own idle/keepalive timeout was shorter. The ping is what discovers the connection is already gone.

Diagnose with DechoNet

• HTTP Check fetches the site from outside your network. A clean external response points the finger at your local path — a proxy, VPN, or Wi-Fi problem — rather than the origin.
• Port Check confirms port 443 is reachable and the failure isn’t a raw connectivity problem underneath HTTP/2.
• SSL Check confirms the TLS layer is healthy, ruling out the layer below the HTTP/2 conversation.

Resolution Checklist

• Isolate server vs. network first: run HTTP Check (or load the site from a different network / mobile hotspot). If it’s fine externally but fails on your network, the problem is a proxy, VPN, or link — not the site.
• For local failures, disable the corporate proxy, VPN, or TLS-inspecting antivirus one at a time and retest. Any one of them can be dropping the long-lived connection.
• For server-side failures under load, look at what’s saturating the HTTP/2 stack: thread-pool or worker exhaustion, slow upstream backends, or long GC pauses that stop the server from servicing the ping.
• Update the web server / HTTP/2 module — some ping-handling bugs (Tomcat, older proxy builds) are fixed in newer releases. Don’t disable HTTP/2 as a permanent fix; that trades the error for slower loads.
• Align idle timeouts across the chain (origin, load balancer, CDN) so Chrome isn’t reusing connections a downstream layer has already closed.
• Re-run HTTP Check after the change to confirm the connection stays healthy.

When to Escalate

• Escalate to your CDN or host if HTTP Check shows a healthy origin but the error appears only through their edge — a stalled or buggy HTTP/2 proxy on their side is dropping the ping.
• If the failures track exactly with load, escalate as a capacity or thread-pool problem, not a browser one: the server is answering requests but running too hot to service the heartbeat.
• If it’s confined to one corporate network, hand it to the network team — an inspecting proxy or firewall is interfering with long-lived HTTP/2 connections, and only they can adjust it.