Hosting: controlli rapidi quando il sito va in timeout

Quando un sito va in timeout

Un timeout non indica sempre lo stesso problema. In hosting può dipendere da un DNS errato, da un web server che non risponde, da PHP bloccato, da query lente, da cache assente oppure da risorse esaurite sul server. La priorità è capire dove si interrompe la catena: browser, rete, web server, applicazione o database.

La regola pratica è semplice: prima si verifica se il sito è raggiungibile fuori dal server, poi si controllano i log essenziali e solo dopo si interviene sulla configurazione. Così si evita di cambiare parametri a caso e si riduce il rischio di peggiorare il problema.

Controllo rapido della causa più probabile

Se il sito carica a tratti o si ferma dopo diversi secondi, la causa più comune è una combinazione di uno di questi fattori:

• risorse CPU o RAM sature sul server;
• query MySQL/MariaDB lente o bloccate;
• PHP-FPM o worker web occupati;
• plugin, tema o script esterni che attendono una risposta remota;
• cache disattivata o inefficace;
• problemi DNS o rete verso il backend.

Se invece il timeout è immediato, spesso il problema è diverso: porta chiusa, servizio fermo, firewall, reverse proxy non raggiungibile o errore di routing.

Verifiche immediate da fare subito

Le verifiche seguenti servono a capire in pochi minuti se il problema è lato client, DNS, web server o applicazione.

1. Apri il sito da una rete diversa o in navigazione privata. Se in un altro browser o da un’altra connessione funziona, il problema può essere locale, di cache del browser o della rete del client.
2. Controlla il codice di errore nel browser. Un timeout puro di solito appare come attesa infinita o messaggio del tipo “tempo di attesa scaduto”. Se compare un errore HTTP preciso, la pista cambia.
3. Verifica il DNS del dominio con uno strumento affidabile o dal terminale. Se il record non punta all’IP giusto, il sito può sembrare lento o non raggiungibile.

Se hai accesso al server, un controllo minimo utile è questo:

curl -I --max-time 15 https://tuodominio.it

Esito atteso: una risposta HTTP entro 15 secondi. Se il comando va in timeout, il collo di bottiglia è prima o durante la risposta del server.

Un secondo controllo utile, se il server è Linux, è verificare se il processo web e il database sono attivi:

systemctl status nginx apache2 php-fpm mariadb mysql

Esito atteso: i servizi principali devono risultare “active (running)”. Se uno è “failed” o “inactive”, hai già un indizio forte sulla causa.

Capire dove si ferma la catena

Per risolvere bene un timeout bisogna separare il problema in quattro livelli: rete, web server, PHP e database. Ogni livello ha sintomi diversi.

1. Rete e DNS

Se il dominio non risolve correttamente o risolve verso un IP sbagliato, il browser aspetta o non riceve risposta. In hosting questo capita dopo modifiche ai record, cambio provider, migrazione o propagazione incompleta.

Controlla che i record A e AAAA siano corretti, che il TTL non sia eccessivamente alto e che non ci siano conflitti tra IPv4 e IPv6. Un record AAAA errato può causare timeout anche se IPv4 funziona.

2. Web server

Se Nginx, Apache o LiteSpeed sono saturi o mal configurati, la richiesta entra ma non viene servita in tempo. In questi casi il sito può aprirsi a volte e andare in timeout in altre, soprattutto sotto carico.

Un indizio frequente è la presenza di molti processi in attesa o di errori nei log di accesso e errore. Anche un numero troppo basso di worker può diventare un collo di bottiglia.

3. PHP

Molti timeout nascono da script PHP che restano in attesa troppo a lungo. Può succedere per plugin pesanti, chiamate verso API esterne lente, importazioni, backup eseguiti via web o loop applicativi.

Se il timeout riguarda soprattutto pagine dinamiche e non i file statici, PHP è un sospetto forte.

4. Database

Se il sito usa WordPress, Joomla, PrestaShop o un CMS simile, le query lente o i lock sul database possono rallentare tutto. In questo caso il server web è vivo, ma attende risposta dal database oltre il tempo utile.

Un database sotto pressione può generare timeout anche senza errori visibili a schermo.

Se hai cPanel, Plesk o FastPanel

