Come verificare se un sito è davvero giù

Perché questa verifica serve davvero

Quando un sito non si apre, la prima reazione è spesso quella sbagliata: cambiare qualcosa subito. In realtà, in molti casi il problema non è il sito ma il dispositivo, la rete, il DNS, la cache del browser oppure un blocco temporaneo del server o del provider. La differenza è importante, perché una diagnosi corretta fa risparmiare tempo, evita interventi inutili e riduce il rischio di peggiorare la situazione.

La domanda giusta non è solo “il sito è giù?”, ma “dove si interrompe la catena di accesso?”. La catena è semplice: nome di dominio, risoluzione DNS, connessione alla porta, risposta del web server, eventuale applicazione, contenuti e cache. Se si rompe uno di questi passaggi, il risultato finale può sembrare identico: pagina bianca, timeout, errore 5xx o connessione rifiutata.

In questa guida trovi un metodo pratico, ordinato e verificabile per capire se un sito è davvero indisponibile oppure se il guasto è locale. L’obiettivo è arrivare alla causa probabile con pochi controlli, senza strumenti inutili e senza falsi allarmi.

Prima regola: non fidarti del primo sintomo

Un errore nel browser non identifica da solo il problema. Un timeout può dipendere da un server saturo, da un DNS lento, da una rete instabile o da un firewall. Un errore 404 può essere una pagina mancante, ma anche un rewrite rotto. Un 500 può essere il PHP, il database, un plugin o un proxy. Il sintomo è solo il punto di partenza.

La verifica corretta si fa per esclusione: prima controlli il tuo lato, poi verifichi la raggiungibilità esterna, poi osservi la risposta del server, infine passi ai log e ai servizi interni. Questo approccio è molto più affidabile del “provo a ricaricare finché funziona”.

Controlli rapidi dal lato utente

Parti sempre dai controlli più semplici. Sono i più veloci e spesso bastano a chiarire tutto.

1. Apri il sito in finestra privata o in un altro browser. Se si apre, il problema è spesso cache, estensioni o cookie corrotti.
2. Prova da un’altra rete. Se il sito funziona su hotspot mobile ma non sulla tua linea, il problema è locale o del provider.
3. Disattiva temporaneamente VPN e proxy. Alcuni siti bloccano IP condivisi o geolocalizzati male.
4. Verifica data e ora del dispositivo. Un orario errato può rompere HTTPS e far sembrare il sito irraggiungibile.

Se uno di questi test cambia il risultato, non sei davanti a un guasto del sito ma a un problema del tuo ambiente di accesso.

Capire se il dominio risolve correttamente

Il passaggio successivo è verificare il DNS. Se il dominio non risolve, il browser non sa dove andare. Se risolve male, potresti finire su un server vecchio, un IP errato o un record parziale.

Dal terminale puoi controllare in modo semplice:

nslookup esempio.it

oppure:

dig esempio.it +short

Esito atteso: compare un indirizzo IP coerente con il server reale. Se non esce nulla, se esce un IP vecchio o se la risposta è lenta e incoerente, il problema può essere nel DNS autoritativo, nella propagazione o nella cache locale.

Se il dominio usa www e versione senza www, controlla entrambi. Non è raro che uno dei due punti al server corretto e l’altro no. Lo stesso vale per i record A, AAAA e i redirect.

Distinguere DNS rotto da server irraggiungibile

Se il nome risolve, devi capire se il server risponde davvero. Qui la differenza tra DNS e servizio è decisiva. Un dominio può essere perfettamente configurato ma puntare a un server spento, a un firewall chiuso o a un web server fermo.

Un test utile è questo:

ping esempio.it

Attenzione: il ping non prova che il sito web funzioni, perché molti server bloccano ICMP. Se non risponde, non è automaticamente un guasto. Serve solo come indizio. Più utile è verificare la porta web:

curl -I https://esempio.it

Esito atteso: un codice HTTP, anche solo 200, 301, 302 o 403. Se ottieni timeout, connection refused o nessuna risposta, il problema è più vicino al server o alla rete che al contenuto del sito.

Se il sito risponde in HTTP ma non in HTTPS, spesso il guasto riguarda certificato, virtual host SSL o redirect. Se risponde in HTTPS ma non in HTTP, può essere una scelta voluta oppure una configurazione incompleta.

Leggere i sintomi più comuni

Ogni errore racconta qualcosa. Non serve memorizzare tutto, basta saperlo leggere nel modo giusto.

• Timeout: il server non risponde in tempo. Possibili cause: sovraccarico, rete lenta, firewall, proxy, backend bloccato.
• Connessione rifiutata: la porta non ascolta o viene chiusa. Possibili cause: web server fermo, servizio crashato, regola firewall.
• Errore 500: il server risponde ma l’applicazione fallisce. Possibili cause: PHP, database, plugin, permessi, limite memoria.
• Errore 502/504: spesso c’è un proxy o un bilanciatore davanti al backend. Possibili cause: PHP-FPM, upstream lento, processo bloccato.
• Pagina bianca: l’applicazione si rompe senza mostrare l’errore. Spesso è PHP, memoria esaurita o un plugin difettoso.

Questa lettura non sostituisce i log, ma aiuta a decidere dove guardare per primo.

Verificare lo stato del server senza toccare nulla

Se hai accesso al server, il controllo successivo è osservare i servizi base: web server, PHP, database e spazio disco. Un sito può sembrare giù anche solo perché il disco è pieno o perché il database è fermo.

Su Linux, una sequenza essenziale è questa:

systemctl status nginx

systemctl status apache2

systemctl status php-fpm

systemctl status mariadb

Non serve eseguirli tutti se sai già quale stack usi. L’esito atteso è active (running). Se trovi failed o inactive, hai già un indizio forte.

