ERR_CONNECTION_REFUSED: cosa significa e come risolverlo

Cosa significa ERR_CONNECTION_REFUSED

Una connessione TCP inizia con un handshake: il client invia un pacchetto SYN, e il server risponde con SYN-ACK se un processo è associato a quella porta. Quando nessun processo è in ascolto, lo stack di rete del sistema operativo rimanda indietro un pacchetto RST invece, chiudendo subito il tentativo. Quel RST è ciò che produce ERR_CONNECTION_REFUSED in Chrome e i suoi equivalenti in altri browser. La connessione ha raggiunto la macchina di destinazione e ha ricevuto un chiaro no, il che separa questo errore da un timeout, dove nulla risponde affatto.

La risposta RST proviene dallo stack TCP del kernel, non da alcun codice applicativo, motivo per cui arriva entro pochi millisecondi invece che dopo diversi secondi di attesa. Questo significa anche che la macchina stessa è accesa e risponde al traffico di rete; semplicemente non ha nulla associato alla porta specifica che la richiesta ha preso di mira. Questa distinzione conta quando si decide dove guardare per primo: una connessione rifiutata indica la porta e il processo dietro di essa, non l'alimentazione del server o il suo collegamento di rete.

Come appare l'errore

Chrome mostra una semplice pagina "This site can't be reached ... ERR_CONNECTION_REFUSED" senza ulteriori dettagli. Firefox riporta "Unable to connect" e nomina l'host e la porta che ha provato. La riga di comando dà un quadro più esatto:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused

Il messaggio nomina la porta esatta che curl ha provato e riporta il rifiuto entro un paio di millisecondi, abbastanza veloce da escludere un timeout. telnet host port o nc -zv host port restituiscono la stessa riga "Connection refused".

Cosa causa ERR_CONNECTION_REFUSED

• Nulla è in ascolto su quella porta. Il web server, l'applicazione, o il proxy che dovrebbero essere associati alla porta non sono in esecuzione.
• Il servizio si è fermato o è andato in crash. Un processo che è terminato, è stato ucciso per uso eccessivo di memoria, o è stato fermato per manutenzione lascia la porta libera.
• Una regola firewall rifiuta la connessione del tutto. Una regola REJECT rimanda indietro lo stesso RST che darebbe una porta chiusa, quindi dall'esterno sembra identico al fatto che non ci sia nulla lì.
• La porta sbagliata è nell'URL. Un errore di battitura, un vecchio segnalibro da prima di un cambio di porta, o un servizio che si è spostato su una porta diversa producono tutti questo errore contro la vecchia porta.
• Un server di sviluppo locale non è in esecuzione. localhost:3000 rifiutato quasi sempre significa che il server di sviluppo è stato fermato o non è mai stato avviato in questa sessione di terminale.
• Un proxy o una VPN sono mal configurati. Un proxy puntato a un backend che è giù, o un client VPN che riscrive le richieste verso una porta che nulla serve, rifiuta la connessione per conto proprio.
• Il mapping di porta di un container non corrisponde all'applicazione al suo interno. Un servizio Docker o Kubernetes la cui porta pubblicata differisce dalla porta a cui l'applicazione effettivamente si associa produce questo errore anche se il processo stesso è in esecuzione e in buono stato.

Come capire di chi è la colpa

Se il sito si carica per altre persone in questo momento, o si è caricato per te un minuto fa, il problema è più probabilmente locale: una VPN, un'impostazione proxy, o una regola firewall sulla tua stessa macchina o rete. Se fallisce allo stesso modo da un telefono con dati mobili, il lato server sta rifiutando le connessioni per tutti. Eseguire un controllo HTTP o di porta da più postazioni contemporaneamente risolve la questione in una sola richiesta; se i punti di controllo in più paesi riportano tutti la connessione rifiutata, la causa è il server o il suo firewall, non la tua rete.

Come correggere ERR_CONNECTION_REFUSED

Se sei un visitatore

