Apache: 503 dopo reload per proxy timeout lento

Diagnosi probabile

Un errore 503 Service Unavailable dopo un reload spesso non dipende da Apache in sé, ma da un backend lento o non raggiungibile: PHP-FPM, app Node, API interne, pool FastCGI o un upstream dietro proxy. In pratica il web server risponde, ma il servizio a monte non completa la richiesta entro i tempi previsti.

Verifiche immediate

1. Controlla gli errori del virtual host o del servizio web: cerca righe con proxy, timeout, connection refused o AH01114. L’esito atteso è trovare il componente che non risponde.
2. Verifica lo stato del backend: per esempio systemctl status php-fpm o il servizio dell’app. Se è inactive, failed o pieno di restart, il problema è lì.
3. Prova la porta locale del backend con una richiesta diretta, ad esempio curl -I http://127.0.0.1:8080. Se la risposta è lenta o assente, il collo di bottiglia non è il frontend.

Soluzione consigliata passo-passo

1. Riporta il servizio backend in stato stabile: riavvia solo il componente guasto, non tutto lo stack. Dopo il restart, controlla che il processo resti attivo per almeno 1-2 minuti.
2. Se il backend risponde ma è lento, aumenta in modo prudente i timeout solo quanto basta. In Apache, verifica i valori di ProxyTimeout o delle direttive del vhost; l’obiettivo è evitare 503 su richieste legittime, non mascherare un blocco permanente.
3. Se usi PHP-FPM, controlla il pool: un numero troppo basso di worker o richieste bloccate può generare 503 anche con CPU libera. Il controllo pratico è vedere se ci sono richieste in coda e log di max children reached.
4. Se l’errore compare dopo un deploy, confronta l’ultima modifica di config o applicazione con un rollback rapido del solo file toccato. Prima di cambiare altro, fai un backup del vhost o del pool.

Controlli finali / rollback

1. Verifica che la homepage e una pagina dinamica rispondano con 200 o con il codice atteso, e che nei log non compaiano nuovi 503 per almeno qualche minuto.
2. Controlla il tempo di risposta: se il backend resta oltre soglia, non alzare ancora i timeout senza correggere la causa della lentezza.
3. Se il fix peggiora la situazione, ripristina il file di configurazione salvato prima della modifica e riavvia solo i servizi coinvolti.

Regola pratica: prima identifica chi non risponde, poi tocchi i timeout. In caso contrario rischi di nascondere il guasto invece di risolverlo.

Assunzione: il server è già raggiungibile via SSH o pannello e l’errore nasce dopo un reload o un deploy recente.