ERR_EMPTY_RESPONSE: cause e soluzioni

Cosa significa ERR_EMPTY_RESPONSE

Questo errore si colloca più tardi nel ciclo di vita della richiesta rispetto a una connessione rifiutata o in timeout. Il browser si connette con successo al server, e in una richiesta HTTPS di solito si completa anche l'handshake TLS, ma dopo che la richiesta è stata inviata, la connessione si chiude senza alcuna status line HTTP, nessun header, e nessun corpo affatto. Questo è diverso da una pagina di errore 500 o 502, che è comunque una risposta HTTP completa; qui, non c'è nulla da interpretare perché non è tornato nulla.

Questo rende ERR_EMPTY_RESPONSE più difficile da diagnosticare dal lato client rispetto alla maggior parte degli errori di connessione, dato che ogni livello fino alla connessione di trasporto inclusa ha funzionato correttamente. Il difetto si trova specificamente in qualunque cosa generi la risposta HTTP: il processo applicativo, il framework che gestisce la richiesta, o un proxy davanti a esso che ha chiuso il socket invece di inoltrare, o generare, una vera pagina di errore.

Come appare l'errore

Chrome mostra "This site can't be reached ... ERR_EMPTY_RESPONSE" una volta che la connessione si chiude senza dati. curl riporta la stessa condizione in termini chiari:

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

"Empty reply from server" è la dicitura esatta di curl per questa condizione, ed è il segnale più chiaro che la connessione stessa ha funzionato mentre qualunque cosa avrebbe dovuto generare una risposta non lo ha fatto.

Cosa causa ERR_EMPTY_RESPONSE

• Un processo worker è andato in crash mentre gestiva la richiesta. Un'eccezione non gestita, un kill per esaurimento di memoria, o un segmentation fault possono chiudere la connessione prima che venga scritta qualunque risposta.
• L'applicazione è andata in timeout dietro un proxy che chiude silenziosamente. Alcune configurazioni di reverse proxy chiudono la connessione del client senza inviare una pagina di errore quando il backend impiega troppo tempo, invece di restituire un vero 502 o 504.
• Sulla porta HTTPS viene servito HTTP semplice, o viceversa. Un client che parla TLS con una porta che serve HTTP semplice, o il contrario, non riceve alcuna risposta valida che il livello di protocollo del client possa interpretare, e questo spesso si manifesta come risposta vuota piuttosto che un chiaro errore di protocollo.
• Un'estensione del browser o un proxy locale interferisce con la risposta. Ad blocker, estensioni per la privacy, o un proxy aziendale che ispeziona e occasionalmente gestisce male una risposta possono ridurla a nulla.
• Un health check di un load balancer segna il backend come non in buono stato a metà richiesta, chiudendo la connessione verso quel backend prima che la risposta finisca.

Come capire di chi è la colpa

Disattiva prima le estensioni del browser o prova una finestra in incognito; un'estensione lato client è una delle cause più comuni e più facili da escludere. Se la risposta vuota persiste con le estensioni disattivate, testa da un secondo dispositivo o una seconda rete per escludere un proxy locale. Se avviene costantemente da più postazioni esterne, la causa è il server o un crash applicativo. Eseguire un controllo HTTP da più punti di controllo contemporaneamente conferma se la risposta vuota è universale o legata a un client, un'estensione, o una rete specifici.

Come correggere ERR_EMPTY_RESPONSE

Se sei un visitatore

1. Prova una finestra in incognito o privata con le estensioni disattivate per escludere un ad blocker o un'estensione per la privacy che interferisce con la risposta.
2. Disattiva qualunque proxy locale o VPN e riprova, dato che alcuni intercettano e occasionalmente gestiscono male le risposte invece di lasciarle passare.
3. Cancella la cache del browser per il sito; uno stato di connessione in cache e corrotto può occasionalmente ripresentarsi come questo errore al nuovo tentativo.
4. Aspetta e ricarica. Se la causa è un processo worker andato in crash sul server, un process supervisor tipicamente lo riavvia entro pochi secondi.

