Errori 500: cause e soluzioni pratiche

Perché un sito web genera errori 500 e come risolverli: guida pratica al triage

Un errore 500 è il tipo di problema che fa sembrare un sito guasto senza spiegare il motivo. Il browser mostra un messaggio secco, il visitatore si trova davanti a un vicolo cieco e il guasto reale di solito si trova altrove. Ecco perché capire perché un sito web genera errori 500 e come risolverli diventa un esercizio di triage, non un gioco a indovinare: se stai cercando una diagnosi rapida, l’obiettivo è distinguere il vero errore 500 sito web dalla semplice apparenza.

Parti da una regola: non dare per scontato che ogni brutta pagina di errore sia un vero 500 lato server. Un 502, un 503, un gateway timeout o una pagina proxy brandizzata da Cloudflare possono sembrare abbastanza simili da confondere perfino team esperti. Etichettare male il problema fa perdere tempo, quindi conviene sempre partire dalle cause errore 500 server più probabili prima di toccare il codice.

1. Verifica che l’errore sia davvero un 500 lato server

Apri la pagina in una finestra privata e annota il testo esatto. Un errore origin semplice spesso dice “500 Internal Server Error” o qualcosa di altrettanto generico, mentre un livello proxy può mostrare il proprio codice, un request ID o un messaggio sul server upstream. Questa piccola differenza conta, perché un 502 di solito indica una risposta gateway errata, mentre un 503 spesso significa che il servizio è temporaneamente non disponibile.

Controlla la risposta attraverso almeno 2 percorsi: il browser e, se disponibile, una richiesta da riga di comando. Se la pagina nel browser mostra 500 ma il server in realtà restituisce 502 all’edge, potresti inseguire il sistema sbagliato. La soluzione cambia in base all’origine e, in pratica, capire come risolvere errore 500 richiede prima di tutto di verificare quale strato stia davvero fallendo.

Cloudflare, Fastly, nginx, Apache e la tua applicazione possono etichettare il guasto in modo diverso. Un sito potrebbe mostrare una pagina CDN curata con un’etichetta 5xx, mentre un altro restituisce una schermata bianca essenziale e una riga breve nel body HTML. Stesso sintomo, origine diversa.

2. Riproduci l’errore in modo controllato

Prova l’URL esatto che va in errore, non solo la homepage. Un 500 su /checkout può dipendere da un campo di modulo, da un hook di un plugin o da una regola di routing, mentre la pagina principale funziona perfettamente. Se il problema compare solo su 1 URL, la ricerca si restringe molto.

Ripeti la richiesta su 3 variabili: browser, dispositivo e momento. Se fallisce in Chrome su desktop ma non su Safari mobile, potresti trovarti davanti a un percorso di script o a un caso limite della cache. Se fallisce solo dopo un’importazione newsletter o alle 2 di notte, l’orario stesso è un indizio.

Rendi il test noioso. Una richiesta, una modifica, un risultato. Poi prova lo stesso URL con uno stato di accesso diverso, perché gli utenti autenticati a volte attivano percorsi di codice che gli ospiti non toccano mai. È particolarmente comune nei siti con pannelli admin o dashboard per i membri.

Tieni un registro semplice: URL, orario, azione e risposta. Bastano quattro campi. Dopo 3 o 4 voci, gli schemi iniziano a emergere.

3. Controlla il log errori del web server per trovare il primo punto di guasto

Il log errori è di solito il primo posto da controllare dopo che la pagina fallisce due volte. Abbina l’orario del 500 alla voce di log più vicina, poi leggi la riga prima e la riga dopo. La prima riga spesso dice più di quanto farà mai la pagina di errore.

Stai cercando un nome di script, un nome di modulo, un avviso di permessi o un timeout upstream. Un errore fatale PHP potrebbe nominare direttamente il file. Un errore del web server può citare una directory mancante, una destinazione di rewrite errata o una connessione negata a un processo backend.