Controlla anche lo spazio disponibile:

df -h

Esito atteso: partizioni principali con spazio libero sufficiente. Un disco al 100% può bloccare log, cache, sessioni e database, generando errori molto diversi tra loro ma con la stessa radice.

Guardare i log giusti prima di fare ipotesi

I log sono più utili delle supposizioni. Se il sito è giù, i primi file da osservare dipendono dal tipo di stack, ma in genere i punti chiave sono questi: log del web server, log PHP, log dell’applicazione e log del database.

Per un ambiente Linux classico puoi partire con:

tail -n 50 /var/log/nginx/error.log

tail -n 50 /var/log/apache2/error.log

journalctl -u php-fpm -n 50 --no-pager

Se usi WordPress, controlla anche errori di plugin o temi. Se usi un pannello come cPanel, Plesk o FastPanel, spesso trovi una sezione log già pronta, più semplice e meno invasiva del terminale.

Il punto non è leggere tutto, ma cercare ripetizioni: lo stesso errore che compare molte volte in pochi minuti è molto più utile di un singolo messaggio isolato.

Quando il problema è davvero esterno

Se da più reti, più dispositivi e più DNS il sito resta irraggiungibile, il problema è probabilmente esterno al tuo ambiente locale. A quel punto conviene verificare tre aree: DNS pubblico, provider hosting e percorso di rete.

Puoi usare un controllo esterno con un servizio di monitoraggio o con un semplice test da un server diverso. Anche un VPS economico o una macchina in una rete distinta possono bastare per capire se il sito risponde fuori dalla tua connessione.

Se il sito funziona da fuori ma non da dentro la tua rete, il sospetto si sposta su firewall, routing, DNS locale o blocco IP. Se non funziona da nessuna parte, il problema è quasi sempre lato hosting, applicazione o DNS autoritativo.

Se il sito è in produzione, stabilizza prima di cambiare tutto

Quando il guasto impatta utenti reali, la priorità non è sperimentare: è stabilizzare. Se hai un backup di configurazione, meglio ancora. Se il problema è iniziato dopo un aggiornamento, un plugin o una modifica DNS, il rollback è spesso il fix più sicuro.

Le azioni meno rischiose sono queste:

1. Ripristinare l’ultima configurazione nota buona.
2. Riavviare solo il servizio coinvolto, non l’intero server.
3. Disattivare temporaneamente il componente sospetto, ad esempio plugin, tema, regola firewall o redirect nuovo.
4. Verificare subito l’effetto con un controllo esterno e uno locale.

Se la causa non è chiara, evita modifiche multiple insieme. Ogni cambiamento deve essere misurabile, altrimenti non saprai mai cosa ha risolto o peggiorato il problema.

Metodo pratico in 5 minuti

Se vuoi una procedura veloce, usa questa sequenza:

1. Prova il sito da un altro browser e da una rete diversa.
2. Controlla la risoluzione DNS del dominio.
3. Verifica se la porta web risponde con curl -I.
4. Guarda lo stato del servizio web e del database.
5. Leggi gli ultimi errori nei log.

Se il punto di rottura emerge in uno di questi passi, hai già la diagnosi operativa. Non serve andare oltre con strumenti più complessi finché non hai esaurito i controlli semplici.

Strumenti utili ma da usare con criterio

Esistono servizi online che aiutano a capire se un sito è giù per tutti o solo per te. Sono utili come conferma, non come prova assoluta. Un servizio esterno può non vedere un problema regionale, un blocco selettivo o una cache CDN non aggiornata.

Anche i controlli da riga di comando vanno letti nel contesto giusto. Un ping negativo non significa che il sito è offline. Un 200 su una pagina leggera non garantisce che il resto dell’applicazione funzioni. Un DNS corretto non garantisce che il backend sia sano. Serve sempre la combinazione di più indizi.

Errore comune: confondere il sito con il sito “visibile solo a me”

Molti falsi allarmi nascono da un problema locale che sembra globale. Cache del browser, DNS del router, estensioni, cookie corrotti, antivirus aggressivi, proxy aziendali o filtri di rete possono bloccare un dominio in modo parziale. In questi casi il sito esiste e funziona, ma non per quel particolare ambiente.

Per questo il controllo da rete diversa è così importante: separa il problema personale dal guasto reale. Se il sito si apre da mobile e non da fibra, la diagnosi cambia completamente.

Quando coinvolgere l’hosting

Se hai verificato DNS, rete, browser e servizi base, e il problema resta, è il momento di aprire un ticket al provider o al system administrator. Per farlo in modo utile, prepara questi dati:

• orario preciso del guasto;
• dominio o sottodominio coinvolto;
• errore esatto visto dagli utenti;
• risultato dei test DNS e curl;
• eventuali cambiamenti recenti.

Con queste informazioni il supporto può saltare i controlli banali e passare subito alla parte utile. Un ticket ben scritto spesso dimezza i tempi di risoluzione.

Conclusione operativa

Capire se un sito è davvero giù non significa solo vedere un errore: significa trovare il punto esatto in cui la catena si rompe. Prima controlli il tuo lato, poi DNS, poi raggiungibilità, poi servizi e log. Questo ordine evita diagnosi sbagliate e ti porta più vicino alla causa reale in pochi minuti.

Il principio è semplice: non correggere ciò che non hai ancora misurato. È il modo più rapido per distinguere un problema locale da un guasto vero, e il più affidabile per decidere se intervenire subito oppure aprire un ticket con dati utili.

Se il sito non risponde, non chiederti subito “cosa devo cambiare?”. Chiediti prima “in quale punto della catena si è rotto il passaggio?”.

Con questa abitudine, ogni verifica diventa più veloce, più pulita e molto meno rischiosa.