ERR_HTTP2_PROTOCOL_ERROR: Bedeutung und so behebst du den Fehler

Was ist ERR_HTTP2_PROTOCOL_ERROR?

ERR_HTTP2_PROTOCOL_ERROR ist ein Fehler in Chrome und Edge und bedeutet, dass der Browser eine HTTP/2-Antwort erhalten hat, die gegen die Regeln des Protokolls verstößt. In Chromium ist das der Netzwerkfehler -337: „there is an HTTP/2 protocol error“. Chrome hat dafür keine eigene Fehlerseite, du siehst 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.

HTTP/2 ist die schnellere HTTP-Version, die heute die meisten HTTPS-Seiten nutzen. Sie ist strenger als HTTP/1.1: Antworten werden in binäre Frames aufgeteilt, Header folgen genauen Regeln, und die angekündigte Größe einer Antwort muss mit dem übereinstimmen, was tatsächlich ankommt. Sieht Chrome eine Antwort, die gegen diese Regeln verstößt, etwa eine, die mittendrin abbricht oder einen verbotenen Header enthält, behandelt es die ganze Antwort als fehlerhaft und verwirft sie.

Entwickler sehen den Fehler oft in der DevTools-Konsole als net::ERR_HTTP2_PROTOCOL_ERROR 200 (OK). Diese Kombination ist ein starker Hinweis: Der Server hat mit 200 geantwortet, aber der Response-Body ist nie vollständig angekommen.

Was HTTP/2 als fehlerhaft behandelt

Der HTTP/2-Standard (RFC 9113) listet die Fehler auf, die eine Antwort ungültig machen, und auch ein Stream, der vor seinem Ende zurückgesetzt wird, scheitert. Hinter den meisten Fehlern in der Praxis stecken diese Probleme:

Was verursacht ERR_HTTP2_PROTOCOL_ERROR?

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

• Am Server: mittendrin abgeschnittene Antworten (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, verbotene oder ungültige Header und fehlerhafte HTTP/2-Unterstützung in einer älteren Server- oder CDN-Konfiguration.

• Auf deiner Seite: Antivirus- oder Firewall-Software, die HTTPS prüft und Antworten umschreibt, Browser-Erweiterungen, die Anfragen oder Antworten verändern, eine beschädigte zwischengespeicherte Kopie der Seite und gelegentlich eine veraltete Chrome-Version.

Lösung 1: Hartes Neuladen und Inkognito testen

Drück 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.

Öffne die Seite dann in einem Inkognito-Fenster (Strg + Umschalt + N, Mac Cmd + Umschalt + N). Inkognito hat keine Cookies, keinen Cache aus deinem 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 deinem normalen Fenster.

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

Eine beschädigte Kopie im Cache oder ein aufgeblähtes Cookie kann den Fehler auf einer Website immer wieder auslösen. Lösche nur die Daten dieser Website: Klicke auf das Symbol links in der Adressleiste → Cookies und Websitedaten (oder Website-Einstellungen) → Daten löschen und neu laden. Für eine gründlichere Bereinigung drück Strg + Umschalt + Entf und lösche Bilder und Dateien im Cache für die letzten 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 Antworten weiterreichen, die Chrome als fehlerhaft einstuft. Schalte nur die HTTPS-Scan-Funktion aus (oft HTTPS-Scan, Web-Schutz (Web Shield), SSL/TLS-Protokollfilterung oder Verschlüsselte Verbindungen scannen genannt) und lade neu. Behebt das den Fehler, aktualisiere das Antivirenprogramm und richte eine Ausnahme für die Website ein.

Deaktiviere als Nächstes alle Erweiterungen unter chrome://extensions, lade neu und schalte 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

Öffne chrome://settings/help, um ausstehende Updates zu installieren, und starte den Browser neu. Öffne dann dieselbe Seite in Firefox oder Safari. Scheitert sie überall, ist die Website kaputt, und nur ihr Betreiber kann das beheben. Scheitern nur Chrome oder Edge, liegt es meist trotzdem an der Website, weil Chrome fehlerhaftes HTTP/2 am strengsten ablehnt, aber Lösung 2 und 3 lohnen einen zweiten Versuch.

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

Chrome lässt sich mit ausgeschaltetem HTTP/2 starten. So weißt du sicher, ob HTTP/2 das Problem ist. Schließ zuerst alle Chrome-Fenster und starte es dann aus einem Terminal:

# Windows (Eingabeaufforderung)
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-http2

# macOS (Terminal)
open -a "Google Chrome" --args --disable-http2

Lädt die Seite in diesem Fenster, sind die HTTP/2-Antworten der Website fehlerhaft, und der Betreiber muss sie beheben. Schließ Chrome danach und öffne es wieder ganz normal. Das Flag gilt nur für diesen einen Start.

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

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

1. Mit curl reproduzieren

# HTTP/2: auf das Ende der Ausgabe achten
curl -sv --http2 https://example.com/broken-page -o /dev/null
# Ein kaputter Stream endet etwa so:
# HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)
# (ab curl 8.19: HTTP/2 stream 1 reset by server (error 0x1 PROTOCOL_ERROR))

# Dieselbe URL zum Vergleich über HTTP/1.1
curl -sv --http1.1 https://example.com/broken-page -o /dev/null

Funktioniert HTTP/1.1 und scheitert HTTP/2, hast du den Fehler bestätigt. Vergleiche die Response-Header der beiden und notiere, wie viele Bytes ankommen, bevor der Stream abbricht. Das Tool HTTP-Headers zeigt dir außerdem, welche Header deine Website sendet – von außerhalb deines 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 zu früh aufhört. nginx puffert größere Antworten deiner App in temporären Dateien. Ist die Festplatte voll oder kann nginx nicht in seinen Temp-Ordner schreiben, endet die Antwort vorzeitig, und der Browser meldet einen Protokollfehler. Prüfe:

df -h                                   # ist eine Festplatte voll?
sudo grep -E "No space left|Permission denied" /var/log/nginx/error.log | tail
ls -ld /var/lib/nginx/proxy /var/lib/nginx/fastcgi   # Temp-Verzeichnisse unter Debian/Ubuntu; Besitzer muss der nginx-Benutzer sein

Prüfe 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: Lass den Server ihn berechnen. Setz 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.

• Verbindungsspezifische Header: Entferne Code, der Connection, Keep-Alive, Transfer-Encoding oder Upgrade in Antworten setzt. HTTP/2 verbietet sie, und während nginx die meisten davon selbst entfernt, tun das manche App-Server und Proxys nicht.

• Header-Werte: Stell 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: Nutzt du Cloudflare oder ein anderes CDN, teste 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, nutze den SSL-Checker.