Un sito web può risultare completamente irraggiungibile da una determinata connessione e, contemporaneamente, funzionare senza alcun problema da altre reti.
È quello che ci è capitato durante la gestione di un sito WordPress protetto da Cloudflare.
Dal nostro collegamento il browser restituiva:
ERR_CONNECTION_TIMED_OUT
Il primo pensiero, naturalmente, è stato verificare il server. La causa, però, era altrove: un problema di rete dell’ISP impediva di raggiungere alcuni indirizzi IP di Cloudflare.
La parte interessante di questo caso non è tanto il problema specifico, quanto la procedura utilizzata per individuarlo senza intervenire inutilmente su un’infrastruttura che funzionava correttamente.
Nota: domini, indirizzi IP e altri dati infrastrutturali reali sono stati omessi o anonimizzati per ragioni di sicurezza.
1. Il problema: il sito sembra completamente down
Il sito risultava irraggiungibile dal browser e Chrome restituiva:
ERR_CONNECTION_TIMED_OUT
Un timeout è diverso da un errore HTTP come 500, 502, 503 o 504.
Nel nostro caso il browser non stava ricevendo una pagina di errore dal server: non riusciva proprio a stabilire la connessione.
Contemporaneamente abbiamo però scoperto che altri utenti, collegati da reti differenti, riuscivano ad aprire normalmente il sito.
Primo indizio importante:
il sito era davvero down oppure era irraggiungibile solamente da alcune reti?
2. Prima verifica: controllare lo stato del server
Prima di formulare altre ipotesi abbiamo controllato le condizioni generali del server:
uptime
free -h
df -h
I valori erano perfettamente nella norma:
- CPU senza carichi anomali;
- memoria disponibile;
- nessun utilizzo significativo della swap;
- spazio disco sufficiente;
- nessun riavvio o crash recente.
Il server, almeno a livello di risorse, era sano.
3. Controllare NGINX, Varnish e le porte
Il passaggio successivo è stato verificare i servizi web:
sudo systemctl status nginx --no-pager
sudo systemctl status varnish --no-pager
e le porte in ascolto:
sudo ss -lntp | grep -E ':80|:443|:6081'
Anche in questo caso tutto risultava regolare.
NGINX era attivo, Varnish era attivo e le porte previste erano correttamente in ascolto.
Questo ci permetteva già di evitare una delle reazioni più comuni in questi casi: iniziare a riavviare servizi senza aver individuato la causa del problema.
4. Verificare Varnish e il backend dall’interno
A questo punto abbiamo interrogato direttamente Varnish dal server:
curl -I --max-time 10 http://127.0.0.1:6081 \
-H 'Host: www.example.com'
Risultato:
HTTP/1.1 200 OK
Abbiamo quindi interrogato direttamente il backend web:
curl -I --max-time 10 http://127.0.0.1:8080 \
-H 'Host: www.example.com'
Anche in questo caso:
HTTP/1.1 200 OK
La catena interna:
WordPress → NGINX → Varnish
stava funzionando.
Il problema iniziava quindi ad allontanarsi sempre di più da WordPress e dal server.
5. Verificare Cloudflare dal client che presenta il problema
Il sito utilizzava Cloudflare con proxy attivo.
Dal computer collegato alla rete sulla quale il sito risultava irraggiungibile abbiamo controllato gli indirizzi restituiti dal DNS:
dig +short www.example.com A
Il dominio risolveva correttamente verso indirizzi appartenenti alla rete Cloudflare.
Abbiamo quindi provato:
curl -4 -Iv --max-time 10 https://www.example.com/
Il risultato è stato particolarmente significativo:
Trying CLOUDFLARE_IP_1:443...
Connection timed out
Trying CLOUDFLARE_IP_2:443...
Connection timed out
Non ricevevamo un errore da Cloudflare.
Non ricevevamo un errore dal server.
La connessione TCP verso quegli indirizzi Cloudflare non veniva proprio stabilita.
6. Cloudflare era down?
No.
Era importante non saltare subito alla conclusione opposta.
Abbiamo provato a raggiungere direttamente altri servizi ospitati sulla rete Cloudflare:
curl -4 -Iv --max-time 10 https://www.cloudflare.com/
La connessione funzionava regolarmente:
Connected
HTTP/2 200
Abbiamo quindi provato un secondo sito da noi gestito, anch’esso protetto da Cloudflare.
Anche quello funzionava normalmente dalla stessa connessione.
La situazione iniziava quindi a essere molto interessante:
Rete locale → alcuni IP Cloudflare → TIMEOUT
Rete locale → altri IP Cloudflare → OK
Non sembrava esserci un blocco generale verso Cloudflare.
7. Bypassare Cloudflare senza modificare il DNS
Uno dei test più utili dell’intera diagnosi è stato collegarci direttamente all’origin mantenendo però hostname e SNI corretti.
È possibile farlo con curl --resolve:
curl -Iv --max-time 10 \
--resolve www.example.com:443:ORIGIN_IP \
https://www.example.com/
Il risultato:
Connected
SSL certificate verify ok
HTTP/2 200
server: nginx
Questo test è estremamente utile perché permette di simulare:
Client → Origin
anziché:
Client → Cloudflare → Origin
senza modificare realmente il DNS pubblico.
Dalla stessa connessione che non riusciva a raggiungere il sito attraverso Cloudflare, l’origin rispondeva immediatamente.
A questo punto avevamo:
Client → Cloudflare → TIMEOUT
Client → Origin → HTTP 200
Server e applicazione potevano essere ragionevolmente esclusi.
8. La prova Proxy ON / Proxy OFF
Per ottenere un’ulteriore conferma abbiamo effettuato temporaneamente un test direttamente da Cloudflare.
Con il record impostato come:
Proxied
il dominio risolveva sugli indirizzi Cloudflare e dalla rete interessata risultava irraggiungibile.
Portando temporaneamente il record a:
DNS only
il dominio puntava direttamente all’origin e il sito tornava immediatamente raggiungibile.
Riattivando il proxy, il timeout ricompariva.
La prova A/B era quindi estremamente chiara:
Cloudflare Proxy OFF → sito raggiungibile
Cloudflare Proxy ON → timeout
Questo non significa automaticamente che Cloudflare sia il responsabile.
Significa che il problema si trova nel percorso di rete necessario per raggiungere il sito quando passa attraverso Cloudflare.
9. La prova decisiva: cercare altri domini con lo stesso problema
A questo punto abbiamo fatto un’ulteriore verifica.
Abbiamo individuato un altro sito, completamente indipendente dal primo, che dalla stessa connessione presentava esattamente lo stesso comportamento.
Controllando il DNS:
dig +short www.example-one.com A
dig +short www.example-two.com A
abbiamo scoperto che entrambi venivano serviti, in quel momento, attraverso gli stessi indirizzi della rete Cloudflare.
Entrambi risultavano irraggiungibili.
Altri siti Cloudflare che utilizzavano indirizzi differenti funzionavano invece normalmente.
Era ormai difficile attribuire il problema:
- al singolo dominio;
- a WordPress;
- al server;
- a NGINX;
- a Varnish;
- al certificato SSL;
- alla configurazione specifica del sito.
10. La diagnosi
Tutti gli elementi raccolti indicavano un problema di routing o raggiungibilità tra il nostro ISP e una parte della rete Cloudflare.
Riassumendo:
Server → OK
NGINX → OK
Varnish → OK
WordPress → OK
Certificato SSL origin → OK
Accesso diretto all'origin → OK
Cloudflare da altre reti → OK
Altri IP Cloudflare → OK
Specifici IP dalla nostra rete → TIMEOUT
Inoltre il sito risultava normalmente raggiungibile da utenti collegati attraverso altri operatori o da altre aree geografiche.
A questo punto abbiamo deciso di non modificare l’infrastruttura per aggirare il problema.
Il proxy Cloudflare poteva essere disattivato e avrebbe apparentemente “risolto” il problema, ma sarebbe stato un workaround: avremmo rinunciato alle funzionalità e alle protezioni del proxy per compensare un malfunzionamento che non apparteneva alla nostra infrastruttura.
11. La soluzione definitiva
Abbiamo quindi aperto una segnalazione tecnica con l’ISP, fornendo le informazioni raccolte durante la diagnostica.
Dopo l’intervento dell’operatore, il problema è stato risolto.
I siti sono tornati normalmente raggiungibili mantenendo Cloudflare in modalità Proxied.
Non è stato necessario modificare:
- WordPress;
- NGINX;
- Varnish;
- configurazione del server;
- certificati SSL;
- DNS;
- configurazione Cloudflare.
La diagnosi è stata quindi confermata: il problema era lato ISP.
Procedura rapida da riutilizzare
Quando un sito dietro Cloudflare restituisce ERR_CONNECTION_TIMED_OUT solamente da alcune connessioni, questa è una buona sequenza di controlli.
Controllare il server
uptime
free -h
df -h
Controllare i servizi
systemctl status nginx
systemctl status varnish
ss -lntp | grep -E ':80|:443|:6081'
Testare internamente frontend e backend
curl -I http://127.0.0.1:6081 -H 'Host: www.example.com'
curl -I http://127.0.0.1:8080 -H 'Host: www.example.com'
Controllare gli IP restituiti dal DNS
dig +short www.example.com A
Testare la connessione HTTPS dal client interessato
curl -4 -Iv --max-time 10 https://www.example.com/
Testare direttamente l’origin
curl -Iv --max-time 10 \
--resolve www.example.com:443:ORIGIN_IP \
https://www.example.com/
Confrontare altri domini Cloudflare
Verificare se:
- altri domini sugli stessi indirizzi presentano il problema;
- domini Cloudflare su indirizzi differenti funzionano;
- il sito è raggiungibile da altri ISP.
Eventualmente effettuare un breve test Proxy OFF
Passare temporaneamente da Proxied a DNS only può essere un ottimo test diagnostico, a condizione di sapere esattamente cosa si sta facendo e di avere verificato preventivamente che l’origin sia correttamente configurato e protetto.
Se:
DNS only → OK
Proxied → TIMEOUT
abbiamo un’indicazione importante su quale tratto del percorso approfondire.
Cosa abbiamo imparato da questo caso
Quando un sito sembra down, la domanda da porsi non dovrebbe essere immediatamente:
Cosa non funziona sul server?
La domanda più utile è:
In quale punto del percorso client → ISP → CDN/proxy → origin → applicazione si interrompe la connessione?
Nel nostro caso il sito non era realmente down.
Il server funzionava. WordPress funzionava. NGINX e Varnish funzionavano. Cloudflare funzionava.
Era l’ISP a non riuscire a raggiungere correttamente una parte della rete attraverso cui venivano serviti alcuni siti.
Seguire una diagnostica progressiva ci ha permesso non solo di individuare il vero responsabile, ma soprattutto di evitare modifiche inutili a sistemi che stavano già funzionando correttamente.