Un’abitudine utile: copia l’orario esatto della richiesta fallita e confrontalo con access log ed error log. Se il sito è molto trafficato, l’evento “più vicino” può comunque essere sbagliato di alcuni secondi, quindi controlla anche il percorso della richiesta e il codice di stato. Un singolo request ID, se il tuo stack lo aggiunge, può risparmiare una lunga ricerca.

Quando il log nomina un plugin, una libreria o un modulo, fermati un attimo lì. Leggi il contesto attorno. Una riga che parla di “allowed memory size exhausted” punta a limiti di risorse, mentre una riga “permission denied” punta a problemi di ownership o di modalità, anche se entrambi si presentano come 500.

4. Cerca i trigger legati a limiti di risorse e timeout

Gli errori 500 compaiono spesso quando il server finisce qualcosa di basilare. La memoria è una. Il tempo di esecuzione è un’altra. I worker disponibili sono la terza. Quando uno di questi elementi è saturo, la richiesta può fallire prima che la pagina abbia finito di caricarsi.

L’esaurimento della memoria PHP è un caso classico. Un esportazione report, un ridimensionamento immagini o un import prodotti possono richiedere più memoria di quanta ne abbia il processo, e il risultato può essere un 500 invece di un avviso elegante. Se il guasto inizia durante richieste grandi e scompare quando il carico cala, questo è un forte sospetto.

Controlla anche i limiti di tempo di esecuzione. Uno script che resta in loop troppo a lungo può andare in timeout e lasciare al server il compito di ripulire il disastro. Può succedere durante job di importazione, task cron o una chiamata API lenta in attesa di un altro servizio. Basta una dipendenza lenta.

La saturazione di worker o processi è più facile da perdere perché il sito può sembrare sano con poco traffico. Poi arrivano 20 richieste insieme, la coda si riempie e le nuove richieste iniziano a fallire. Alcuni piani di hosting impongono anche limiti a livello di account su CPU, processi in ingresso o I/O, quindi il problema potrebbe essere nel piano stesso e non nel codice.

Se il tuo stack ha un monitoraggio, verifica se i 500 aumentano con i picchi di traffico. Un 500 che compare solo durante una campagna, un rilascio o una finestra di backup è spesso un problema di carico con un altro nome. Qui cosa è cambiato nel monitoraggio dei siti web dopo può aiutare a capire il tipo di alerting di cui hai bisogno adesso.

5. Verifica permessi di file e cartelle al di fuori del CMS

Non tutti i 500 nascono dall’applicazione. I file possono finire con il proprietario sbagliato dopo un deploy, una sincronizzazione o una migrazione. Anche i permessi delle cartelle possono cambiare senza volerlo. Una directory modificata può bloccare scritture nella cache, nei log o negli upload e provocare un guasto al momento della richiesta.

Controlla prima i percorsi che spesso si dimenticano: upload, file temporanei, file di configurazione, artefatti di deploy e directory dei log. Se uno di questi percorsi non è scrivibile dall’utente del web server, il sito può fallire non appena prova a scrivere un file di sessione o creare una voce di cache. È un piccolo problema con un risultato rumoroso.

I problemi di ownership sono particolarmente comuni dopo migrazioni da un host a un altro. Un file può avere i bit di permesso corretti ma il proprietario sbagliato, e questo blocca comunque il processo. È il tipo di dettaglio che fa sembrare irrazionale un 500 finché non guardi fuori dal CMS e ispezioni direttamente il livello server.

Non “risolvere” i permessi aprendoli ovunque. Un rapido chmod 777 può nascondere il problema, ma crea anche un pasticcio di sicurezza e di solito maschera il vero mismatch di ownership. Se ti serve una base di sicurezza per il server dopo le modifiche, la più ampia guida sulla sicurezza del sito web è utile da tenere a portata mentre testi.

6. Esamina i cambi recenti del server o del deployment

