Errore 500 Internal Server Error: cosa significa e i controlli da fare

Un sito che risponde "500 Internal Server Error" non dice niente di utile a chi deve risolverlo. A differenza del 502 (bad gateway, il server a monte non risponde), del 503 (servizio non disponibile, spesso per sovraccarico o manutenzione) e del 504 (timeout del gateway), il 500 è il contenitore generico: qualcosa si è rotto nell'esecuzione dello script, ma il messaggio che il browser mostra non lo spiega. Per saperlo bisogna aprire i log sul server.

Dove guardare per primo

Nell'ordine, prima di toccare qualunque cosa:

1. Il plugin o il tema installato per ultimo. Se il 500 è comparso subito dopo un aggiornamento o un'installazione, disattivalo da FTP rinominando la cartella in wp-content/plugins/ (aggiungendo per esempio _disabled al nome): se il sito torna su, hai trovato il colpevole senza nemmeno leggere un log.
2. Il file .htaccess, se il sito gira su Apache. Una regola di riscrittura scritta male o un modulo richiesto e non disponibile manda in errore l'intero sito. Rinominalo temporaneamente e prova a ricaricare WordPress rigenera quello standard da pannello.
3. Il log di PHP, che quasi sempre contiene il vero motivo del crash (fatal error, memoria esaurita, funzione mancante).
4. Il log del web server (NGINX o Apache), che a volte intercetta errori di PHP-FPM prima ancora che arrivino al log applicativo.

I percorsi dei log: cambiano con sistema e pannello

Non esiste un percorso unico valido ovunque. Su un server Linux semplice decide la distribuzione, su un server con pannello di controllo decide il pannello.

Ambiente	Log NGINX	Log PHP-FPM
Ubuntu / Debian (pacchetti standard)	/var/log/nginx/error.log	/var/log/php8.3-fpm.log (la versione è nel nome del file)
AlmaLinux / Rocky / RHEL	/var/log/nginx/error.log	/var/log/php-fpm/error.log per il servizio, /var/log/php-fpm/www-error.log per gli errori del sito
DirectAdmin	/var/log/nginx/domains/ (per dominio)	/usr/local/php83/var/log/php-fpm.log

Un dettaglio che manda fuori strada molti: il log di servizio di PHP-FPM (/var/log/php8.3-fpm.log su Ubuntu) registra solo eventi del processo, non gli errori del codice del sito — per esempio un avviso quando il pool raggiunge pm.max_children. Gli errori PHP veri e propri, se il pool non ha un error_log dedicato configurato, finiscono nel log di NGINX con il prefisso "FastCGI sent in stderr".

Comandi verificati su Ubuntu 24.04 (NGINX + PHP-FPM 8.3)

Per seguire un errore mentre lo riproduci:

sudo tail -f /var/log/nginx/error.log

Se nel pool PHP-FPM è impostato un log dedicato (file in /etc/php/8.3/fpm/pool.d/), con una riga tipo:

php_admin_value[error_log] = /var/log/php8.3-fpm/sito.log
php_admin_flag[log_errors] = on

dopo aver salvato va ricaricato il servizio:

sudo systemctl reload php8.3-fpm

Attivare il debug di WordPress per vedere il messaggio reale

Il modo più diretto per sapere perché WordPress sta restituendo un 500 è leggere il file wp-config.php e modificare (o aggiungere, prima della riga "That's all, stop editing!") queste tre righe:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con WP_DEBUG_DISPLAY a false gli errori non compaiono sulla pagina pubblica (da evitare su un sito in produzione visibile agli utenti), ma vengono scritti in un file. Per impostazione predefinita il file è wp-content/debug.log; se si vuole un percorso diverso si può sostituire true con un percorso assoluto, per esempio define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );.

Una volta riprodotto l'errore, basta leggere le ultime righe:

tail -n 50 wp-content/debug.log

Fatto il controllo, le tre righe vanno rimesse a false: lasciare il debug attivo su un sito pubblico espone dettagli dell'installazione a chiunque trovi il file, se questo finisce per errore in una cartella raggiungibile dal browser.

Quando è il server, quando è il codice

Se il log di PHP mostra un fatal error con nome di funzione, classe o file del tema/plugin, il problema è nel codice: va aggiornato, sostituito o segnalato a chi lo mantiene. Se invece il log di NGINX o di PHP-FPM mostra errori di permessi sui file, timeout del pool, o il processo PHP-FPM che si riavvia da solo, il problema è lato server: configurazione del pool, spazio su disco esaurito, o limiti di memoria troppo bassi in php.ini. Un controllo rapido dello spazio libero (df -h) e della memoria (free -m) prima di aprire qualunque log evita di cercare nel codice un problema che è solo mancanza di risorse.