Error 500 Internal Server Error: encuentra la causa en el log

Un error 500 Internal Server Error significa que el servidor aceptó la petición pero no pudo completarla: la configuración del servidor web está rota, un script PHP murió con un error fatal o se quedó sin memoria. La página de error nunca indica la causa, pero una línea del log de errores del dominio casi siempre lo hace. Reprodujimos a propósito ocho causas habituales de un error 500 en un sitio de prueba y anotamos, para cada una, qué ve el visitante, qué línea aparece en el log y qué hacer a continuación.

Qué ve el visitante y qué te indica

Antes incluso de abrir el log, el aspecto de la página de error da una pista sobre qué capa ha fallado. En el entorno de pruebas, cada tipo de fallo producía una respuesta propia y fácil de reconocer:

WordPress muestra “Error establishing a database connection” cuando no puede conectar con la base de datos, y en ese caso no se registra ninguna línea de PHP: consulta nuestra guía sobre el error de conexión a la base de datos para saber qué revisar. Si el servidor devuelve 502 o 503 en lugar de 500, el problema no está en el código del sitio, sino en la comunicación entre el servidor web y PHP. En el mismo entorno, un PHP-FPM detenido produjo exactamente un 503 con una línea AH01079 en el log de Apache; los pasos para ese caso están en nuestro artículo sobre el error 503 Service Unavailable.

Cómo encontrar la línea correcta del log en un minuto

Un error 500 queda registrado en el log de errores del servidor web aunque no haya un log de PHP aparte. Cuando PHP-FPM no tiene archivo de log propio, pasa el texto del error al servidor web, que lo escribe en el log del dominio. En el entorno de pruebas apareció como una línea con el código AH01071 en el log de Apache y con la frase “FastCGI sent in stderr” en el log de nginx.

1. Vuelve a cargar una vez la página que falla y anota la hora. Los logs pueden ser largos, y la marca de tiempo reduce la búsqueda a unas pocas líneas.
2. En el panel de control de tu hosting, abre la sección de dominios, selecciona el dominio y abre su log de errores. En el servidor estos logs suelen estar en /var/log/apache2/ y /var/log/nginx/, pero en un hosting compartido lo más sencillo es leerlos desde el panel.
3. Si has descargado el log o puedes conectarte por SSH, filtra solo las líneas que explican un error 500:

   grep -E "AH00124|AH01071|Invalid command|PHP (Fatal|Parse) error" error.log | tail -n 5

4. Lee la línea desde el final. Contiene la ruta del archivo y el número de línea, por ejemplo wp-content/plugins/bench-fatal/bench-fatal.php:3. La carpeta que va después de plugins/ o themes/ es la culpable.

Un detalle que confunde: WordPress escribe las marcas de tiempo de su propio log en UTC, así que ajusta según tu zona horaria al cotejar entradas.

Tabla: línea del log, causa, qué hacer

Las líneas están abreviadas, pero las palabras clave se mantienen tal cual para que puedas buscarlas en tu propio log.

Lo que vimos en el entorno de pruebas

.htaccess y php_value: un error 500 antes de que arranque PHP

Ambos fallos devolvieron la misma página gris de Apache en aproximadamente un milisegundo, porque la petición nunca llegaba a PHP. La errata RewriteEngin On y la línea php_value memory_limit 256M generaron entradas casi idénticas marcadas como core:alert. El segundo caso es típico tras una migración: el hosting anterior ejecutaba PHP como módulo de Apache, el nuevo usa PHP-FPM, y de repente php_value es un comando desconocido. Lleva esos ajustes a un archivo .user.ini en la raíz del sitio:

upload_max_filesize = 64M

En el entorno de pruebas, el nuevo .user.ini no se aplicó al instante: PHP vuelve a leer estos archivos como máximo una vez cada 300 segundos (el ajuste user_ini.cache_ttl), y el valor solo cambió después de reiniciar PHP. Así que espera cinco minutos antes de concluir que el ajuste no funciona. Los valores que el proveedor ha bloqueado a nivel de servidor no se pueden cambiar con .user.ini. Para los límites de subida en concreto, consulta cómo aumentar upload_max_filesize.

Error de sintaxis: página en blanco o estado 200 con el texto del error

Un punto y coma olvidado en wp-config.php con display_errors desactivado produjo un 500 de cero bytes: una página blanca sin ningún texto. WordPress no puede ayudar aquí, porque el error ocurre antes de que se cargue. El mensaje completo estaba en el log:

AH01071: Got error 'PHP message: PHP Parse error:  syntax error, unexpected identifier "define" in /srv/cw3/www/wp-config.php on line 12'

Faltaba el punto y coma en la línea 11, pero PHP indicó la línea 12: el analizador detecta el error solo en la siguiente instrucción, así que revisa siempre también la línea anterior. Después activamos display_errors, y el resultado no fue el esperado: el servidor respondió con estado 200 y la página mostraba el texto del Parse error con la ruta completa del archivo en el servidor. Una monitorización que solo mira el código de estado dará el sitio por bueno, mientras cada visitante ve la estructura de tus carpetas. No muestres errores en un sitio en producción: de todos modos están en el log.

Error fatal en un plugin y memoria agotada

La llamada a una función inexistente en un plugin y una reserva de memoria sin fin se veían igual para WordPress: estado 500 y la página “There has been a critical error on this website”. Solo el log las distingue:

PHP Fatal error:  Uncaught Error: Call to undefined function rh_function_that_does_not_exist() in .../wp-content/plugins/bench-fatal/bench-fatal.php:3
PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 2097152 bytes) in .../wp-content/plugins/bench-memory/bench-memory.php on line 3

134.217.728 bytes son exactamente 128 MB, el memory_limit actual. Al renombrar la carpeta del plugin, el sitio volvió a responder con 200 en la siguiente petición. Ambos casos se explican en detalle en nuestras guías sobre el error crítico de WordPress y sobre cómo aumentar memory_limit. Subir el límite tiene sentido cuando un plugin necesita realmente más memoria, no cuando está atrapado en un bucle infinito como en nuestra prueba.

Extensión de PHP ausente

Arrancamos PHP-FPM sin la extensión mysqli. WordPress lo comprobó por su cuenta y mostró la página “Requirements Not Met” con estado 500, sin que apareciera ni una sola línea en los logs. Un script independiente que llamaba a mysqli_connect() devolvió una página en blanco y la línea Call to undefined function mysqli_connect(). Ten en cuenta que php -m en la terminal seguía mostrando mysqli en ese momento, porque PHP de línea de comandos y PHP-FPM leen configuraciones distintas. Comprueba las extensiones en el panel de control para la versión de PHP correcta o con phpinfo() en el navegador, no en la consola.

Permisos de archivos y la trampa de OPcache

Asignamos un archivo de WordPress a root con modo 600, de modo que PHP-FPM no podía leerlo. Aun así, el sitio siguió cargando con estado 200: OPcache aún conservaba en memoria la copia compilada. Tras reiniciar PHP, el mismo sitio devolvió 500 con Failed to open stream: Permission denied en wp-settings.php. En la práctica, un chown o chmod incorrecto puede dar la cara horas después, tras un reinicio rutinario de PHP, cuando ya no es evidente la relación con el cambio. Si el script que pide el visitante es él mismo ilegible, la respuesta no es 500 sino 403 con el texto Access denied. Los valores normales son 644 para archivos y 755 para carpetas, con el usuario del sitio como propietario.

Bucle de reescritura interno

La regla RewriteRule ^(.*)$ /index.php/$1 [L] sin condición reescribe la URL hacia sí misma. Apache se detiene tras diez redirecciones internas y devuelve 500:

AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error.

No es lo mismo que un bucle ERR_TOO_MANY_REDIRECTS: allí el navegador rebota entre URL; aquí el bucle ocurre dentro del servidor y el navegador solo ve un 500. Lo soluciona una condición antes de la regla, o restaurar el bloque estándar de WordPress:

RewriteCond %{REQUEST_URI} !^/index\.php
RewriteRule ^(.*)$ /index.php/$1 [L]

Cómo activar el log de errores de WordPress de forma segura

Si el log del servidor web no está disponible o está lleno de entradas ajenas, activa el log de WordPress. Añade esto en wp-config.php encima de la línea require_once ABSPATH . 'wp-settings.php';:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/user/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Sustituye /home/user/logs/ por una carpeta de tu cuenta que esté fuera del directorio público del sitio. Esto es importante: con un simple true, el log va a wp-content/debug.log, y en el entorno de pruebas ese archivo se abría en cualquier navegador con estado 200, rutas del servidor incluidas. Con una ruta aparte, los visitantes seguían viendo solo la página de error crítico, mientras el log recibía la línea con la causa. Cuando la encuentres, vuelve a poner WP_DEBUG en false: la documentación de WordPress desaconseja el modo de depuración en sitios en producción.

Cuándo contactar con el soporte del hosting

Contacta con el soporte si el log no tiene ninguna línea a la hora del error, si el 500 aparece y desaparece sin que hayas cambiado nada o si varios sitios de la cuenta fallan a la vez. Incluye la hora exacta, la URL de la página, la línea del log y lo que ya has comprobado: con estos datos la respuesta será concreta. Para distinguir rápido un problema del sitio de uno del servidor, consulta nuestra guía para diagnosticar problemas de hosting en 15 minutos. El soporte de RichHost atiende de 10:00 a 20:00, hora de Kiev, y suele responder en menos de 30 minutos. En los planes de hosting compartido de RichHost los sitios se gestionan con nuestro propio panel de control con asistente de IA.

Preguntas frecuentes

¿Puede el proveedor de hosting causar un error 500 y no el sitio?

Puede, pero si el log tiene una línea de PHP que apunta a tus archivos, la causa está en el código o la configuración del sitio. Los fallos del lado del servidor suelen aparecer como 502 o 503, o dejan el log vacío.

¿Por qué el sitio carga pero wp-admin devuelve 500?

El error solo ocurre en código que se ejecuta en el área de administración: un plugin activo únicamente allí o una operación que se queda sin memoria. La línea del log apunta al archivo exacto; después actúa igual que con el sitio público.

¿Puedo dejar display_errors activado para ver los errores antes?

No. En el entorno de pruebas, la página de error devolvía estado 200 y mostraba a los visitantes las rutas completas de los archivos. Envía los errores al log, no a la pantalla.

El error desapareció solo. ¿Puedo ignorarlo?

Mejor busca la entrada del log de ese momento. Nuestra prueba de permisos demostró que un fallo puede esconderse detrás de OPcache y volver tras un reinicio de PHP.