Jak naprawić błąd ERR_SPDY_PROTOCOL_ERROR w Chrome

ERR_SPDY_PROTOCOL_ERROR to błąd sieciowy Chrome, który występuje, gdy przeglądarka nie może nawiązać lub utrzymać prawidłowej sesji SPDY lub HTTP/2 z serwerem WWW. Objawia się nieudanym ładowaniem strony, zazwyczaj wraz ze standardowym ekranem błędu Chrome, i może być wywołany przez nieaktualne połączenia socket, uszkodzone dane cache, niezgodności TLS/SSL, zakłócające rozszerzenia lub błędnie skonfigurowaną negocjację protokołu po stronie serwera.

Nazwa błędu odnosi się do SPDY — obecnie przestarzałego, multipleksowanego protokołu transportowego Google, który poprzedzał HTTP/2. Chociaż Chrome porzucił natywną obsługę SPDY po wersji 51, wewnętrzna warstwa zarządzania socketami i sesjami nadal używa terminologii wywodzącej się z SPDY, dlatego kod błędu utrzymuje się nawet w przypadku nowoczesnych połączeń HTTP/2 i HTTP/3. Zrozumienie tej różnicy jest niezbędne do dokładnego zdiagnozowania przyczyny.

Co tak naprawdę powoduje ERR_SPDY_PROTOCOL_ERROR

Przed ślepym stosowaniem poprawek warto poznać dokładne tryby awarii stojące za tym błędem:

• Nieaktualne sesje socket SPDY/HTTP2 zbuforowane w puli połączeń Chrome, które nie odpowiadają już aktualnemu stanowi TLS serwera
• Wygasłe lub ponownie wystawione certyfikaty SSL/TLS po stronie serwera, które unieważniają istniejącą sesję bez czystego resetu uzgadniania
• Niezgodności ALPN (Application-Layer Protocol Negotiation), gdzie serwer ogłasza obsługę HTTP/2, ale uzgadnianie TLS kończy się niepowodzeniem w trakcie sesji
• Uszkodzone dane profilu przeglądarki, w tym cache, pliki cookie lub plik stanu sieci
• Proxy, VPN lub oprogramowanie zabezpieczające wykonujące inspekcję TLS, która niszczy warstwę ramkowania HTTP/2
• Nieaktualne wersje Chrome ze znanymi błędami w implementacji HTTP/2 lub QUIC
• Błędna konfiguracja po stronie serwera — na przykład instancja Nginx lub Apache z uszkodzonym modułem h2 lub wygasłym certyfikatem na węźle brzegowym CDN

Poprawka 1: Bezpośrednie opróżnienie socketów SPDY

Jest to najbardziej ukierunkowana poprawka i powinna być Twoim pierwszym działaniem. Chrome utrzymuje trwałą pulę sesji socket SPDY/HTTP2. Jeśli sesja ulegnie uszkodzeniu — na przykład po restarcie serwera lub ponownym wystawieniu certyfikatu — Chrome będzie nadal używać uszkodzonej sesji, dopóki nie zostanie ona jawnie opróżniona.

1. Otwórz nową kartę Chrome.
2. Przejdź do chrome://net-internals/#sockets
3. Kliknij Flush socket pools.
4. Następnie przejdź do chrome://net-internals/#dns
5. Kliknij Clear host cache.
6. Zamknij kartę i przeładuj niedziałającą stronę.

To dwuetapowe opróżnienie czyści jednocześnie pulę sesji warstwy transportowej i cache rozwiązywania DNS, co w jednym przebiegu eliminuje dwie najczęstsze przyczyny błędów wewnątrz przeglądarki.

Dlaczego stary URL już nie działa: Wiele poradników nadal odwołuje się do chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active. Chrome usunął zakładkę Events w nowszych wersjach. Używaj bezpośrednio #sockets i #dns.

Poprawka 2: Wyczyszczenie cache przeglądarki i plików cookie

Zbuforowane odpowiedzi HTTP, przechowywane pliki cookie i nieaktualny stan HSTS (HTTP Strict Transport Security) mogą kolidować z aktualną konfiguracją TLS lub protokołu serwera.

1. Otwórz Chrome i naciśnij Ctrl+Shift+Delete (Windows/Linux) lub Cmd+Shift+Delete (macOS).
2. Ustaw Zakres czasu na Cały czas.
3. Zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki w pamięci podręcznej.
4. Kliknij Wyczyść dane.

