ERR_HTTP2_PROTOCOL_ERROR: Ursachen und Lösungen

Was ERR_HTTP2_PROTOCOL_ERROR bedeutet

HTTP/2 sendet Anfragen und Antworten als binäre Frames über eine einzige Verbindung, mit strengen Regeln für Frame-Größe, Header-Kodierung (HPACK) und Stream-Zustand. Ein Server, Proxy, oder CDN, der einen fehlerhaften Frame, einen übergroßen Header, oder einen Frame für einen bereits geschlossenen Stream sendet, bricht diese Regeln, und der Client reißt die Verbindung ab, statt zu raten, was gemeint war. Da der Fehler vom Anwendungsserver, einem Proxy dazwischen, einer CDN-Edge, oder dem eigenen Netzwerk-Stack des Browsers ausgehen kann, deckt dieser Fehler ein breiteres Spektrum an Grundursachen ab als die meisten anderen in dieser Liste.

Wie sich der Fehler zeigt

Chrome und Edge zeigen "This page isn't working - ERR_HTTP2_PROTOCOL_ERROR", manchmal nur bei manchen Seitenaufrufen und nicht bei anderen, was ein Hinweis darauf ist, dass der Fehler unregelmäßig auftritt statt einer festen Fehlkonfiguration. Firefox zeigt meist einen generischen Verbindungsfehler, statt das Protokoll zu benennen.

curl kann HTTP/2 erzwingen und genau zeigen, bei welchem Frame die Verbindung gescheitert ist:

curl --http2 -v https://example.com/ 2>&1 | tail -20
...
* Recv failure: Connection reset by peer
* HTTP/2 stream 1 was not closed cleanly: PROTOCOL_ERROR (err 1)

Das mit einer HTTP/1.1-Anfrage an dieselbe URL zu vergleichen isoliert, ob das Problem protokollspezifisch ist:

curl --http1.1 -sI https://example.com/

Gelingt die HTTP/1.1-Anfrage und die HTTP/2-Anfrage scheitert, liegt der Fehler daran, wie etwas in der Kette HTTP/2 implementiert, nicht an der Anwendung selbst.

Was ERR_HTTP2_PROTOCOL_ERROR verursacht

• Fehlerhafte oder übergroße Header von der Anwendung oder einem Proxy. Ein sehr langes Cookie, ein übergroßer Satz Antwort-Header, oder ein Header-Wert mit Zeichen, die HPACK nicht kodieren kann, verletzt die Frame-Größe, die Server oder Client erwarten.
• Ein Reverse-Proxy oder Load Balancer mit einer fehlerhaften oder veralteten HTTP/2-Implementierung. Manche älteren nginx-, Apache-, oder Embedded-Device-HTTP/2-Stacks haben bekannte Probleme mit bestimmten Frame-Sequenzen unter Last.
• Ein CDN-Edge-Bug oder eine Protokoll-Fehlpassung zwischen Edge und Ursprung. Die Strecke Browser-zu-Edge und die Strecke Edge-zu-Ursprung können unterschiedliche Protokolle nutzen; ein Bug bei der Übersetzung dazwischen erzeugt diesen Fehler gelegentlich nur für bestimmte Anfrageformen.
• Antivirensoftware oder eine Browser-Erweiterung, die HTTPS-Traffic abfängt. Dieselbe Klasse Software, die SSL-Handshake-Fehler verursacht, kann auch einen gesunden HTTP/2-Stream brechen, wenn ihre Abfangschicht kein korrektes HTTP/2 spricht.
• Ein veralteter Browser mit einer alten HTTP/2-Implementierung, oder ein beschädigter Browser-Netzwerk-Cache.
• Eine Content-Length-Fehlpassung hinter einem Reverse-Proxy. Leitet nginx (oder ein anderer Proxy) eine Antwort weiter, deren deklarierte Content-Length nicht mit den tatsächlich gesendeten Bytes übereinstimmt, kann das nachgelagerte HTTP/2-Framing mittendrin brechen.

So finden Sie heraus, wer schuld ist

Führen Sie eine HTTP-Prüfung von mehreren Standorten aus: Tritt der Fehlschlag überall gleich auf, liegt die Ursache an der HTTP/2-Behandlung des Servers oder CDN. Scheitert es nur bei Ihnen, liegt es weit wahrscheinlicher lokal, an einem Browser, einem Antivirenprogramm, oder einem Netzwerkgerät zwischen Ihnen und der Website.

So beheben Sie ERR_HTTP2_PROTOCOL_ERROR

Wenn Sie Besucher sind

1. Laden Sie die Seite neu. Da die Ursache oft ein einzelner fehlerhafter Frame ist statt einer dauerhaften Fehlkonfiguration, gelingt eine frische Verbindung häufig.
2. Leeren Sie den Browser-Cache unter chrome://settings/clearBrowserData, da eine beschädigte zwischengespeicherte Ressource dies beim Neuladen auslösen kann.
3. Deaktivieren Sie vorübergehend das HTTPS/SSL-Scanning des Antivirenprogramms und versuchen Sie es erneut; diese Softwareklasse ist eine häufige und oft übersehene Ursache.
4. Probieren Sie ein Inkognito-Fenster, um eine Erweiterung auszuschließen.
5. Aktualisieren Sie den Browser auf die neueste Version, da ältere HTTP/2-Client-Implementierungen bekannte Bugs hatten.

Wenn Sie die Website betreiben