Se gestisci il sito

1. Controlla i log dell'applicazione per un crash allo stesso timestamp della richiesta fallita; un'eccezione non gestita o un kill per esaurimento di memoria è la causa più comune e di solito lascia una traccia chiara.
2. Conferma che il protocollo corretto sia associato a ciascuna porta. Verifica che la porta 443 stia effettivamente servendo TLS e la porta 80 stia servendo HTTP semplice, non il contrario, con un controllo diretto:

   curl -v https://example.com:443/
   curl -v http://example.com:80/

3. Rivedi il comportamento di timeout del reverse proxy. Su nginx, un backend che supera proxy_read_timeout dovrebbe comunque restituire un 504, quindi una risposta vuota invece di una vera pagina di errore di solito significa che qualcosa sta chiudendo la connessione più in basso nello stack.
4. Controlla i log del load balancer e dell'health check per un backend segnato come non in buono stato intorno al momento del fallimento, il che può chiudere le connessioni in corso verso quell'istanza.
5. Riavvia il worker o il servizio interessato se un crash è confermato, e monitora attentamente i log dopo il riavvio per una ripetizione dello stesso errore.

Come prevenire ERR_EMPTY_RESPONSE

Un crash del worker sotto condizioni specifiche, come un particolare payload di richiesta o un picco di memoria, può essere abbastanza intermittente da superare un test manuale pur fallendo regolarmente per i visitatori reali. Il monitoraggio HTTP continuo che controlla il codice di stato e il corpo della risposta a intervalli regolari da oltre 300 punti di controllo in 158 città coglie un pattern di risposta vuota che un singolo controllo manuale probabilmente mancherebbe, con avvisi via email, SMS, chiamata vocale, Slack, Telegram e altro.

Errori correlati

• ERR_CONNECTION_RESET termina anch'esso in anticipo una connessione funzionante, ma con un reset esplicito piuttosto che una chiusura silenziosa.
• 502 Bad Gateway è una vera risposta di errore HTTP da un proxy, a differenza della risposta vuota che descrive questo errore.
• This site can't be reached copre l'intero insieme di errori di connessione che Chrome raggruppa sotto un unico titolo.

Domande frequenti

ERR_EMPTY_RESPONSE è la stessa cosa di un errore 502?

No. Un 502 è una risposta HTTP completa con una status line, header, e di solito un corpo, inviata deliberatamente da un proxy. ERR_EMPTY_RESPONSE significa che non è stata inviata affatto alcuna risposta HTTP, solo una connessione chiusa.

Perché questo succede solo su una pagina specifica?

Una pagina che scatena questo errore costantemente, mentre altre si caricano bene, di solito indica un crash nel percorso di codice che quella specifica pagina o endpoint API usa, piuttosto che un problema generale di server o rete.

Un ad blocker può davvero causare questo errore?

Sì. Alcuni ad blocker ed estensioni per la privacy intercettano e riscrivono le risposte, e un bug o una regola aggressiva possono occasionalmente ridurre a nulla una risposta legittima invece di bloccarla in modo pulito.

ERR_EMPTY_RESPONSE significa che i miei dati sono andati persi?

Non necessariamente per una richiesta GET, ma per l'invio di un modulo o una chiamata API che modifica dati, controlla se l'azione si è effettivamente completata sul server prima di riprovare, dato che il client non può dire da una risposta vuota se la richiesta sia stata elaborata.

Perché curl dice "Empty reply from server" invece di un codice di errore?

Perché non c'è alcuna risposta HTTP da cui leggere un codice di stato. La dicitura stessa di curl descrive l'evento a livello di trasporto, una connessione chiusa senza dati, che sta un livello sotto il protocollo HTTP stesso.

Potrebbe essere la mia stessa rete a chiudere la connessione invece del server?

È meno comune di una causa lato server ma succede. Un proxy aziendale o un firewall che termina le connessioni di lunga durata dopo un periodo di inattività fisso può produrre lo stesso sintomo; testare la stessa richiesta da una rete diversa esclude questo rapidamente.