ERR_SSL_PROTOCOL_ERROR: jak naprawić (Chrome, localhost)

Czym jest ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR oznacza, że bezpieczne połączenie urwało się podczas uzgadniania TLS, zanim przeglądarka zdążyła cokolwiek wczytać. Chrome i Edge pokazują go jako „Ta witryna nie umożliwia bezpiecznego połączenia. Serwer example.com wysłał nieprawidłową odpowiedź.” Jeśli adres to localhost, Twój serwer deweloperski prawie na pewno mówi zwykłym HTTP: otwórz zamiast tego http://localhost (zobacz sekcję dla programistów poniżej).

Każde połączenie HTTPS zaczyna się od uzgadniania TLS, w którym przeglądarka i serwer ustalają wersję protokołu (TLS 1.2 lub 1.3) oraz szyfry i wymieniają się certyfikatami. ERR_SSL_PROTOCOL_ERROR znaczy, że te negocjacje się załamały: druga strona odpowiedziała czymś, co nie jest poprawnym TLS, albo odrzuciła uzgadnianie w sposób, którego przeglądarka nie potrafiła sklasyfikować.

Pojawia się, zanim zostanie wysłane jakiekolwiek żądanie HTTP, więc nie jest kodem stanu HTTP. Lista błędów Chromium definiuje go jako błąd -107 z jednym wierszem opisu, „An SSL protocol error occurred”: to zbiorczy błąd zepsutego uzgadniania, w odróżnieniu od konkretnego błędu -113 („brak wspólnej wersji protokołu lub szyfru”).

Jak wygląda ERR_SSL_PROTOCOL_ERROR

Chrome i inne przeglądarki oparte na Chromium wyświetlają ten błąd jako ostrzeżenie na całą stronę z komunikatem „Ta witryna nie umożliwia bezpiecznego połączenia”. Pod nim zobaczysz konkretny kod błędu. Oto najczęstsze warianty.

• Serwer localhost wysłał nieprawidłową odpowiedź (po angielsku „localhost sent an invalid response”) — wersja, którą widzą programiści: https:// otwarte na lokalnym serwerze, który mówi zwykłym HTTP
• ERR_SSL_PROTOCOL_ERROR — kod błędu, który Chrome wypisuje małą czcionką pod komunikatem
• net::ERR_SSL_PROTOCOL_ERROR — pełny wewnętrzny kod błędu widoczny w konsoli narzędzi Chrome DevTools
• Ta witryna nie umożliwia bezpiecznego połączenia — nagłówek widoczny dla użytkownika w Chrome
• Serwer [domena] wysłał nieprawidłową odpowiedź — szczegółowy tekst błędu, który Chrome wyświetla pod nagłówkiem
• ERR_SSL_PROTOCOL_ERROR we wszystkich przeglądarkach — gdy błąd pojawia się jednocześnie w Chrome, Edge, Brave i Operze (wskazuje na problem po stronie serwera lub całego systemu, a nie na błąd jednej przeglądarki)

Co powoduje ERR_SSL_PROTOCOL_ERROR?

Ten błąd ma przyczyny po stronie klienta (Twoje urządzenie) i po stronie serwera (strona internetowa). Pierwszy krok to ustalenie, po której stronie leży problem. Jeśli błąd pojawia się na każdej stronie, problem leży po Twojej stronie. Jeśli tylko na jednej konkretnej stronie, przyczyna jest prawdopodobnie po stronie serwera.

