Error HTTP 500: causas y solución (nginx, Apache, WordPress)

¿Qué es el error HTTP 500?

El error HTTP 500 (Internal Server Error) significa que algo se rompió en el servidor web mientras procesaba tu petición, y el servidor no dijo qué. Es el error de servidor más genérico.

El estándar HTTP lo define en una frase: «The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request» (RFC 9110 §15.6.1), es decir: el servidor encontró una condición inesperada que le impidió completar la petición. A diferencia de un 503, no dice nada sobre si el problema es temporal.

Casi siempre es un fallo, una mala configuración o una caída del código del servidor, no algo que haya hecho el visitante. La solución tiene que venir del propietario o del administrador del sitio.

Cómo se ve un error 500

El texto depende del servidor y de la aplicación:

• 500 Internal Server Error — la línea de estado estándar
• 500 Internal Server Error con «nginx» debajo — la página de error propia de nginx
• The server encountered an internal error or misconfiguration and was unable to complete your request. — la página por defecto de Apache
• Ha habido un error crítico en esta web. — la página de error fatal de WordPress, tal como aparece en español (en inglés: «There has been a critical error on this website.»)
• HTTP Error 500.19 - Internal Server Error — IIS, donde el número tras el punto indica el motivo (500.19: datos de configuración no válidos)
• Esta página no funciona · La página example.com no puede procesar esta solicitud ahora. · HTTP ERROR 500 — Chrome, cuando la respuesta 500 no trae una página propia
• Request failed with status code 500 — Axios y otro código JavaScript que llama a una API
• 500. Se trata de un error. — la propia página de error de Google, tal como aparece en español (en inglés: «500. That's an error.»)

Error 500 Internal Server Error en nginx

La mayoría de las veces nginx solo transmite un 500 que devolvió la aplicación que hay detrás (PHP-FPM, Node.js, Python); con PHP-FPM, el mensaje de error de PHP acaba en el log de nginx. nginx también genera un 500 propio en unos pocos casos. Las líneas del log de errores que debes buscar:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Fuente: el código de nginx; un backend caído o sobrecargado da un 502 o un 504, no un 500.)

Causas comunes del error HTTP 500

Un 500 puede venir de decenas de problemas del lado del servidor. Los más comunes:

• Un archivo .htaccess roto — una directiva no válida o una RewriteRule incorrecta hace que Apache responda 500 en ese directorio y en todo lo que cuelga de él.
• Errores fatales de PHP — errores de sintaxis, excepciones sin capturar o llamadas a funciones no definidas detienen el script.
• Límites de memoria o de tiempo de PHP — un script que supera memory_limit (128M por defecto) o max_execution_time (30 segundos) se detiene.
• Líneas php_value en un servidor PHP-FPM — solo funcionan con el mod_php de Apache; con PHP-FPM, Apache las rechaza con un 500.
• Permisos de archivo incorrectos — PHP no puede leer un archivo que incluye, o un host con suPHP/suEXEC rechaza los archivos que cualquiera puede modificar (777). (Un archivo que el propio servidor web no puede leer da 403.)
• Un plugin o un tema — una extensión nueva o actualizada de WordPress, Joomla o Drupal que hace caer todo el sitio.
• Fallos de conexión con la base de datos — credenciales incorrectas, un servidor de base de datos detenido o demasiadas conexiones.
• Archivos del núcleo corruptos — tras una actualización fallida o una subida interrumpida.
• Un disco lleno — el servidor no puede escribir logs, sesiones ni archivos temporales.
• Los desencadenantes propios de nginx — un bucle de reescritura, un archivo de contraseñas ilegible o una escritura de archivo temporal que falla (a menudo un disco lleno); mira la sección de nginx más arriba.

Cómo solucionar un error 500 (como visitante)

Si ves un error 500 en el sitio web de otra persona, el problema está en el servidor, no en tu dispositivo. Sin embargo, hay algunas cosas que puedes intentar antes de rendirte.

• Recarga una vez pasado un minuto (F5, o Cmd+R en Mac). Muchos 500 duran solo lo que dura un despliegue o un reinicio.
• Comprueba si está caído para todos — el Verificador de páginas caídas abre la página desde 11 lugares, y el Verificador de encabezados HTTP muestra el código de estado exacto que recibe nuestro servidor.
• Borra las cookies del sitio, o prueba con una ventana privada. Una cookie de sesión dañada puede hacer que algunas aplicaciones fallen en todas las páginas solo para ti.
• Inténtalo más tarde — la solución está en el servidor, así que dale tiempo al propietario.
• Avisa al propietario del sitio si dura horas, con la dirección de la página y la hora en que ocurrió.

Solución 1: revisa los logs de error del servidor

Los logs de error son la herramienta de depuración más importante para errores 500. Te dicen exactamente qué salió mal, incluyendo la ruta del archivo, el número de línea y el mensaje de error. Siempre revisa los logs primero antes de intentar cualquier otra cosa.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Solución 2: verificar y reparar el .htaccess

Un archivo .htaccess roto es una causa clásica de errores 500 en Apache: una errata, una directiva que el servidor no admite o una RewriteRule incorrecta dejan fuera de servicio el directorio. El log de errores de Apache nombra el archivo .htaccess y la directiva incorrecta, por ejemplo Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

La prueba más rápida es renombrar el archivo temporalmente. Si el sitio carga tras renombrarlo, el problema era el .htaccess.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Solución 3: corregir los permisos de archivos

