Hosting: controlli rapidi quando il sito non apre dal browser

Perché partire da controlli rapidi

Quando un sito non apre, il rischio è perdere tempo su ipotesi sbagliate. In hosting il guasto può essere molto diverso a seconda del sintomo: pagina bianca, timeout, errore 500, 502/504, certificato TLS, DNS errato, firewall, PHP in crash, database non raggiungibile o cache corrotta.

La strategia più efficace è sempre la stessa: stabilizzare, verificare il punto di rottura, applicare il fix minimo e poi controllare che il problema non si ripresenti. Questo approccio riduce il rischio di peggiorare la situazione e aiuta a capire se il difetto è nel sito, nel server o nella rete.

Di seguito trovi una sequenza pratica, pensata per ambienti hosting comuni come cPanel, Plesk, FastPanel, VPS Linux e installazioni WordPress o CMS simili. Se il problema è in produzione, esegui i passaggi nell’ordine indicato.

1. Identifica il sintomo esatto

Prima di toccare qualsiasi configurazione, chiarisci cosa vede davvero l’utente. Non è la stessa cosa se il browser mostra un timeout, un errore DNS o una pagina bianca.

• Timeout: il sito prova a caricare ma resta in attesa troppo a lungo.
• Errore 5xx: il problema è quasi sempre lato server o applicazione.
• Pagina bianca: spesso PHP, plugin, tema o memory limit.
• Connessione rifiutata: servizio web fermo, porta chiusa o firewall.
• Errore DNS: dominio non risolve o punta all’IP sbagliato.
• Errore certificato: il sito risponde, ma HTTPS è rotto o non valido.

Se possibile prova da più punti:

• browser diverso;
• rete diversa, ad esempio hotspot del telefono;
• modalità anonima, per escludere cache locale e cookie;
• controllo da un servizio esterno di reachability, se disponibile.

Se il sintomo cambia tra rete interna e rete esterna, il problema può essere DNS, CDN, firewall o propagazione.

2. Controlla prima DNS e raggiungibilità

Molti problemi “il sito non apre” dipendono in realtà dal DNS, non dal sito. Un record errato o una propagazione incompleta può far puntare il dominio a un server sbagliato o a un IP non più valido.

Verifiche utili:

1. Confronta l’IP atteso con quello risolto dal dominio.
2. Controlla se il record A, AAAA o CNAME è corretto.
3. Verifica che il dominio usi i nameserver giusti.
4. Se il sito usa IPv6, controlla che il record AAAA sia valido; un IPv6 rotto può creare timeout su alcuni client.

Se hai accesso al terminale, un controllo rapido è:

dig +short tuodominio.it A

e, se serve, anche:

dig +short tuodominio.it AAAA

Esito atteso: l’IP restituito deve essere quello del server corretto o della CDN prevista. Se l’output è vuoto, il dominio non sta risolvendo correttamente.

In cPanel, Plesk o FastPanel controlla la zona DNS del dominio e verifica che i record non siano stati modificati di recente. Se usi un provider DNS esterno, la correzione va fatta lì, non sul pannello hosting.

3. Verifica se il web server risponde

Se il DNS è corretto, passa al web server. Un servizio fermo, un processo bloccato o una porta non in ascolto producono spesso connessione rifiutata o errore 502/503.

Su Linux, i controlli minimi sono questi:

systemctl status nginx

systemctl status apache2

oppure, su sistemi basati su Alma/Rocky/CentOS:

systemctl status httpd

Esito atteso: il servizio deve risultare active (running). Se risulta failed o inactive, il problema è lato web server o dipendenze.

Controlla anche se la porta 80 e 443 sono in ascolto:

ss -ltnp | grep -E ':80|:443'

Esito atteso: deve comparire il processo del web server. Se le porte non sono in ascolto, il sito non può rispondere correttamente.

Se usi un pannello, guarda il servizio web nella sezione dedicata ai servizi e riavvialo solo se il pannello segnala arresto o errore evidente. Evita riavvii ripetuti senza prima leggere il log.

4. Leggi subito i log essenziali

