---
title: "err_http2_protocol_error: Ursachen und Lösungen in Chrome"
description: "err_http2_protocol_error bedeutet: Chrome erhielt einen HTTP/2-Frame, den es nicht annehmen kann, und brach die Anfrage ab. Ursachen, Lösungen, Prüfschritte."
url: https://proxynet.io/de/blog/err-http2-protocol-error
date: 2026-11-07
author: "Acar Diveroli"
category: "Anleitungen"
lang: de
---

# err_http2_protocol_error: Ursachen und Lösungen in Chrome

Sie öffnen in Chrome eine Web-App, die Kasse eines Shops oder die Seite eines Videodienstes und bekommen stattdessen einen grauen Bildschirm: „Die Website ist nicht erreichbar“, eine Zeile, nach der die Webseite „eventuell vorübergehend nicht verfügbar“ ist oder „dauerhaft an eine neue Webadresse verschoben“ wurde, und ganz unten `ERR_HTTP2_PROTOCOL_ERROR`. Manchmal lädt die Seite stattdessen nur halb, ein Skript oder ein Bild fehlt, und die Entwicklerkonsole meldet „Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR“.

Der Code verweist auf HTTP/2, das Protokoll, das die meisten sicheren Websites mit Chrome sprechen, und er bedeutet fast immer, dass die Website oder ein Gerät zwischen Ihnen und ihr etwas gesendet hat, das die Regeln von HTTP/2 verletzt. Im Folgenden: was der Code bedeutet, wie eine Anfrage scheitert, die Ursachen, die wir nachgestellt haben, die Lösungen für Besucher, was Betreiber auf nginx, IIS und Cloudflare prüfen, und der Fehler in Go, Node.js und Python.

> **Hinweis: Kurzantwort**
>
> `ERR_HTTP2_PROTOCOL_ERROR` bedeutet, dass auf der HTTP/2-Verbindung von Chrome zur Website ein Frame übertragen wurde, der gegen das HTTP/2-Protokoll verstößt; die Anfrage wurde deshalb abgebrochen statt beantwortet. Meist hat der Server der Website oder ein davor geschaltetes CDN die Anfrage mit einem `PROTOCOL_ERROR` zurückgesetzt, weil eine Antwort fehlerhaft aufgebaut war: ein verbotener Header wie `Transfer-Encoding`, ein `Content-Length`-Wert, der nicht mehr zum komprimierten Body passt, oder zu große Header. Seltener beschädigt ein Sicherheitsprogramm, eine Firewall oder ein VPN, das verschlüsselten Datenverkehr prüft, die Frames. Als Besucher laden Sie neu, versuchen ein Inkognitofenster oder einen anderen Browser, schalten VPN und den Webschutz des Virenschutzes für einen Test aus und löschen die gespeicherten Daten der Website. Ist die Website Ihre, vergleichen Sie die fehlerhafte Antwort über HTTP/2 und über HTTP/1.1.

## Was bedeutet ERR_HTTP2_PROTOCOL_ERROR?

