ERR_HTTP2_PROTOCOL_ERROR: oorzaken en oplossingen

Wat ERR_HTTP2_PROTOCOL_ERROR betekent

HTTP/2 verstuurt verzoeken en antwoorden als binaire frames over één verbinding, met strikte regels voor framegrootte, headercodering (HPACK), en streamstatus. Een server, proxy, of CDN die een misvormd frame, een te grote header, of een frame voor een al gesloten stream verstuurt, schendt die regels, en de client breekt de verbinding af in plaats van te gokken wat er bedoeld was. Omdat de storing kan ontstaan bij de app-server, een tussenliggende proxy, een CDN-edge, of de eigen netwerkstack van de browser, dekt deze fout een breder bereik aan hoofdoorzaken dan de meeste andere op deze lijst.

Hoe de fout verschijnt

Chrome en Edge tonen "This page isn't working - ERR_HTTP2_PROTOCOL_ERROR", soms alleen bij sommige paginaladingen en niet bij andere, wat een aanwijzing is dat de storing onregelmatig is in plaats van een vaste verkeerde configuratie. Firefox toont meestal een generieke verbindingsfout zonder het protocol te noemen.

curl kan HTTP/2 afdwingen en precies tonen bij welk frame de verbinding mislukte:

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)

Dit vergelijken met een HTTP/1.1-verzoek naar dezelfde URL isoleert of het probleem protocolspecifiek is:

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

Slaagt het HTTP/1.1-verzoek en faalt het HTTP/2-verzoek, dan zit de storing in hoe iets in de keten HTTP/2 implementeert, niet in de applicatie zelf.

Wat ERR_HTTP2_PROTOCOL_ERROR veroorzaakt

• Misvormde of te grote headers van de applicatie of een proxy. Een heel lange cookie, een te grote set antwoordheaders, of een headerwaarde met tekens die HPACK niet kan coderen, schendt de framegrootte die de server of client verwacht.
• Een reverse proxy of loadbalancer met een buggy of verouderde HTTP/2-implementatie. Sommige oudere HTTP/2-stacks van nginx, Apache, of embedded apparaten hebben bekende problemen met specifieke framevolgordes onder belasting.
• Een bug op de CDN-edge of een protocolmismatch tussen edge en origin. Het traject browser-naar-edge en het traject edge-naar-origin kunnen verschillende protocollen gebruiken; een bug bij het vertalen daartussen levert soms alleen deze fout op voor bepaalde requestvormen.
• Antivirussoftware of een browserextensie die HTTPS-verkeer onderschept. Dezelfde soort software die SSL-handshakestoringen veroorzaakt kan ook een gezonde HTTP/2-stream breken als de onderscheppingslaag ervan geen correct HTTP/2 spreekt.
• Een verouderde browser met een oude HTTP/2-implementatie, of een beschadigde netwerkcache van de browser.
• Een mismatch in Content-Length achter een reverse proxy. Stuurt nginx (of een andere proxy) een antwoord door waarvan de opgegeven Content-Length niet overeenkomt met de daadwerkelijk verstuurde bytes, dan kan de HTTP/2-framing verderop in de keten halverwege breken.

Hoe u vaststelt wiens fout het is

Voer een HTTP-controle vanaf meerdere locaties uit: is de storing overal consistent, dan ligt de fout bij de HTTP/2-afhandeling van de server of CDN. Faalt hij alleen bij u, dan is het veel waarschijnlijker lokaal, een browser, een antivirus, of een netwerkapparaat tussen u en de site.

Hoe u ERR_HTTP2_PROTOCOL_ERROR oplost

Bent u de bezoeker

1. Laad de pagina opnieuw. Aangezien de oorzaak vaak één misvormd frame is in plaats van een aanhoudende verkeerde configuratie, slaagt een verse verbinding vaak alsnog.
2. Wis de browsercache via chrome://settings/clearBrowserData, aangezien een beschadigde gecachete resource dit kan veroorzaken bij het herladen.
3. Zet HTTPS/SSL-scanning van uw antivirus tijdelijk uit en probeer opnieuw; dit soort software is een veelvoorkomende en vaak over het hoofd geziene oorzaak.
4. Probeer een incognitovenster om een extensie uit te sluiten.
5. Werk de browser bij naar de nieuwste versie, aangezien oudere HTTP/2-clientimplementaties bekende bugs hadden.

Beheert u de site