1. Vergleichen Sie HTTP/2 mit HTTP/1.1 mit den obigen curl-Befehlen. Scheitert nur HTTP/2, liegt das Problem in der HTTP/2-Schicht eines Proxys oder CDN, nicht in der Anwendung.
2. Erhöhen Sie nginx' Header-Größenlimits, falls große Cookies oder Header beteiligt sind:

   http2_max_field_size 16k;
   http2_max_header_size 32k;
   large_client_header_buffers 4 16k;

   Starten Sie nginx nach der Änderung neu oder laden Sie es neu, und testen Sie erneut.
3. Prüfen Sie auf eine Content-Length-Fehlpassung zwischen dem, was die Anwendung sendet, und dem, was der Proxy weiterleitet; aktivieren Sie Proxy-Buffering (proxy_buffering on;), damit nginx die vollständige Antwort lesen kann, bevor es sie für HTTP/2 framt.
4. Aktualisieren Sie nginx, Apache, oder jeden Load Balancer auf eine aktuelle Version; HTTP/2-Frame-Behandlungs-Bugs sind die Art Ding, die in Punkt-Releases behoben wird.
5. Deaktivieren Sie HTTP/2 als Diagnosetest, nicht als dauerhafte Lösung: Entfernen Sie http2 vorübergehend aus der nginx-listen-Direktive. Hören die Fehler auf, ist bestätigt, dass der Fehler konkret in der HTTP/2-Schicht sitzt, und Sie können es wieder aktivieren, sobald die Header- oder Buffering-Lösung oben umgesetzt ist.
6. Prüfen Sie CDN-seitige Logs, falls eines vor dem Ursprung sitzt; die meisten CDNs zeigen HTTP/2-Framing-Fehler in ihren Edge-Logs mit mehr Detail, als der Browser je zeigt.

Verwandte Fehler

• ERR_SSL_PROTOCOL_ERROR sieht ähnlich aus, scheitert aber früher, während des TLS-Handshakes, bevor überhaupt ein HTTP/2-Frame ausgetauscht wird.
• 5xx-Server-Fehlercodes decken Fälle ab, in denen Verbindung und Protokoll einwandfrei funktionieren, aber die Anwendung selbst scheitert.

Ein Detail, das sich zu trennen lohnt: Ein HTTP/2-Protokollfehler ist nicht dasselbe wie ein Stream, den die Anwendung sauber zurückgesetzt hat, zum Beispiel wenn ein Client eine Anfrage mitten im Verlauf abbricht. Browser-Entwicklertools und Server-Zugriffslogs bezeichnen manchmal beides als "reset", aber nur eine echte Framing-Verletzung erzeugt ERR_HTTP2_PROTOCOL_ERROR im Browser; ein absichtlich abgebrochener Stream stoppt einfach ohne Fehlerseite.

So beugen Sie ERR_HTTP2_PROTOCOL_ERROR vor

Da dieser Fehler oft unregelmäßig auftritt, gebunden an bestimmte Header-Größen oder bestimmte Proxy-Versionen, kann er einen Teil der Besucher wochenlang betreffen, bevor jemand ein Muster bemerkt. Eine planmäßig von mehreren Standorten laufende HTTP-Prüfung erkennt eine steigende Fehlerrate direkt nach einem Deploy, einer CDN-Änderung, oder einem Proxy-Upgrade, statt sich auf verstreute Nutzermeldungen zu verlassen. HostTracker alarmiert per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr, sobald eine Prüfung zu scheitern beginnt.

Häufig gestellte Fragen

Ist ERR_HTTP2_PROTOCOL_ERROR dasselbe wie ein SSL-Fehler?

Nein. Dieser Fehler passiert, nachdem TLS erfolgreich war, auf der HTTP/2-Framing-Ebene. Ein SSL-Fehler bedeutet, die verschlüsselte Verbindung selbst kam nie zustande.

Warum erscheint der Fehler nur manchmal, nicht bei jedem Seitenaufruf?

Die meisten Ursachen hier werden durch bestimmte Bedingungen ausgelöst, einen Header, der ein Limit überschreitet, eine Race Condition in einem Proxy unter Last, eine bestimmte zwischengespeicherte Ressource, statt einer festen Fehlkonfiguration, die jedes Mal scheitert.

Schadet das Deaktivieren von HTTP/2 auf meinem Server der Leistung?

HTTP/2 bietet echte Vorteile (Multiplexing, Header-Kompression), behandeln Sie das Deaktivieren also als vorübergehenden Diagnoseschritt, nicht als dauerhafte Lösung. Beheben Sie das zugrunde liegende Header-Größen- oder Buffering-Problem und aktivieren Sie es wieder.

Kann ein CDN das verursachen, auch wenn mein Ursprungsserver in Ordnung ist?

Ja. Die CDN-Edge und der Ursprung können auf jeder Strecke der Verbindung unterschiedliche Protokolle nutzen, und ein Bug oder eine Fehlkonfiguration dabei, wie das CDN dazwischen übersetzt, kann diesen Fehler unabhängig von der Gesundheit des Ursprungs erzeugen.

Passiert das auf HTTP/1.1-Websites?

Nein, ERR_HTTP2_PROTOCOL_ERROR ist spezifisch für Verbindungen, die HTTP/2 ausgehandelt haben. Eine Website, die nur HTTP/1.1 bedient, kann diesen bestimmten Fehler nicht erzeugen, kann aber eigene Verbindungsprobleme haben.