ERR_QUIC_PROTOCOL_ERROR: co oznacza i jak naprawić w Chrome

Czym jest ERR_QUIC_PROTOCOL_ERROR?

ERR_QUIC_PROTOCOL_ERROR oznacza, że połączenie QUIC Chrome ze stroną zerwało się, zwykle gdy strona zaczęła już wysyłać treść. QUIC to oparty na UDP protokół transportowy, na którym działa HTTP/3. Chrome pokazuje ogólną stronę „Ta witryna jest nieosiągalna” ("Strona internetowa pod adresem … może być tymczasowo niedostępna lub została na stałe przeniesiona pod nowy adres internetowy") z kodem poniżej; Chromium definiuje go jako błąd -356, "There is a QUIC protocol error".

Chrome zwykle sam sobie radzi: gdy żądanie QUIC się nie powiedzie, ponawia je zwykłym połączeniem TCP, chyba że serwer zdążył już zacząć odpowiadać (http_network_transaction.cc). Dlatego sieć, która całkowicie blokuje QUIC, nie powoduje tego błędu; powoduje go sieć, VPN lub serwer, który pozwala QUIC wystartować, a potem go przerywa.

Błąd występuje tylko w przeglądarkach opartych na Chromium: Chrome, Edge, Opera, Brave i Vivaldi. To inna awaria niż ERR_SSL_PROTOCOL_ERROR (zerwany handshake TLS) i ERR_NETWORK_CHANGED (połączenie się zmieniło). Najpierw odśwież stronę, bo ponowna próba często działa; jeśli błąd wciąż wraca, poniższe rozwiązania zaczynają się od najpewniejszego, czyli wyłączenia QUIC, a potem przechodzą przez kolejne przyczyny.

Czym jest QUIC i dlaczego Chrome go używa?

QUIC opracował Google, po raz pierwszy ogłoszono go w 2013 roku, a IETF ustandaryzował go jako RFC 9000 w 2021 roku. Zastępuje TCP + TLS jednym szyfrowanym protokołem na UDP i jest transportem dla HTTP/3 (Prywatny DNS w Androidzie też go używa do DNS przez HTTP/3: zobacz czym jest prywatny DNS).

Połączenie TCP + TLS 1.3 potrzebuje dwóch rund przed pierwszym żądaniem; QUIC potrzebuje jednej i może wznowić połączenie bez żadnej. 7 października 2020 roku Google ogłosił, że 25% użytkowników Chrome Stable korzysta już z IETF QUIC (wersja robocza h3-29). Google zmierzył spadek opóźnień w Wyszukiwarce o ponad 2%, spadek rebufferingu w YouTube o ponad 9% oraz wzrost przepustowości o ponad 3% na komputerach i 7% na urządzeniach mobilnych (Chromium Blog).

Chrome używa QUIC tylko wtedy, gdy strona go ogłasza, w nagłówku Alt-Svc albo w rekordzie HTTPS w DNS. Sprawdziliśmy 20 najczęściej odwiedzanych stron 26 października 2026 roku: 10 ogłasza HTTP/3 w nagłówku Alt-Svc (Google, YouTube, Facebook, Instagram, Amazon, LinkedIn, Bing, WhatsApp, Cloudflare i OpenAI).

Co powoduje ERR_QUIC_PROTOCOL_ERROR?

Każda przyczyna ma ten sam schemat: QUIC wystartował, a potem coś go przerwało.