W celu bardziej precyzyjnego podejścia — jeśli chcesz wyczyścić dane tylko dla jednej konkretnej domeny bez usuwania całego stanu przeglądarki — użyj następującego sposobu:

1. Przejdź do chrome://settings/siteData
2. Wyszukaj dotkniętą domenę.
3. Usuń tylko pliki cookie i dane przechowywane dla tej witryny.

Dodatkowo wyczyść stan HSTS dla domeny pod adresem chrome://net-internals/#hsts, wpisując nazwę hosta w polu Delete domain security policies. Nieaktualny wpis HSTS może zmusić Chrome do ścieżki aktualizacji, która koliduje z serwerem, który zmienił konfigurację TLS.

Poprawka 3: Aktualizacja Google Chrome

Implementacje HTTP/2 i QUIC w Chrome otrzymują częste łatki. Korzystanie z nieaktualnej wersji może oznaczać, że posiadasz znane błędy obsługi protokołu, które zostały już naprawione w nowszych wersjach.

1. Kliknij menu z trzema kropkami i przejdź do Pomoc > Informacje o Google Chrome.
2. Chrome automatycznie sprawdzi i pobierze aktualizacje.
3. Kliknij Uruchom ponownie, aby zastosować aktualizację.

Aby sprawdzić bieżącą wersję z paska adresu, przejdź do chrome://version/. Porównaj numer wersji z blogiem Chrome Releases, aby potwierdzić, że korzystasz z najnowszego stabilnego kanału.

Poprawka 4: Wyłączenie VPN, proxy i narzędzi inspekcji TLS

VPN, firmowe proxy i produkty antywirusowe wykonujące głęboką inspekcję SSL/TLS (zwane również przechwytywaniem HTTPS) są częstą i niedostatecznie diagnozowaną przyczyną ERR_SPDY_PROTOCOL_ERROR. Narzędzia te kończą połączenie TLS po stronie klienta, ponownie szyfrują je własnym certyfikatem i przekazują do serwera. Jeśli implementacja HTTP/2 narzędzia jest niekompletna lub łańcuch certyfikatów jest niezaufany, Chrome odrzuci sesję.

Aby wyłączyć ustawienia proxy w Windows:

1. Naciśnij Win+I, aby otworzyć Ustawienia.
2. Przejdź do Sieć i Internet > Serwer proxy.
3. Ustaw Automatycznie wykryj ustawienia na Włączone i Użyj serwera proxy na Wyłączone.

Aby wyłączyć ustawienia proxy przez Wiersz polecenia:

netsh winhttp reset proxy

Aby sprawdzić, czy proxy jest aktualnie aktywne:

netsh winhttp show proxy

Jeśli jesteś w sieci firmowej, skonsultuj się z administratorem IT przed wyłączeniem ustawień proxy, ponieważ może to naruszać politykę sieciową. Zamiast tego zapytaj, czy narzędzie inspekcji SSL obsługuje tryb przekazywania HTTP/2.

Poprawka 5: Resetowanie stosu TCP/IP i opróżnienie cache DNS

Uszkodzone wpisy stosu TCP/IP lub zatruty cache DNS mogą powodować błędy połączeń, które objawiają się jako błędy protokołu. Ta poprawka działa na poziomie warstwy sieciowej systemu operacyjnego, poniżej samego Chrome.

Otwórz Wiersz polecenia jako Administrator (naciśnij Win+R, wpisz cmd, następnie naciśnij Ctrl+Shift+Enter), a następnie uruchom kolejno następujące polecenia:

netsh int ip reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Uruchom ponownie komputer po wykonaniu tych poleceń. Polecenie netsh winsock reset jest szczególnie ważne — uszkodzony katalog Winsock może powodować sporadyczne i pozornie losowe błędy protokołu, które są trudne do prześledzenia do ich źródła.

Na macOS równoważne polecenie opróżnienia DNS to:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Poprawka 6: Wyłączenie lub izolacja rozszerzeń przeglądarki

Rozszerzenia przechwytujące żądania sieciowe — blokery reklam, narzędzia prywatności, rozszerzenia antywirusowe, rozszerzenia VPN i niestandardowe przełączniki proxy — mogą uszkadzać ramki HTTP/2 lub wstrzykiwać nagłówki naruszające specyfikację HTTP/2, wywołując błąd protokołu.