Es bedeutet, dass auf der HTTP/2-Verbindung zwischen Ihrem Browser und der Website etwas angekommen ist, das das Protokoll nicht erlaubt, und die Anfrage nicht abgeschlossen werden konnte. HTTP/2 ist die zweite große Version von HTTP; es läuft innerhalb einer TLS-verschlüsselten Verbindung auf TCP-Port 443, und der Server wählt es beim TLS-Handshake über die Kennung `h2`. Chrome und Edge bauen auf Chromium auf, dessen [Liste der Netzwerkfehler](https://github.com/chromium/chromium/blob/main/net/base/net_error_list.h) diesen Code als Fehler -337 mit einer einzigen Zeile definiert: „There is an HTTP/2 protocol error.“ (Es ist ein HTTP/2-Protokollfehler aufgetreten.)

Diese Zeile benennt das Symptom, nicht den Verursacher. Der HTTP/2-Standard verwendet `PROTOCOL_ERROR` als Sammelcode für Fälle, in denen „kein spezifischerer Fehlercode verfügbar ist“; die Meldung sagt also, dass eine Regel verletzt wurde, aber nicht welche. Der verwandte Code `ERR_QUIC_PROTOCOL_ERROR` betrifft HTTP/3 über QUIC und UDP, hat andere Ursachen und wird in [err_quic_protocol_error in Chrome und Edge beheben](/de/blog/err-quic-protocol-error) erklärt.

## Was sagt Ihnen die Fehlerseite?

| Zeile auf dem Bildschirm | Bedeutung |
|---|---|
| „Die Website ist nicht erreichbar“ | Die allgemeine Überschrift von Chrome für eine Anfrage, die scheiterte, bevor eine Seite angezeigt werden konnte |
| „Die Webseite unter example.com ist eventuell vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.“ | Ein Standardsatz, keine Diagnose; die Website ist meist erreichbar |
| `ERR_HTTP2_PROTOCOL_ERROR` | Die einzige konkrete Information auf der Seite |

Wir haben diese Zeilen in Chromium 145 auf dem Bildschirm gesehen. Die Seite hat keine Liste „Versuche Folgendes:“ und keine Schaltfläche zum Neuladen: Chromium hat keinen eigenen Text für HTTP/2-Fehler und greift auf seine allgemeine Seite zurück. Edge zeigt denselben Code; die anderen Codes unter dieser Überschrift erklärt [Die Website ist nicht erreichbar: Bedeutung und Ursachen](/de/blog/this-site-cant-be-reached).

Bricht die Verbindung ab, nachdem der Server bereits einen `200 OK`-Header gesendet hat, kann die Seite unvollständig erscheinen, und die Entwicklerkonsole (F12) protokolliert für die abgeschnittene Anfrage „Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR“. Eine 200 neben dem Fehler bedeutet genau das: Die Antwort hatte begonnen, bevor der Stream zurückgesetzt wurde.

## Wie scheitert eine HTTP/2-Anfrage?

1. **Die Verbindung beginnt.** Chrome öffnet eine TLS-Verbindung zu Port 443 und bietet `h2` an; der Server nimmt an, und beide Seiten tauschen je einen `SETTINGS`-Frame mit ihren Grenzwerten aus.
2. **Anfragen reisen als Streams.** Jede Anfrage erhält auf der gemeinsamen Verbindung einen eigenen Stream, der `HEADERS`-Frames für die Header und `DATA`-Frames für den Body trägt.
3. **Ein Frame verletzt eine Regel.** [RFC 9113](https://www.rfc-editor.org/rfc/rfc9113.html), der HTTP/2-Standard, nennt eine Nachricht fehlerhaft („malformed“), wenn `Content-Length` nicht der Summe der `DATA`-Frames entspricht, ein Header-Wert mit einem Leerzeichen beginnt oder endet oder ein verbindungsspezifischer Header wie `Connection` oder `Transfer-Encoding` vorhanden ist.
4. **Der Endpunkt, der es bemerkt, setzt den Stream zurück.** Eine fehlerhafte Nachricht muss als Stream-Fehler vom Typ `PROTOCOL_ERROR` behandelt werden, also sendet der Endpunkt einen `RST_STREAM`-Frame; ein Fehler, der die ganze Verbindung beschädigt, wird zu einem `GOAWAY`-Frame, und die Verbindung wird geschlossen.
5. **Chrome meldet -337.** Empfängt Chrome einen `RST_STREAM` mit `PROTOCOL_ERROR` oder erkennt es selbst einen ungültigen Frame, lässt es diese Anfrage mit `ERR_HTTP2_PROTOCOL_ERROR` scheitern. Chromium wiederholt sie nicht und fällt nicht auf HTTP/1.1 zurück; nur der Code `HTTP_1_1_REQUIRED` bringt Chrome dazu, eine Anfrage über das ältere Protokoll erneut zu senden.

## Was verursacht ERR_HTTP2_PROTOCOL_ERROR?

| Ursache | Typisches Anzeichen | Wer behebt es |
|---|---|---|
| Die Anwendung der Website sendet eine Antwort, die HTTP/2-Regeln verletzt: ein verbotener Header, ein falscher `Content-Length`-Wert, ein Header-Wert mit Leerzeichen am Ende | Eine Website oder Seite, jeder Besucher | Der Betreiber der Website |
| Ein CDN oder Reverse-Proxy lehnt die fehlerhafte Antwort des Ursprungsservers ab und setzt Ihren Stream zurück | Scheitert über das CDN, funktioniert vom Ursprungsserver | Der Betreiber der Website |
| Antwort-Header über dem Limit eines Servers oder CDN, meist durch riesige Cookies | Eine Website, nach der Anmeldung | Der Betreiber; das Löschen der Websitedaten hilft sofort |
| Eine alte oder falsch konfigurierte HTTP/2-Implementierung auf dem Server | Eine Website, oft direkt nach dem Einschalten von HTTPS | Der Betreiber der Website |
| Sicherheitssoftware, eine Firewall oder ein Filter, der TLS prüft und die Frames verändert | Viele Websites, auf einem Computer oder in einem Netz | Sie oder die IT-Abteilung |
| Ein VPN oder eine „Schutz“-App, die den Datenverkehr durch sich selbst leitet | Nur solange die App läuft | Sie |

Auf unserem HTTP/2-Testserver tolerierte Chromium 145 einen `Content-Length`-Wert, der größer war als der Body, und zeigte sogar die abgeschnittene Seite an, während der HTTP/2-Client von Node.js, httpx für Python und undici dieselbe Antwort mit `PROTOCOL_ERROR` ablehnten; setzte der Server den Stream selbst zurück, zeigte Chromium sofort `ERR_HTTP2_PROTOCOL_ERROR`. Das ist das übliche Muster in der Praxis: Eine leicht fehlerhafte Antwort, die der Browser schlucken würde, wird von einem strengeren CDN oder Load Balancer vor der Website abgelehnt, der den Stream des Besuchers zurücksetzt.

## Wie beheben Sie den Fehler als Besucher?

Scheitern auch andere sichere Websites, liegt die Ursache auf Ihrer Seite; scheitert die Website auch auf Ihrem Smartphone bei ausgeschaltetem WLAN, liegt sie bei der Website. Laden Sie die Seite nach jedem Schritt neu.

1. **Laden Sie einmal neu.** Wählen Sie links oben **Diese Seite neu laden**.
2. **Versuchen Sie ein Inkognitofenster oder einen anderen Browser.** Öffnen Sie **Dreipunkt-Menü > Neues Inkognitofenster**; lädt die Seite dort, schalten Sie unter **Dreipunkt-Menü > Erweiterungen > Erweiterungen verwalten** die Erweiterungen einzeln aus.
3. **Trennen Sie das VPN und Filter-Apps,** auch Apps, die Werbung blockieren, indem sie den Datenverkehr durch sich selbst leiten.
4. **Pausieren Sie den Webschutz des Virenschutzes für einen Test.** Programme, die HTTPS-Datenverkehr prüfen, sitzen innerhalb der verschlüsselten Verbindung. Schalten Sie nur diese Funktion aus, laden Sie einmal neu und schalten Sie sie dann wieder ein; hat die Pause geholfen, aktualisieren Sie das Programm.
5. **Löschen Sie die gespeicherten Daten der Website.** Wählen Sie **Dreipunkt-Menü > Einstellungen**, dann **Datenschutz und Sicherheit > Drittanbieter-Cookies > Alle Websitedaten und -berechtigungen ansehen**, suchen Sie die Website, wählen Sie **Löschen** und bestätigen Sie mit **Löschen**.
6. **Aktualisieren Sie Chrome.** Wählen Sie **Dreipunkt-Menü > Hilfe > Über Google Chrome** und dann **Neu starten**, falls es erscheint.
7. **Fragen Sie in einem Firmen- oder Schulnetz die IT-Abteilung.** Eine Firewall, die den Datenverkehr prüft, gehört der Organisation, und die Lösung ebenso.

Unter Android aktualisieren Sie Chrome über den Play Store: Tippen Sie auf das Profilsymbol, dann auf **Apps und Gerät verwalten**, und tippen Sie unter „Updates verfügbar“ neben Chrome auf **Aktualisieren**. Um gespeicherte Daten zu entfernen, öffnen Sie Chrome, tippen Sie auf **Dreipunkt-Menü > Browserdaten löschen**, wählen Sie die Datentypen und tippen Sie auf **Daten löschen**. Wechseln Sie zwischen WLAN und mobilen Daten und schalten Sie jede VPN-App aus, bevor Sie der Website die Schuld geben.

## Wenn es Ihre Website ist: So finden Sie die fehlerhafte Antwort

1. **Grenzen Sie die Anfrage ein.** Öffnen Sie in den DevTools den Bereich **Netzwerk**, laden Sie neu und suchen Sie die Anfrage, die mit diesem Fehler als gescheitert markiert ist; die Spalte **Protokoll**, die Sie per Rechtsklick auf die Kopfzeile der Tabelle einblenden, zeigt `h2`.
2. **Fragen Sie sie zweimal von der Kommandozeile an.** `curl --http2 -v https://example.com/pfad` und `curl --http1.1 -v` mit derselben URL erzwingen die beiden Protokolle und geben die Antwort-Header aus. Scheitert HTTP/2, während HTTP/1.1 die Seite liefert, verletzt die Antwort eine HTTP/2-Regel. Das in Windows 11 enthaltene curl lehnt `--http2` ab („the installed libcurl version does not support this“), testen Sie also unter Linux, macOS oder auf dem Server.
3. **Vergleichen Sie den Ursprungsserver mit dem Edge.** Hinter einem CDN oder Load Balancer fragen Sie dieselbe URL einmal direkt beim Ursprungsserver und einmal über die öffentliche Adresse an und vergleichen die Header: `Content-Length` und `Content-Encoding`, jeden `Connection`-, `Keep-Alive`- oder `Transfer-Encoding`-Header und Werte mit Leerzeichen am Ende.
4. **Reparieren Sie die Antwort, nicht das Protokoll.** Eine Komprimierungs-Middleware, die den Body mit gzip packt, nachdem die Anwendung `Content-Length` bereits gesetzt hat, ist die klassische Ursache; lassen Sie nur eine Schicht komprimieren und die Länge neu berechnen. Entfernen Sie verbindungsspezifische Header aus dem Anwendungscode und halten Sie Cookies klein. HTTP/2 auf dem Server auszuschalten ist ein Diagnoseschritt für ein paar Minuten, nie die Lösung: Die Antwort bleibt fehlerhaft, und der nächste strenge Client scheitert wieder.
5. **nginx.** Aktuelle Versionen schalten HTTP/2 mit `http2 on;` neben `listen 443 ssl;` ein, verfügbar seit 1.25.1; die ältere Form `listen 443 ssl http2;` ist veraltet, und `http2_max_field_size` und `http2_max_header_size` sind seit 1.19.7 hinfällig und durch `large_client_header_buffers` ersetzt, wie die [Dokumentation zu ngx_http_v2_module](https://nginx.org/en/docs/http/ngx_http_v2_module.html) erklärt.
6. **IIS.** IIS 10 unter Windows Server 2016 und neuer spricht HTTP/2 nur über TLS und fällt bei Windows-Authentifizierung auf HTTP/1.1 zurück, so [Microsofts Artikel zu HTTP/2 auf IIS](https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-10/http2-on-iis); das Feld „Protocol version“ unter **Logging** (Protokollierung) > **Select Fields** (Felder auswählen) zeigt, welche Anfragen HTTP/2 verwenden. Zum Testen kann Windows HTTP/2 pro TLS-Bindung mit `netsh http update sslcert ... disablehttp2=enable` ausschalten (aus der Dokumentation zu `netsh http`, hier nicht getestet).
7. **Cloudflare.** HTTP/2 ist in allen Tarifen standardmäßig eingeschaltet, und die [HTTP/2-Seite](https://developers.cloudflare.com/speed/optimization/protocol/http2/) von Cloudflare nennt falsch formatierte Header des Ursprungsservers und Komprimierungsprobleme, etwa gzip ohne aktualisiertes `Content-Length`, als übliche Ursachen auf Websites, die über Cloudflare laufen, und empfiehlt, stattdessen Cloudflare komprimieren zu lassen.

## Entwickler und Scraper: derselbe Fehler in Go, Node.js und Python

HTTP-Clients, die `h2` aushandeln, scheitern genauso wie Chrome. Gos `http.Server` und `http.DefaultTransport` verwenden HTTP/2 für HTTPS automatisch (`GODEBUG=http2client=0` schaltet die Client-Seite ab). In Node.js 24.22 sprach das eingebaute `fetch` mit unserem Testserver HTTP/1.1, während ein undici-`Agent` mit `allowH2: true` HTTP/2 aushandelte. In Python braucht httpx `pip install httpx[http2]` und `httpx.Client(http2=True)`; HTTP/2 ist standardmäßig aus. Bei einer Antwort, deren `Content-Length` 100 Byte versprach, aber 5 lieferte, meldeten unsere Clients:

```text
# Node.js 24.22, node:http2
response: :status=200 content-length=100 content-type=text/plain
stream error: ERR_HTTP2_STREAM_ERROR Stream closed with error code NGHTTP2_PROTOCOL_ERROR

# undici 7.30 mit allowH2: true
TypeError: terminated <- ERR_HTTP2_STREAM_ERROR: Stream closed with error code NGHTTP2_PROTOCOL_ERROR

# Python httpx 0.28 mit http2=True
h2.exceptions.InvalidBodyLengthError: InvalidBodyLengthError: Expected 100 bytes, received 5
```

Behandeln Sie einen HTTP/2-Protokollfehler als fehlerhafte Antwort, nicht als Sperre: Wiederholen Sie die Anfrage einmal über HTTP/1.1 zur Bestätigung, reparieren Sie den Server, wenn er Ihrer ist, und melden Sie URL und Header dem Betreiber, wenn nicht. Ein Wechsel der IP-Adresse bringt nichts; jede Adresse erhält dieselbe fehlerhafte Antwort.

Ein Proxy kommt selten ins Spiel. Bei einer `https://`-Website bittet der Client den Proxy mit einer `CONNECT`-Anfrage um einen Tunnel und führt TLS, mit HTTP/2 darin, Ende zu Ende mit der Website; der Proxy sieht nie einen Frame, ein [HTTPS-Proxy](https://proxynet.io/de/https-proxy) verursacht diesen Fehler also weder, noch behebt er ihn. Nur ein Proxy, der TLS absichtlich beendet, etwa ein Inspektions-Gateway in einer Firma, ist ein eigener HTTP/2-Endpunkt.

Ein zweiter Ausgang unterscheidet einen globalen Fehler von einem regionalen: Wiederholen Sie die Anfrage über einen [Datacenter-Proxy](https://proxynet.io/de/datacenter-proxy) in einem anderen Land; derselbe Fehler dort bedeutet, dass die Antwort für alle fehlerhaft ist, eine saubere Antwort deutet auf Ihr eigenes Netz oder Ihre Inspektionssoftware.

## Verwandte Fehler

| Code | Nummer | Bedeutung |
|---|---|---|
| `ERR_HTTP2_PROTOCOL_ERROR` | -337 | Eine HTTP/2-Regel wurde verletzt; die Anfrage wurde abgebrochen |
| `ERR_HTTP2_SERVER_REFUSED_STREAM` | -351 | Der Server lehnte den Stream ab, bevor er ihn verarbeitete; Chrome wiederholt eventuell |
| `ERR_HTTP_1_1_REQUIRED` | -365 | Der Server verlangte HTTP/1.1; Chrome sendet die Anfrage darüber erneut |
| `ERR_QUIC_PROTOCOL_ERROR` | -356 | Die HTTP/3-Verbindung über QUIC ist abgebrochen |

Sehen Sie stattdessen `ERR_SSL_PROTOCOL_ERROR`, wurde HTTP/2 nie erreicht; [err_ssl_protocol_error in Chrome und Edge beheben](/de/blog/err-ssl-protocol-error) behandelt diesen Fall.

## Wo Ihnen der Fehler begegnen kann

- Web-Anwendungen hinter einem CDN oder Load Balancer, bei denen eine API-Antwort einen von Hand hinzugefügten Header trägt.
- ASP.NET- und andere auf IIS gehostete Apps kurz nach dem Einschalten von HTTPS, da HTTP/2 auf IIS nur über TLS existiert.
- Seiten von Videodiensten, auf denen die Anfragen des Players scheitern, während der Rest der Seite lädt.

## Häufige Fehler

- **Immer wieder den gesamten Browser-Cache leeren.** Nur die Cookies der betroffenen Website zählen, und nur, wenn zu große Header die Ursache sind.
- **Die Systemuhr korrigieren.** Ein falsches Datum erzeugt Zertifikatswarnungen, nicht diesen Code.
- **QUIC unter chrome://flags ausschalten.** Dieser Schalter betrifft HTTP/3; für HTTP/2 gibt es in Chrome keinen Schalter.
- **IP-Adressen in einem Scraper rotieren.** Die Antwort ist für jede Adresse fehlerhaft.

## Entscheidungshilfe

| Ihre Lage | Was tun |
|---|---|
| Eine Website scheitert auf jedem Gerät und in jedem Netz | Die Website oder ihr CDN; den Betreiber informieren und die fehlerhafte URL schicken |
| Viele Websites scheitern auf einem Computer | Erweiterungen, dann Webschutz des Virenschutzes, dann VPN- oder Filter-Apps |
| Nur ein Netz zeigt ihn | TLS-Inspektion in diesem Netz; fragen, wer es betreibt |
| Die Seite lädt halb, mit Konsolenfehlern | Der Server hat nach einer 200 einen Stream zurückgesetzt; der Betreiber muss diese Antwort prüfen |
| Ihre Website, hinter Cloudflare oder einem Load Balancer | Header und `Content-Length` des Ursprungsservers mit denen des Edge vergleichen |

## Häufige Fragen

### Wie behebe ich ERR_HTTP2_PROTOCOL_ERROR unter Android?

Aktualisieren Sie Chrome über den Play Store, wechseln Sie zwischen WLAN und mobilen Daten und schalten Sie jede VPN- oder Werbeblocker-App aus. Scheitert die Website auch über mobile Daten, ist die Website oder ihr CDN die Ursache.

### Warum zeigt mein Serverprotokoll 200 OK, obwohl Besucher den Fehler sehen?

Weil die Statuszeile gesendet und protokolliert wurde, bevor der Stream zurückgesetzt wurde. Die Anwendung antwortete mit 200, und dann fand der Server, ein CDN oder der Browser den Rest der Antwort fehlerhaft und brach den Stream ab.

### Tritt der Fehler bei Websites hinter Cloudflare häufiger auf?

Er ist dort häufiger sichtbar, weil der Edge von Cloudflare ein strenger HTTP/2-Endpunkt zwischen Ursprungsserver und Besucher ist. Eine Antwort, die ein Browser direkt vom Ursprungsserver vielleicht toleriert hätte, wird am Edge abgelehnt.

### Kann ich HTTP/2 in Chrome ausschalten?

Nein. Die Einstellungen von Chrome haben keinen HTTP/2-Schalter, und der QUIC-Eintrag unter `chrome://flags` betrifft HTTP/3. Testen Sie serverseitig mit `curl --http1.1` und `curl --http2`; auf der Client-Seite ist Firefox die schnellste zweite Meinung.

### Ist ERR_HTTP2_PROTOCOL_ERROR ein Zeichen, dass mein Computer gehackt wurde?

Meist nicht; die meisten Fälle gehen auf den Server der Website, ihr CDN oder Sicherheitssoftware auf Ihrem Computer zurück.

### Behebt ein VPN oder Proxy ERR_HTTP2_PROTOCOL_ERROR?

Nicht, wenn die Antwort der Website fehlerhaft ist, denn dieselben Frames erreichen Sie über jeden Weg. Ein VPN oder ein prüfender Proxy ist öfter die Ursache als die Lösung.

## Fazit

`ERR_HTTP2_PROTOCOL_ERROR` bedeutet, dass ein Frame auf der HTTP/2-Verbindung von Chrome die Regeln des Protokolls verletzt hat, meist weil die Website oder ihr CDN eine Anfrage nach einer fehlerhaften Antwort zurückgesetzt hat: ein verbotener Header, ein `Content-Length`-Wert, der nicht mehr zum komprimierten Body passte, oder zu große Header. Besucher testen ein Inkognitofenster, einen anderen Browser und ein pausiertes VPN oder Virenschutzprogramm; Betreiber vergleichen die Antwort über HTTP/1.1 und HTTP/2 und reparieren sie, statt HTTP/2 auszuschalten. Für Prüfungen von mehreren Standorten aus vergleichen Sie die Proxy-Typen auf [unserer Proxy-Seite](/de/proxy).