• HTTPS wysłane do serwera, który mówi po HTTP — najczęściej wyszukiwany przypadek: https://localhost na serwerze deweloperskim albo strona, której port 443 nie jest skonfigurowany pod TLS. Przeglądarka zaczyna uzgadnianie i dostaje z powrotem zwykły tekst, co Chrome zgłasza jako „wysłał nieprawidłową odpowiedź”.
• Skanowanie SSL/HTTPS w antywirusie — oprogramowanie zabezpieczające, które przechwytuje HTTPS (Avast, Kaspersky, Bitdefender, ESET), wpina się w uzgadnianie i może je zepsuć na wszystkich stronach naraz.
• VPN lub proxy — VPN-y i firmowe serwery proxy, które sprawdzają ruch HTTPS, mogą uszkodzić uzgadnianie, zwłaszcza tuż po zmianie sieci.
• Sieć, która filtruje stronę — filtry dostawców internetu, szkół, firm i państw oraz blokery oparte na DNS celowo psują uzgadnianie dla blokowanych stron. Znak rozpoznawczy: strona wczytuje się w mobilnej transmisji danych lub w innej sieci Wi-Fi.
• Zepsuta konfiguracja TLS na serwerze — port 443 odpowiada zwykłym HTTP (blok serwera na 443 bez włączonego TLS) albo na porcie 443 nasłuchuje inny program.
• Rozszerzenia przeglądarki — dodatki do ochrony prywatności, blokowania reklam i bezpieczeństwa, które przepisują żądania HTTPS, mogą zakłócać uzgadnianie.
• Nieaktualny stan przeglądarki — zapisane dane sesji, które nie pasują już do serwera.
• Często z nim mylone — serwer utknięty na TLS 1.0 lub 1.1 pokazuje ERR_SSL_VERSION_OR_CIPHER_MISMATCH („używa nieobsługiwanego protokołu”), wygasły, źle nazwany lub samopodpisany certyfikat albo błędny zegar pokazują błąd certyfikatu (NET::ERR_CERT_…), a problem z QUIC (HTTP/3) pokazuje ERR_QUIC_PROTOCOL_ERROR. Zobacz ERR_SSL_VERSION_OR_CIPHER_MISMATCH i „Połączenie nie jest prywatne”.

ERR_SSL_PROTOCOL_ERROR na localhost (programiści)

Serwer localhost wysłał nieprawidłową odpowiedź. ERR_SSL_PROTOCOL_ERROR prawie zawsze oznacza, że otworzyłeś https://localhost na serwerze deweloperskim, który mówi tylko zwykłym HTTP. Przeglądarka zaczyna uzgadnianie TLS, serwer odpowiada zwykłym tekstem HTTP, a Chrome zgłasza tę odpowiedź jako nieprawidłową. Firefox zgłasza ten sam błąd jako SSL_ERROR_RX_RECORD_TOO_LONG.

• Użyj adresu, który wypisuje serwer — zmień https://localhost:3000 na http://localhost:3000. Serwery deweloperskie Next.js, Vite, React, Django, Rails i Flask serwują HTTP, dopóki nie włączysz HTTPS
• Sprawdź port — https://localhost bez portu oznacza port 443. Jeśli Twoja aplikacja działa na 3000 lub 5173, żądanie trafia do innego programu albo donikąd
• Chrome ciągle przełącza na https:// — może to powodować zapamiętane przekierowanie z wcześniejszej aplikacji na tym samym porcie: wyczyść obrazy i pliki zapisane w pamięci podręcznej albo przetestuj w oknie incognito. (Wersje Chrome sprzed 132 mogły też zachować wpis HSTS dla localhost, który usuwasz w chrome://net-internals/#hsts w polu Delete domain security policies)
• Potrzebujesz HTTPS lokalnie (callbacki OAuth, bezpieczne ciasteczka) — next dev --experimental-https tworzy lokalnie zaufany certyfikat za pomocą mkcert; Vite przyjmuje opcje certyfikatu w server.https albo @vitejs/plugin-basic-ssl dla szybkiego samopodpisanego; w innych przypadkach mkcert -install && mkcert localhost 127.0.0.1 tworzy pliki, które Twój serwer może wczytać
• Samopodpisany certyfikat daje inny błąd — NET::ERR_CERT_AUTHORITY_INVALID, nie ten. Kliknij Zaawansowane → Otwórz stronę localhost (niebezpieczną) albo, lepiej, użyj certyfikatu z mkcert (stara flaga allow-insecure-localhost wygasła)

