«Connection timed out» e «Connection refused»: la differenza quando il sito non risponde

Chi gestisce un sito prima o poi vede comparire uno di questi due messaggi: «Connection timed out» o «Connection refused». Sembrano la stessa cosa — il sito non si apre — ma raccontano due guasti opposti, e capire quale dei due si sta vedendo riduce subito il campo delle cause possibili da dieci a due o tre.

Connection refused: qualcuno ha risposto di no

Il browser o il terminale manda un pacchetto SYN per aprire la connessione TCP. Se arriva a una macchina viva ma nessun processo è in ascolto su quella porta, il sistema operativo di destinazione risponde subito con un pacchetto RST (reset). Il client traduce quella risposta nel messaggio «connection refused». La cosa importante è che si tratta di una risposta attiva: l'indirizzo IP è corretto, la rotta funziona, l'host è raggiungibile. Il problema è circoscritto: non c'è nessun servizio che accetta connessioni su quella porta, oppure un firewall la sta rifiutando esplicitamente.

Connection timed out: nessuno ha risposto

Qui il client manda il SYN, lo ritrasmette un paio di volte, e dopo un periodo di attesa smette di aspettare: questo è esattamente il comportamento di un timeout del protocollo, il client non ha ricevuto alcuna risposta valida prima della scadenza del tempo limite. A differenza del refused, il timeout non dice nulla di certo sul server: può essere spento, può avere l'indirizzo sbagliato, oppure — il caso più frequente — qualcosa lungo il percorso sta scartando i pacchetti in silenzio: un firewall, un security group del cloud, una NAT configurata male.

Perché uno è immediato e l'altro fa aspendere

La differenza di comportamento nasce dalla regola del firewall che intercetta il traffico. Una regola REJECT scarta il pacchetto ma invia indietro un errore (RST o ICMP), mentre una regola DROP scarta il pacchetto senza rispondere nulla, lasciando il client in attesa fino al timeout. Una misurazione pubblicata su una guida tecnica a iptables mostra la differenza concreta sui tempi:

Regola firewall	Errore riportato	Tempo di risposta
-j DROP	Connection timed out (ETIMEDOUT)	133,5 secondi
-j REJECT (default)	Connection refused (ECONNREFUSED)	meno di 0,001 secondi
--reject-with tcp-reset	Connection refused (ECONNREFUSED)	meno di 0,001 secondi

Questo spiega perché la maggior parte dei firewall esposti su internet usa DROP come politica di default: un refused istantaneo conferma a chi sta scansionando le porte che la macchina esiste e sta rifiutando attivamente, mentre un timeout lascia nel dubbio se dietro quell'indirizzo ci sia qualcosa o nulla.

Le cause più comuni, porta per porta

Porta / servizio	Refused significa di solito	Timed out significa di solito
22 (SSH)	sshd non è attivo, o ascolta su una porta diversa	un security group o firewall non lascia passare quell'IP
80 / 443 (HTTP/HTTPS)	il server web è fermo	un firewall non fa arrivare il traffico
3306 / 5432 (MySQL, PostgreSQL)	il database ascolta solo su localhost	il database non è mai stato esposto, o c'è un firewall di mezzo
25 (SMTP)	nessun server di posta in ascolto	spesso l'ISP blocca la porta in uscita

I primi controlli, anche senza essere sistemisti

Prima di scrivere al supporto del provider, due verifiche si fanno con strumenti già presenti su qualsiasi computer:

• Ping verso il dominio o l'IP: se non risponde affatto, il problema è a monte (DNS, routing), non necessariamente sul server.
• Telnet o nc sulla porta specifica (es. telnet dominio.it 443 o nc -zv dominio.it 443): se la connessione viene rifiutata all'istante è un refused, se resta appesa per decine di secondi è un timeout. Questo test da solo indica già se cercare "servizio spento" o "firewall/rete".
• Pannello di controllo del provider: molti hosting e VPS mostrano lo stato del firewall cloud (security group) separatamente dal firewall del sistema operativo; un blocco può essere a uno dei due livelli, non necessariamente a entrambi.

Se il test mostra un refused, la prima cosa da controllare è se il servizio è davvero attivo (es. systemctl status nginx o il pannello di hosting che mostra lo stato del web server). Se mostra un timeout, la ricerca va spostata sulle regole del firewall, sul security group del provider cloud o su un'eventuale lista IP bloccati.