ERR_HTTP2_PROTOCOL_ERROR: Bedeutung und Lösung

Was ist ERR_HTTP2_PROTOCOL_ERROR?

ERR_HTTP2_PROTOCOL_ERROR ist ein Fehler in Chrome und Edge und bedeutet, dass der HTTP/2-Stream, der die Seite transportiert, fehlgeschlagen ist: Der Server hat ihn vor dem Ende zurückgesetzt oder Header gesendet, die der Browser ablehnt. In Chromium ist das der Netzwerkfehler -337: „There is an HTTP/2 protocol error“ (net_error_list.h). Chrome hat dafür keine eigene Fehlerseite, Sie sehen also die allgemeine: „Diese Website ist nicht erreichbar. Die Webseite unter … ist möglicherweise vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.“ Darunter steht ERR_HTTP2_PROTOCOL_ERROR. Edge zeigt denselben Code auf seiner eigenen Fehlerseite.

HTTP/2 ist die schnellere HTTP-Version, die heute die meisten HTTPS-Seiten nutzen. Jede Anfrage läuft als eigener Stream innerhalb einer einzigen Verbindung, und jede Seite kann einen Stream mit einem Reset abbrechen. Chrome meldet jeden Reset vom Server als Protokollfehler, egal aus welchem Grund der Server ihn gesendet hat. Außerdem bricht Chrome einen Stream selbst ab, wenn die Header gegen die Regeln von HTTP/2 verstoßen (ein Transfer-Encoding-Header, Großbuchstaben in einem Header-Namen, ein fehlender Status).

Entwickler sehen den Fehler oft in der DevTools-Konsole als net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Diese Kombination ist ein starker Hinweis: Die Header waren gültig und der Server hat mit 200 geantwortet, aber der Stream ist gescheitert, während der Body noch ankam.

Was HTTP/2 als fehlerhaft behandelt

Der HTTP/2-Standard (RFC 9113) listet die Fehler auf, die eine Antwort ungültig machen. Hinter den meisten Fehlern in der Praxis stecken diese Probleme, und so kommt jedes davon im Browser an:

Was verursacht ERR_HTTP2_PROTOCOL_ERROR?

Die meisten Fälle kommen von der Serverseite, aber ein paar Dinge auf Ihrem eigenen Computer können eine Antwort auf dem Weg zu Ihnen beschädigen:

• Am Server: eine Antwort, die Server oder Proxy nicht zu Ende senden können (ein Proxy, dem der Speicherplatz ausgeht oder der seine Temp-Dateien nicht schreiben kann, eine App, die beim Streamen abstürzt, ein Timeout), falsche Content-Length-Werte, bei denen der vorgeschaltete Proxy aufgibt, verbotene oder ungültige Header und fehlerhafte HTTP/2-Unterstützung in einer älteren Server- oder CDN-Konfiguration.
• Auf Ihrer Seite: Antivirus- oder Firewall-Software, die HTTPS prüft und den Datenverkehr umschreibt, Browser-Erweiterungen, die Anfragen oder Antworten verändern, eine Anfrage, die der Server falsch verarbeitet (zum Beispiel übergroße Cookies), und gelegentlich eine veraltete Chrome-Version.

Lösung 1: Hartes Neuladen und Inkognito testen

Drücken Sie Strg + Umschalt + R (Mac: Cmd + Umschalt + R), um ohne Cache neu zu laden. Eine Antwort, die einmal abgeschnitten wurde, kommt beim nächsten Versuch womöglich vollständig an.

Öffnen Sie die Seite dann in einem Inkognito-Fenster (Strg + Umschalt + N, Mac Cmd + Umschalt + N). Inkognito hat keine Cookies, keinen Cache aus Ihrem normalen Profil, und Erweiterungen sind standardmäßig aus. Lädt die Seite dort, lösen Lösung 2 oder Lösung 3 das Problem in Ihrem normalen Fenster.

Lösung 2: Cookies und Cache dieser Website löschen

Das Löschen von Cookies und Cache der Website ändert die Anfrage, die Chrome sendet (weniger Cookies, keine zwischengespeicherte Kopie, die erneut geprüft werden muss), und das kann einen Serverfehler umgehen. Klicken Sie links in der Adressleiste auf Website-Informationen anzeigen → Cookies und Websitedaten → Websitedaten auf dem Gerät verwalten → löschen und neu laden. Für eine gründlichere Bereinigung drücken Sie Strg + Umschalt + Entf und löschen Bilder und Dateien im Cache für den Zeitraum Letzte 7 Tage.

Lösung 3: HTTPS-Scan des Antivirus und Erweiterungen pausieren

Sicherheitssoftware, die HTTPS entschlüsselt und prüft, sitzt mitten in jeder HTTP/2-Verbindung. Ist ihre HTTP/2-Verarbeitung fehlerhaft oder veraltet, kann sie Streams beschädigen oder Header weiterreichen, die Chrome ablehnt. Schalten Sie nur die HTTPS-Scan-Funktion aus (Avast/AVG: Web-Schutz → Enable HTTPS scanning; ESET: SSL/TLS-Protokollfilterung; Kaspersky: Verschlüsselte Verbindungen scannen) und laden Sie neu. Behebt das den Fehler, aktualisieren Sie das Antivirenprogramm und richten Sie eine Ausnahme für die Website ein.

Deaktivieren Sie als Nächstes alle Erweiterungen unter chrome://extensions, laden Sie neu und schalten Sie sie dann nacheinander wieder ein. Werbeblocker, Datenschutz-Tools und alles, was Header bearbeitet, sind die üblichen Verdächtigen.