Jak naprawić ERR_SSL_PROTOCOL_ERROR (dla użytkowników)

Zacznij od Rozwiązania 1: w dwie minuty pokaże ci, czy problem leży w przeglądarce, w urządzeniu lub sieci, czy w samej stronie. Potem idź w dół listy.

Rozwiązanie 1: wypróbuj tryb incognito i inną sieć

Okno incognito startuje bez ciasteczek, bez pamięci podręcznej i bez rozszerzeń (chyba że zezwoliłeś na nie w tym trybie). Otwórz stronę w oknie incognito (Ctrl+Shift+N w Chrome i Edge, Ctrl+Shift+P w Firefox), a potem w innej sieci, na przykład w mobilnej transmisji danych w telefonie.

Jeśli strona wczytuje się w trybie incognito, przyczyna leży w przeglądarce: rozszerzenie lub nieaktualne dane (Rozwiązania 4 i 5). Jeśli wczytuje się tylko w innej sieci, filtruje ją lub przechwytuje Twoja sieć albo VPN lub proxy (Rozwiązanie 3). Jeśli zawodzi wszędzie, przetestuj stronę narzędziem „Sprawdź certyfikat SSL”: jeśli tam też zawodzi, naprawić to może tylko właściciel strony.

Rozwiązanie 2: wyłącz skanowanie SSL/HTTPS w antywirusie

Wiele programów antywirusowych (Avast, Kaspersky, Bitdefender, ESET, Norton) ma funkcję „skanowania HTTPS” lub „inspekcji SSL”, która przechwytuje szyfrowane połączenia, działając jak pośredniczący serwer proxy (man-in-the-middle). Gdy źle obsłuży uzgadnianie danej strony, zawodzą wszystkie przeglądarki na komputerze.

Poszukaj w antywirusie ustawień o nazwach takich jak Web Shield, Skanowanie HTTPS, Skanowanie SSL lub Skanowanie połączeń szyfrowanych i wyłącz je tymczasowo. Jeśli błąd zniknie, możesz dodać daną domenę do listy wyjątków antywirusa.

Rozwiązanie 3: wyłącz VPN lub proxy

VPN-y i serwery proxy HTTP znajdują się między przeglądarką a serwerem WWW. Niektóre VPN-y sprawdzają ruch HTTPS albo kierują połączenia przez serwery z zepsutym TLS. Firmowe proxy często stosują przechwytywanie SSL (podobne do skanowania HTTPS w antywirusie), które może psuć uzgadnianie TLS.

Tymczasowo rozłącz VPN i spróbuj wczytać stronę. Jeśli działa bez VPN, problem leży w tym, jak Twój VPN obsługuje połączenia SSL. Spróbuj innego serwera VPN albo skontaktuj się z jego dostawcą.

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

Rozszerzenia, które filtrują lub przekierowują ruch, takie jak rozszerzenia VPN i proxy oraz dodatki zabezpieczające, mogą psuć bezpieczne połączenia.

Przejdź do chrome://extensions/, wyłącz wszystkie rozszerzenia i odśwież stronę. Jeśli błąd zniknie, włączaj je z powrotem po jednym, aby znaleźć winowajcę.

Rozwiązanie 5: wyczyść pamięć podręczną i pliki cookie przeglądarki

Nieaktualne pliki cookie lub dane z pamięci podręcznej czasem przeszkadzają, a ich wyczyszczenie zajmuje minutę.

• Krok 1: Naciśnij Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), aby otworzyć Usuń dane przeglądania
• Krok 2: Jako zakres czasu wybierz Więcej → Od początku
• Krok 3: Zaznacz Pliki cookie i inne dane witryn oraz Obrazy i pliki zapisane w pamięci podręcznej
• Krok 4: Kliknij Usuń dane (Usuń z tego urządzenia, jeśli nie jesteś zalogowany) i zrestartuj Chrome

Dla pojedynczej strony otwórz chrome://settings/content/all, wyszukaj domenę i usuń jej dane.

Rozwiązanie 6: wykluczyć QUIC (HTTP/3)

