ERR_HTTP2_PROTOCOL_ERROR: co oznacza i jak naprawić

Czym jest błąd ERR_HTTP2_PROTOCOL_ERROR?

ERR_HTTP2_PROTOCOL_ERROR to błąd Chrome i Edge, który oznacza, że strumień HTTP/2 niosący stronę zakończył się niepowodzeniem: serwer zresetował go przed końcem albo wysłał nagłówki, które przeglądarka odrzuca. W Chromium to błąd sieciowy -337: „There is an HTTP/2 protocol error” (net_error_list.h). Chrome nie ma dla niego osobnej strony błędu, więc widzisz ogólną: „Ta witryna jest nieosiągalna” oraz opis „Strona internetowa pod adresem … może być tymczasowo niedostępna lub została na stałe przeniesiona pod nowy adres internetowy”, a pod spodem ERR_HTTP2_PROTOCOL_ERROR. Edge pokazuje ten sam kod na własnym ekranie „Hmm… can't reach this page”.

HTTP/2 to szybsza wersja HTTP, z której korzysta dziś większość stron HTTPS. Każde żądanie biegnie osobnym strumieniem wewnątrz jednego połączenia, a każda ze stron może anulować strumień resetem. Chrome zgłasza każdy reset od serwera jako błąd protokołu, bez względu na jego powód, a sam anuluje strumień, gdy nagłówki łamią zasady HTTP/2 (nagłówek Transfer-Encoding, wielkie litery w nazwie nagłówka, brak statusu).

Programiści często widzą ten błąd w konsoli DevTools jako net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). To połączenie jest mocną wskazówką: nagłówki były poprawne i serwer odpowiedział kodem 200, ale strumień urwał się w trakcie nadchodzenia treści.

Co HTTP/2 uznaje za zniekształconą odpowiedź

Standard HTTP/2 (RFC 9113) wymienia błędy, które sprawiają, że odpowiedź jest zniekształcona. To problemy stojące za większością błędów spotykanych w praktyce i tak każdy z nich dociera do przeglądarki:

Co powoduje błąd ERR_HTTP2_PROTOCOL_ERROR?

Większość przypadków ma źródło po stronie serwera, ale kilka rzeczy na Twoim komputerze również może uszkodzić odpowiedź w drodze do przeglądarki:

• Po stronie serwera: odpowiedź, której serwer lub proxy nie mogą dokończyć (proxy, któremu zabrakło miejsca na dysku albo nie może zapisać plików tymczasowych, aplikacja, która pada podczas strumieniowania, przekroczony limit czasu), błędne wartości Content-Length, przez które stojące przed serwerem proxy się poddaje, zakazane lub nieprawidłowe nagłówki oraz błędna obsługa HTTP/2 w starszej konfiguracji serwera lub CDN.
• Po Twojej stronie: antywirus lub zapora, które sprawdzają HTTPS i przepisują ruch, rozszerzenia przeglądarki modyfikujące żądania lub odpowiedzi, żądanie, które serwer błędnie obsługuje (na przykład przez zbyt duże pliki cookie), a czasem przestarzała wersja Chrome.

Rozwiązanie 1: wymuś pełne odświeżenie i spróbuj trybu incognito

Naciśnij Ctrl + Shift + R (Mac: Cmd + Shift + R), aby odświeżyć stronę z pominięciem pamięci podręcznej. Odpowiedź, która raz została ucięta, przy następnej próbie może dotrzeć bez problemu.

Następnie otwórz stronę w oknie incognito (Ctrl + Shift + N, Mac Cmd + Shift + N). Tryb incognito nie ma plików cookie ani pamięci podręcznej z Twojego zwykłego profilu, a rozszerzenia są w nim domyślnie wyłączone. Jeśli strona się w nim ładuje, Rozwiązanie 2 lub Rozwiązanie 3 naprawi problem w zwykłym oknie.

Rozwiązanie 2: wyczyść pliki cookie i zapisane pliki tej strony