Los permisos causan un 500 cuando PHP no puede leer un archivo que incluye, o en hosts con suPHP/suEXEC que rechazan los archivos que cualquiera puede modificar. Lo habitual es 644 para archivos y 755 para carpetas. No uses nunca 777: es un riesgo de seguridad y, en hosts con suEXEC/suPHP, provoca un 500 por sí solo.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Solución 4: aumentar la memoria y los límites de ejecución de PHP

PHP detiene los scripts que superan el límite de memoria o el tiempo máximo de ejecución, y el visitante recibe un 500. Los valores por defecto, 128M de memoria y 30 segundos, suelen quedarse cortos para páginas pesadas.

Súbelos donde tu servidor los lee. Con PHP-FPM, edita el php.ini de FPM (por ejemplo /etc/php/8.3/fpm/php.ini) y recarga php-fpm; los cambios en .user.ini pueden tardar hasta 5 minutos en aplicarse.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Solución 5: desactivar plugins y tema (CMS)

Si usas WordPress, Joomla u otro CMS, un plugin o tema defectuoso es una de las causas más comunes de errores 500. La forma más rápida de comprobarlo es desactivar todos los plugins a la vez y luego reactivarlos uno por uno.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Solución 6: verificar la conexión y reparar la base de datos

Un error 500 puede ocurrir cuando la aplicación no puede conectarse a su base de datos. Esto sucede cuando las credenciales son incorrectas, el servidor de base de datos está caído o las tablas están corruptas.

Primero verifica las credenciales de tu base de datos en el archivo de configuración (wp-config.php para WordPress, .env para Laravel). Luego prueba la conexión y repara las tablas corruptas si es necesario.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Solución 7: verificar la compatibilidad de la versión de PHP

El código escrito para una versión antigua de PHP puede dar errores fatales en una más nueva (o al revés). Tras actualizar PHP, lo habitual son las funciones eliminadas y los comportamientos que cambiaron; las funciones obsoletas solo generan avisos.

Comprueba qué versión de PHP usa realmente tu sitio. php -v en la línea de comandos puede mostrar un PHP distinto del que usa tu sitio, así que mira también en el panel de tu hosting o en una página phpinfo() temporal:

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Solución 8: verificar el espacio en disco

Cuando a un servidor se le acaba el espacio en disco (o los inodos), no puede escribir logs, archivos temporales ni datos de sesión, y las peticiones empiezan a fallar con 500.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs 502 vs 503 vs 504: ¿cuál es la diferencia?

La clave: 500 = el servidor falló internamente. 502 = el proxy recibió basura del backend. 503 = el servidor está vivo pero ocupado. 504 = el proxy se cansó de esperar. Puedes comprobar el código de estado exacto que devuelve tu servidor con el Verificador de encabezados HTTP de DNS Robot.

Si el error es un 502, la aplicación puede estar bien y el problema estar entre el proxy y la aplicación. Nuestra guía del 502 Bad Gateway cubre ese caso.

Cómo afectan los errores 500 al SEO

La propia documentación de Google describe lo que ocurre (documentación de Google sobre sus rastreadores):

• El rastreo se ralentiza. Ante errores 5xx, Google reduce el ritmo de rastreo del sitio, en proporción al número de URL que devuelven errores.
• Las páginas indexadas se mantienen al principio. Las URL ya indexadas se conservan un tiempo, pero las que devuelven un error de servidor de forma persistente se eliminan.
• La recuperación es gradual. Cuando el servidor vuelve a responder con 2xx, Google va aumentando el rastreo poco a poco.
• Usa 503 para una parada planificada de un día o dos, con una cabecera Retry-After (Google), para que la parada se lea como temporal (guía del 503).

Cómo prevenir los errores 500

La prevención siempre es mejor que la depuración. Sigue estas mejores prácticas para minimizar el riesgo de errores 500 en tu sitio web.

• Configura monitorización de uptime — Usa herramientas como UptimeRobot o Pingdom para verificar tu sitio cada 1-5 minutos. Recibe alertas instantáneas cuando ocurra un error 500.
• Siempre prueba los cambios en staging — Nunca despliegues directamente a producción. Prueba las actualizaciones de plugins, las actualizaciones de PHP y los cambios de configuración en un entorno de staging primero.
• Usa control de versiones (Git) — Haz commit de cada cambio para poder revertir instantáneamente un despliegue malo con un solo comando.
• Implementa manejo de errores adecuado — Envuelve las consultas a la base de datos y las llamadas a APIs en bloques try-catch. Registra las trazas de pila completas del lado del servidor para cada error.
• Monitoriza el espacio en disco y los recursos del servidor — Configura alertas para uso de disco por encima del 80%, CPU alta y presión de memoria.
• Mantén el software actualizado — Las versiones desactualizadas del CMS, plugins y software del servidor contienen errores conocidos que causan bloqueos.
• Mantén copias de seguridad automatizadas — Prueba tu procedimiento de restauración regularmente. Una copia de seguridad que nunca has probado no es una copia de seguridad.
• Configura los límites de PHP apropiadamente — Configura memory_limit y max_execution_time basándote en tu carga de trabajo real, no en los valores predeterminados.
• Usa pipelines CI/CD — Automatiza las pruebas antes del despliegue. Si las pruebas fallan, el despliegue no debe proceder.