Chrome próbuje QUIC (HTTP/3 po UDP) równolegle ze zwykłym połączeniem TCP i wraca do TCP, gdy QUIC zawodzi, więc QUIC rzadko powoduje ERR_SSL_PROTOCOL_ERROR. Jeśli strona lub DevTools pokazują zamiast tego ERR_QUIC_PROTOCOL_ERROR, rozwiązaniem jest wyłączenie QUIC (zobacz ERR_QUIC_PROTOCOL_ERROR):

• Krok 1: Wpisz chrome://flags/#enable-quic w pasku adresu
• Krok 2: Znajdź Experimental QUIC protocol
• Krok 3: Zmień ustawienie z Default na Disabled
• Krok 4: Kliknij Uruchom ponownie, aby uruchomić Chrome ponownie

Strony nadal się wczytują bez QUIC, przez HTTP/2 po TCP; włącz QUIC z powrotem, gdy sieć lub strona zostaną naprawione.

Rozwiązanie 7: zaktualizuj przeglądarkę

Starsze wersje przeglądarek mogą nie mieć funkcji TLS i szyfrów, których oczekują nowoczesne strony, a aktualizacje naprawiają błędy TLS.

Aktualizacja Chrome: przejdź do chrome://settings/help lub Menu → Pomoc → Google Chrome – informacje. Chrome pobiera aktualizacje automatycznie, ale wymaga ponownego uruchomienia, aby je zastosować. Dla Edge: edge://settings/help. Dla Firefox: Menu → Pomoc → O programie Firefox.

Rozwiązanie 8: wyczyść pamięć podręczną DNS

Nieaktualny DNS może skierować przeglądarkę na stary serwer, który nie obsługuje już strony przez TLS. Wyczyszczenie pamięci podręcznej DNS wymusza nowe zapytanie.

# Windows (Command Prompt as Admin)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Linux
sudo resolvectl flush-caches

# Chrome internal DNS cache
# Visit chrome://net-internals/#dns → Click "Clear host cache"

Po wyczyszczeniu sprawdź, czy domena rozwiązuje się na właściwy adres IP, za pomocą narzędzia „Sprawdź rekordy DNS” od DNS Robot. Jeśli adres IP wygląda błędnie, strona mogła zmienić dostawcę hostingu, a DNS jeszcze się w pełni nie rozpropagował.

Rozwiązanie 9: sprawdź datę i godzinę systemową

Błędny zegar zwykle pokazuje się jako inny błąd, NET::ERR_CERT_DATE_INVALID („Twój zegar się śpieszy” lub „Twój zegar się spóźnia”), bo certyfikat jest ważny tylko między dwiema datami. Wykluczenie tego zajmuje dziesięć sekund:

• Windows: Ustawienia → Czas i język → Data i godzina → włącz „Ustaw czas automatycznie” oraz „Ustaw strefę czasową automatycznie”
• Mac: Ustawienia systemowe → Ogólne → Data i czas → włącz automatyczne ustawianie daty i czasu („Set time and date automatically”)
• Linux: Uruchom sudo timedatectl set-ntp true, aby włączyć synchronizację NTP

Rozwiązanie 10: wyczyść stan SSL (Windows)

Wiele poradników podpowiada Wyczyść stan SSL w Opcjach internetowych systemu Windows (inetcpl.cpl → Zawartość → Wyczyść stan SSL). To czyści pamięć podręczną sesji własnej biblioteki TLS systemu Windows, z której korzystają aplikacje oparte na sieci Windows. Chrome i Edge używają własnej biblioteki TLS, więc rzadko cokolwiek to dla nich zmienia.

Odpowiednik dla przeglądarki jest prostszy: zamknij wszystkie okna przeglądarki (sprawdź w zasobniku systemowym, czy nie działa Chrome w tle) i otwórz ją ponownie. To porzuca wszystkie zapisane sesje TLS. Jeśli błąd przetrwa pełny restart, przejdź do kolejnych rozwiązań.