Metoda systematycznej izolacji:

1. Otwórz chrome://extensions/
2. Wyłącz wszystkie rozszerzenia jednocześnie.
3. Przeładuj niedziałającą stronę.
4. Jeśli błąd zniknął, włączaj rozszerzenia jedno po drugim, przeładowując stronę po każdym, aż do zidentyfikowania winowajcy.

Alternatywnie otwórz Chrome w trybie incognito (Ctrl+Shift+N), który domyślnie wyłącza wszystkie rozszerzenia (chyba że jawnie zezwoliłeś na nie w trybie incognito). Jeśli strona ładuje się poprawnie w trybie incognito, rozszerzenie jest definitywnie przyczyną.

Poprawka 7: Restart routera lub modemu

Tabele NAT (Network Address Translation) i stanowa inspekcja pakietów na routerach konsumenckich mogą przechowywać nieaktualne wpisy sesji TCP, które uniemożliwiają nowym połączeniom HTTP/2 ukończenie uzgadniania. Pełny cykl zasilania — nie tylko programowy restart — czyści te tabele.

1. Całkowicie wyłącz router i modem.
2. Poczekaj 60 sekund (nie 30 — kondensatory potrzebują czasu na pełne rozładowanie i wyczyszczenie stanu ulotnego).
3. Najpierw włącz modem, poczekaj na pełną synchronizację, a następnie włącz router.
4. Poczekaj na pełne połączenie przed testowaniem.

Poprawka 8: Tymczasowe wyłączenie antywirusa lub zapory sieciowej

Oprogramowanie zabezpieczające z funkcjami skanowania HTTPS lub tarczy internetowej działa podobnie do firmowego proxy inspekcji TLS. Przechwytuje uzgadnianie TLS, co może zakłócić negocjację sesji HTTP/2, jeśli silnik oprogramowania zabezpieczającego nie obsługuje w pełni rozszerzenia ALPN lub ramkowania HTTP/2.

Znane produkty powodujące ten problem to Avast, AVG, Kaspersky i ESET, gdy ich moduły ochrony internetowej są aktywne.

• Tymczasowo wyłącz funkcję Tarczy internetowej lub Skanowania HTTPS (nie całego antywirusa).
• Przetestuj niedziałający URL.
• Jeśli błąd zniknie, poszukaj opcji dodania dotkniętej witryny do listy wykluczeń skanowania HTTPS zamiast globalnego wyłączania ochrony.

Poprawka 9: Utworzenie nowego profilu Chrome

Uszkodzony profil użytkownika Chrome — konkretnie podfolder Network w katalogu profilu — może powodować trwały ERR_SPDY_PROTOCOL_ERROR przeżywający czyszczenie cache i opróżnianie socketów. Plik stanu sieci profilu przechowuje dane HSTS, dzienniki przejrzystości certyfikatów i zbuforowane wyniki negocjacji protokołu.

Aby przetestować z nowym profilem:

1. Przejdź do chrome://settings/
2. Przewiń do Osoby i kliknij Dodaj osobę (lub Dodaj profil).
3. Utwórz minimalny profil testowy.
4. Otwórz niedziałający URL w nowym profilu.

Jeśli URL ładuje się poprawnie w nowym profilu, problem jest izolowany do przechowywanego stanu sieci oryginalnego profilu. Możesz ręcznie usunąć folder Network z katalogu profilu bez utraty zakładek ani haseł:

• Windows: %LOCALAPPDATA%GoogleChromeUser DataDefaultNetwork
• macOS: ~/Library/Application Support/Google/Chrome/Default/Network
• Linux: ~/.config/google-chrome/Default/Network

Usuń folder Network przy zamkniętym Chrome, a następnie uruchom go ponownie.

Poprawka 10: Diagnozowanie i eskalacja problemów po stronie serwera

Jeśli wszystkie poprawki po stronie klienta zawiodą, błąd pochodzi z serwera. Typowe przyczyny po stronie serwera to:

• Wygasły lub niedawno ponownie wystawiony certyfikat SSL/TLS bez restartu serwera w celu załadowania nowego certyfikatu
• Uszkodzona konfiguracja HTTP/2 w Nginx (błędnie skonfigurowana dyrektywa http2) lub Apache (załadowany mod_http2, ale Protocols h2 http/1.1 niepoprawnie ustawiony)
• Błędna konfiguracja CDN lub odwrotnego proxy, gdzie węzeł brzegowy i serwer źródłowy mają sprzeczne ustawienia protokołu
• Niezgodność wersji TLS — na przykład serwer skonfigurowany do używania tylko TLS 1.3, podczas gdy pośrednie proxy obsługuje tylko TLS 1.2

Przykład poprawnej konfiguracji HTTP/2 w Nginx:

server {
    listen 443 ssl;
    http2 on;
    ssl_certificate     /etc/ssl/certs/your_domain.crt;
    ssl_certificate_key /etc/ssl/private/your_domain.key;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
}

Uwaga: W Nginx 1.25.1+, http2 on zastępuje starszą składnię listen 443 ssl http2. Używanie przestarzałej składni w nowszych wersjach może powodować błędy negocjacji ALPN.

Przykład poprawnej konfiguracji HTTP/2 w Apache:

Protocols h2 http/1.1
SSLEngine on
SSLCertificateFile    /etc/ssl/certs/your_domain.crt
SSLCertificateKeyFile /etc/ssl/private/your_domain.key

Jeśli zarządzasz własną infrastrukturą serwerową, upewnienie się, że Twoje Certyfikaty SSL są ważne, prawidłowo połączone w łańcuch i odnawiane przed wygaśnięciem, eliminuje najczęstszy wyzwalacz tego błędu po stronie serwera. Środowiska hostingowe działające na odpowiednio utrzymywanym Hostingu VPS dają bezpośredni dostęp do plików konfiguracyjnych serwera, co ułatwia stosowanie tych poprawek bez czekania na dostawcę hostingu współdzielonego.

Dla zespołów uruchamiających aplikacje internetowe na Serwerach Dedykowanych, weryfikacja, czy mod_http2 lub moduł HTTP/2 Nginx jest poprawnie skompilowany i włączony, powinna być częścią każdej listy kontrolnej po wdrożeniu.

Narzędzia diagnostyczne do szybszego identyfikowania przyczyny

Przed sekwencyjnym przechodzeniem przez każdą poprawkę użyj tych narzędzi, aby zawęzić źródło problemu:

Polecenie curl jest szczególnie przydatne do potwierdzenia, czy problem dotyczy konkretnej przeglądarki, czy całego serwera:

curl -v --http2 https://your-domain.com 2>&1 | grep -E "ALPN|HTTP|SSL|error"

Jeśli curl również nie może wynegocjować HTTP/2, problem definitywnie leży po stronie serwera. Jeśli curl powiedzie się, ale Chrome zawiedzie, problem tkwi w stanie sesji przeglądarki lub lokalnym narzędziu przechwytującym.

ERR_SPDY_PROTOCOL_ERROR a powiązane błędy sieciowe Chrome

W przypadku witryn, gdzie QUIC powoduje niestabilność, możesz go wyłączyć pod adresem chrome://flags/#enable-quic, ustawiając flagę na Disabled. Zmusza to Chrome do powrotu do HTTP/2 opartego na TCP lub HTTP/1.1.

Techniczna macierz decyzyjna: którą poprawkę zastosować jako pierwszą

Użyj tej macierzy, aby ustalić priorytety rozwiązywania problemów w zależności od kontekstu, w którym pojawia się błąd:

Jeśli zarządzasz własnym serwerem WWW i potrzebujesz panelu sterowania upraszczającego zarządzanie SSL i protokołami, Panele sterowania VPS zapewniają graficzne interfejsy do instalacji certyfikatów i konfiguracji serwera WWW, które zmniejszają ryzyko ręcznej błędnej konfiguracji. W przypadku mniejszych projektów na Hostingu Współdzielonym ustawienia protokołu są zarządzane na poziomie infrastruktury — skontaktuj się z pomocą techniczną, jeśli podejrzewasz błędną konfigurację HTTP/2 po stronie serwera.

Lista kontrolna działań przed eskalacją

Przejdź przez tę listę kontrolną w kolejności. Zatrzymaj się na kroku, który rozwiązuje błąd.

