500 Internal Server Error: inizia dall'error log
Un 500 Internal Server Error indica che un web server ha riscontrato una condizione imprevista e non ha potuto completare una richiesta. È un HTTP status code, cioè un numero che un server utilizza per descrivere il risultato di una richiesta del browser, ma non identifica il problema sottostante. Il più ampio gruppo 5xx comprende gli errori server-side: 502 indica una risposta non valida da un upstream server, 503 significa che un servizio non è disponibile o è sovraccarico e 504 indica che una richiesta a un upstream server ha superato il tempo massimo. Un errore 500 è la risposta generica usata quando il server non riesce a classificare il problema con maggiore precisione.
La richiesta ha già raggiunto il sito web, quindi un vero errore 500 non è causato dal browser del visitatore, dalla risoluzione del Domain Name System (DNS) o dalla rete locale. Svuotare la cache del browser non riparerà il server. Il risultato visibile può essere un messaggio come “500 Internal Server Error” o “HTTP Error 500”, una pagina completamente vuota oppure il messaggio di WordPress “Si è verificato un errore critico su questo sito web”. WordPress può visualizzare quest'ultimo messaggio dopo aver intercettato un fatal PHP error, cioè un malfunzionamento che costringe uno script PHP a interrompersi. Anche una risposta vuota può avere un codice 500, che i proprietari possono verificare tramite il pannello Network degli strumenti per sviluppatori del browser o mediante una richiesta da command line.
Prima di apportare modifiche al server, ricarica una volta la pagina ed esegui un test da un altro dispositivo, da un'altra rete o mediante un servizio esterno di verifica dello stato. Un breve picco nell'utilizzo delle risorse o il ripristino di una dipendenza può rendere temporaneo il problema. Se tutti vedono l'errore, il problema si trova sul server. Se riguarda un solo visitatore, una CDN, un proxy o una page cache potrebbe conservare una vecchia risposta di errore. Una CDN, ossia una content delivery network, memorizza copie dei contenuti del sito web in posizioni più vicine ai visitatori. Svuotare la cache interessata può risolvere questo caso limitato.
Tra le cause comuni vi sono plugin, extension o theme incompatibili, come codice che non può essere eseguito sulla versione di PHP installata o due componenti che dichiarano la stessa function. Sui server Apache, un file .htaccess non valido può impedire il funzionamento di ogni indirizzo sotto la propria directory, perché questo file controlla redirect, URL rewriting e altre impostazioni locali. Può bastare un errore di battitura, una directive non supportata o un'impostazione copiata da un altro server. Tra le altre cause vi sono l'esaurimento della memoria PHP, un'incompatibilità della versione di PHP dopo un upgrade, problemi di connessione al database, integrazioni bloccate, scheduled task non funzionanti e risposte non valide provenienti da un'application programming interface esterna.
Anche l'accesso ai file può essere responsabile. Il server potrebbe non riuscire a leggere un file necessario oppure un ambiente di hosting con protezioni avanzate potrebbe rifiutare permission eccessivamente permissive. Su molti servizi di hosting condiviso, i file devono utilizzare il permission mode 644 e le directory il permission mode 755, con l'ownership assegnato all'utente dell'account di hosting. Un file impostato su 777, che consente un accesso molto ampio, oppure appartenente a un utente non riconosciuto può creare problemi sia operativi sia di sicurezza. I valori corretti possono variare in base alla configurazione dell'hosting, quindi i proprietari devono seguire la documentazione del proprio provider.
Leggi prima l'error log. Un error log è un record del server relativo ai malfunzionamenti e spesso identifica il file e la riga in cui l'elaborazione si è interrotta. I pannelli di controllo dell'hosting lo rendono comunemente disponibile nelle sezioni Logs o Error Log, mentre i provider possono documentare posizioni separate per i record di Apache, Nginx o PHP-FPM. Se queste informazioni non sono sufficienti, abilita il debug logging dell'applicazione. In WordPress, le costanti debug e debug-log nel file wp-config.php possono scrivere fatal error e notice in un file. Non mostrare mai pubblicamente errori dettagliati su un sito web attivo, perché possono rivelare percorsi interni dei file e altri dettagli dell'implementazione.
Crea un backup completo dei file e del database prima di modificare o rinominare qualsiasi elemento. Successivamente, rinomina .htaccess in .htaccess_old ed esegui un nuovo test. Se il sito torna a funzionare, gli utenti di WordPress possono creare un file pulito salvando Impostazioni e poi Permalink. Per le altre applicazioni, le directive devono essere ripristinate gradualmente finché non viene identificata quella difettosa. Per verificare i plugin, disattivali tutti e abilitali nuovamente uno alla volta. Quando la dashboard non è accessibile, usa SFTP, un metodo cifrato per trasferire file, per rinominare wp-content/plugins; ripristina poi il nome della folder e verifica singolarmente le directory dei plugin. Rinomina la folder del theme attivo per fare in modo che WordPress utilizzi un default theme.
Se il log segnala l'esaurimento della memoria, aumenta il memory limit di PHP tramite i controlli dell'hosting, la configurazione o wp-config.php, ma soltanto come passaggio diagnostico. Un componente che consuma molta più memoria rispetto al resto del sito web rimane il problema sottostante. Se il malfunzionamento è iniziato dopo un upgrade di PHP, torna temporaneamente alla versione precedente per confermare la compatibilità, quindi aggiorna il codice incompatibile. Una release di PHP non supportata non deve diventare una soluzione permanente. Controlla inoltre permission, ownership e orari delle modifiche recenti ai file; svuota page cache, object cache, CDN cache e reverse-proxy cache; se le prove indicano un problema relativo a un servizio database, a un module o a una limitazione delle risorse fuori dal controllo del proprietario dell'account, comunica al provider di hosting l'ora esatta dell'errore e la relativa voce del log.
WordPress offre altri due percorsi di ripristino. I core file danneggiati possono essere sostituiti caricando tramite SFTP una nuova copia di WordPress, conservando wp-content e wp-config.php. Un update interrotto può lasciare un file .maintenance nella root del sito web; la rimozione di tale file sblocca il sito. Le procedure diagnostiche più rischiose, compresa la visualizzazione dettagliata degli errori, devono preferibilmente essere eseguite su una staging copy, cioè un duplicato privato utilizzato per i test prima dell'ambiente di produzione.
Un errore 500 può anche indicare un compromised website. Sucuri segnala schemi che includono PHP iniettato all'inizio di index.php, wp-config.php o functions.php di un theme. Questo codice può non funzionare immediatamente oppure dopo che una modifica di PHP lo rende incompatibile. Gli aggressori possono anche modificare .htaccess aggiungendo redirect, regole dipendenti dal visitatore, impostazioni php_value o directive auto_prepend_file che il server rifiuta. Backdoor danneggiate e una rimozione incompleta del malware possono produrre lo stesso risultato.
Tra i segnali di allarme vi sono un errore non preceduto da alcun update o modifica della configurazione, orari inspiegabili di modifiche recenti, malfunzionamenti limitati a determinati visitatori o alle persone provenienti dai motori di ricerca, file sconosciuti, file .htaccess inattesi e voci del log che indicano codice sconosciuto. Nessuno di questi elementi dimostra da solo una compromissione, perché gli update automatici e la cache possono generare indizi simili. Se compare codice sconosciuto, esegui una scansione malware server-side o un confronto dell'integrità dei file con core file sicuramente integri, controlla i file .htaccess in ogni directory, verifica gli account amministratore creati di recente ed esamina gli access log relativi al periodo del primo malfunzionamento registrato. Dopo aver confermato un'infezione, rimuovi i file dannosi, cambia le credenziali di hosting, SFTP, database e amministratore del CMS e correggi l'entry point originale. Il ripristino di un backup pulito senza chiudere la vulnerabilità può consentire una nuova infezione.
È improbabile che una breve interruzione causi danni duraturi al posizionamento nei motori di ricerca, perché i crawler generalmente riprovano dopo gli errori del server.