Lösung 4: Chrome aktualisieren und andere Browser testen

Öffnen Sie chrome://settings/help, um ausstehende Updates zu installieren, und starten Sie den Browser neu. Öffnen Sie dann dieselbe Seite in Firefox oder Safari sowie auf einem anderen Gerät oder in einem anderen Netzwerk. Scheitert sie überall, ist die Website kaputt, und nur ihr Betreiber kann das beheben (der HTTPS-Scan eines Antivirus betrifft jeden Browser auf einem Computer, ein zweites Gerät ist also der eigentliche Test). Scheitern nur Chrome oder Edge, sendet die Website wahrscheinlich einen Header, den Chrome ablehnt; Lösung 2 und 3 lohnen trotzdem einen zweiten Versuch.

Lösung 5: Die Seite ohne HTTP/2 testen

Chrome lässt sich mit ausgeschaltetem HTTP/2 (und HTTP/3) starten. So sehen Sie, ob HTTP/2 beteiligt ist. Starten Sie aus einem Terminal ein zweites, separates Chrome; der zusätzliche Profilordner macht es zu einer neuen Instanz, auch wenn Ihr normales Chrome offen ist:

# 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

Lädt die Seite in diesem Fenster, sind die HTTP/2-Antworten der Website das Problem, und der Betreiber muss sie beheben. Scheitert sie jetzt mit ERR_CONTENT_LENGTH_MISMATCH oder ERR_INCOMPLETE_CHUNKED_ENCODING, schneidet der Server die Antwort unabhängig vom Protokoll ab. Schließen Sie das Fenster danach; Ihr normales Chrome bleibt unberührt.

Für Website-Betreiber: HTTP/2-Protokollfehler beheben

Melden Besucher aus verschiedenen Netzwerken und Browsern den Fehler, liegt das Problem in Ihrem Stack. Diese drei Prüfungen finden fast alle Ursachen.

1. Mit curl reproduzieren

# 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

Funktioniert HTTP/1.1 und scheitert HTTP/2, ist HTTP/2 beteiligt. „Reset by server“ weist darauf hin, dass der Server oder ein Proxy mitten in der Antwort aufgegeben hat. curl prüft nicht genau dasselbe wie Chrome (es lehnt Content-Length-Abweichungen und verbindungsspezifische Header ab, die Chrome durchlässt), betrachten Sie es also als starken Hinweis, nicht als Beweis. Der HTTP-Headers-Checker listet die Header auf, die Ihre App setzt, von außerhalb Ihres Netzwerks gesehen.

2. Nach mittendrin abgeschnittenen Antworten suchen

Die häufigste Ursache auf Serverseite ist eine Antwort, die beginnt (Status 200, Header gesendet) und dann nicht zu Ende gebracht werden kann. nginx puffert größere Antworten Ihrer App in temporären Dateien. Ist die Festplatte voll oder kann nginx nicht in seinen Temp-Ordner schreiben, setzt es den Stream zurück, und der Browser meldet einen Protokollfehler. Prüfen Sie:

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

Prüfen Sie auch die App selbst: Ein PHP- oder Node-Prozess, der beim Streamen einer großen Seite oder eines Downloads abstürzt, in ein Timeout läuft oder ein Speicherlimit erreicht, führt zum selben Ergebnis. Die App-Logs rund um den Zeitpunkt des Fehlers zeigen das meist.

3. Content-Length und verbotene Header korrigieren

• Content-Length: Lassen Sie den Server ihn berechnen. Setzen Sie ihn nicht von Hand im App-Code, wenn ein Plugin, eine Middleware oder der Webserver die Ausgabe zusätzlich komprimiert oder verändert, denn dann passt die angekündigte Länge nicht mehr zu den gesendeten Bytes. Eine im PHP-Code gesetzte Länge, während ein Plugin oder eine PHP-Einstellung die Ausgabe ebenfalls komprimiert, ist ein Weg, wie das auf WordPress-Seiten passiert.
• Transfer-Encoding: Senden Sie ihn nie in einer HTTP/2-Antwort; Chrome setzt den Stream zurück, sobald es einen sieht. RFC 9113 verbietet außerdem Connection, Keep-Alive, Proxy-Connection und Upgrade. Chrome ignoriert diese, curl und andere strenge Clients lehnen sie aber ab, und nginx entfernt die meisten davon aus weitergeleiteten Antworten für Sie.
• Header-Werte: Stellen Sie sicher, dass kein Header einen Zeilenumbruch oder ein Steuerzeichen enthält. Das kommt oft von Nutzereingaben, die in einem Header landen, etwa ein Dateiname in Content-Disposition.
• Vorgeschaltetes CDN: Nutzen Sie Cloudflare oder ein anderes CDN, testen Sie den Origin-Server direkt (mit curl --resolve oder einem hosts-Eintrag), um herauszufinden, ob der Fehler vom Origin oder vom CDN kommt.

ERR_HTTP2_PROTOCOL_ERROR vs. ähnliche Fehler

Ausführliche Anleitungen: ERR_QUIC_PROTOCOL_ERROR, ERR_SSL_PROTOCOL_ERROR, ERR_CONNECTION_CLOSED und ERR_EMPTY_RESPONSE. Um das Zertifikat und die HTTPS-Einrichtung einer Website von außen zu prüfen, nutzen Sie den SSL-Checker.