ERR_QUIC_PROTOCOL_ERROR 해결: 뜻과 QUIC 비활성화 방법 (Chrome·Edge)

ERR_QUIC_PROTOCOL_ERROR란 무엇입니까?

ERR_QUIC_PROTOCOL_ERROR는 Chrome과 웹사이트 사이의 QUIC 연결이, 대개 사이트가 페이지를 보내기 시작한 뒤에 끊겼다는 뜻입니다. QUIC는 HTTP/3의 바탕이 되는 UDP 기반 전송 방식입니다. Chrome은 일반적인 "사이트에 연결할 수 없음" 페이지("…의 웹페이지가 일시적으로 다운되었거나 새 웹 주소로 완전히 이동했을 수 있습니다.") 아래에 이 코드를 표시하며, Chromium에서는 -356번 오류, "There is a QUIC protocol error"로 정의되어 있습니다.

Chrome은 보통 스스로 복구합니다. QUIC 요청이 실패하면, 서버가 이미 응답을 시작한 경우가 아닌 한 일반 TCP 연결로 요청을 다시 보냅니다(http_network_transaction.cc). 그래서 QUIC를 완전히 차단하는 네트워크는 이 오류를 일으키지 않습니다. 오류를 일으키는 것은 QUIC 시작은 허용하고 그다음에 끊어 버리는 네트워크, VPN, 서버입니다.

이 오류는 Chrome, Edge, Opera, Brave, Vivaldi 같은 Chromium 기반 브라우저에서만 나타납니다. ERR_SSL_PROTOCOL_ERROR(TLS 핸드셰이크 실패)나 ERR_NETWORK_CHANGED(연결이 바뀜)와는 다른 문제입니다. 먼저 새로고침하십시오. 재시도로 해결되는 경우가 많습니다. 오류가 계속 돌아온다면, 아래 해결 방법은 가장 확실한 QUIC 끄기부터 시작해 원인별로 하나씩 짚어 갑니다.

QUIC란 무엇이며 Chrome이 사용하는 이유는?

QUIC는 Google이 개발해 2013년에 처음 발표했고, 2021년에 IETF가 RFC 9000으로 표준화했습니다. TCP + TLS를 UDP 위에서 동작하는 하나의 암호화 프로토콜로 대체하며, HTTP/3의 바탕이 됩니다(Android의 비공개 DNS도 DNS over HTTP/3에 이를 사용합니다. 비공개 DNS란 무엇인가 참조).

TCP + TLS 1.3 연결은 첫 요청 전에 왕복이 두 번 필요하지만, QUIC는 한 번이면 되고 재개할 때는 0번도 가능합니다. 2020년 10월 7일 Google은 Chrome 안정 버전 사용자의 25%가 이미 IETF QUIC(초안 h3-29)를 쓰고 있다고 발표했습니다. Google은 검색 지연이 2% 넘게 줄고, YouTube 재버퍼링이 9% 넘게 줄었으며, 처리량이 데스크톱에서 3% 넘게, 모바일에서 7% 넘게 늘었다고 측정했습니다(Chromium Blog).

Chrome은 사이트가 Alt-Svc 헤더나 DNS HTTPS 레코드로 알린 경우에만 QUIC를 사용합니다. 2026년 10월 26일에 가장 많이 방문하는 사이트 20곳을 확인했더니, 10곳이 Alt-Svc 헤더로 HTTP/3를 알리고 있었습니다(Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare, OpenAI).

ERR_QUIC_PROTOCOL_ERROR의 원인

모든 원인은 같은 패턴입니다. QUIC는 시작되었는데, 그다음에 무언가가 끊어 버립니다.

• QUIC 시작은 허용하고 그다음에 끊어 버리는 네트워크 — 전송 도중 UDP 트래픽을 버리거나 타임아웃시키는 방화벽, 라우터, ISP 장비. (UDP 443을 완전히 차단하는 네트워크는 Chrome이 TCP를 쓰게 할 뿐이며 오류가 나지 않습니다.)
• 연결 도중 UDP를 놓치는 VPN — VPN이 다시 연결되거나 서버나 경로를 바꾸거나 조용한 UDP 흐름을 타임아웃시키면 열려 있던 QUIC 연결이 끊깁니다. (QUIC에 너무 작은 경로는 핸드셰이크 단계에서 실패하며, 그때는 Chrome이 TCP를 씁니다.)
• 트래픽을 검사하는 보안 소프트웨어 — 연결을 가로채는 백신이나 방화벽의 "웹 보호" 기능이 QUIC 스트림을 깨뜨릴 수 있습니다.
• 불안정한 연결 — 약한 Wi-Fi, 또는 다운로드 도중 네트워크를 바꾸는 경우.
• 웹사이트의 HTTP/3 설정 — HTTP/3를 알리면서도 QUIC 스택이 응답 도중 실패하는 서버나 CDN. 이 경우 모든 사람이 어느 네트워크에서든 그 사이트에서만 오류를 봅니다. 사이트 다운 확인로 다른 사람에게도 실패하는지 확인할 수 있습니다.
• 원인이 아닌 것: 프록시 — Chrome은 직접 연결에서만 QUIC를 사용하므로, 프록시가 설정되어 있으면 모든 요청이 TCP로 전달됩니다.