Wyczyszczenie plików cookie i zapisanych plików strony zmienia żądanie wysyłane przez Chrome (mniej plików cookie, brak kopii z pamięci podręcznej do ponownej weryfikacji), co może ominąć błąd serwera. Kliknij Wyświetl informacje o witrynie po lewej stronie paska adresu → Pliki cookie i dane witryn → Zarządzaj danymi witryn na urządzeniu → usuń dane, a potem odśwież. Aby wyczyścić więcej, naciśnij Ctrl + Shift + Delete i usuń Obrazy i pliki zapisane w pamięci podręcznej z zakresu Ostatnie 7 dni.

Rozwiązanie 3: wstrzymaj skanowanie HTTPS w antywirusie i rozszerzenia

Oprogramowanie zabezpieczające, które odszyfrowuje i sprawdza HTTPS, stoi pośrodku każdego połączenia HTTP/2. Jeśli jego obsługa HTTP/2 jest błędna lub przestarzała, może psuć strumienie albo przekazywać nagłówki, które Chrome odrzuca. Wyłącz tylko funkcję skanowania HTTPS (Avast/AVG: Web Shield → „Enable HTTPS scanning”; ESET: „SSL/TLS protocol filtering”; Kaspersky: „Scan encrypted connections”) i odśwież stronę. Jeśli to pomoże, zaktualizuj antywirus i dodaj wyjątek dla tej strony.

Następnie wyłącz wszystkie rozszerzenia w chrome://extensions, odśwież stronę, a potem włączaj je z powrotem po jednym. Zwykle podejrzanymi są blokery reklam, narzędzia do ochrony prywatności i wszystko, co edytuje nagłówki.

Rozwiązanie 4: zaktualizuj Chrome i sprawdź inne przeglądarki

Otwórz chrome://settings/help, aby zainstalować oczekującą aktualizację, a potem uruchom przeglądarkę ponownie. Następnie otwórz tę samą stronę w Firefoksie lub Safari oraz na innym urządzeniu lub w innej sieci. Jeśli nie działa nigdzie, strona jest uszkodzona i naprawić ją może tylko właściciel (skanowanie HTTPS w antywirusie dotyczy każdej przeglądarki na jednym komputerze, więc prawdziwym testem jest drugie urządzenie). Jeśli nie działa tylko w Chrome lub Edge, strona prawdopodobnie wysyła nagłówek, który Chrome odrzuca; warto mimo to powtórzyć Rozwiązania 2 i 3.

Rozwiązanie 5: przetestuj stronę bez HTTP/2

Chrome można uruchomić z wyłączonym HTTP/2 (i HTTP/3), co pokazuje, czy HTTP/2 ma z tym coś wspólnego. Uruchom z terminala drugi, osobny Chrome; dodatkowy folder profilu sprawia, że jest to nowa instancja, nawet gdy zwykły Chrome jest otwarty:

# Windows (Command Prompt)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --user-data-dir="%TEMP%\h2test" --disable-http2 --disable-quic

# macOS (Terminal)
open -na "Google Chrome" --args --user-data-dir=/tmp/h2test --disable-http2 --disable-quic

Jeśli w tym oknie strona się ładuje, problemem są odpowiedzi HTTP/2 tej strony i musi je naprawić właściciel. Jeśli teraz kończy się to błędem ERR_CONTENT_LENGTH_MISMATCH lub ERR_INCOMPLETE_CHUNKED_ENCODING, serwer ucina odpowiedź niezależnie od protokołu. Zamknij to okno, gdy skończysz; Twój zwykły Chrome pozostaje nietknięty.

Dla właścicieli stron: jak naprawić błędy protokołu HTTP/2

Jeśli błąd zgłaszają odwiedzający z różnych sieci i przeglądarek, problem leży w Twojej infrastrukturze. Te trzy kontrole wykrywają prawie wszystkie przypadki.

1. Odtwórz błąd za pomocą curl

