504: il backend ci ha messo troppo
L'errore 504 Gateway Timeout indica che un server proxy intermedio ha atteso troppo a lungo una risposta dal server upstream e ha chiuso la connessione. A differenza del 502, il backend non è necessariamente in crash: sta semplicemente impiegando più tempo del consentito. Identificare cosa sta rallentando è la chiave per la soluzione.
Identificare il responsabile della lentezza
Verifica i log del backend per individuare richieste lente. Su Apache con mod_log_config: aggiungi %D al LogFormat per loggare il tempo di risposta in microsecondi. Su Nginx aggiungi $request_time al log_format. Cerca richieste >5 secondi per identificare gli endpoint problematici.
Query database lente
Causa numero uno: query SQL non ottimizzate. Attiva il slow query log di MySQL: in my.cnf aggiungi slow_query_log=1 e long_query_time=2. Analizza con mysqldumpslow. Aggiungi indici sulle colonne usate in WHERE e JOIN. Usa EXPLAIN per capire il piano di esecuzione di query lente.
API esterne timeout
Se la tua applicazione chiama API di terze parti (gateway pagamento, geolocalizzazione, email service) e queste sono lente o offline, il tuo backend resta in attesa. Imposta sempre timeout espliciti sulle chiamate cURL/Guzzle/fetch: curl_setopt($ch, CURLOPT_TIMEOUT, 10);. Considera chiamate asincrone via queue per chiamate non bloccanti.
Aumentare i timeout (workaround temporaneo)
Per richieste che legittimamente richiedono tempo (esportazioni, report), aumenta i timeout: Nginx proxy_read_timeout 300; fastcgi_read_timeout 300;. Apache ProxyTimeout 300. PHP max_execution_time = 300. Cloudflare ha un limite hardcoded di 100 secondi: per richieste più lunghe serve un cron o background job.
Background job per richieste lunghe
Per operazioni che durano più di 30 secondi (es. esportazioni CSV di migliaia di righe, importazioni, elaborazioni AI), implementa un sistema di code: Laravel Queue, Symfony Messenger, Sidekiq, Celery. L'utente avvia il task e riceve un job ID; il browser fa polling per controllare lo stato. Nessun 504 mai più.
Lock di tabelle e deadlock
Su MySQL InnoDB, deadlock e lock prolungati bloccano query di tutti gli utenti. Esegui SHOW PROCESSLIST per vedere query in attesa. SHOW ENGINE INNODB STATUS mostra deadlock recenti. Ottimizza ordine delle transazioni e durata. Considera l'uso di SELECT ... FOR UPDATE NOWAIT per fallire velocemente invece di attendere.
Risorse server saturate
CPU al 100% o I/O disco saturato rendono tutto lento. Monitora con top, iotop, vmstat 1. Se è un problema strutturale, è ora di scalare verticalmente (più CPU/RAM) o orizzontalmente (più server con load balancer). Strumenti APM come New Relic o Datadog identificano colli di bottiglia precisi.
Hai bisogno di aiuto?
Se il tuo sito ha problemi di accesso, il team di G Tech Group può aiutarti. Contattaci tramite il modulo di contatto.