해결 방법 1: Chrome에서 QUIC 프로토콜 비활성화

가장 확실한 해결 방법입니다. QUIC를 끄면 Chrome은 모든 사이트에서 TCP 위의 HTTP/2(또는 HTTP/1.1)를 사용합니다. 페이지는 그대로 로드되며, QUIC의 속도 이점만 포기하게 됩니다. Google이 측정한 수준은 검색이 약 2% 빨라지고 YouTube 재버퍼링이 9% 줄어드는 정도입니다.

IT 관리자용: Chrome과 Edge의 QuicAllowed 정책을 false로 설정하면 chrome://flags를 건드리지 않고도 관리되는 기기에서 QUIC를 끌 수 있습니다.

Google Chrome에서 QUIC 비활성화

Windows, Mac, Linux에서 Chrome의 QUIC를 비활성화하려면 다음 단계를 따르십시오.

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Microsoft Edge에서 QUIC 비활성화

Edge는 Chromium 기반이므로 과정이 거의 동일합니다.

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

Opera 및 Brave에서 QUIC 비활성화

Opera와 Brave도 동일한 Chromium 플래그 시스템을 사용합니다.

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

해결 방법 2: Chrome의 연결 초기화

데이터를 삭제해도 이 문제가 해결되는 경우는 드물지만, 열려 있는 연결을 초기화하면 해결될 수 있습니다. 그러면 Chrome이 사이트와 새 QUIC(또는 TCP) 연결을 처음부터 맺습니다.

연결을 초기화한 다음 캐시 삭제

먼저 Flush socket pools를 실행하십시오(아래 참고). 오류가 계속되면 캐시를 삭제합니다.

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

해결 방법 3: 브라우저 확장 프로그램 비활성화

원인인 경우는 드뭅니다. 확장 프로그램은 QUIC 자체를 바꿀 수 없고, 데스크톱 Chrome의 "VPN" 확장 프로그램은 사실 프록시여서 Chrome이 QUIC를 아예 쓰지 않게 만듭니다.

사이트를 시크릿 창(Ctrl+Shift+N)에서 여십시오. 허용하지 않은 한 확장 프로그램은 꺼져 있습니다. 거기서 로드된다면 chrome://extensions/에서 확장 프로그램을 하나씩 꺼 가며 원인을 찾으십시오.

해결 방법 4: 방화벽 및 백신 설정 확인

UDP 포트 443을 완전히 차단하는 방화벽은 이 오류를 일으키지 않습니다. Chrome이 TCP를 쓸 뿐입니다. 문제는 QUIC 시작은 허용한 뒤 도중에 패킷을 버리거나 검사하는 방화벽이나 보안 제품입니다.

아웃바운드 UDP 443을 완전히 허용하거나 완전히 차단하십시오. 흔한 환경별 확인 방법은 다음과 같습니다.

Windows 방화벽

Windows Defender 방화벽은 기본적으로 아웃바운드 트래픽을 허용하고, 차단 규칙은 항상 허용 규칙보다 우선합니다. 그러니 누군가 추가한 차단 규칙을 찾아 끄십시오. PowerShell을 관리자 권한으로 실행합니다.

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

macOS 방화벽

macOS의 내장 방화벽은 들어오는 연결만 제어하므로 QUIC를 차단할 수 없습니다. Little Snitch나 LuLu 같은 아웃바운드 방화벽을 쓰고 있다면, 포트 443으로 가는 Chrome의 UDP 트래픽에 대한 규칙을 확인하십시오.

라우터 수준 방화벽

가장 빠른 테스트는 스마트폰의 모바일 핫스팟에 연결해 사이트를 로드해 보는 것입니다. 오류가 사라지면 원인은 라우터, ISP 장비 또는 사무실 방화벽입니다.

그런 다음 라우터 관리 페이지(보통 192.168.1.1 또는 192.168.0.1)에서 UDP를 제한하는 방화벽, "SPI", 보안 설정을 찾아보고 펌웨어를 업데이트하십시오.

해결 방법 5: VPN 확인

VPN은 UDP를 포함한 모든 트래픽을 터널로 보내므로 QUIC도 보통은 그대로 통과합니다. 문제는 터널 자체가 불안정할 때 생깁니다. 재연결, 서버나 경로 변경, 조용한 UDP 흐름을 타임아웃시키는 VPN은 열려 있는 QUIC 연결을 끊습니다.