# HTTP/2: watch the end of the output
curl -sv --http2 https://example.com/broken-page -o /dev/null
# A stream the server gave up on ends with something like:
# HTTP/2 stream 1 was not closed cleanly: INTERNAL_ERROR (err 2)
# (curl 8.19+: HTTP/2 stream 1 reset by server (error 0x2 INTERNAL_ERROR);
#  "reset by curl" means curl rejected the response itself)

# Same URL over HTTP/1.1 for comparison
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Jeśli HTTP/1.1 działa, a HTTP/2 nie, HTTP/2 ma w tym udział. „Reset by server” wskazuje, że serwer lub proxy poddało się w połowie odpowiedzi. curl nie sprawdza dokładnie tego, co Chrome (odrzuca niezgodności Content-Length i nagłówki połączenia, które Chrome przepuszcza), więc traktuj to jako mocną wskazówkę, a nie dowód. Checker nagłówków HTTP pokazuje nagłówki ustawiane przez Twoją aplikację, widziane spoza Twojej sieci.

2. Sprawdź, czy odpowiedzi nie są ucinane w połowie strumienia

Najczęstszą przyczyną po stronie serwera jest odpowiedź, która się zaczyna (status 200, wysłane nagłówki), a potem nie może zostać dokończona. nginx buforuje większe odpowiedzi z Twojej aplikacji w plikach tymczasowych, a jeśli dysk jest pełny albo nginx nie może zapisywać w swoim katalogu tymczasowym, resetuje strumień, a przeglądarka zgłasza błąd protokołu. Sprawdź:

df -h                                   # is any disk full?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # Debian/Ubuntu packages
ls -ld /var/cache/nginx/proxy_temp /var/cache/nginx/fastcgi_temp   # nginx.org packages
# the temp folders must be writable by the nginx worker user

Sprawdź też samą aplikację: proces PHP lub Node, który pada, przekracza limit czasu albo limit pamięci podczas strumieniowania dużej strony lub pliku do pobrania, daje ten sam efekt. Logi aplikacji z okolic momentu wystąpienia błędu zwykle to pokazują.

3. Napraw Content-Length i zakazane nagłówki

• Content-Length: pozwól serwerowi go obliczyć. Nie ustawiaj go ręcznie w kodzie aplikacji, jeśli wtyczka, middleware lub serwer WWW również kompresuje lub modyfikuje dane wyjściowe, bo wtedy zadeklarowana długość nie zgadza się już z wysłanymi bajtami. Na stronach WordPress dzieje się tak na przykład wtedy, gdy długość jest ustawiana w kodzie PHP, a wtyczka lub ustawienie PHP dodatkowo kompresuje dane wyjściowe.
• Transfer-Encoding: nigdy nie wysyłaj go w odpowiedzi HTTP/2; Chrome resetuje strumień, gdy go zobaczy. RFC 9113 zakazuje też Connection, Keep-Alive, Proxy-Connection i Upgrade. Chrome je ignoruje, ale curl i inni surowi klienci je odrzucają, a nginx usuwa większość z nich z odpowiedzi proxy za Ciebie.
• Wartości nagłówków: upewnij się, że żaden nagłówek nie zawiera znaku nowej linii ani znaku sterującego. Często bierze się to z danych od użytkownika umieszczonych w nagłówku, na przykład nazwy pliku w Content-Disposition.
• CDN przed serwerem: jeśli korzystasz z Cloudflare lub innego CDN, przetestuj serwer źródłowy bezpośrednio (za pomocą curl --resolve lub wpisu w pliku hosts), aby ustalić, czy błąd pochodzi z serwera źródłowego, czy z CDN.

ERR_HTTP2_PROTOCOL_ERROR a podobne błędy

Szczegółowe poradniki: ERR_QUIC_PROTOCOL_ERROR, ERR_SSL_PROTOCOL_ERROR, ERR_CONNECTION_CLOSED i ERR_EMPTY_RESPONSE. Aby sprawdzić certyfikat i konfigurację HTTPS strony z zewnątrz, użyj SSL Checker.