Rozwiązanie 11: zresetuj ustawienia sieciowe (ostateczność)

Jeśli nic innego nie pomaga, zresetuj stos sieciowy. W Windows te polecenia resetują Winsock i TCP/IP, w tym statyczne adresy IP i serwery DNS ustawione ręcznie; w macOS i Linuksie tylko czyszczą pamięć podręczną DNS lub restartują usługę sieciową.

# Windows (Command Prompt as Admin)
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

# Then restart your computer

# macOS — flush the DNS cache
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux — restart NetworkManager
sudo systemctl restart NetworkManager

Jak naprawić ERR_SSL_PROTOCOL_ERROR (dla właścicieli stron)

Jeśli wielu odwiedzających zgłasza ERR_SSL_PROTOCOL_ERROR, problem leży po stronie serwera: zwykle port 443 odpowiada zwykłym HTTP albo ten port zajmuje inny program. Problemy z certyfikatem pokazują własne błędy, ale sprawdź je przy okazji. (Certyfikat i klucz, które do siebie nie pasują, w ogóle uniemożliwiają serwerowi wczytanie nowej konfiguracji: po zmianie sprawdź ją przez nginx -t lub apachectl configtest.)

Sprawdź certyfikat SSL

Pierwszy krok to sprawdzenie, czy certyfikat SSL jest ważny, poprawnie zainstalowany i niewygasły. Użyj „Sprawdź certyfikat SSL” od DNS Robot, aby od razu zobaczyć status certyfikatu, datę wygaśnięcia, wystawcę i łańcuch certyfikatów.

Te problemy z certyfikatem pokazują własne błędy zamiast ERR_SSL_PROTOCOL_ERROR, ale napraw je przy okazji:

• Wygasły certyfikat (NET::ERR_CERT_DATE_INVALID) — certyfikaty Let's Encrypt są ważne 90 dni (od lutego 2027 64 dni), więc odnawianie musi działać automatycznie; jeśli zawiodło (nie działa timer certbota, zepsute wyzwanie DNS), certyfikat wygasa po cichu.
• Zła domena (NET::ERR_CERT_COMMON_NAME_INVALID) — certyfikat wystawiono dla example.com, a strona działa pod www.example.com (lub odwrotnie). Certyfikat musi pasować do dokładnej domeny albo zawierać wildcard (*.example.com).
• Certyfikat samopodpisany (NET::ERR_CERT_AUTHORITY_INVALID) — w porządku do developmentu, ale przeglądarki nigdy mu nie ufają w produkcji.
• Unieważniony certyfikat (NET::ERR_CERT_REVOKED) — urząd certyfikacji unieważnił go po kompromitacji klucza lub błędnym wystawieniu.
• Zły certyfikat dla nazwy (NET::ERR_CERT_COMMON_NAME_INVALID) — kilka stron dzieli jeden adres IP, a serwer nie używa SNI (Server Name Indication), by wybrać certyfikat każdej z nich.

# Check certificate from command line
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# Check certificate chain completeness
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>&1 | grep -E "depth|Verify"

# Renew Let's Encrypt certificate
sudo certbot renew --dry-run   # test first
sudo certbot renew

Włącz TLS 1.2 i TLS 1.3

Wszystkie nowoczesne przeglądarki wymagają co najmniej TLS 1.2: TLS 1.0 i 1.1 zostały formalnie wycofane w 2021 roku przez RFC 8996. Strona, która odrzuca wersję drugiej strony, kończy uzgadnianie alertem TLS 70, protocol_version (RFC 8446 §6.2). Serwer obsługujący tylko TLS 1.0 lub 1.1 pokazuje ERR_SSL_VERSION_OR_CIPHER_MISMATCH zamiast tego błędu, ale w obu przypadkach zawodzi. TLS 1.3 łączy się w jednej wymianie zamiast dwóch w TLS 1.2: włącz oba.

# Nginx — ssl_protocols in nginx.conf or site config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers off;

# Apache — in httpd.conf or ssl.conf
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder off