I log danno quasi sempre la direzione giusta in pochi minuti. Non serve leggere tutto: bastano gli errori recenti e quelli corrispondenti all’orario del guasto.

File o aree da controllare:

• log errori di Nginx o Apache;
• log PHP-FPM;
• log applicativi del CMS;
• eventuali log del proxy o del bilanciatore;
• log del database, se il sito usa MySQL o MariaDB.

Esempi di controllo rapidi:

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

tail -n 50 /var/log/httpd/error_log

tail -n 50 /var/log/php-fpm/error.log

Esito atteso: comparirà un errore concreto, come file mancante, permission denied, upstream down, memory exhausted, timeout, crash del processo o errore di configurazione.

Se trovi un errore del tipo connect() failed (111: Connection refused) while connecting to upstream, il problema spesso è PHP-FPM fermo o non raggiungibile. Se trovi permission denied, il problema è quasi sempre permessi o ownership dei file. Se compare Primary script unknown, il path del sito o la configurazione FastCGI è errata.

5. Controlla PHP e il gestore FastCGI

Molti siti in hosting moderno dipendono da PHP-FPM. Se il processo PHP non gira, si blocca o ha raggiunto i limiti, il sito può mostrare pagina bianca, 502 o 503.

Verifiche utili:

1. Controlla che il servizio PHP-FPM sia attivo.
2. Verifica la versione PHP assegnata al dominio.
3. Controlla i limiti di memoria e il numero massimo di processi.
4. Esamina eventuali errori fatali del sito o di plugin e temi.

Comandi utili:

systemctl status php-fpm

systemctl status php8.1-fpm

Il nome del servizio cambia in base alla versione installata. Se il servizio è attivo ma il sito continua a non rispondere, il pool PHP potrebbe essere saturo o mal configurato.

Se sospetti un errore applicativo, controlla il log PHP del sito o il file di debug del CMS. In WordPress, ad esempio, un plugin recente o un tema può mandare in errore tutta la pagina. In questo caso il fix più sicuro è disattivare temporaneamente l’ultimo elemento modificato, non resettare tutto il sito.

6. Verifica database e credenziali

Se il sito carica a metà, mostra errori di connessione al database o resta bianco dopo l’avvio, il database è un candidato forte. La causa può essere servizio fermo, credenziali errate, tabelle corrotte o saturazione di risorse.

Controlli rapidi:

1. Verifica che MySQL o MariaDB siano attivi.
2. Controlla se il sito usa il database giusto.
3. Conferma utente, password e host nel file di configurazione del CMS.
4. Esamina eventuali errori di connessione o tabelle danneggiate.

Comandi utili:

systemctl status mariadb

systemctl status mysql

Esito atteso: il servizio deve essere active (running). Se non lo è, il sito che dipende dal database quasi certamente non può aprirsi correttamente.

Se il database è attivo ma il sito non funziona, controlla il file di configurazione dell’applicazione. Su WordPress, ad esempio, i parametri da verificare sono quelli nel file wp-config.php. Un errore di password o host produce immediatamente errore di connessione.

7. Escludi cache corrotta o contenuto statico rotto

A volte il server e l’applicazione sono sani, ma il problema è una cache rotta, un file temporaneo danneggiato o un contenuto statico non aggiornato. Questo succede spesso con CMS, plugin di cache, CDN o reverse proxy.

Prima di cancellare qualsiasi cosa, prova il metodo meno invasivo:

1. svuota la cache del plugin o del pannello, se esiste;
2. purga la cache CDN, se il sito la usa;
3. rigenera eventuali cache applicative o opcode cache con un riavvio controllato del servizio PHP, solo se necessario.

Se il sito torna online dopo la pulizia cache, il problema era quasi certamente legato a contenuti obsoleti o file temporanei danneggiati. Dopo il fix, verifica se il problema ricompare a ogni deploy o aggiornamento: in quel caso c’è un conflitto tra cache e pubblicazione.

8. Controlla permessi, ownership e spazio disco

Un hosting può sembrare “rotto” quando in realtà il filesystem è pieno o i permessi sono sbagliati. Se il disco è esaurito, il server non riesce a scrivere log, sessioni, cache o file temporanei. Se i permessi sono errati, il web server non può leggere i file o scrivere dove serve.

