ERR_CONNECTION_TIMED_OUT: il server non risponde in tempo

Cosa significa l’errore

Il browser ha risolto il nome, ha inviato la richiesta di connessione alla porta 443 (o 80) e ha aspettato. Non è arrivato nulla: né una risposta, né un rifiuto. Dopo un po’ Chrome si arrende e mostra ERR_CONNECTION_TIMED_OUT sotto “Impossibile raggiungere il sito”; Firefox dice “Timeout della connessione”. La differenza con ERR_CONNECTION_REFUSED conta: in una connessione rifiutata il server risponde attivamente “qui non c’è niente”; in un timeout non risponde nessuno. Rifiutata: la macchina funziona ma il server web no. Timeout: i pacchetti si perdono per strada o la macchina non riesce a rispondere.

Cause frequenti

1. Un firewall scarta i pacchetti. ufw, firewalld, iptables o il gruppo di sicurezza del provider cloud usano drop invece di reject: il pacchetto sparisce in silenzio e il browser aspetta invano. Tipico dopo un server nuovo o un cambio di regole.
2. Il server o il servizio è bloccato o saturo. La macchina risponde al ping, ma nginx, Apache o PHP-FPM hanno tutte le connessioni occupate oppure la memoria è finita. Le nuove connessioni restano in coda finché il browser non rinuncia.
3. IP sbagliato nel DNS. Dopo un trasloco del server, il record A punta ancora alla vecchia macchina, ormai spenta: il nome si risolve, ma lì non risponde nessuno.
4. La rete del visitatore. Un router che blocca la destinazione, una VPN caduta, un proxy aziendale, un filtro dei contenuti o un operatore con problemi di instradamento.
5. MTU o IPv6. Il dominio ha un record AAAA, ma il server non risponde in IPv6; oppure un tunnel riduce la dimensione massima dei pacchetti e le connessioni TLS restano a metà.

Se sei un visitatore

1. Apri il sito dal telefono senza Wi-Fi. Se così entra, il problema è nella tua rete, non nel sito.
2. Scollega la VPN e disattiva un proxy manuale che non usi.
3. Riavvia il router e svuota la cache DNS (sudo dscacheutil -flushcache su macOS, sudo resolvectl flush-caches su Linux).
4. Prova in una finestra in incognito e in un altro browser.
5. Se non risponde nemmeno da un’altra rete e da un altro dispositivo, può sistemarlo solo il proprietario.

Se è il tuo sito: verificare prima

Apri il Website down checker: se il server non risponde nemmeno dalla nostra località di verifica in Europa, il guasto non è nella tua rete. Poi, dalla riga di comando:

# a quale indirizzo punta il dominio?
dig +short example.com A
dig +short example.com AAAA

# il server risponde? (-v mostra a quale passo si ferma)
curl -v --max-time 10 -4 https://example.com/
curl -v --max-time 10 -6 https://example.com/

Se curl -4 entra e curl -6 resta appeso, il problema è IPv6. Se curl si ferma su “Trying 203.0.113.10:443…”, i pacchetti si perdono prima di arrivare al server web. Entra via SSH (se non risponde neanche quello, passa alla sezione sul provider di hosting):

# chi ascolta sulla 80 e sulla 443, e su quale indirizzo?
sudo ss -tlnp | grep -E ':80 |:443 '

# regole del firewall
sudo ufw status verbose

# carico, memoria, disco
uptime
free -h
df -h

Soluzioni sul tuo server

1. Aprire il firewall

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Su un server cloud controlla anche il gruppo di sicurezza del provider: blocca prima che il pacchetto arrivi alla tua macchina e dall’interno non si vede. Se usi fail2ban, verifica che non abbia bandito il tuo stesso IP.

2. Liberare un server saturo

Se uptime mostra un carico molto superiore al numero di core, o free -h una memoria esaurita, il server accetta le connessioni troppo lentamente. Cerca il processo colpevole con top e leggi il log di PHP-FPM: server reached pm.max_children significa che tutti i worker sono occupati, spesso per una query lenta o una raffica di bot. Riavvia il servizio interessato dopo aver controllato la sua configurazione:

sudo nginx -t && sudo systemctl restart nginx
sudo systemctl restart php8.4-fpm
sudo tail -n 50 /var/log/nginx/error.log

Se si ripete ogni giorno, alza i worker se la memoria lo permette, metti una cache davanti all’applicazione e blocca i bot inutili.

3. Correggere l’IP nel DNS

Confronta dig +short example.com A con hostname -I sul server. Se non coincidono, correggi il record A presso il tuo provider DNS. Se il server non ha un IPv6 pubblico, elimina il record AAAA: un AAAA senza server dietro produce esattamente questo errore per una parte dei visitatori.

4. Ascoltare su tutti gli indirizzi

In nginx il blocco server ha bisogno di listen 443 ssl; e listen [::]:443 ssl;. Se ascolta solo su 127.0.0.1, dall’esterno non risponde nessuno. Dopo la modifica: sudo nginx -t && sudo systemctl reload nginx.

Se il problema è presso il tuo provider di hosting

Su un hosting condiviso non controlli né il firewall né il carico. Se il sito non risponde dall’esterno e nemmeno SSH, invia questo messaggio:

Buongiorno, il mio sito example.com non risponde da circa le 9:30 (UTC): i browser mostrano ERR_CONNECTION_TIMED_OUT e la porta 443 non risponde. Il dominio si risolve a 203.0.113.10, l’IP del mio hosting. Da parte mia non ho modificato nulla. Il server di quella macchina è saturo o fermo, oppure c’è un blocco nel firewall?

Perché non succeda di nuovo

Un server che tace è il caso in cui il proprietario se ne accorge più tardi: nessuna pagina di errore, solo silenzio. Un controllo dall’esterno lo nota al primo tentativo fallito. Sul tuo server, il monitoraggio server con agente server ti avvisa prima, quando il carico sale, la memoria si esaurisce o il disco si riempie.

Down? Interveniamo. Sul tuo server o su un hosting condiviso con accesso SSH, il Quick Fix riavvia il servizio fermo se il suo test di configurazione riesce, a prezzo fisso, 24 ore su 24, anche nel fine settimana; il Deep Fix si occupa del firewall, del sovraccarico o del DNS, a blocchi di 15 minuti; la stima è il prezzo massimo.