Po zmianie konfiguracji TLS zrestartuj serwer WWW (sudo systemctl restart nginx lub sudo systemctl restart apache2) i sprawdź przez „Sprawdź certyfikat SSL” od DNS Robot, czy protokoły są aktywne.

Zainstaluj kompletny łańcuch certyfikatów

Niekompletny łańcuch pokazuje się jako błąd certyfikatu (NET::ERR_CERT_AUTHORITY_INVALID) w przeglądarkach i aplikacjach, które nie potrafią uzupełnić brakującego certyfikatu pośredniego, więc zainstaluj pełny łańcuch przy okazji sprawdzania. Serwer musi wysyłać Twój certyfikat oraz certyfikaty pośrednie, które łączą go z zaufanym certyfikatem głównym.

Większość urzędów certyfikacji udostępnia plik „CA bundle” lub „full chain”. Dla Let's Encrypt użyj fullchain.pem (nie samego cert.pem). W przypadku innych urzędów pobierz certyfikat pośredni z ich dokumentacji i dołącz go do swojego certyfikatu.

# Nginx — use fullchain, not just cert
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

# Apache
SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem

Sprawdź konfigurację HSTS

HSTS (HTTP Strict Transport Security) nakazuje przeglądarkom zawsze używać HTTPS dla Twojej domeny. Jeśli polityka HSTS ma długi max-age, a Twoja konfiguracja TLS później się zepsuje, przeglądarki nie mogą wrócić do HTTP: odwiedzający widzą stronę błędu bez możliwości przejścia dalej.

Sprawdź nagłówek HSTS narzędziem Checker nagłówków HTTP od DNS Robot. Jeśli ustawiłeś bardzo długi max-age (na przykład 2 lata), a certyfikat wygasł, użytkownicy, którzy wcześniej odwiedzili Twoją stronę, są zablokowani na HTTPS bez możliwości powrotu. Aby to naprawić, najpierw napraw certyfikat SSL, a przeglądarki znów będą łączyć się normalnie.

Sprawdź konfigurację serwera

Ten błąd serwera psuje uzgadnianie nawet przy ważnym certyfikacie, a jeszcze jeden pokazuje inny błąd:

• Port 443 serwuje zwykłe HTTP — klasyczna przyczyna po stronie właściciela: w nginx listen 443; bez ssl (musi być listen 443 ssl;) albo inna usługa związana z portem 443.
• Niezgodność zestawów szyfrów — serwer oferujący tylko szyfry, które przeglądarki odrzucają, pokazuje ERR_SSL_VERSION_OR_CIPHER_MISMATCH. Używaj nowoczesnych szyfrów AEAD (AES-GCM, ChaCha20).

Przetestuj z zewnątrz poleceniem openssl s_client -connect example.com:443 -servername example.com </dev/null: „wrong version number” (OpenSSL) lub „tlsv1 alert protocol version” (wbudowany openssl w macOS) oznacza, że port 443 nie mówi po TLS, a wydruk certyfikatu oznacza, że uzgadnianie działa.

ERR_SSL_PROTOCOL_ERROR na Androidzie

Użytkownicy Androida napotykają ERR_SSL_PROTOCOL_ERROR zarówno w Chrome na Androida, jak i w aplikacjach opartych na WebView. Rozwiązania różnią się nieco od tych na komputerze, bo Android inaczej zarządza certyfikatami i ustawieniami sieci.

