ERR_HTTP2_PROTOCOL_ERROR: cause e soluzioni

2026-09-19

ERR_HTTP2_PROTOCOL_ERROR significa che il browser e il server hanno negoziato HTTP/2 con successo, ma un frame o uno stream specifico nello scambio ha violato le regole del protocollo e la connessione è stata resettata. È diverso da un fallimento TLS: la connessione cifrata ha funzionato, e il problema si trova un livello più su, in come si è formato lo stream HTTP/2 stesso.

Cosa significa ERR_HTTP2_PROTOCOL_ERROR

HTTP/2 invia richieste e risposte come frame binari su un'unica connessione, con regole rigide su dimensione dei frame, codifica degli header (HPACK), e stato dello stream. Un server, un proxy, o una CDN che invia un frame malformato, un header sovradimensionato, o un frame per uno stream già chiuso viola quelle regole, e il client interrompe la connessione invece di indovinare cosa si intendesse. Poiché il fallimento può avere origine nel server applicativo, in un proxy intermedio, in un edge CDN, o nello stesso stack di rete del browser, questo errore copre una gamma più ampia di cause radice rispetto alla maggior parte degli altri in questa lista.

Come appare l'errore

Chrome ed Edge mostrano "This page isn't working - ERR_HTTP2_PROTOCOL_ERROR", a volte solo su alcuni caricamenti della pagina e non altri, il che è un indizio che il difetto è intermittente piuttosto che una configurazione errata fissa. Firefox di solito mostra un errore di connessione generico invece di nominare il protocollo.

curl può forzare HTTP/2 e mostrare esattamente su quale frame la connessione è fallita:

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)

Confrontare questo con una richiesta HTTP/1.1 verso lo stesso URL isola se il problema è specifico al protocollo:

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

Se la richiesta HTTP/1.1 riesce e quella HTTP/2 fallisce, il difetto sta in come qualcosa nella catena implementa HTTP/2, non nell'applicazione stessa.

Cosa causa ERR_HTTP2_PROTOCOL_ERROR

Header malformati o sovradimensionati dall'applicazione o da un proxy. Un cookie molto lungo, un insieme sovradimensionato di header di risposta, o un valore di header contenente caratteri che HPACK non può codificare violeranno la dimensione di frame che il server o il client si aspettano.
Un reverse proxy o un load balancer con un'implementazione HTTP/2 bacata o obsoleta. Alcuni stack HTTP/2 più vecchi di nginx, Apache, o dispositivi embedded hanno problemi noti con specifiche sequenze di frame sotto carico.
Un bug dell'edge CDN o un mismatch di protocollo tra edge e origine. Il tratto browser-edge e il tratto edge-origine possono usare protocolli diversi; un bug nella traduzione tra i due occasionalmente produce questo errore solo per certe forme di richiesta.
Software antivirus o un'estensione del browser che intercetta il traffico HTTPS. La stessa classe di software che causa fallimenti dell'handshake SSL può anche rompere uno stream HTTP/2 sano se il suo livello di intercettazione non parla correttamente HTTP/2.
Un browser obsoleto con una vecchia implementazione HTTP/2, o una cache di rete del browser corrotta.
Un mismatch di Content-Length dietro un reverse proxy. Se nginx (o un altro proxy) inoltra una risposta il cui Content-Length dichiarato non corrisponde ai byte effettivamente inviati, il framing HTTP/2 a valle può rompersi a metà.

Come capire di chi è la colpa

Esegui un controllo HTTP da più postazioni: se il fallimento è coerente ovunque, la gestione HTTP/2 del server o della CDN è colpevole. Se fallisce solo per te, è molto più probabile che sia locale, un browser, un antivirus, o un dispositivo di rete tra te e il sito.

Come correggere ERR_HTTP2_PROTOCOL_ERROR

Se sei un visitatore

Ricarica la pagina. Dato che la causa è spesso un singolo frame malformato piuttosto che una configurazione errata persistente, una connessione nuova spesso riesce.
Cancella la cache del browser su chrome://settings/clearBrowserData, dato che una risorsa in cache corrotta può innescare questo al ricaricamento.
Disattiva temporaneamente la scansione HTTPS/SSL dell'antivirus e riprova; questa classe di software è una causa comune e spesso trascurata.
Prova una finestra in incognito per escludere un'estensione.
Aggiorna il browser all'ultima versione, dato che implementazioni client HTTP/2 più vecchie avevano bug noti.