• [ ] Opróżnij pule socketów pod adresem chrome://net-internals/#sockets
• [ ] Wyczyść cache hosta DNS pod adresem chrome://net-internals/#dns
• [ ] Usuń politykę HSTS domeny pod adresem chrome://net-internals/#hsts
• [ ] Wyczyść cały cache przeglądarki i pliki cookie (Cały czas)
• [ ] Przetestuj w trybie incognito, aby wykluczyć rozszerzenia
• [ ] Przetestuj w drugiej przeglądarce (Firefox, Edge), aby wykluczyć problemy specyficzne dla Chrome
• [ ] Tymczasowo wyłącz skanowanie HTTPS w antywirusie
• [ ] Wyłącz VPN lub proxy
• [ ] Uruchom netsh winsock reset i ipconfig /flushdns jako Administrator
• [ ] Wykonaj pełny cykl zasilania routera i modemu (60-sekundowe pełne rozładowanie)
• [ ] Utwórz nowy profil Chrome i usuń folder Network ze starego profilu
• [ ] Uruchom curl -v --http2 https://your-domain.com, aby sprawdzić, czy problem leży po stronie serwera
• [ ] Jeśli problem po stronie serwera: sprawdź ważność certyfikatu SSL, konfigurację modułu HTTP/2 i przeładuj proces serwera
• [ ] Zaktualizuj Chrome do najnowszej stabilnej wersji

FAQ

Czym jest ERR_SPDY_PROTOCOL_ERROR i dlaczego nadal pojawia się, skoro SPDY jest przestarzały?

Wewnętrzny stos sieciowy Chrome odziedziczył kody błędów z ery SPDY, które nigdy nie zostały przemianowane. Błąd pojawia się teraz przy każdej awarii w warstwie sesji HTTP/2 lub QUIC — w tym błędach negocjacji ALPN, uszkodzonych uzgadnianiach TLS i nieaktualnych wpisach puli połączeń — mimo że sam SPDY nie jest używany od Chrome 51.

Dlaczego błąd pojawia się tylko na jednej witrynie, a nie na innych?

Prawie zawsze wskazuje to na nieaktualną sesję socket Chrome specyficzną dla tej domeny lub problem po stronie serwera na tym konkretnym hoście — na przykład niedawno ponownie wystawiony certyfikat, który unieważnił istniejące sesje, lub uszkodzoną konfigurację HTTP/2 na tym serwerze. Opróżnienie pul socketów i przetestowanie za pomocą curl --http2 potwierdzi, które z nich jest przyczyną.

Czy oprogramowanie antywirusowe może naprawdę powodować ERR_SPDY_PROTOCOL_ERROR?

Tak. Produkty zabezpieczające wykonujące inspekcję HTTPS (Avast, AVG, Kaspersky, ESET i inne) działają jako proxy TLS typu man-in-the-middle. Jeśli ich implementacja HTTP/2 jest niekompletna lub wstrzyknięty certyfikat nie jest zaufany przez magazyn certyfikatów Chrome, sesja HTTP/2 zakończy się niepowodzeniem z dokładnie tym błędem. Wyłączenie tylko komponentu skanowania HTTPS — nie całego antywirusa — jest właściwą ukierunkowaną poprawką.

Jak sprawdzić, czy problem leży po mojej stronie, czy po stronie serwera?

Uruchom curl -v --http2 https://your-domain.com z wiersza poleceń. Jeśli curl również nie może wynegocjować HTTP/2, serwer jest błędnie skonfigurowany. Jeśli curl powiedzie się, ale Chrome zawiedzie, problem jest lokalny — nieaktualna sesja Chrome, rozszerzenie lub przechwytujące narzędzie zabezpieczające.

Czy ten błąd wpływa na SEO lub wydajność witryny?

Dla użytkowników końcowych tak — błąd całkowicie uniemożliwia załadowanie strony. Dla właścicieli witryn trwały ERR_SPDY_PROTOCOL_ERROR spowodowany błędną konfiguracją HTTP/2 po stronie serwera lub wygasłym certyfikatem będzie skutkować nieudanymi próbami indeksowania przez Googlebot, co może negatywnie wpłynąć na pokrycie indeksowania. Zapewnienie ważności certyfikatu SSL i poprawności konfiguracji HTTP/2 jest podstawowym wymogiem technicznego SEO.