• Przełącz sieć — wyłącz Wi-Fi i spróbuj w transmisji danych (lub odwrotnie). Jeśli strona się wczytuje, sieć ją filtruje lub przechwytuje
• Wyłącz prywatny DNS do testu — Ustawienia → Sieć i internet → Prywatny DNS → Wyłączony (a w Chrome: Ustawienia → Prywatność i bezpieczeństwo → Użyj bezpiecznego serwera DNS). Filtrująca usługa DNS (blokowanie reklam, kontrola rodzicielska) kieruje blokowane strony na serwer, który nie potrafi dokończyć uzgadniania
• Wyczyść dane Chrome — Ustawienia → Aplikacje → Chrome → Pamięć → Wyczyść pamięć podręczną (potem „Manage space”, jeśli to nie pomogło)
• Zaktualizuj Chrome — Sklep Play → zdjęcie profilowe → Zarządzaj aplikacjami i urządzeniami → zaktualizuj Chrome
• Wyczyść dane certyfikatów — Ustawienia → Zabezpieczenia (na nowszych telefonach: Więcej ustawień bezpieczeństwa → Szyfrowanie i dane logowania) → Wyczyść dane certyfikatów. To usuwa wszystkie certyfikaty zainstalowane przez użytkownika
• Sprawdź datę i godzinę — Ustawienia → System → Data i godzina → automatyczne. Błędny zegar pokazuje błąd certyfikatu, ale łatwo go wykluczyć
• Zresetuj ustawienia sieciowe — Ustawienia → System → Opcje resetowania, a potem reset Wi-Fi i sieci komórkowej (nazwa zależy od wersji Androida)

ERR_SSL_PROTOCOL_ERROR na iPhonie i iPadzie

Na iPhonie Chrome pokazuje ERR_SSL_PROTOCOL_ERROR, a Safari informuje, że „nie może nawiązać bezpiecznego połączenia z serwerem”. Przyczyny są te same co na komputerze, tylko przełączniki są w innych miejscach:

• Przełącz sieć — wyłącz Wi-Fi i spróbuj w transmisji danych. Jeśli strona się wczytuje, sieć Wi-Fi ją filtruje lub przechwytuje
• Usuń VPN-y i profile, których nie rozpoznajesz — Ustawienia → Ogólne → VPN i urządzenia zarządzane. Profil instalujący własny certyfikat lub VPN może przechwytywać HTTPS
• Przetestuj bez usługi Przekazywanie prywatne iCloud — Ustawienia → [Twoje imię i nazwisko] → iCloud → Przekazywanie prywatne → wyłącz, potem spróbuj ponownie
• Sprawdź limity Czasu przed ekranem — Ustawienia → Czas przed ekranem → Ograniczaj treść i prywatność, a w nich ustawienie treści internetowych. Zablokowana strona zawodzi zamiast się wczytać
• Ustaw zegar automatycznie — Ustawienia → Ogólne → Data i godzina → Ustaw automatycznie

ERR_SSL_PROTOCOL_ERROR w innych przeglądarkach

ERR_SSL_PROTOCOL_ERROR to kod błędu specyficzny dla Chromium. Inne przeglądarki wyświetlają inne komunikaty dla tej samej awarii uzgadniania SSL.

Jeśli błąd pojawia się we wszystkich przeglądarkach naraz, problem leży w Twoim systemie (skanowanie HTTPS w antywirusie, VPN lub proxy, Twoja sieć) albo na serwerze (port 443 nie obsługuje poprawnie TLS). Jeśli zawodzi tylko jedna przeglądarka, sprawdź jej rozszerzenia i zapisane dane.

Powiązane kody błędów SSL/TLS

Chrome ma kilka kodów błędów związanych z SSL. Wszystkie wskazują na różne problemy z uzgadnianiem TLS lub certyfikatem.

W przypadku wszystkich błędów SSL możesz szybko zdiagnozować problem za pomocą „Sprawdź certyfikat SSL” od DNS Robot — jednym skanem pokazuje status certyfikatu, kompletność łańcucha, obsługiwane wersje TLS i datę wygaśnięcia.

Jeśli na Twojej stronie jest napisane, że witryna „używa nieobsługiwanego protokołu”, masz ERR_SSL_VERSION_OR_CIPHER_MISMATCH, a nie ten błąd: zobacz jak naprawić ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Jeśli strona mówi zamiast tego „Serwer example.com nieoczekiwanie zakończył połączenie” (ERR_CONNECTION_CLOSED), połączenie zostało przerwane, a nie zepsute. W tym przypadku zobacz ERR_CONNECTION_CLOSED.