chrome://flags에서 QUIC를 끄면 해결된 건가요?

해결이 아니라 임시 우회입니다. 'Experimental QUIC protocol' 플래그를 끄면 Chrome이 TCP·HTTP/2로 되돌아가 내 화면에서는 오류가 사라집니다. 하지만 원인이 서버나 CDN에 있다면 QUIC를 쓰는 다른 사용자는 여전히 같은 오류를 만납니다. QUIC를 꺼서 'QUIC 경로가 문제'라는 진단만 확정하고, HTTP/3를 포기하는 대신 실제 원인을 고치세요.

휴대폰 셀룰러에서는 되는데 회사 와이파이에서만 안 됩니다. 왜죠?

QUIC는 UDP 443 포트로 동작하는데, 많은 기업 방화벽과 네트워크 장비가 TCP 443은 허용하면서 UDP 443은 조용히 차단합니다. UDP를 막는 네트워크에서는 Chrome의 QUIC 시도가 갈 곳을 잃고, UDP가 자유로운 셀룰러에서는 같은 사이트가 연결됩니다. 네트워크에 따라 갈리는 실패는 중간 장비가 UDP를 삼키고 있다는 가장 강한 신호입니다.

인증서나 TLS 문제인가요?

아닙니다. QUIC는 TLS 1.3이 내장돼 있어 인증서 문제라면 QUIC 오류가 아니라 TLS 오류로 나타납니다. ERR_QUIC_PROTOCOL_ERROR는 QUIC 전송 자체가 UDP 위에서 실패한 것 — 핸드셰이크나 스트림이 깨진 것입니다. 인증서가 완벽히 유효해도 이 오류는 뜰 수 있습니다.

조회수: 95

ERR_QUIC_PROTOCOL_ERROR 해결

ERR_QUIC_PROTOCOL_ERROR는 Chrome의 QUIC(HTTP/3, UDP 443) 연결이 깨진 것. 서버·UDP 443·중간 장비를 3단계로 진단합니다. 무료 즉시 진단으로 바로 확인.

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

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

Problem

Chrome이 ERR_QUIC_PROTOCOL_ERROR로 페이지 로드에 실패합니다. 다른 브라우저나 다른 네트워크에서는 열리는데, Chrome은 QUIC 연결에서 계속 죽습니다.

Symptoms

Chrome이 ERR_QUIC_PROTOCOL_ERROR를 표시하고 페이지가 비거나 절반만 렌더됩니다.
같은 URL이 Firefox·Safari에서는, 또는 다른 네트워크의 Chrome에서는 잘 열립니다.
특정 네트워크(주로 회사 와이파이)에서 실패하고 다른 네트워크(주로 셀룰러)에서는 됩니다.
chrome://flags에서 QUIC를 끄면 사라집니다 — 이건 해결책이 아니라 단서입니다.

What This Error Actually Means

QUIC는 Google이 만들고 IETF가 2021년 RFC 9000으로 표준화한 전송 프로토콜입니다. HTTP/3(RFC 9114)가 그 위에서 돕니다. 이전의 모든 것과 다른 핵심은 QUIC가 TCP가 아니라 UDP 위에서 돌고, TLS 1.3 핸드셰이크를 전송에 직접 접어 넣어 연결 설정에서 왕복 한 번을 줄인다는 점입니다.

이 오류가 생기는 지점이 여기입니다. 서버는 일반 HTTPS 응답에 Alt-Svc: h3=... 헤더를 실어 HTTP/3를 광고합니다. Chrome은 이를 기억했다가 다음 방문에서 UDP 443 위 QUIC 연결을 일반 TCP 연결과 경쟁시킵니다. QUIC가 되면 더 빠릅니다. QUIC 시도가 Chrome이 깔끔하게 복구하지 못하는 방식으로 깨지면, TCP로 조용히 되돌아가는 대신 ERR_QUIC_PROTOCOL_ERROR가 나타납니다.

그래서 이 오류는 “사이트가 죽었다”가 아닙니다. TCP 443은 보통 멀쩡합니다 — QUIC를 끄자마자 사이트가 열리는 이유가 그것입니다. 깨진 것은 UDP/QUIC 경로뿐입니다: 패킷이 통과하지 못하거나, 한쪽이 QUIC를 잘못 말하고 있는 것입니다.