Quando il problema è su hosting condiviso o VPS con pannello, conviene usare prima gli strumenti grafici. Sono più sicuri e permettono di vedere subito log, risorse e servizi.

cPanel

1. Apri Metrics o Resource Usage per vedere se il sito ha superato limiti di CPU, RAM o I/O. Esito atteso: nessun picco persistente o blocco su limiti di account.
2. Vai in Errors per leggere gli ultimi errori del sito. Cerca timeout, connessioni al database fallite, file mancanti o errori PHP.
3. Se usi WordPress, controlla i plugin recenti e disattiva temporaneamente quelli introdotti di recente, partendo da quelli di cache, sicurezza, backup e page builder.

Plesk

1. Apri Websites & Domains e controlla lo stato del dominio e della sottoscrizione. Esito atteso: dominio attivo e nessun limite di risorse raggiunto.
2. Vai in Logs e verifica gli errori più recenti. Se vedi errori 504, gateway timeout o script che superano il tempo massimo, il problema è lato applicazione o backend.
3. Controlla PHP Settings e verifica che il memory_limit e il max_execution_time siano coerenti con il sito. Non aumentare questi valori senza prima capire la causa, perché potrebbero nascondere un problema più profondo.

FastPanel

1. Apri la sezione del sito e controlla i log di errore e accesso. Esito atteso: eventuali richieste lente devono comparire con orario e percorso preciso.
2. Verifica lo stato di Nginx, Apache, PHP-FPM e MariaDB dal pannello. Se un servizio risulta fermo o in errore, riavvialo solo dopo aver letto il log associato.
3. Controlla eventuali limiti di risorse del progetto o del container. Se il timeout coincide con picchi di utilizzo, il problema può essere capacitivo e non solo applicativo.

Interventi sicuri e reversibili

La soluzione più sicura è sempre quella che riduce il rischio senza cambiare troppe variabili insieme. Evita di modificare contemporaneamente DNS, PHP, plugin e database, perché poi diventa difficile capire cosa ha risolto.

1. Riavvia solo il servizio bloccato, non tutto il server

Se dai controlli emerge un servizio in errore, riavvia solo quello. Ad esempio, se PHP-FPM non risponde, riavvia PHP-FPM; se il database ha un lock o un crash, riavvia il database; se il web server è saturo, riavvia il servizio web.

Su Linux i comandi tipici sono questi:

sudo systemctl restart php-fpm

oppure, a seconda della distribuzione:

sudo systemctl restart php8.1-fpm

Esito atteso: il servizio torna “active (running)” e il sito risponde entro pochi secondi.

Verifica subito dopo con:

systemctl status php-fpm php8.1-fpm --no-pager

Se il servizio torna giù immediatamente, non insistere: c’è quasi sempre un errore di configurazione o un problema applicativo da leggere nei log.

2. Disattiva temporaneamente la causa più recente

Se il timeout è iniziato dopo una modifica, la strada più rapida è tornare indietro su quell’ultima modifica. In ambiente WordPress, spesso i colpevoli sono plugin di cache, sicurezza, backup, editor visuali o integrazioni esterne.

Se non puoi entrare nel pannello, puoi rinominare la cartella del plugin via file manager o FTP per disattivarlo in modo reversibile. Esito atteso: il sito torna a rispondere senza eliminare dati.

Se la modifica recente è stata un cambio tema, prova a tornare temporaneamente a un tema standard del CMS. Questo aiuta a capire se il problema è nel template o nel core.

3. Controlla il database per lentezza e lock

Se il sito è dinamico, verifica se ci sono query lunghe o tabelle bloccate. Su MySQL/MariaDB un controllo utile è vedere se il server è sotto carico o se ci sono processi in attesa.

mysqladmin processlist

Esito atteso: nessuna query bloccata per tempi anomali. Se vedi molte query in stato “Locked”, “Sending data” o “Copying to tmp table” per troppo tempo, il database è un punto critico.

In questi casi la correzione sicura è:

1. identificare la query lenta o la tabella coinvolta;
2. verificare plugin, cron o import che la generano;
3. intervenire sul componente che la produce, non solo sul sintomo.

4. Riduci il carico applicativo

Se il problema si presenta solo in alcune pagine, ottimizza prima quelle. Le azioni più sicure sono:

• attivare o verificare la cache di pagina;
• ridurre chiamate esterne non necessarie;
• limitare script pesanti caricati su tutte le pagine;
• verificare immagini troppo grandi o risorse terze lente;
• disattivare temporaneamente cron via web se genera picchi.

Queste misure non “nascondono” il problema se fatte bene: servono a stabilizzare il sito mentre cerchi la causa vera.

5. Verifica i timeout dell’applicazione

A volte il timeout non è del server ma dell’applicazione o del proxy. Parametri come max_execution_time, request_terminate_timeout, proxy_read_timeout e fastcgi_read_timeout possono influire.

Non aumentare questi valori come prima mossa. Se il sito impiega troppo a rispondere, alzare il timeout serve solo a far aspettare di più l’utente. Meglio capire perché la richiesta è lenta.

Log da controllare per trovare la causa reale

I log sono spesso il punto più veloce per arrivare alla diagnosi. Cerca sempre l’orario esatto del timeout e confrontalo con i messaggi del web server, di PHP e del database.

I file o le sezioni più utili sono:

• log errori del web server;
• log PHP-FPM;
• slow query log di MySQL/MariaDB;
• event log del pannello di controllo;
• log del CMS o del plugin coinvolto.

Se trovi messaggi come “upstream timed out”, “premature end of script headers”, “server reached max_children” o “connection timed out”, hai già un’area precisa su cui lavorare.

Se invece i log sono vuoti, può significare che la richiesta non arriva proprio al backend, quindi il problema è prima: DNS, firewall, bilanciatore, CDN o proxy.

Quando il timeout dipende da CDN, proxy o firewall

Un timeout non nasce sempre dal server applicativo. Può dipendere anche da un proxy intermedio, da una CDN mal configurata o da regole firewall troppo restrittive.

Se usi Cloudflare o un servizio simile, verifica che l’origine sia raggiungibile direttamente. In alcuni casi il problema è un blocco dell’IP della CDN, un certificato non valido sull’origine o una regola WAF troppo aggressiva.

Se il sito funziona da IP diretto ma non dal dominio, il problema è probabilmente nella catena DNS, proxy o SSL. Se invece non funziona neppure da IP diretto, il problema è sul server o sull’applicazione.

Come distinguere un timeout da un sito lento

Un sito lento non è per forza guasto. La differenza pratica è questa:

• lento: la pagina arriva, ma impiega troppo tempo;
• timeout: la risposta non arriva entro il tempo massimo previsto;
• intermittente: a volte funziona, a volte va in attesa.

Se il problema è solo lentezza, i controlli più utili sono su TTFB, cache hit, query lente, dimensione delle pagine e risorse esterne. Se è timeout, prima bisogna capire se una parte della catena non risponde affatto.

Checklist di stabilizzazione

Prima di fare cambiamenti più ampi, conviene seguire questa sequenza minima:

1. verificare se il problema è riproducibile da più reti e browser;
2. controllare DNS, web server, PHP e database nello stesso orario del guasto;
3. leggere i log prima di riavviare o modificare parametri;
4. disattivare temporaneamente la modifica più recente o il plugin sospetto;
5. confermare il recupero con una richiesta reale al sito.

Controlli finali e rollback

Dopo ogni intervento, esegui sempre questi controlli:

1. Apri la home page e una pagina interna importante. Esito atteso: caricamento entro un tempo normale e senza attese anomale.
2. Verifica un form, un login o una pagina dinamica. Esito atteso: la parte applicativa risponde senza blocchi.
3. Controlla i log per almeno 10-15 minuti. Esito atteso: nessun nuovo errore di timeout o di saturazione.

Se il problema è iniziato dopo una modifica, il rollback più sicuro è tornare alla configurazione precedente, riattivando solo ciò che era già stabile. Mantieni sempre un backup di file di configurazione, plugin disattivati e parametri modificati.

Se il timeout ricompare subito dopo il riavvio di un servizio, dopo la riattivazione di un plugin o dopo una modifica ai timeout, interrompi i test e torna all’ultima configurazione funzionante. Questo evita una falsa soluzione che maschera il guasto vero.

Assunzione operativa: il timeout riguarda un sito o un’applicazione web su hosting Linux con pannello o accesso ai log; se l’infrastruttura è diversa, i controlli restano validi ma cambiano i percorsi dei log e i nomi dei servizi.