1. Conferma l'URL e la porta. Controlla un errore di battitura, un vecchio segnalibro, o un link che punta ancora a una porta dismessa.
2. Disattiva la tua VPN o il tuo proxy e ricarica. Se il sito si carica dopo, la configurazione della VPN o del proxy è la causa; controlla le sue impostazioni o contatta chi lo gestisce.
3. Prova una rete diversa, come i dati mobili invece del Wi-Fi, per escludere una regola firewall o del router locale.
4. Aspetta e riprova. Se chi gestisce il sito sta effettuando un deploy o riavviando un servizio, la porta potrebbe essere libera solo per pochi secondi.

Se gestisci il sito

1. Conferma che il processo sia in esecuzione e associato alla porta attesa:

   ss -ltnp | grep :443
   netstat -tlnp | grep :443

   Un risultato vuoto significa che nulla è in ascolto; avvia il servizio o correggi la sua porta configurata.
2. Controlla lo stato e i log del servizio:

   systemctl status nginx
   journalctl -u nginx -n 50

   Un'unit andata in crash o fallita compare qui, spesso con il motivo per cui è terminata.
3. Controlla che il firewall non abbia una regola REJECT sulla porta:

   iptables -L -n | grep REJECT
   ufw status verbose

   Una regola REJECT sembra identica a una porta chiusa vista dall'esterno, quindi questo passaggio è facile da perdere.
4. Conferma che il servizio ascolti sull'interfaccia giusta. Un server associato a 127.0.0.1 invece di 0.0.0.0 rifiuta ogni connessione che arriva da fuori la macchina, anche se funziona correttamente da una shell locale.
5. Riavvia il servizio una volta corretta la configurazione, e conferma che la porta sia di nuovo associata con lo stesso comando ss prima di considerare il problema risolto.

Come prevenire ERR_CONNECTION_REFUSED

Un servizio andato in crash o una regola firewall accidentale di solito compaiono per prima cosa come connessioni rifiutate piuttosto che come un avviso dal server stesso, dato che un processo che non è in esecuzione non può segnalare il proprio fallimento. Il monitoraggio di porta regolare coglie questo entro pochi minuti connettendosi da fuori la rete nello stesso modo in cui lo farebbe un visitatore, e invia un avviso via email, SMS, chiamata vocale, Slack, Telegram e altri canali nel momento in cui un controllo fallisce.

Errori correlati

• ERR_CONNECTION_TIMED_OUT avviene quando nulla risponde affatto al tentativo di connessione, invece di rifiutarlo attivamente.
• ERR_CONNECTION_RESET avviene quando una connessione è stata accettata e poi interrotta a metà.
• 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_REFUSED è la stessa cosa di un firewall che mi blocca?

Può essere. Una regola firewall REJECT produce la stessa risposta RST di una porta chiusa, quindi i due casi appaiono identici dal browser. Una regola DROP si comporta diversamente e produce invece un timeout.

Perché questo succede solo su localhost?

Quasi sempre perché il server di sviluppo locale non è in esecuzione in quel terminale, è stato fermato, o è andato in crash all'avvio a causa di un errore di codice o configurazione. Controlla il terminale dove di solito lo avvii per un messaggio di errore.

Una VPN può causare ERR_CONNECTION_REFUSED?

Sì. Una VPN che instrada il traffico attraverso un proxy o un gateway può rifiutare le connessioni per conto del gateway se il suo backend è giù, anche se il server di destinazione reale è in buono stato.

ERR_CONNECTION_REFUSED significa che il sito web è giù per tutti?

Non necessariamente. Testa da una seconda rete o esegui un controllo da più postazioni prima di concludere questo. Una singola regola firewall mal configurata o una VPN locale possono produrre lo stesso errore mentre il sito funziona bene per tutti gli altri.

Qual è la differenza tra rifiutato e resettato?

Rifiutato significa che il tentativo di connessione non si è mai completato; la destinazione lo ha respinto immediatamente. Resettato significa che la connessione è stata stabilita e funzionava, poi è stata interrotta a metà, di solito da qualcosa più avanti nel percorso.

Come scopro quale processo dovrebbe essere in ascolto?

Controlla i log di avvio dell'applicazione stessa e la sua configurazione per la porta a cui si aspetta di associarsi. Se il processo è in esecuzione ma associato a una porta diversa da quella che l'URL usa, aggiorna l'URL o la configurazione in modo che i due corrispondano, poi conferma con ss -ltnp che la porta sia ora associata come previsto.