ERR_HTTP2_PROTOCOL_ERROR는 인증서 문제인가요?

아닙니다. 이 오류는 TLS가 완전히 수립된 뒤에 발생하므로 인증서는 이미 검증됐습니다. 문제는 암호화된 연결 위에서 도는 HTTP/2 계층 — 브라우저와 서버가 프레이밍에서 어긋난 것이지 암호화가 아닙니다.

HTTP/1.1에서는 잘 열리는데 HTTP/2에서만 실패합니다. 왜죠?

HTTP/2는 HTTP/1.1보다 훨씬 엄격합니다. 헤더 필드명은 소문자여야 하고, 특정 헤더는 거부되며, 프레임·스트림 규칙(RFC 9113)을 강제합니다. HTTP/1.1이 봐주던 것 — 대문자 헤더, 본문과 안 맞는 Content-Length — 이 HTTP/2에서는 치명적 PROTOCOL_ERROR가 됩니다.

일부 사용자에게만 실패합니다. 왜죠?

그들의 경로에 있는 중간 장치 — 회사 프록시, VPN, TLS를 검사하는 백신 — 가 HTTP/2 스트림을 Chrome이 거부하는 방식으로 다시 쓰거나 재구성할 수 있습니다. origin은 멀쩡하고, 브라우저와 서버 사이의 무언가가 프레임을 망가뜨리는 것입니다.

조회수: 119

ERR_HTTP2_PROTOCOL_ERROR 해결

ERR_HTTP2_PROTOCOL_ERROR는 TLS 연결 후 HTTP/2 세션이 깨진 것. 서버 설정, 헤더, CDN을 3단계로 점검합니다. 무료 HTTP 진단으로 바로 확인.

내 도메인에 이 문제가 있는지 지금 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.

Problem

Chrome이 ERR_HTTP2_PROTOCOL_ERROR로 페이지 로드에 실패합니다. 사이트는 도달 가능했고 TLS도 연결됐는데, 요청이 스트림 도중에 끊겼습니다.

Symptoms

Chrome이 ERR_HTTP2_PROTOCOL_ERROR를 표시하고 페이지가 비거나 부분만 로드됩니다.
일부 자산은 로드되고 일부는 안 되거나, 새로고침하면 되기도 합니다.
같은 URL이 HTTP/1.1로 강제된 클라이언트나 다른 네트워크에서는 잘 열립니다.

이 오류의 실제 의미

이것은 연결 오류도, TLS 오류도 아닙니다. 이 화면을 볼 때쯤이면 TCP 연결은 열려 있고 TLS 핸드셰이크는 완료됐으며 — 인증서는 이미 검증됐습니다. 깨진 것은 그 암호화된 터널 안에서 도는 HTTP/2 대화입니다.

HTTP/2(2022년 원본 RFC 7540을 대체한 RFC 9113)는 HTTP/1.1에 없던 규칙을 가진 바이너리 멀티플렉싱 프로토콜입니다. 헤더 필드명은 소문자여야 합니다. 연결 전용 헤더 몇 가지는 금지됩니다. 프레임은 유효한 상태에서 도착해야 하고, 금지 헤더를 담거나 필수 헤더가 빠지거나 실제로 보낸 본문과 Content-Length가 안 맞으면 요청·응답이 “malformed”로 간주됩니다. 어느 쪽이든 이를 감지하면 규격은 이를 PROTOCOL_ERROR 유형의 스트림 오류로 다루고 RST_STREAM을 보내라고 규정합니다 — 이것이 Chrome에서 ERR_HTTP2_PROTOCOL_ERROR로 나타납니다.

실무적 해석: 누군가 HTTP/2를 잘못 말하고 있습니다. 대개 서버, 때로는 중간의 장치입니다.

Top 3 Causes

서버가 malformed HTTP/2 응답을 내보냄 - 대문자 헤더명, 헤더 값의 불법 문자, 실제 전송 바이트와 어긋나는 Content-Length. HTTP/1.1은 넘어갔지만 HTTP/2는 스트림을 끊습니다. 버그 있는 애플리케이션 코드나 오래된 서버 모듈이 흔한 원인입니다.
깨졌거나 반쯤 켜진 HTTP/2 서버 설정 - http2 지시자가 없거나 잘못 적용됨(nginx listen 443 ssl에 http2 누락, Apache에 mod_http2/Protocols h2 없음), 또는 모듈 버전에 알려진 프레이밍 버그가 있음. 서버는 HTTP/2를 광고하지만 구현이 잘못됐습니다.
중간 장치가 스트림을 재구성 - CDN, 리버스 프록시, 회사 프록시, VPN, TLS 검사 백신이 헤더를 다시 쓰거나 프레임을 Chrome이 거부하는 방식으로 재포장합니다. 오류가 네트워크·사용자별로 나타나는 이유입니다.

Diagnose with DechoNet

HTTP 진단으로 서버가 실제 반환하는 응답 헤더와 상태를 확인 — malformed·과대 헤더와 Content-Length 불일치가 여기서 드러납니다.
SSL 진단으로 TLS 자체가 건강한지 확인해 HTTP/2 아래 계층을 배제합니다.
포트 진단으로 443 포트 도달 가능 여부를 확인해 연결 문제가 아님을 확인합니다.

Resolution Checklist

HTTP/2 특유의 문제인지 확인: 같은 URL을 HTTP/1.1로 로드(또는 서버에서 HTTP/2를 한 번만 끄기). HTTP/1.1이 되면 프레이밍 계층이 범인입니다.
HTTP 진단을 실행해 대문자 헤더명, 헤더 값의 쓰레기 문자, 본문과 안 맞는 Content-Length를 찾아 애플리케이션에서 고칩니다.
서버 HTTP/2가 실제로 켜져 있고 최신인지 확인(nginx listen 443 ssl http2 / Apache 최신 mod_http2와 Protocols h2 http/1.1).
앞단에 CDN·프록시가 있으면 HTTP/2 설정을 토글하고 업데이트합니다. 알려진 버그가 있는 엣지 버전은 프레임을 손상시킬 수 있습니다.
사용자별 실패는 VPN, 회사 프록시, TLS 검사 백신을 끈 상태로 테스트해 중간 장치를 격리합니다.
수정 후 HTTP 진단을 재실행해 응답이 깨끗한지 확인합니다.

When to Escalate

HTTP 진단은 origin 응답이 깨끗한데 오류가 그들의 엣지를 통해서만 나타나면, 깨진 프레이밍은 그쪽에 있으니 CDN·호스팅 제공업체로 에스컬레이션하세요.
malformed 헤더가 직접 소유하지 않은 애플리케이션 코드(프레임워크, 플러그인)에서 온다면, HTTP/2를 영구히 끄는 대신(오류를 느린 로드로 바꿀 뿐) 해당 헤더를 유지보수자에게 구체적으로 신고하세요.