1. Vergelijk HTTP/2 met HTTP/1.1 met de curl-commando's hierboven. Faalt alleen HTTP/2, dan zit het probleem in de HTTP/2-laag van een proxy of CDN, niet in de applicatie.
2. Verhoog de headergroottelimieten van nginx als er grote cookies of headers bij betrokken zijn:

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

   Herstart of herlaad nginx na de wijziging en test opnieuw.
3. Controleer op een mismatch in Content-Length tussen wat de applicatie verstuurt en wat de proxy doorstuurt; schakel proxybuffering in (proxy_buffering on;) zodat nginx het volledige antwoord kan lezen voordat het dit voor HTTP/2 in frames verpakt.
4. Werk nginx, Apache, of een loadbalancer bij naar een actuele versie; bugs in HTTP/2-frameafhandeling zijn precies het soort ding dat in puntreleases wordt opgelost.
5. Schakel HTTP/2 uit als diagnostische test, geen permanente oplossing: verwijder http2 tijdelijk uit de nginx-listen-directive. Stoppen de fouten dan, dan is bevestigd dat de storing specifiek in de HTTP/2-laag zit, en kunt u het weer inschakelen zodra de header- of bufferingsfix hierboven is doorgevoerd.
6. Controleer logs aan de CDN-kant als er een voor de origin staat; de meeste CDN's tonen HTTP/2-framingfouten in hun edge-logs met meer detail dan de browser ooit toont.

Gerelateerde fouten

• ERR_SSL_PROTOCOL_ERROR lijkt erop maar faalt eerder, tijdens de TLS-handshake, voordat er ook maar één HTTP/2-frame wordt uitgewisseld.
• 5xx-serverfoutcodes behandelen gevallen waarin de verbinding en het protocol prima werken maar de applicatie zelf faalt.

Eén detail dat het waard is om apart te noemen: een HTTP/2-protocolfout is niet hetzelfde als een HTTP/2-stream die netjes door de applicatie werd gereset, bijvoorbeeld wanneer een client een verzoek halverwege annuleert. Ontwikkelaarstools van de browser en toegangslogs van de server bestempelen soms beide als "reset," maar alleen een echte schending van de framing levert ERR_HTTP2_PROTOCOL_ERROR op in de browser; een opzettelijk geannuleerde stream stopt gewoon zonder foutpagina.

Hoe u ERR_HTTP2_PROTOCOL_ERROR voorkomt

Omdat deze fout vaak onregelmatig is, gebonden aan specifieke headergroottes of specifieke proxyversies, kan hij weken lang een deel van de bezoekers raken voordat iemand een patroon opmerkt. Een HTTP-controle die volgens schema draait vanaf meerdere locaties vangt een oplopend storingspercentage direct na een deployment, een CDN-wijziging, of een proxy-upgrade op, in plaats van te vertrouwen op verspreide gebruikersmeldingen. HostTracker waarschuwt via e-mail, sms, spraakoproep, Slack, Telegram en meer zodra een controle begint te falen.

Veelgestelde vragen

Is ERR_HTTP2_PROTOCOL_ERROR hetzelfde als een SSL-fout?

Nee. Deze fout gebeurt nadat TLS slaagt, op de framinglaag van HTTP/2. Een SSL-fout betekent dat de versleutelde verbinding zelf nooit tot stand kwam.

Waarom verschijnt de fout alleen soms, niet bij elke paginalading?

De meeste oorzaken hier worden getriggerd door specifieke omstandigheden, een header die over een limiet groeit, een race in een proxy onder belasting, een bepaalde gecachete resource, in plaats van een vaste verkeerde configuratie die elke keer faalt.

Schaadt het uitschakelen van HTTP/2 op mijn server de prestaties?

HTTP/2 biedt echte voordelen (multiplexing, headercompressie), dus behandel het uitschakelen ervan als een tijdelijke diagnostische stap, geen permanente oplossing. Los het onderliggende probleem met headergrootte of buffering op en schakel het weer in.

Kan een CDN dit veroorzaken zelfs als mijn origin-server prima is?

Ja. De CDN-edge en de origin kunnen op elk deel van de verbinding een ander protocol gebruiken, en een bug of verkeerde configuratie in hoe de CDN daartussen vertaalt kan deze fout veroorzaken los van de eigen gezondheid van de origin.

Gebeurt dit ook op HTTP/1.1-sites?

Nee, ERR_HTTP2_PROTOCOL_ERROR is specifiek voor verbindingen die HTTP/2 onderhandelden. Een site die alleen HTTP/1.1 serveert kan deze specifieke fout niet opleveren, al kan die wel zijn eigen verbindingsproblemen hebben.