L’errore 408 Request Timeout indica che il server non ha ricevuto dal client una richiesta completa entro il tempo previsto. È diverso dal 504, nel quale un gateway attende troppo la risposta del servizio a monte.
Questa guida approfondisce errore 408 Request Timeout con controlli progressivi, modifiche reversibili e verifiche finali. Non inviare password, cookie, token, chiavi private o codici 2FA nei ticket.
Che cosa significa
Il 408 può comparire durante connessioni lente, upload interrotti, client che aprono una connessione senza completare gli header o proxy che mantengono sessioni inattive.
Alcuni server chiudono connessioni keep-alive inattive senza mostrare una pagina visibile all’utente. Per questo la frequenza nei log è più importante di un singolo evento isolato.
Come riconoscere il problema
- Upload lenti terminano con 408.
- Il codice compare negli access log senza segnalazioni utente.
- Solo una rete instabile presenta il problema.
- Bot o scanner aprono molte connessioni incomplete.
- La richiesta fallisce prima che PHP venga eseguito.
Cause più frequenti
1. Connessione lenta o instabile
Il client non invia header o corpo entro la soglia. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
2. Upload molto grande
Il trasferimento richiede più tempo del limite del web server o proxy. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
3. Keep-alive inattivo
Una connessione resta aperta senza inviare la richiesta successiva. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
4. Proxy o VPN
Il livello intermedio interrompe o ritarda i dati. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
5. Bot e slow request
Client automatici aprono connessioni incomplete. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
6. Timeout troppo restrittivo
La configurazione non è adeguata alle richieste legittime previste. Confronta questa ipotesi con il messaggio completo e con i log dell’orario interessato, evitando conclusioni basate soltanto sulla pagina mostrata dal browser.
Diagnosi passo per passo
- Registra fase e durata. Stabilisci se il timeout avviene prima o durante l’upload. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla access log. Verifica metodo, dimensione, IP, user agent e tempo. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Prova una seconda rete. Confronta connessione fissa e mobile. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Riduci il file. Determina se il tempo cresce con la dimensione. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Controlla proxy e CDN. Verifica limiti e timeout del livello frontale. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Distingui 408 e 504. Controlla quale componente stava attendendo dati. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
- Analizza frequenza e IP. Molti 408 da bot possono essere normali rumori di rete. Salva il risultato prima di passare al controllo seguente, così potrai identificare il punto preciso in cui il comportamento cambia.
Metodo sicuro di diagnosi
Prima di applicare modifiche, registra lo stato iniziale: URL o servizio coinvolto, messaggio completo, data e ora, rete o client, ultima operazione eseguita e risultato da un secondo strumento. Questo consente di distinguere una causa locale da una configurazione condivisa e rende possibile il rollback.
Cambia un solo elemento alla volta. Dopo ogni intervento ripeti esattamente lo stesso test, controlla i log dello stesso intervallo temporale e annota il risultato. Modificare contemporaneamente DNS, cache, PHP, plugin e firewall rende impossibile stabilire quale correzione abbia avuto effetto.
Controllo incrociato
Usa almeno due fonti indipendenti. Per HTTP confronta browser, curl e log; per WordPress confronta frontend, wp-admin e WP-CLI; per DNS interroga nameserver autoritativo e resolver pubblico; per la posta confronta header, Webmail e Track Delivery. Cache e proxy possono mostrare stati differenti per alcuni minuti.
Quando il problema sembra risolto, ripeti il test con una seconda rete o un secondo account e verifica che le protezioni restino attive. Una soluzione che disabilita globalmente TLS, WAF, autenticazione o controlli di sicurezza non è considerata definitiva.
Procedura di risoluzione
- Stabilizza la connessione. Ripeti da una rete affidabile e senza VPN problematica. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Usa SFTP per file grandi. Evita upload web quando il trasferimento è molto lungo. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Riduci o comprimi il file. Limita la durata della richiesta. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Correggi il client. Aggiorna software che invia richieste incomplete. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Regola il timeout con prudenza. Aumenta soltanto il livello che chiude richieste legittime. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Limita slow clients e bot. Mantieni protezioni contro connessioni abusive. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
- Monitora dopo la modifica. Controlla se i 408 legittimi diminuiscono senza aumentare connessioni occupate. Dopo la modifica ripeti il test originale e verifica che non siano comparsi nuovi errori o regressioni.
Verifica della stabilità dopo l’intervento
Non fermarti al primo test riuscito. Ripeti l’operazione dopo aver aperto una nuova sessione, svuotato soltanto la cache pertinente e atteso l’eventuale scadenza del TTL o del rate limit. Controlla inoltre che una seconda pagina, un secondo utente o un secondo destinatario non presentino ancora il problema.
Conserva per almeno il tempo necessario il backup e la configurazione precedente. Se l’anomalia ricompare, confronta orario, log e processo pianificato: una ricorrenza regolare può dipendere da cron, rinnovi, rotazioni, cache rigenerate o servizi esterni.
Controlli finali
- Upload e richieste legittime terminano.
- Il numero di 408 anomali diminuisce.
- Le connessioni inattive vengono comunque chiuse.
- Nessun aumento di processi occupati.
- Client e proxy usano tempi coerenti.
Prevenzione
- Usa SFTP per grandi file.
- Monitora access log.
- Mantieni timeout equilibrati.
- Aggiorna client.
- Proteggi dalle slow request.
Errori da evitare
- Non impostare timeout illimitati.
- Non confondere il problema con PHP max_execution_time.
- Non disattivare protezioni anti-DoS.
- Non ripetere molti upload simultanei.
- Non attribuire ogni 408 al server.
Quando contattare l’assistenza Xlogic
Apri un ticket quando il problema persiste dopo i controlli di base, coinvolge più servizi o richiede log e configurazioni non disponibili nel pannello. Indica:
- URL e metodo
- dimensione del file
- durata
- IP e rete
- riga di access log
Non inviare credenziali. URL, orari, codici, header non sensibili e messaggi di errore sono sufficienti per iniziare la diagnosi.
Fonti tecniche ufficiali
Verifica prolungata dopo la correzione
Una singola prova riuscita non dimostra che il problema sia definitivamente risolto. Ripeti l’operazione dopo una nuova sessione, da una seconda rete o con un secondo utente quando applicabile. Per DNS e posta considera anche TTL, code e cache dei resolver; per HTTP e WordPress controlla una pagina dinamica, una funzione amministrativa e il relativo registro degli errori.
Conserva temporaneamente il backup, i valori precedenti e gli estratti dei log. Se l’anomalia ricompare, confronta l’orario con cron, backup, aggiornamenti, rinnovi SSL, rotazioni DNS, code email e servizi esterni. Una ricorrenza regolare è spesso più significativa del messaggio mostrato durante il singolo evento.
Prima di chiudere l’intervento verifica inoltre che le misure di sicurezza siano ancora operative: HTTPS valido, autenticazione richiesta, WAF attivo, permessi non eccessivi e nessun endpoint di debug o manutenzione lasciato pubblico. La soluzione deve correggere la causa senza ridurre stabilmente le protezioni del servizio.
Domande frequenti su errore 408 Request Timeout
Qual è la differenza tra 408 e 504?
Nel 408 il server attende la richiesta del client; nel 504 un gateway attende la risposta a monte.
Un upload grande può causare 408?
Sì, soprattutto con connessioni lente o timeout restrittivi.
Devo aumentare max_execution_time?
Normalmente no, perché il 408 può avvenire prima dell’esecuzione PHP.
I bot possono generare 408 nei log?
Sì, aprendo connessioni incomplete o molto lente.
SFTP evita il problema?
Per file grandi evita i timeout della singola richiesta web e offre trasferimenti più adatti.