ERR_CONNECTION_RESET: cause e soluzioni
ERR_CONNECTION_RESET significa che una connessione che funzionava è stata interrotta bruscamente a metà, di solito da un firewall, un software di sicurezza, o un crash lato server, piuttosto che da una delle due parti che la chiude normalmente.
Cosa significa ERR_CONNECTION_RESET
A differenza di ERR_CONNECTION_REFUSED, che scatta prima che si muova qualunque dato, un reset avviene dopo che l'handshake TCP è riuscito e la connessione stava già scambiando dati. Qualcosa lungo il percorso, o uno degli endpoint stesso, invia poi un pacchetto RST che termina la connessione senza la solita sequenza di chiusura. Il browser non ha modo di sapere se l'RST è arrivato dal server, da un middlebox come un firewall o un load balancer, o dallo stack di rete del client stesso, quindi il messaggio resta generico indipendentemente dalla causa.
Una chiusura TCP normale prevede uno scambio FIN in entrambe le direzioni, che permette a ciascuna parte di finire di inviare ciò che aveva già in coda. Un RST salta tutto questo del tutto: qualunque cosa fosse in transito viene scartata, e qualunque dato che il server avesse già iniziato a scrivere ma il client non avesse ancora ricevuto va perso. Ecco perché un reset a metà di un download di file grande o di una risposta API lunga spesso lascia un risultato visibilmente troncato invece di un fallimento pulito prima che si carichi qualcosa.
Come appare l'errore
Chrome mostra "This site can't be reached ... ERR_CONNECTION_RESET" a metà del caricamento, a volte dopo che parte della pagina si è già visualizzata. curl lo riporta direttamente:
curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer
Sul lato server, nginx registra una riga corrispondente per lo stesso evento: readv() failed (104: Connection reset by peer) while reading upstream. Un reset che avviene costantemente allo stesso conteggio di byte o allo stesso numero di secondi dentro una richiesta indica un limite di dimensione o di timeout da qualche parte sul percorso, piuttosto che un problema di rete casuale.
Cosa causa ERR_CONNECTION_RESET
- Un firewall, un IDS, o un WAF interrompe la connessione a metà flusso. Una regola che corrisponde a metà di una richiesta o risposta, piuttosto che al momento della connessione, produce un reset invece di un rifiuto immediato.
- Problemi di MTU o frammentazione dei pacchetti. Un percorso con un MTU più piccolo di quanto entrambi gli endpoint si aspettino può corrompere pacchetti grandi, e alcuni router mal configurati rispondono resettando la connessione invece di frammentare correttamente.
- Ispezione TLS da parte di software antivirus o di un proxy aziendale. Un'intercettazione che fallisce a metà di un handshake o di una risposta spesso resetta la connessione invece di fallire in modo controllato.
- Un processo worker del server va in crash a metà richiesta. Un errore applicativo, un kill per esaurimento di memoria, o un riavvio del worker durante un deploy lasciano tutti una connessione aperta senza nulla che possa più rispondervi.
- Un mismatch del timeout keep-alive tra client e server o proxy. Se il timeout di inattività di un load balancer è più breve di quello del backend, può resettare una connessione che il backend considera ancora attiva.
- Interferenza dell'ISP o traffic shaping. Alcuni ISP resettano connessioni di lunga durata o ad alta banda, in particolare per streaming o download grandi, come forma di gestione del traffico.
Come capire di chi è la colpa
Testa la stessa richiesta da una seconda rete, come i dati mobili invece del Wi-Fi dell'ufficio. Se lì funziona, un firewall locale, un antivirus, o un proxy sta intercettando la connessione. Se il reset avviene in modo identico ovunque, la causa si trova sul lato server o in una regola WAF davanti a esso. Un controllo HTTP eseguito da più postazioni contemporaneamente mostra se il reset è universale o limitato a una rete, senza che tu debba testare da un secondo dispositivo.
Come correggere ERR_CONNECTION_RESET
Se sei un visitatore
- Riavvia il tuo router o modem. Una voce della tabella NAT bloccata o uno stato di connessione obsoleto sui router consumer è una causa comune e facile da risolvere.
- Disattiva qualunque VPN o proxy e ricarica. Se il reset si ferma, la VPN o il proxy stanno intercettando o gestendo male la connessione.
- Disattiva la scansione HTTPS nel tuo antivirus, di solito elencata sotto "protezione web" o "scansione SSL/TLS," e riprova. Se questo lo risolve, aggiungi il sito a una lista di esclusione invece di lasciare la scansione disattivata.
- Controlla un'impostazione MTU insolitamente bassa se sei su una VPN o un hotspot mobile; abbassarla leggermente sul client può risolvere reset legati alla frammentazione.
Se gestisci il sito
- Controlla i log dell'applicazione e di sistema per un crash o un kill per esaurimento di memoria intorno al momento del reset. Un processo worker che muore a metà richiesta è una delle cause più comuni.
- Rivedi le regole WAF e IDS e i loro log. Una regola che resetta connessioni corrispondenti a certi payload o frequenze può sembrare identica a un fallimento di rete casuale finché non controlli specificamente il log di sicurezza.
- Allinea i timeout keep-alive lungo tutto lo stack. Su nginx, imposta il timeout rivolto al proxy in modo che corrisponda o superi quello del backend stesso:
Un mismatch qui è una causa frequente di reset sotto carico, quando il frontend chiude una connessione che il backend si aspetta ancora di usare.keepalive_timeout 65s; proxy_read_timeout 65s; - Osserva i messaggi di reset upstream nel log del reverse proxy, come
upstream prematurely closed connection while reading response header from upstream, che indica direttamente l'applicazione backend piuttosto che la rete. - Ricarica dopo qualunque cambiamento invece di modificare sul posto:
nginx -t && systemctl reload nginxconvalida la configurazione prima che entri in vigore.
Come prevenire ERR_CONNECTION_RESET
Un reset che compare solo sotto carico, o solo per risposte grandi, raramente si manifesta durante un rapido controllo manuale, dato che dipende da soglie di tempistica o dimensione che una singola richiesta potrebbe non raggiungere. Il monitoraggio HTTP continuo che controlla il codice di stato e il contenuto del corpo secondo una pianificazione da oltre 300 punti di controllo in 158 città coglie un pattern di reset intermittente che un test occasionale mancherebbe, e avvisa via email, SMS, chiamata vocale, Slack, Telegram e altro non appena inizia.
Errori correlati
- ERR_CONNECTION_REFUSED avviene quando la connessione non viene mai stabilita fin dall'inizio.
- ERR_CONNECTION_TIMED_OUT avviene quando nulla risponde affatto al tentativo di connessione.
- This site can't be reached copre l'intero insieme di errori di connessione che Chrome raggruppa sotto un unico titolo.
Domande frequenti
ERR_CONNECTION_RESET significa che sono stato hackerato?
No. Quasi sempre indica un dispositivo di rete, una regola firewall, un'intercettazione antivirus, o un crash lato server, non un attacco al tuo dispositivo.
Perché questo succede solo con download di file grandi?
I trasferimenti grandi hanno più probabilità di incontrare un mismatch MTU, un timeout del proxy, o un limite di dimensione configurato su un firewall o un load balancer, tutte cose che possono terminare una connessione a metà flusso che una piccola richiesta finirebbe prima di innescare.
Il mio stesso antivirus può causare questo?
Sì. Le funzioni di scansione HTTPS che intercettano e ricifrano il traffico TLS a volte falliscono su siti specifici o risposte grandi e resettano la connessione invece di lasciarla passare.
Un reset è peggio di un timeout?
Non intrinsecamente. Un reset significa che qualcosa ha attivamente terminato la connessione, il che è spesso più facile da diagnosticare di un timeout, dove non succede nulla e non puoi dire se il pacchetto sia mai arrivato.
Perché il reset avviene sempre nello stesso punto?
Un conteggio di byte o un tempo trascorso costanti prima del reset di solito indicano un limite fisso, come un timeout del proxy, una dimensione massima della risposta, o un'impostazione keep-alive, piuttosto che un guasto casuale.
Un operatore mobile può resettare le mie connessioni?
Alcuni operatori resettano davvero connessioni di lunga durata come parte della gestione della rete, in particolare su celle congestionate o per trasferimenti ad alta banda come lo streaming video. Se la stessa richiesta funziona in modo affidabile su Wi-Fi ma va in reset sui dati mobili, un'interferenza a livello di operatore è una spiegazione ragionevole.