Quando un sito smette di funzionare, la tentazione è provare soluzioni a caso finché qualcosa non cambia. È il modo più lento per risolvere un problema. Il server, invece, tiene un diario dettagliato di tutto quello che accade: ogni visita, ogni errore, ogni risorsa che non è riuscito a servire. Quel diario sono i file di log, e saperli leggere è la competenza che separa chi risolve un guasto in dieci minuti da chi ci passa un pomeriggio.
In questa guida vediamo quali log esistono, dove trovarli, come interpretarne le righe e come costruire un metodo di diagnosi per i casi di downtime, cioè quando il sito non è raggiungibile. Se ti serve prima un orientamento generale sul tipo di errore che hai davanti, parti dalla guida agli errori del sito web.
I tipi di log che ti servono davvero
Su un normale hosting web i log utili sono tre, e ognuno risponde a una domanda diversa.
L’access log registra ogni richiesta arrivata al server web: chi l’ha fatta, quando, quale pagina ha chiesto e quale codice di risposta ha ricevuto. Serve a capire che cosa è successo dal punto di vista del traffico, per esempio se un bot ha bombardato il sito di richieste o se una pagina restituisce errori a molti visitatori.
L’error log del server web registra i problemi incontrati da Apache, Nginx o LiteSpeed: file non trovati, permessi negati, regole di configurazione non valide, timeout verso PHP. È il primo posto da guardare quando compare un errore 500, 502 o 503.
Il log degli errori PHP registra gli avvisi e gli errori fatali generati dal codice dell’applicazione. Se il sito è fatto con WordPress, puoi attivare anche un log dedicato, il file debug.log, che spesso indica direttamente il plugin o il tema responsabile del problema.
Dove si trovano i file di log
La posizione dipende dal tipo di hosting. Sugli hosting condivisi con cPanel trovi gli accessi nella sezione Metriche, alla voce dedicata agli accessi non elaborati, e gli errori recenti nella voce Errori; molti pannelli mostrano anche un visualizzatore dei log direttamente nel browser. Con Plesk i log sono raccolti nella sezione Log di ciascun dominio, con filtri per tipo e per data.
Su un VPS o un server dedicato i log si trovano nel filesystem. Le posizioni predefinite più comuni sono queste:
| Software | Access log | Error log |
|---|---|---|
| Apache (Debian, Ubuntu) | /var/log/apache2/access.log |
/var/log/apache2/error.log |
| Apache (CentOS, AlmaLinux, Rocky) | /var/log/httpd/access_log |
/var/log/httpd/error_log |
| Nginx | /var/log/nginx/access.log |
/var/log/nginx/error.log |
Ogni sito ospitato può avere però file separati, configurati nel suo virtual host: se non trovi le righe che cerchi, controlla la configurazione del sito. Per seguire un log in tempo reale mentre riproduci l’errore, sul server puoi usare il comando tail -f seguito dal percorso del file.
Come leggere una riga dell’access log
La maggior parte dei server usa il formato chiamato Combined Log Format. Una riga tipica ha questo aspetto:
203.0.113.45 - - [12/Nov/2026:10:15:32 +0100] "GET /contatti/ HTTP/2.0" 404 5120 "https://www.google.com/" "Mozilla/5.0 ..."Letta da sinistra a destra, dice che l’indirizzo IP 203.0.113.45 ha richiesto la pagina /contatti/ il 12 novembre alle 10:15, che il server ha risposto con il codice 404 inviando 5120 byte, che il visitatore arrivava da Google e quale browser stava usando. Il campo più prezioso è quasi sempre il codice di stato: filtrando il log per i codici 404 trovi i link rotti, filtrando per i 5xx trovi gli errori del server, e contando le richieste per indirizzo IP individui un bot troppo aggressivo. Il significato di ogni codice è spiegato nella guida ai codici di stato HTTP.
Come leggere l’error log
Le righe dell’error log sono più eterogenee, ma contengono sempre la data, il livello di gravità e un messaggio. Alcuni esempi frequenti e il loro significato:
- Permission denied: il server non può leggere un file o una cartella per via dei permessi, tipica causa di un errore 403.
- Invalid command o RewriteRule: bad flag: una direttiva non valida nel file
.htaccess, che produce un errore 500 su tutto il sito. - upstream timed out (Nginx): PHP o l’applicazione non hanno risposto in tempo, l’origine più comune degli errori 504.
- PHP Fatal error: il codice si è interrotto; il messaggio indica il file e la riga, quindi il plugin o il componente responsabile.
Un consiglio pratico: annota l’ora esatta in cui hai visto l’errore nel browser e cerca nel log le righe di quel minuto. Su un sito con traffico, è il modo più rapido per trovare l’ago nel pagliaio.
Comandi utili per analizzare i log
Su un VPS o su un hosting con accesso SSH, qualche comando da terminale permette di estrarre in pochi secondi informazioni che a occhio richiederebbero ore. Non serve essere sistemisti: bastano pochi schemi da adattare.
Per vedere solo le richieste che hanno ricevuto un errore del server, puoi filtrare l’access log sul campo del codice di stato:
awk '$9 ~ /^5/' access.log | tail -n 20Per scoprire quali indirizzi IP fanno più richieste, utile quando sospetti un bot o un attacco:
awk '{print $1}' access.log | sort | uniq -c | sort -nr | headPer elencare le pagine che restituiscono più spesso un 404, così da individuare i link rotti più importanti:
awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -nr | headE per cercare nell’error log tutte le righe che contengono una parola chiave, come il nome di un plugin o la parola Fatal, basta il comando grep -i "fatal" error.log. Se i log più vecchi sono compressi, con estensione .gz, puoi usare zgrep nello stesso modo senza decomprimerli. Questi comandi presuppongono il formato standard dei log: se il tuo server usa un formato personalizzato, la posizione dei campi può cambiare.
Quando il sito è down: un metodo in quattro livelli
Un sito irraggiungibile può avere cause molto diverse, e il metodo più efficace è salire un livello alla volta, dalla rete all’applicazione.
Primo livello: è giù per tutti? Verifica il sito da un’altra rete e con un servizio di controllo esterno. Se funziona altrove, il problema è locale, e la guida agli errori del browser ti aiuta a individuarlo.
Secondo livello: il dominio risponde? Controlla che il dominio non sia scaduto e che i DNS puntino all’indirizzo IP giusto. Un rinnovo dimenticato o un record DNS modificato per errore spengono un sito perfettamente funzionante.
Terzo livello: il server risponde? Se il dominio è a posto ma la connessione non si stabilisce, il problema è nel server: servizio web fermo, risorse esaurite, manutenzione dell’hosting o attacco in corso. Lo stato dei servizi è visibile nel pannello o sulla pagina di stato del provider.
Quarto livello: l’applicazione funziona? Se il server risponde ma con un errore, i log sono la tua fonte principale. Un errore 500 rimanda quasi sempre al codice o alla configurazione, un 503 a sovraccarico o manutenzione, un 502 o 504 alla comunicazione tra server web e PHP. Per i siti costruiti con WordPress, la guida agli errori di WordPress raccoglie le cause applicative più frequenti.
Monitorare il sito per sapere prima degli utenti
Scoprire che il sito è giù da un cliente o da un calo di vendite è il modo peggiore di saperlo. Un servizio di monitoraggio dell’uptime controlla il sito a intervalli regolari, tipicamente da uno a cinque minuti, e ti avvisa via email, SMS o app quando non risponde. Molti servizi offrono un piano gratuito più che sufficiente per un sito piccolo. Oltre all’avviso immediato, lo storico dei controlli ti dice quanto spesso il sito va giù e per quanto tempo: un dato oggettivo da usare per valutare la qualità del tuo hosting.
Ricorda però che i tempi di inattività hanno anche un effetto sulla visibilità. Un sito che restituisce errori per poche ore non perde posizionamento, ma interruzioni lunghe o frequenti portano Google a ridurre la scansione e, nei casi peggiori, a rimuovere temporaneamente le pagine dai risultati. Se devi spegnere il sito per una manutenzione programmata, fallo restituendo un codice 503 con l’intestazione Retry-After: è il modo corretto per dire ai motori di ricerca di tornare più tardi.
Quando chiedere aiuto, e cosa fornire
Se il problema è nel server e non hai accesso alla sua configurazione, l’assistenza dell’hosting è la strada giusta. La richiesta sarà risolta molto più in fretta se includi l’indirizzo esatto della pagina, l’ora in cui si è verificato l’errore, il messaggio mostrato dal browser e le righe pertinenti dei log. Per problemi difficili da riprodurre, un file HAR registrato dagli strumenti per sviluppatori del browser documenta tutte le richieste della pagina ed è uno strumento prezioso per il supporto tecnico.
Domande frequenti
I log occupano spazio sul mio hosting?
Sì, ma quasi tutti i server li ruotano automaticamente, comprimendo e cancellando i file più vecchi. Su un VPS gestito da te, la rotazione è affidata a strumenti come logrotate, che conviene verificare per evitare che i log riempiano il disco.
Posso vedere i log se ho solo accesso FTP?
Dipende dall’hosting. Alcuni provider salvano i log in una cartella accessibile via FTP, altri li mostrano solo nel pannello. Il log di debug di WordPress, invece, si trova sempre in wp-content ed è leggibile via FTP.
Per quanto tempo vengono conservati i log?
Sugli hosting condivisi di solito da pochi giorni a qualche settimana. Se ti serve uno storico più lungo, per esempio per analisi di traffico o di sicurezza, conviene scaricarli periodicamente o abilitarne l’archiviazione dal pannello.