Se gestisci il sito

Confronta HTTP/2 con HTTP/1.1 con i comandi curl sopra. Se fallisce solo HTTP/2, il problema è nel livello HTTP/2 di un proxy o di una CDN, non nell'applicazione.
Alza i limiti di dimensione degli header di nginx se sono coinvolti cookie o header grandi:
```
http2_max_field_size 16k;
http2_max_header_size 32k;
large_client_header_buffers 4 16k;
```
Riavvia o ricarica nginx dopo la modifica e riprova.
Controlla un mismatch di Content-Length tra ciò che l'applicazione invia e ciò che il proxy inoltra; attiva il buffering del proxy (proxy_buffering on;) così nginx può leggere la risposta completa prima di incapsularla per HTTP/2.
Aggiorna nginx, Apache, o qualunque load balancer a una versione attuale; i bug di gestione dei frame HTTP/2 sono il tipo di cosa che viene corretta nelle release minori.
Disattiva HTTP/2 come test diagnostico, non come correzione permanente: rimuovi temporaneamente http2 dalla direttiva listen di nginx. Se gli errori si fermano, il difetto è confermato essere specificamente nel livello HTTP/2, e puoi riattivarlo una volta messa in atto la correzione degli header o del buffering sopra.
Controlla i log lato CDN se ce n'è una davanti all'origine; la maggior parte delle CDN mostra gli errori di framing HTTP/2 nei propri log edge con più dettaglio di quanto il browser mostri mai.

Errori correlati

ERR_SSL_PROTOCOL_ERROR sembra simile ma fallisce prima, durante l'handshake TLS, prima ancora che venga scambiato qualunque frame HTTP/2.
I codici di errore server 5xx coprono i casi in cui la connessione e il protocollo funzionano bene ma l'applicazione stessa fallisce.

Un dettaglio che vale la pena distinguere: un errore di protocollo HTTP/2 non è la stessa cosa di uno stream HTTP/2 resettato in modo pulito dall'applicazione, per esempio quando un client annulla una richiesta a metà. Gli strumenti per sviluppatori del browser e i log di accesso del server a volte etichettano entrambi come "reset," ma solo una vera violazione del framing produce ERR_HTTP2_PROTOCOL_ERROR nel browser; uno stream annullato intenzionalmente si ferma semplicemente senza una pagina di errore.

Come prevenire ERR_HTTP2_PROTOCOL_ERROR

Poiché questo errore è spesso intermittente, legato a specifiche dimensioni di header o a specifiche versioni di proxy, può colpire una frazione dei visitatori per settimane prima che qualcuno noti un pattern. Un controllo HTTP eseguito secondo una pianificazione da più postazioni coglie un tasso di fallimento in crescita subito dopo un deploy, un cambio di CDN, o un aggiornamento del proxy, invece di affidarsi a segnalazioni sparse degli utenti. HostTracker avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro non appena un controllo inizia a fallire.

Domande frequenti

ERR_HTTP2_PROTOCOL_ERROR è la stessa cosa di un errore SSL?

No. Questo errore avviene dopo che il TLS riesce, al livello di framing HTTP/2. Un errore SSL significa che la connessione cifrata stessa non si è mai formata.

Perché l'errore compare solo a volte, non a ogni caricamento della pagina?

La maggior parte delle cause qui è innescata da condizioni specifiche, un header che cresce oltre un limite, una race in un proxy sotto carico, una particolare risorsa in cache, piuttosto che una configurazione errata fissa che fallisce ogni volta.

Disattivare HTTP/2 sul mio server danneggerà le prestazioni?

HTTP/2 offre vantaggi reali (multiplexing, compressione degli header), quindi tratta la sua disattivazione come un passo diagnostico temporaneo, non una correzione permanente. Correggi il problema sottostante di dimensione degli header o buffering e riattivalo.

Una CDN può causare questo anche se il mio server di origine sta bene?

Sì. L'edge della CDN e l'origine possono usare protocolli diversi su ciascun tratto della connessione, e un bug o una configurazione errata in come la CDN traduce tra i due può produrre questo errore indipendentemente dallo stato di salute dell'origine.

Questo succede su siti HTTP/1.1?

No, ERR_HTTP2_PROTOCOL_ERROR è specifico per connessioni che hanno negoziato HTTP/2. Un sito che serve solo HTTP/1.1 non può produrre questo particolare errore, anche se può avere propri problemi di connessione.