500 Internal Server Error

Qué significa este error y cómo reconocerlo

• El navegador muestra una página en blanco, genérica o personalizada con el mensaje 500 Internal Server Error.
• Una página que funcionaba anteriormente falla después de editar código, instalar o actualizar un plugin o tema, realizar un despliegue o cambiar la configuración.
• Solo fallan ciertas URL, formularios, pantallas de administración o funciones del sitio, mientras el resto permanece disponible.
• Un log de PHP, de la aplicación o del servidor web registra un error fatal, un error de sintaxis, un problema de permisos, una dependencia ausente o un fallo por límite de recursos al mismo tiempo.
• Repetir la solicitud produce la misma respuesta 500, aunque pueden producirse fallos intermitentes cuando intervienen un límite de recursos o una dependencia de la aplicación.

Causas principales, ordenadas por probabilidad

1. Fallo del código de la aplicación, plugin, tema o módulo — Un error de sintaxis, un error fatal, una actualización incompatible o una condición no gestionada pueden impedir que la solicitud se complete.
2. Configuración de Apache no válida — Una directiva incorrecta o no compatible en .htaccess, o una regla que requiere un módulo desactivado, puede provocar una respuesta 500. .htaccess se aplica a configuraciones basadas en Apache, no a todos los servidores web.
3. Permisos o propiedad incorrectos de archivos o directorios — Las cargas manuales, las migraciones y los despliegues pueden impedir que el proceso web lea los archivos necesarios.
4. Agotamiento de la memoria o del tiempo de ejecución de PHP — Las importaciones grandes, las consultas costosas o las extensiones que consumen muchos recursos pueden superar los límites configurados; algunos entornos devuelven 500 cuando sucede.
5. Configuración o dependencias ausentes del despliegue — Un cambio en las credenciales de la base de datos, una variable de entorno ausente, un paquete no disponible o un runtime incompatible pueden romper la aplicación.
6. Archivos incompletos o dañados de la aplicación o del CMS — Una actualización interrumpida puede dejar archivos principales necesarios ausentes o dañados.

Cómo solucionarlo

1. Confirma el alcance y la hora

Vuelve a cargar la URL exacta que devuelve 500 y registra la hora, incluida la zona horaria. Comprueba si falla todo el sitio o solo una ruta, un formulario, una pantalla de administración, una función de plugin o un tipo de solicitud. Un fallo específico de una función hace más probables sus cambios recientes de código y dependencias; un fallo de todo el sitio apunta más a la configuración del servidor, el despliegue o los archivos principales.

2. Comprueba primero los logs relevantes

Revisa el error_log de PHP, el log de errores del servidor web y el log de la aplicación o del CMS disponible en el alojamiento. Algunas ubicaciones habituales son /var/log/apache2/error.log para Apache y /var/log/nginx/error.log para Nginx, pero la estructura varía según el alojamiento. Compara las entradas con la hora del fallo y registra el archivo, el número de línea, la excepción, el mensaje del upstream o la directiva de configuración. La página genérica del navegador por sí sola no basta para identificar la causa.

3. Aísla un cambio reciente de código o extensión

Si el log identifica un archivo, plugin, tema, módulo o cambio de despliegue, revierte ese cambio o desactiva el componente indicado en un entorno que permita probarlo. En un CMS, utiliza el área de administración cuando esté disponible. Si no puedes acceder al área de administración, SFTP o el administrador de archivos del alojamiento pueden permitirte cambiar el nombre del directorio del componente relevante. Cambia un componente cada vez y vuelve a probar la URL que falla. Si el error desaparece, investiga la compatibilidad, la configuración y las actualizaciones disponibles antes de volver a activarlo.

4. Prueba .htaccess solo en Apache

Si el log apunta a un error de análisis de .htaccess o el fallo comenzó después de cambiar una regla de Apache, haz una copia de seguridad y cambia temporalmente el nombre de .htaccess a .htaccess.bak mediante SFTP o el administrador de archivos del alojamiento. Vuelve a probar la página. Si funciona, restaura o recrea el archivo con cuidado y añade las directivas personalizadas de forma gradual. Una directiva no compatible o la ausencia de un módulo de Apache puede ser el problema subyacente. No apliques este paso en una configuración que solo use Nginx, donde .htaccess no se utiliza para configurar las solicitudes.

5. Corrige los permisos y la propiedad con cuidado

Cuando el log indique un fallo de permisos o propiedad, compara la ruta afectada con un archivo que funcione o con la configuración documentada por el proveedor de alojamiento. 644 para archivos y 755 para directorios son valores habituales, pero los valores correctos dependen del alojamiento y del modelo de despliegue. Corrige la ruta afectada mediante SFTP, SSH o el administrador de archivos del alojamiento, y no hagas que los archivos o directorios tengan permisos de escritura global como solución rápida.

6. Investiga los límites de recursos de PHP y de la aplicación

Si el log menciona agotamiento de memoria, tiempo máximo de ejecución o un límite similar, identifica la operación que consume el recurso, como una importación grande o una tarea costosa de un plugin. Ajusta memory_limit o max_execution_time en el php.ini, .user.ini, la configuración del alojamiento o la configuración del despliegue correspondiente solo si tu proveedor lo permite. También reduce la carga o corrige la operación ineficiente; aumentar únicamente el límite puede posponer el fallo, pero no solucionarlo.

7. Compara la configuración del despliegue y los archivos necesarios

En los fallos que comenzaron después de un despliegue o una migración, compara las variables de entorno, las credenciales de la base de datos, las versiones del runtime, las dependencias instaladas, las rutas de los archivos y la configuración generada con el entorno que funciona. Confirma que los archivos necesarios estén presentes y que la aplicación pueda conectarse a la base de datos o al servicio configurado. Utiliza como punto de partida la variable, el paquete o el error de conexión ausente que aparece en el log, en lugar de cambiar configuraciones no relacionadas.

8. Restaura los archivos dañados solo después de conservar las pruebas

Si se indica que hubo una actualización incompleta o un archivo principal dañado, guarda el log relevante y una copia de los archivos actuales antes de realizar reparaciones. Después, restaura archivos válidos o vuelve a ejecutar el proceso de actualización compatible con la plataforma, utilizando una copia de seguridad cuando esté disponible. Vuelve a probar la URL original y comprueba que no se esté escribiendo en el log ningún error nuevo coincidente.

Prevención y cómo verificar la solución

• Haz una copia de seguridad tanto de los archivos como de la base de datos antes de instalar o actualizar un plugin, tema, módulo o componente del CMS.
• Prueba los cambios de código y .htaccess en una copia de staging cuando sea posible y conserva una configuración válida para poder revertirlos.
• Despliega las variables de configuración y las dependencias de forma coherente entre entornos, y verifica los archivos necesarios después de las migraciones.
• Supervisa los logs de errores de PHP, de la aplicación y del servidor web en lugar de depender únicamente de comprobaciones externas de disponibilidad.
• Haz un cambio cada vez, registra lo que ha cambiado y vuelve a probar la URL exacta que fallaba.
• Mantén los diagnósticos detallados en los logs del servidor en lugar de mostrarlos a los visitantes en un sitio en producción.

Preguntas frecuentes