L’errore HTTP 500, Internal Server Error, indica che il server ha incontrato una condizione imprevista che gli ha impedito di completare la richiesta. Il codice non identifica da solo la causa: il problema può dipendere dalla configurazione del web server, da PHP, da un file .htaccess, da permessi errati, dall’applicazione o da una risorsa necessaria che non risponde correttamente.
Per questo motivo la soluzione non consiste nel “provare a caso” diverse impostazioni: bisogna partire dal momento in cui compare l’errore, identificare quale componente sta gestendo la richiesta e leggere i log che contengono l’errore reale.
Che cosa significa realmente un errore 500
Il codice 500 Internal Server Error è una risposta HTTP generica: informa che il server non ha potuto completare la richiesta, ma non indica quale componente abbia generato il problema.
Il problema può trovarsi nell’applicazione, nel runtime PHP, nella configurazione di Apache o Nginx, nei permessi oppure in una risorsa necessaria all’elaborazione. Per questo il codice visualizzato dal browser va sempre messo in relazione con i log del componente che ha gestito la richiesta.
Errore 500, 502 e 503: non sono la stessa cosa
Alcuni codici HTTP vengono confusi perché possono comparire durante problemi di disponibilità di un sito, ma descrivono situazioni differenti. Un 500 riguarda principalmente un errore interno durante l’elaborazione della richiesta; un 502 indica invece che un gateway o proxy ha ricevuto una risposta non valida dal server a monte, mentre un 503 indica che il servizio non è momentaneamente disponibile.
| Codice | Significato | Cause tipiche |
|---|---|---|
| 500 | Errore interno del server | PHP fatal error, configurazione errata, .htaccess, permessi, applicazione |
| 502 | Bad Gateway | Proxy o web server che non riceve una risposta valida dal backend |
| 503 | Service Unavailable | Servizio sovraccarico, backend fermo o temporaneamente non disponibile |
Quando più componenti partecipano alla gestione della richiesta, è importante capire quale di essi ha generato il codice prima di intervenire sulla configurazione.
Le cause più comuni dell’errore 500
Errore PHP
È una delle cause più frequenti nei siti dinamici. Un errore fatale, una funzione rimossa dopo il cambio di versione PHP, una classe non trovata o un’eccezione non gestita possono interrompere l’esecuzione dello script e produrre un 500.
Il problema diventa particolarmente evidente dopo un aggiornamento di PHP. Prima di modificare la configurazione del server conviene quindi verificare la compatibilità dell’applicazione con la versione in uso. La guida PHP per un sito web: versioni, compatibilità e prestazioni approfondisce il rapporto tra versione PHP, compatibilità, sicurezza e applicazioni legacy.
File .htaccess non valido
Su Apache, una direttiva non supportata, un errore di sintassi o una configurazione incompatibile con i moduli disponibili può causare un 500 prima ancora che l’applicazione venga eseguita.
Un modo rapido per individuare il problema è verificare se l’errore compare subito dopo la modifica del file. Rinominare temporaneamente .htaccess e ripetere la richiesta può essere un test utile, purché si tenga conto che così si possono disattivare anche regole necessarie al funzionamento del sito.
Permessi e proprietà dei file
Permessi troppo restrittivi possono impedire al web server o a PHP di leggere file necessari all’applicazione. Anche permessi eccessivamente permissivi sono però una cattiva configurazione perché aumentano la superficie di rischio.
Il controllo deve comprendere sia i file sia le directory e, soprattutto, il proprietario e il gruppo con cui vengono eseguiti i processi del sito. Non è corretto risolvere automaticamente un 500 impostando permessi molto ampi come 777: può nascondere il problema reale e introdurre una vulnerabilità.
Memoria PHP esaurita
Un’applicazione può terminare con un errore fatale quando supera il limite di memoria assegnato a PHP. Questo può accadere durante operazioni particolarmente pesanti, importazioni, elaborazioni di immagini, aggiornamenti o richieste generate da plugin e moduli.
Il log PHP normalmente permette di distinguere un vero esaurimento della memoria da un problema generico dell’applicazione. Aumentare memory_limit può essere corretto in alcuni casi, ma non dovrebbe essere usato per mascherare un consumo anomalo causato dal codice.
Timeout e processi PHP-FPM
Una richiesta che richiede troppo tempo può superare un limite di esecuzione di PHP o un timeout configurato tra i diversi componenti del web stack. A seconda di quale livello interrompe la richiesta, il risultato può essere un 500 oppure un altro codice, come 502 o 504. Per questo è importante capire quale timeout viene raggiunto, invece di modificare soltanto un parametro.
Un processo PHP lento può inoltre essere il risultato di una query SQL inefficiente, di una chiamata HTTP esterna che non risponde o di un’applicazione che sta eseguendo un’operazione troppo pesante per una normale richiesta web.
Plugin, moduli o aggiornamenti dell’applicazione
WordPress, PrestaShop e altri CMS possono generare un 500 dopo l’installazione o l’aggiornamento di un componente. Il fatto che il problema sia comparso subito dopo una modifica è un’informazione diagnostica importante.
Se il pannello amministrativo non è più raggiungibile, può essere necessario disattivare temporaneamente il componente responsabile attraverso il filesystem o il database, seguendo le procedure specifiche del CMS.
Configurazione del web server
Direttive Apache, configurazioni virtual host, moduli mancanti o configurazioni generate dal pannello di controllo possono causare risposte 500. In un’architettura con Nginx davanti ad Apache bisogna inoltre verificare quale livello sta restituendo il codice.
Quando il problema interessa un solo dominio, è più probabile una configurazione specifica del virtual host o dell’applicazione. Se invece numerosi siti iniziano contemporaneamente a restituire errori, bisogna allargare l’analisi ai servizi condivisi e all’infrastruttura.
La diagnosi corretta parte dai log
La pagina mostrata dal browser è quasi sempre la fonte meno utile per capire un 500. Il messaggio “Internal Server Error” è generico per definizione; il dettaglio si trova normalmente nei log del web server, di PHP-FPM o dell’applicazione.
La procedura più efficace consiste nel riprodurre l’errore e confrontare subito la richiesta con i log. In questo modo si può associare il messaggio all’evento corretto e individuare il componente che lo ha generato.
| Componente | Cosa cercare | Indicazione utile |
|---|---|---|
| Apache | Error log | Errori di configurazione, autorizzazioni, moduli e richieste PHP |
| Nginx | Error log | Errori di proxy, upstream e gestione della richiesta |
| PHP-FPM | Log PHP | Fatal error, memory limit, problemi dei worker e script |
| Applicazione | Log del CMS o framework | Eccezioni, plugin, moduli e operazioni applicative |
Su un server Linux i log possono essere consultati con strumenti come tail, grep, journalctl, a seconda di come sono stati configurati i servizi. È utile filtrare l’analisi per intervallo temporale e cercare il messaggio generato nello stesso istante della richiesta. Se il log di Apache mostra soltanto un 500 generico, il log di PHP-FPM o dell’applicazione può contenere il dettaglio necessario per risalire alla causa.
Un metodo pratico per isolare il problema
1. Stabilire quando e dove compare
Prima di modificare qualsiasi configurazione bisogna capire se l’errore riguarda tutte le pagine, una sola URL, soltanto il pannello amministrativo oppure una particolare operazione. Anche sapere se il problema riguarda un solo sito o più domini sullo stesso server restringe rapidamente il campo delle possibili cause.
2. Verificare le modifiche recenti
Un 500 comparso subito dopo un aggiornamento, un cambio di PHP, una modifica a .htaccess o una nuova estensione ha un’origine molto più probabile rispetto a un errore comparso senza alcuna modifica apparente.
È utile annotare anche eventuali cambiamenti infrastrutturali: riavvio di PHP-FPM, modifiche al virtual host, aggiornamenti del sistema operativo o del pannello di gestione.
3. Leggere il log nell’istante della richiesta
Riprodurre l’errore e verificare il log nello stesso istante evita di confondere messaggi vecchi o non correlati con la richiesta interessata. Il timestamp consente spesso di collegare direttamente la richiesta HTTP all’errore PHP, Apache o Nginx.
4. Isolare il componente
Se il log indica PHP, l’indagine deve concentrarsi sul codice e sulla versione PHP. Se indica una direttiva Apache, bisogna controllare la configurazione; se invece segnala un problema di upstream, bisogna analizzare la comunicazione tra proxy e backend.
5. Applicare una modifica alla volta
Cambiare contemporaneamente PHP, permessi, .htaccess e impostazioni del server rende molto difficile capire quale intervento abbia risolto il problema. È preferibile, per esempio, disabilitare temporaneamente una regola sospetta, ripetere la richiesta e verificare il log prima di passare alla modifica successiva.
Come interpretare i messaggi nei log
Il messaggio registrato nei log spesso permette di restringere immediatamente l’area della ricerca. Non tutti gli errori che compaiono nello stesso intervallo di tempo sono necessariamente la causa del 500: è importante collegare il messaggio alla richiesta interessata e verificare la sequenza degli eventi.
| Messaggio indicativo | Area da verificare |
|---|---|
PHP Fatal error o Uncaught Error |
Codice PHP, compatibilità, estensioni e dipendenze dell’applicazione |
Allowed memory size exhausted |
memory_limit e consumo di memoria dell’applicazione |
Premature end of script headers |
Esecuzione dello script CGI/FastCGI, PHP-FPM o errore PHP precedente |
Invalid command o errore di configurazione Apache |
Direttive .htaccess, moduli e configurazione del virtual host |
Il testo esatto varia in base alla versione del software e alla configurazione del server. La regola più importante è quindi non cercare una corrispondenza letterale a un singolo messaggio, ma usare il log per identificare il componente e poi seguire l’errore fino alla sua origine.
Verificare la risposta HTTP prima di intervenire
Prima di modificare il server è utile verificare che il 500 venga realmente restituito dalla richiesta interessata e non da una risorsa secondaria. Un controllo diretto della risposta HTTP permette di vedere il codice restituito e, in alcuni casi, anche gli header che aiutano a capire quale componente ha risposto.
Da un terminale si può usare curl -I https://www.example.it/pagina per una richiesta HEAD, quando il server la supporta. Per osservare anche il comportamento della richiesta completa si può usare curl -i https://www.example.it/pagina. Il risultato va confrontato con il log nello stesso istante, soprattutto quando sono presenti proxy o più web server.
Questo controllo è particolarmente utile quando soltanto alcune URL restituiscono 500: se la home page funziona ma una singola rotta fallisce, l’attenzione dovrebbe spostarsi verso il codice eseguito da quella richiesta, le relative regole di riscrittura e le risorse che utilizza.
Errore 500 dopo un cambio di versione PHP
Quando il 500 appare dopo il passaggio a una versione PHP più recente, la compatibilità dell’applicazione è una delle prime ipotesi da verificare. Funzioni deprecate o rimosse, estensioni non disponibili e librerie incompatibili possono interrompere l’esecuzione.
Il downgrade temporaneo a una versione compatibile può essere utile come test diagnostico, ma non dovrebbe diventare la soluzione definitiva quando la versione precedente è obsoleta o non più supportata. Per applicazioni legacy è preferibile pianificare un aggiornamento mantenendo nel frattempo una configurazione controllata e sicura.
Questo aspetto è particolarmente importante quando sullo stesso server convivono applicazioni con requisiti differenti: la scelta della versione PHP deve essere fatta per singolo sito o ambiente, non necessariamente in modo uniforme per tutti i domini.
Errore 500 causato da .htaccess
Apache può restituire 500 quando non riesce a interpretare correttamente una direttiva presente nel file .htaccess. È una situazione frequente dopo il copia-incolla di regole provenienti da configurazioni diverse, dopo il trasferimento di un sito o quando cambiano i moduli disponibili.
Per verificare l’ipotesi si può effettuare un test controllato rinominando temporaneamente il file e riprovando la richiesta. Se l’errore scompare, il problema è molto probabilmente all’interno delle regole. A quel punto è preferibile ripristinare il file e analizzarlo progressivamente, invece di lasciarlo disabilitato.
Un trasferimento di hosting è un altro momento in cui possono emergere differenze di configurazione. Se stai valutando una migrazione, può essere utile consultare anche la guida su come capire quando è il momento di cambiare hosting e quella dedicata alla scelta di un provider hosting affidabile.
Errore 500 e risorse insufficienti
Non tutti i problemi di prestazioni producono direttamente un 500, ma un’applicazione che esaurisce memoria, processi PHP disponibili o altri limiti può arrivare a interrompere la richiesta. Per questo è importante distinguere un errore applicativo da una semplice carenza di risorse.
Se il sito è diventato progressivamente più lento prima di iniziare a restituire errori, è opportuno analizzare anche il carico del server, il numero di processi PHP-FPM, l’utilizzo della memoria e le operazioni eseguite dal database. Un aumento delle risorse può essere necessario, ma deve essere motivato dai dati.
Quando le esigenze di un progetto superano i limiti di un hosting condiviso, può essere utile valutare architetture con risorse più dedicate. La guida Cloud VPS: cos'è, come funziona e come scegliere quella giusta spiega quali caratteristiche valutare e quando una soluzione virtuale può essere appropriata.
Quando il problema è del sito e quando del server
La presenza di un errore 500 non significa automaticamente che il provider hosting abbia un problema. Se il log mostra un fatal error PHP generato da un plugin, la causa è applicativa; se invece più siti indipendenti presentano contemporaneamente errori e i log evidenziano problemi nei servizi comuni, l’indagine deve spostarsi verso l’infrastruttura.
Un piano hosting affidabile dovrebbe inoltre offrire strumenti e log sufficienti per diagnosticare gli errori senza dover procedere per tentativi. Nella scelta di un servizio è quindi importante considerare non soltanto spazio e traffico, ma anche caratteristiche tecniche, affidabilità, backup e modalità di assistenza. La guida Come leggere le caratteristiche di un piano hosting e scegliere quello giusto affronta questi aspetti nel dettaglio.
Perché cancellare cache o riavviare il server non è una vera diagnosi
Svuotare la cache, riavviare PHP-FPM o riavviare il server può talvolta far scomparire temporaneamente il sintomo, ma non identifica necessariamente la causa. Se il problema viene generato da codice incompatibile, configurazione errata o consumo anomalo di risorse, è probabile che ritorni alla prima occasione.
Il riavvio è invece giustificato quando i log indicano un problema reale del servizio o quando serve ripristinare temporaneamente la disponibilità mentre si completa l’analisi. Anche in questo caso il log precedente al riavvio rimane fondamentale per capire cosa è accaduto.
Come evitare che un errore 500 diventi un problema più grave
Un backup non sostituisce la diagnosi, ma riduce il rischio quando un aggiornamento o una modifica introduce un errore. Prima di intervenire su file, configurazioni o database è quindi opportuno verificare che esista una copia recente e che il ripristino sia realmente disponibile.
Quando possibile, le modifiche più invasive dovrebbero essere eseguite in modo reversibile: conservare la configurazione precedente, annotare ciò che viene cambiato e verificare il risultato prima di procedere con altri interventi. In questo modo un errore introdotto durante la correzione può essere isolato e annullato senza aggiungere ulteriori variabili alla diagnosi.
Quando rivolgersi al supporto hosting
Se hai accesso ai log, raccogliere alcune informazioni prima di aprire una richiesta rende il supporto molto più efficace: URL interessata, orario del problema, codice HTTP, modifiche recenti e messaggio di errore presente nei log.
Se invece il 500 riguarda più siti contemporaneamente, compare senza modifiche applicative o è accompagnato da errori nei servizi del server, è ragionevole coinvolgere direttamente il provider. In questi casi il supporto può verificare componenti che non sono accessibili dal normale account hosting.
Per richieste e informazioni puoi utilizzare la pagina Contatti.
Conclusioni
L’errore 500 è un sintomo, non una diagnosi. Le cause possono trovarsi nel codice PHP, nella versione del runtime, nel file .htaccess, nei permessi, nelle risorse disponibili, nella configurazione del web server o nell’infrastruttura che collega i diversi componenti.
Una diagnosi basata sui dati consente di trasformare un errore HTTP generico in un problema circoscritto e verificabile. La causa va quindi cercata nel componente indicato dai log, applicando modifiche controllate e verificandone ogni volta l’effetto.
Approfondimenti
Hai bisogno di supporto per un errore 500?
Se non riesci a individuare la causa dai log o il problema coinvolge l’infrastruttura del server, puoi contattarci fornendo l’URL interessata e l’orario in cui si verifica l’errore.