ERR_HTTP2_PING_FAILED: Chrome 해결

문제

Chrome이 페이지나 리소스를 ERR_HTTP2_PING_FAILED로 로드하지 못합니다. 방금 전까지 잘 되던 페이지가 그러기도 하죠. 연결은 열려 있었고 요청도 흐르고 있었는데, 그 위의 모든 게 한꺼번에 멎고 죽습니다.

증상

• Chrome(또는 Edge)이 net::ERR_HTTP2_PING_FAILED를 냅니다 — 전체 화면 경고보다는 개별 리소스에 대해 콘솔에서 자주 보입니다.
• 간헐적입니다 — 새로고침하면 자주 복구됐다가 나중에 다시 발생합니다.
• 부하가 걸릴 때, 또는 특정 네트워크(사무실, VPN, 모바일, 위성)에서 몰리고 다른 네트워크에선 멀쩡합니다.
• 여러 리소스가 함께 실패합니다 — 하나의 HTTP/2 연결을 공유했기 때문입니다.

이 오류의 진짜 의미

HTTP/2는 하나의 장수 연결 위에 여러 요청을 실어 나르고, Chrome은 그 연결이 건강하다고 믿는 한 계속 재사용합니다. 조용히 죽은 연결 — 네트워크가 바뀐 뒤 남은 half-open TCP 소켓, 매핑이 사라진 NAT, 소켓 읽기를 멈춘 서버 — 로 요청을 밀어넣지 않으려고, Chrome은 주기적으로 HTTP/2 PING 프레임(RFC 9113 §6.7)을 보냅니다. PING은 값싼 제어 프레임이라 반대편은 PING ACK로 답해야 하고, 애플리케이션 작업이 필요 없으니 답하는 건 거의 즉시여야 합니다.

Chrome이 그 핑을 보냈는데 타임아웃 안에 ACK가 돌아오지 않으면, Chrome은 그 연결을 더 이상 믿지 않습니다. 연결을 끊고 ERR_HTTP2_PING_FAILED를 내며, 그 위에서 진행 중이던 모든 요청을 함께 데려갑니다. 그러니 이 오류는 “당신의 앱이 요청에 느리게 응답한다”는 뜻이 아닙니다. 2바이트짜리 심장박동조차 되돌려주지 못했다는 뜻입니다 — 연결이 죽었거나, 막혔거나, 간섭받고 있다는 것이죠.

실무적 번역: 연결이 침묵했고, 그 침묵은 서버에 있거나 경로 어딘가에 있습니다.

가장 흔한 원인 3가지

1. 서버가 핑에 답할 수 없을 만큼 포화 - PING 프레임은 사소하지만, 서버의 HTTP/2 이벤트 루프나 워커 스레드가 완전히 막히면 — 느린 백엔드로 고갈된 스레드풀, 멎은 리버스 프록시, GC 정지 — 심장박동조차 무응답이 됩니다. 구체적 예: Tomcat에서 PING 프레임 핸들러가 null인 부모 스트림에서 예외를 던져 특정 조건에서 핑 처리가 죽었다가 패치된 버그가 있습니다. 포화와 프레이밍 버그는 Chrome 눈엔 똑같이 보입니다: ACK 없음.
2. 중간 장비나 불안정한 경로가 연결을 끊음 - 회사 프록시, VPN, TLS를 검사하는 백신, 손실 많은 모바일·위성 회선이 장수 HTTP/2 연결을 조용히 끊거나 전달을 멈출 수 있습니다. 서버는 핑을 보지도 못합니다. 그래서 오류가 네트워크별로 나타나는 경우가 많습니다 — 깨끗한 연결에서는 같은 사이트가 멀쩡하죠.
3. 유휴 연결 재사용이 유휴 타임아웃과 경합 - Chrome은 살아 있다고 믿는 연결을 재사용하는데, 오리진·로드밸런서·CDN 엣지가 자기 유휴/keepalive 타임아웃이 더 짧아 이미 그 연결을 닫아 버린 경우입니다. 핑이 바로 그 이미 죽은 연결을 발견하는 것이죠.

DechoNet으로 진단하기

• HTTP 진단은 네트워크 바깥에서 사이트를 가져옵니다. 외부에서 응답이 깨끗하면 문제는 로컬 경로 — 프록시, VPN, Wi-Fi — 를 가리키지 오리진이 아닙니다.
• 포트 진단은 443 포트 도달 가능성을 확인해 HTTP/2 아래의 순수 연결 문제가 아님을 확인합니다.
• SSL 진단은 TLS 계층이 건강한지 확인해 HTTP/2 대화 아래 계층을 배제합니다.

해결 체크리스트

• 서버냐 네트워크냐부터 격리: HTTP 진단을 돌리거나 다른 네트워크(모바일 핫스팟)에서 사이트를 열어 보세요. 외부에선 되는데 당신 네트워크에서만 실패하면 문제는 프록시·VPN·회선이지 사이트가 아닙니다.
• 로컬 실패라면 회사 프록시·VPN·TLS 검사 백신을 하나씩 끄고 재시도하세요. 그중 어느 것이든 장수 연결을 끊고 있을 수 있습니다.
• 부하 시 서버측 실패라면 HTTP/2 스택을 포화시키는 게 무엇인지 보세요: 스레드풀·워커 고갈, 느린 상위 백엔드, 서버가 핑을 처리하지 못하게 만드는 긴 GC 정지.
• 웹 서버·HTTP/2 모듈을 업데이트하세요 — 일부 핑 처리 버그(Tomcat, 오래된 프록시 빌드)는 최신 릴리스에서 고쳐졌습니다. HTTP/2를 끄는 건 영구 해결책이 아닙니다 — 오류를 느린 로드로 바꿀 뿐입니다.
• 체인 전반(오리진·로드밸런서·CDN)의 유휴 타임아웃을 맞춰, Chrome이 하위 계층이 이미 닫은 연결을 재사용하지 않게 하세요.
• 수정 후 HTTP 진단을 다시 돌려 연결이 계속 건강한지 확인하세요.

에스컬레이션 시점

• HTTP 진단은 오리진이 건강하다고 하는데 오류가 그들의 엣지를 통해서만 나타나면 CDN·호스트에 에스컬레이션하세요 — 그쪽의 멎었거나 버그 있는 HTTP/2 프록시가 핑을 떨구고 있습니다.
• 실패가 부하와 정확히 함께 움직이면 브라우저 문제가 아니라 용량·스레드풀 문제로 올리세요: 서버가 요청엔 답하지만 심장박동을 처리할 여유가 없을 만큼 뜨겁게 돌고 있는 것입니다.
• 한 회사 네트워크에 국한되면 네트워크 팀에 넘기세요 — 검사 프록시나 방화벽이 장수 HTTP/2 연결에 간섭하고 있고, 그건 그들만 조정할 수 있습니다.