Verifiche da fare:

1. Controlla lo spazio disco e gli inode disponibili.
2. Verifica ownership e permessi delle cartelle del sito.
3. Controlla se sono presenti file creati da root o da un utente sbagliato.

Comandi utili:

df -h

df -िह

Esito atteso: deve esserci spazio libero sufficiente, non solo su / ma anche sulla partizione che ospita /var, /home o il volume del sito.

Se il disco è pieno, libera prima i file più sicuri: log vecchi, cache temporanee, backup duplicati e file di sessione non necessari. Evita cancellazioni aggressive senza sapere cosa stai rimuovendo. Se trovi ownership sbagliata, correggila solo per la directory del sito e fai un backup prima di modifiche ampie.

9. Controlla firewall, WAF e protezioni esterne

Se il server risponde da locale ma non dall’esterno, la causa può essere firewall, WAF, regole del provider, CDN o blocchi temporanei per abuso rilevato.

Verifiche utili:

• porta 80 e 443 aperte sul firewall del server;
• regole del provider cloud o del pannello di sicurezza;
• eventuale blocco del tuo IP da parte di moduli anti brute force o WAF;
• regole CDN o proxy che puntano al vecchio origin.

Se hai un firewall attivo, controlla che non stia bloccando il traffico web o le richieste verso il backend. Se usi una protezione applicativa, verifica i log dei blocchi: a volte un falso positivo impedisce l’apertura del sito solo a parte degli utenti o solo a un paese.

10. Se il problema è WordPress o CMS simili

Quando il sito è basato su WordPress, Joomla, Drupal o simili, il guasto spesso è applicativo e non di rete. In questo caso il controllo più rapido è capire se il problema è nato dopo un aggiornamento, un plugin, un tema o una modifica ai file.

Ordine consigliato:

1. verifica l’ultimo cambio effettuato;
2. disattiva temporaneamente il plugin o il tema sospetto;
3. controlla il file di debug o il log applicativo;
4. se necessario, ripristina solo il componente che ha introdotto l’errore.

Se il sito non apre dopo un aggiornamento, il rollback del solo plugin o tema è molto più sicuro di un ripristino completo. Il ripristino totale va considerato solo se hai un backup recente e il problema è esteso a tutto l’ambiente.

11. Soluzione minima consigliata in caso di incidente

Se il sito è in produzione e hai bisogno di una stabilizzazione rapida, segui questa sequenza:

1. verifica che il DNS punti all’IP giusto;
2. controlla che web server e PHP-FPM siano attivi;
3. leggi gli ultimi errori nei log;
4. riavvia solo il servizio coinvolto, non l’intero server, se il log indica chiaramente il componente guasto;
5. se il problema è applicativo, disattiva solo l’ultimo cambio introdotto.

Questa è la strada più sicura perché riduce l’impatto e limita i cambiamenti. In molti casi un singolo riavvio controllato di PHP-FPM o un fix su DNS/permessi risolve il problema senza effetti collaterali.

12. Controlli finali e prevenzione

Dopo il fix, non fermarti alla semplice apertura della homepage. Fai almeno questi controlli finali:

• apertura da browser diverso e da rete diversa;
• verifica di una pagina interna e non solo della home;
• test di login o form, se il sito li usa;
• controllo dei log per 10-15 minuti dopo la correzione;
• verifica di CPU, RAM, I/O e saturazione PHP o database, se il guasto era legato alle risorse.

Se il problema si ripresenta, raccogli subito le evidenze: orario, errore esatto, log correlati, ultimo cambiamento fatto e stato dei servizi. Questo riduce molto il tempo di diagnosi al prossimo intervento.

Per prevenire ricadute, tieni sempre attivi questi tre elementi minimi: backup verificati, aggiornamenti controllati e monitoraggio della raggiungibilità. Se gestisci più siti, aggiungi anche un controllo periodico su DNS, certificati TLS, spazio disco e stato dei servizi web.

Regola pratica: prima verifica che il sito sia raggiungibile dal punto di vista tecnico, poi cerca il componente guasto, infine intervieni sul solo elemento coinvolto.