• Sieć, która pozwala QUIC wystartować, a potem go przerywa — zapory, routery lub sprzęt dostawcy internetu, które gubią ruch UDP albo zrywają go po limicie czasu w połowie transferu. (Sieć, która całkowicie blokuje UDP 443, sprawia tylko, że Chrome używa TCP, bez żadnego błędu.)
• VPN, który gubi UDP w trakcie połączenia — gdy VPN łączy się ponownie, zmienia serwer lub trasę albo zrywa nieaktywne strumienie UDP po limicie czasu, otwarte połączenie QUIC umiera. (Zbyt wąska ścieżka dla QUIC zawodzi już podczas handshake'u, a wtedy Chrome po prostu używa TCP.)
• Oprogramowanie zabezpieczające, które sprawdza ruch — "ochrona sieciowa" antywirusa lub zapory, przechwytująca połączenia, może psuć strumienie QUIC.
• Niestabilne połączenie — słabe Wi-Fi albo zmiana sieci w trakcie pobierania.
• Konfiguracja HTTP/3 strony — serwer lub CDN, który ogłasza HTTP/3, ale jego stos QUIC zawodzi w połowie odpowiedzi. Wtedy wszyscy widzą błąd właśnie na tej jednej stronie, w każdej sieci: Sprawdzanie, czy strona działa pokaże, czy u innych też się nie otwiera.
• Nie jest przyczyną: proxy — Chrome używa QUIC tylko przy połączeniach bezpośrednich, więc przy ustawionym proxy każde żądanie idzie przez TCP.

Rozwiązanie 1: wyłącz protokół QUIC w Chrome

Najpewniejsze rozwiązanie: przy wyłączonym QUIC Chrome używa HTTP/2 (lub HTTP/1.1) przez TCP dla każdej strony. Strony nadal się ładują; tracisz tylko przewagę szybkości QUIC, którą Google zmierzył na około 2% szybszą Wyszukiwarkę i 9% mniej rebufferingu w YouTube.

Dla administratorów IT: zasada Chrome i Edge QuicAllowed ustawiona na false wyłącza QUIC na zarządzanych urządzeniach, bez ruszania chrome://flags.

Wyłączenie QUIC w Google Chrome

Wykonaj te kroki, aby wyłączyć QUIC w Chrome w systemie Windows, Mac lub Linux.

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

Wyłączenie QUIC w Microsoft Edge

Ponieważ Edge jest oparty na Chromium, proces jest niemal identyczny.

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

Wyłączenie QUIC w Operze i Brave

Opera i Brave korzystają z tego samego systemu flag Chromium.

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

Rozwiązanie 2: zresetuj połączenia Chrome

Czyszczenie danych rzadko to naprawia, ale zresetowanie otwartych połączeń może pomóc: Chrome zacznie wtedy nowe połączenia QUIC (lub TCP) ze stroną.

Opróżnij połączenia, a potem wyczyść pamięć podręczną

Zacznij od Flush socket pools (zobacz uwagę poniżej). Jeśli błąd nie znika, wyczyść pamięć podręczną:

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

Rozwiązanie 3: wyłącz rozszerzenia przeglądarki

Rzadko to przyczyna: rozszerzenia nie mogą zmienić samego QUIC, a rozszerzenia "VPN" w Chrome na komputerze to w rzeczywistości proxy, które w ogóle uniemożliwiają Chrome używanie QUIC.

Otwórz stronę w oknie incognito (Ctrl+Shift+N), gdzie rozszerzenia są wyłączone, chyba że na to pozwoliłeś. Jeśli tam się załaduje, wyłączaj rozszerzenia po kolei w chrome://extensions/, żeby znaleźć winowajcę.

Rozwiązanie 4: sprawdź ustawienia zapory i antywirusa

Zapora, która całkowicie blokuje port UDP 443, nie powoduje tego błędu: Chrome po prostu używa TCP. Kłopot sprawia zapora lub pakiet zabezpieczeń, który pozwala QUIC wystartować, a potem go odrzuca albo inspekcjonuje.

Zezwól na wychodzące UDP 443 w całości albo zablokuj je w całości. Oto jak sprawdzić typowe konfiguracje.

Zapora systemu Windows

Zapora Windows Defender domyślnie zezwala na ruch wychodzący, a reguła blokująca zawsze wygrywa z regułą zezwalającą, więc poszukaj reguły blokującej, którą ktoś dodał, i wyłącz ją. Uruchom PowerShell jako administrator:

# 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>'

Zapora macOS

Wbudowana zapora macOS kontroluje tylko połączenia przychodzące, więc nie może blokować QUIC. Jeśli używasz zapory dla ruchu wychodzącego, takiej jak Little Snitch lub LuLu, sprawdź jej reguły dla ruchu UDP Chrome na port 443.

Zapory na poziomie routera

Najszybszy test: połącz się z hotspotem w telefonie i załaduj stronę. Jeśli błąd znika, przyczyną jest twój router, sprzęt dostawcy internetu lub zapora w biurze.

Potem poszukaj na stronie administracyjnej routera (zwykle 192.168.1.1 lub 192.168.0.1) ustawień zapory, "SPI" lub zabezpieczeń ograniczających UDP i zaktualizuj jego firmware.

Rozwiązanie 5: sprawdź swój VPN

VPN tuneluje cały twój ruch, także UDP, więc QUIC zwykle przechodzi przez niego bez problemu. Kłopot zaczyna się, gdy sam tunel jest niestabilny: ponowne połączenie, zmiana serwera lub trasy albo VPN, który zrywa nieaktywne strumienie UDP po limicie czasu, zabija otwarte połączenia QUIC.

Rozłącz VPN i odśwież stronę. Jeśli błąd znika, spróbuj tego:

• Zmień serwer lub protokół VPN — stabilniejszy serwer albo inny protokół często kończy zrywanie połączeń
• VPN firmowe — wiele sieci firmowych celowo blokuje QUIC, żeby móc sprawdzać HTTPS; stosuj się do konfiguracji od IT i wyłącz QUIC, jeśli błędy nie znikają
• Zostaw QUIC wyłączony na czas korzystania z VPN — Rozwiązanie 1 działa z każdym VPN, bo Chrome używa wtedy TCP

Rozwiązanie 6: poszukaj ukrytego proxy lub filtra ruchu

Ustawienie proxy nie powoduje tego błędu: Chrome używa QUIC tylko przy połączeniach bezpośrednich, więc przy proxy każde żądanie idzie przez TCP. Za proxy może jednak uchodzić oprogramowanie zabezpieczające lub VPN, które filtruje ruch na poziomie sieci bez żadnego ustawienia proxy.

Jeśli błąd pojawia się w każdej sieci, ale tylko na tym komputerze, wyłączaj takie oprogramowanie ("web shield", "ochrona sieci", aplikację VPN działającą w tle) po kolei i odświeżaj stronę.

Rozwiązanie 7: zaktualizuj Chrome do najnowszej wersji

Kod QUIC w Chrome jest regularnie aktualizowany, a aktualizacje naprawiają błędy po stronie Chrome w obsłudze połączenia. Zaktualizuj Chrome (lub Edge, Operę, Brave), zanim cokolwiek zmienisz na komputerze, który przez jakiś czas był offline.

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 

Problemy z QUIC po stronie serwera (dla właścicieli stron)

Jeśli jesteś właścicielem strony, a odwiedzający zgłaszają ERR_QUIC_PROTOCOL_ERROR, problem może leżeć po stronie twojego serwera. Oto najczęstsze przyczyny po stronie serwera.

• Ustawienie HTTP/3 w Cloudflare — jeśli odwiedzający zgłaszają błąd, a używasz Cloudflare, sprawdź Speed > Settings > Protocol Optimization > HTTP/3 i przetestuj z wyłączoną opcją przez jakiś czas
• HTTP/3 na własnym serwerze — nginx ma HTTP/3 od wersji 1.25.0 (listen 443 quic reuseport; plus nagłówek Alt-Svc); LiteSpeed i Caddy też go obsługują. Upewnij się, że nasłuch UDP na porcie 443 jest dostępny, a twój stos QUIC jest aktualny. QUIC zawsze używa TLS 1.3: Sprawdź certyfikat SSL pokaże, czy twój serwer go oferuje
• Load balancery, które nie przekazują UDP — load balancery aplikacji, takie jak AWS ALB, przenoszą tylko TCP. Jeśli ogłaszasz h3 w Alt-Svc, nie przekazując UDP 443, Chrome oznacza QUIC jako uszkodzony dla twojej strony na 5 minut, potem próbuje ponownie, podwajając czekanie do 2 dni, i za każdym razem ściga się z TCP: usuń nagłówek albo użyj load balancera warstwy 4 obsługującego UDP

# 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

Czy QUIC zostawić włączony, czy wyłączyć?

Wyłączenie QUIC to bezpieczne rozwiązanie, ale w zdrowej sieci tracisz realną szybkość. Praktyczny sposób, żeby zdecydować:

Zostaw QUIC włączony w domu, w sieci komórkowej i w każdej sieci, w której błąd się nie pojawia. Dane samego Google pokazują szybszą Wyszukiwarkę, mniej rebufferingu wideo i większą przepustowość, a QUIC utrzymuje połączenia przy przełączeniu telefonu z Wi-Fi na sieć komórkową.

Wyłącz QUIC w sieci lub VPN, w których błąd wciąż wraca. Chrome używa wtedy HTTP/2 (lub HTTP/1.1) przez TCP, który obsługuje każda sieć; większość osób nie zauważy różnicy na dobrym łączu szerokopasmowym.

Gdy ta sama awaria zdarza się przez HTTP/2 zamiast QUIC, Chrome pokazuje ERR_HTTP2_PROTOCOL_ERROR, który ma własne przyczyny i rozwiązania.