Top 3 Causes

방화벽·중간 장비가 UDP 443을 차단 - 관리형 네트워크에서 가장 흔한 원인입니다. 기업 방화벽, 일부 가정용 라우터, 오래된 네트워크 장비는 443의 TCP는 통과시키면서 같은 포트의 UDP는 막거나 제한합니다 — 오랫동안 UDP로는 중요한 게 오가지 않았기 때문입니다. QUIC 패킷은 그 틈으로 사라집니다. 사이트가 아니라 네트워크를 따라 실패가 갈리는 것이 신호입니다.
서버나 CDN이 QUIC를 잘못 구현 - 어설픈 HTTP/3 도입, 버그 있는 엣지 빌드, Alt-Svc: h3를 광고하면서 QUIC 핸드셰이크를 제대로 처리 못 하는 오리진입니다. 서버가 HTTP/3를 약속해놓고 제대로 이행하지 못하니 Chrome 연결이 무너집니다.
로컬 중간 장비가 UDP 흐름을 망침 - 트래픽을 가로채는 VPN, TLS를 검사하는 백신, 브라우저 확장이 TCP는 놔두고 QUIC만 깰 수 있습니다. QUIC는 더 큰 UDP 데이터그램을 쓰므로, MTU가 작거나 단편화 처리가 거친 경로에서는 TCP는 견뎌도 핸드셰이크가 조용히 죽습니다.

Diagnose with DechoNet

HTTP 검사로 응답 헤더를 읽어 서버가 실제로 Alt-Svc: h3 헤더로 HTTP/3를 광고하는지, 그리고 TCP 위 일반 HTTPS 응답이 정상인지 확인하세요. TCP 응답은 깨끗한데 QUIC만 실패하면 문제는 UDP 경로로 좁혀집니다.
포트 검사로 443이 열려 있고 사이트가 도달 가능한지 확인해, 실제 연결 장애와 QUIC 한정 장애를 구분하세요.
SSL 검사로 TLS 계층을 완전히 배제하세요 — 인증서와 핸드셰이크가 유효하면 문제는 암호가 아니라 QUIC 전송에 있습니다.

Resolution Checklist

QUIC 한정 문제인지 확정: chrome://flags에서 Experimental QUIC protocol을 Disabled로 바꾸고 재시작 후 새로고침. 페이지가 이제 열리면 QUIC 경로가 원인 — 여기서 멈추지 말고 계속 진단하세요.
다른 네트워크(셀룰러 테더링)로 테스트. 회사 네트워크 밖에서 되면 방화벽이 UDP 443을 막는 것 — 모든 클라이언트에서 QUIC를 끄는 대신 네트워크 팀과 규칙을 고치세요.
VPN, TLS 검사 백신, 확장을 하나씩 꺼가며 로컬 중간 장비를 격리하세요.
서버나 CDN을 운영한다면: HTTP/3 설정과 엣지 버전을 점검하거나, QUIC가 고쳐질 때까지 Alt-Svc: h3 헤더 전송을 잠시 멈춰 클라이언트를 정상적인 HTTP/2에 머물게 하세요.
HTTP 검사를 다시 돌려 Alt-Svc 헤더와 TCP 응답이 기대대로인지 확인하세요.

When to Escalate

HTTP 검사에서 TCP 오리진은 깨끗한데 CDN을 통할 때만 QUIC가 실패하면 CDN에 문의하세요 — 그들의 HTTP/3 엣지가 끊긴 고리입니다.
실패가 한 사무실이나 ISP에 국한되면 네트워크 팀에 에스컬레이션하세요: UDP 443이 필터링되고 있으며, 지속 가능한 해결책은 모든 자리의 브라우저 플래그가 아니라 방화벽 규칙입니다.
QUIC가 깨진 상태로 Alt-Svc: h3를 광고하는 것은 HTTP/3를 아예 제공하지 않는 것보다 나쁩니다 — 영향받는 모든 사용자가 폴백 전에 실패한 연결 시도 비용을 치릅니다. 될 때까지 광고를 멈추세요.