Torna indietro di 1 deploy, 1 cambio host o 1 modifica di configurazione. I 500 spesso iniziano subito dopo un cambio di versione PHP, una riscrittura del web server, una nuova regola di redirect o un aggiornamento del cron job. Se il problema è iniziato dopo una migrazione, la migrazione stessa può essere il trigger.

I salti di versione PHP possono far emergere codice vecchio che prima passava inosservato. Un modulo che funzionava su una versione può fallire su un’altra. Lo stesso vale per direttive del web server accettate il mese scorso ma che ora generano errore quando il server legge la configurazione. Una sola riga può fare il danno.

Anche le regole di sicurezza sono una causa frequente. Una regola WAF, una nuova condizione firewall o una modifica di hardening del server possono bloccare una richiesta che sembra sospetta, anche quando è legittima. Qui avere un changelog batte sempre la memoria, perché spesso ci si dimentica del “piccolo” aggiornamento che ha rotto il percorso.

Se è stato coinvolto un deployment, confronta l’ultimo rilascio funzionante con quello attuale. Prima di tutto rivedi 3 cose: file di configurazione, regole di routing e qualsiasi nuovo job in background. Il problema spesso non è nella funzionalità che hai rilasciato, ma nell’effetto collaterale che è stato rilasciato insieme.

7. Ripristina il servizio con il rollback sicuro più छोटto possibile

Il rollback deve essere mirato. Disattiva prima il cambiamento lato server più recente, non l’intero sistema. Reverti un file di config, una regola o un passaggio di deploy alla volta, così puoi vedere quale intervento ripristina il sito. Se annulli tutto insieme, perdi l’indizio.

Parti dall’elemento meno rischioso che è cambiato per ultimo. Se una nuova regola di redirect è comparsa 20 minuti prima del guasto, commentala e riprova. Se è stata modificata una impostazione PHP, riporta solo quella al valore precedente e controlla di nuovo. L’obiettivo è ripristinare il servizio, non fare una pulizia spettacolare.

Per i deploy di codice, tieni pronta una copia sicura e fai rollback solo del rilascio coinvolto. Per la configurazione del server, salva il file attuale prima di modificarlo così puoi confrontarlo riga per riga. Sembra basilare perché lo è, e le basi evitano le interruzioni più lunghe.

A volte il rollback più piccolo e sicuro non è affatto tecnico. Se un cron job sta martellando il server ogni 5 minuti, mettilo in pausa e osserva il sito. Se uno script di backup sta esaurendo le risorse, sposta la pianificazione prima di toccare l’applicazione. Al sito non interessa perché il server è stanco.

8. Previeni il ritorno dello stesso 500

Imposta il monitoraggio dei log in modo che il primo 500 ripetuto sia visibile prima che arrivino le lamentele dei clienti. Un singolo errore isolato è una cosa. Cinque di fila dallo stesso percorso sono uno schema. Fai in modo che l’alert mostri il percorso, l’orario e il testo dell’errore.

Fai passare i deploy da uno stage prima della produzione. Una copia di staging intercetta modifiche di configurazione errate e mismatch di versione che altrimenti colpirebbero prima il traffico live. Mantieni lo stack il più possibile vicino alla produzione, perché una impostazione server che sembra innocua in un ambiente di test può fallire in quello reale.

Traccia le modifiche in un solo posto. Questo significa modifiche di configurazione, aggiornamenti dei plugin, cambi PHP, ritocchi ai cron e aggiornamenti delle regole di sicurezza. Se stai già mappando i cambi del sito, il blog di ostohlo ha materiale correlato nel blog dello studio ostohlo, utile quando ti serve una traccia invece di un ricordo.

Gli alert contano soprattutto quando si ripetono. Se la stessa risposta 500 torna dopo ogni deploy o ogni picco di traffico, alza la soglia di revisione e conserva una breve nota dell’incidente con 3 fatti: cosa è cambiato, dove si è rotto e cosa ha risolto. Quella nota diventa la risposta più rapida la volta dopo, soprattutto quando il prossimo guasto arriva durante una finestra di deploy che non ti aspettavi.