VPN을 끊고 새로고침하십시오. 오류가 사라진다면 다음을 시도하십시오.

• VPN 서버나 프로토콜 바꾸기 — 더 안정적인 서버나 다른 프로토콜로 끊김이 멈추는 경우가 많습니다
• 회사 VPN — 많은 회사 네트워크가 HTTPS를 검사하려고 일부러 QUIC를 차단합니다. IT 담당자의 설정을 따르고, 오류가 계속되면 QUIC를 끄십시오
• VPN을 쓰는 동안 QUIC 꺼 두기 — 해결 방법 1은 모든 VPN에서 통합니다. 그러면 Chrome이 TCP를 쓰기 때문입니다

해결 방법 6: 숨은 프록시나 트래픽 필터 찾기

프록시 설정은 이 오류의 원인이 아닙니다. Chrome은 직접 연결에서만 QUIC를 사용하므로, 프록시가 있으면 모든 요청이 TCP로 전달됩니다. 다만 프록시처럼 보일 수 있는 것은 프록시 설정 없이 네트워크 수준에서 트래픽을 걸러 내는 보안 소프트웨어나 VPN 소프트웨어입니다.

어느 네트워크에서든 이 컴퓨터에서만 오류가 난다면, 그런 소프트웨어("웹 실드", "네트워크 보호", 백그라운드에서 실행되는 VPN 앱)를 하나씩 끄고 새로고침해 보십시오.

해결 방법 7: Chrome을 최신 버전으로 업데이트

Chrome의 QUIC 코드는 정기적으로 업데이트되며, 업데이트로 Chrome 쪽 연결 처리의 버그가 수정됩니다. 한동안 오프라인이었던 컴퓨터라면 다른 것을 바꾸기 전에 Chrome(또는 Edge, Opera, Brave)부터 업데이트하십시오.

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

서버 측 QUIC 문제 (웹사이트 소유자용)

웹사이트 소유자이고 방문자가 ERR_QUIC_PROTOCOL_ERROR를 보고하는 경우, 서버에 원인이 있을 수 있습니다. 다음은 가장 흔한 서버 측 원인입니다.

• Cloudflare HTTP/3 설정 — 방문자가 오류를 보고하고 Cloudflare를 쓰고 있다면 Speed > Settings > Protocol Optimization > HTTP/3을 확인하고, 한동안 끈 상태로 테스트해 보십시오
• 자체 서버의 HTTP/3 — nginx는 1.25.0부터 HTTP/3를 지원합니다(listen 443 quic reuseport;와 Alt-Svc 헤더). LiteSpeed와 Caddy도 지원합니다. 포트 443의 UDP 리스너에 접근할 수 있는지, QUIC 스택이 최신인지 확인하십시오. QUIC는 항상 TLS 1.3을 사용합니다. 서버가 TLS 1.3을 제공하는지는 SSL 인증서 확인에서 볼 수 있습니다
• UDP를 전달하지 않는 로드 밸런서 — AWS ALB 같은 애플리케이션 로드 밸런서는 TCP만 전달합니다. UDP 443을 전달하지 않으면서 Alt-Svc에 h3를 알리면, Chrome은 해당 사이트의 QUIC를 5분간 고장으로 표시하고, 이후 다시 시도하면서 대기 시간을 최대 2일까지 두 배씩 늘리고, 매번 TCP와 경쟁시킵니다. 헤더를 제거하거나 UDP를 지원하는(4계층) 로드 밸런서를 쓰십시오

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

QUIC를 활성화 상태로 유지할까, 비활성화할까?

QUIC를 끄는 것은 안전한 해결 방법이지만, 정상적인 네트워크에서는 실제 속도를 포기하는 셈입니다. 판단 기준은 다음과 같습니다.

QUIC를 켜 두십시오. 집, 모바일 데이터, 오류가 나타나지 않는 모든 네트워크에서입니다. Google의 자체 데이터에 따르면 QUIC로 검색이 빨라지고, 동영상 재버퍼링이 줄고, 처리량이 늘어납니다. 스마트폰이 Wi-Fi에서 모바일 데이터로 바뀔 때도 QUIC가 연결을 유지해 줍니다.

QUIC를 끄십시오. 오류가 계속 돌아오는 네트워크나 VPN에서입니다. 그러면 Chrome은 어떤 네트워크든 처리할 수 있는 TCP 위의 HTTP/2(또는 HTTP/1.1)를 씁니다. 좋은 광대역 회선에서는 대부분 차이를 느끼지 못합니다.

QUIC가 아닌 HTTP/2에서 같은 종류의 실패가 생기면 Chrome은 ERR_HTTP2_PROTOCOL_ERROR를 표시합니다. 이 오류는 원인과 해결 방법이 따로 있습니다.