Errores 500 en sitios web: diagnóstico y solución

Por qué un sitio web genera errores 500 y cómo solucionarlos: una guía práctica de diagnóstico

Un error 500 es el tipo de problema que hace que un sitio parezca roto sin decirte por qué. El navegador muestra un mensaje tajante, el visitante llega a un callejón sin salida y la falla real suele estar en otro sitio. Por eso entender por qué un sitio web genera errores 500 y cómo solucionarlos se convierte en una tarea de diagnóstico, no en un juego de adivinanzas, especialmente cuando buscas cómo solucionar error 500 en un sitio web sin perder tiempo en síntomas que se parecen pero no son iguales.

Empieza con una regla: no asumas que toda página de error fea es un verdadero 500 del lado del servidor. Un 502, un 503, un tiempo de espera del gateway o una página de proxy con la marca de Cloudflare pueden parecer lo bastante parecidos como para confundir incluso a equipos con experiencia. Una etiqueta incorrecta hace perder una hora, y entender por qué aparece error 500 interno del servidor ayuda a no perseguir el sistema equivocado desde el inicio.

1. Confirma que el error sea realmente un 500 del lado del servidor

Abre la página en una ventana privada y fíjate en el texto exacto. Un error de origen simple suele decir “500 Internal Server Error” o algo igualmente genérico, mientras que una capa de proxy puede mostrar su propio código, un ID de solicitud o un mensaje sobre el servidor upstream. Esa pequeña diferencia importa, porque un 502 suele apuntar a una mala respuesta del gateway, mientras que un 503 a menudo significa que el servicio no está disponible temporalmente.

Comprueba la respuesta por al menos 2 vías: el navegador y una solicitud desde la línea de comandos, si dispones de una. Si la página del navegador dice 500 pero el servidor realmente devuelve 502 en el borde, quizá estés persiguiendo el sistema equivocado. La solución cambia según el origen, y este primer paso forma parte esencial del diagnóstico de errores 500 en servidor web.

Cloudflare, Fastly, nginx, Apache y tu aplicación pueden registrar la falla de forma distinta. Un sitio puede mostrar una página pulida del CDN con una etiqueta 5xx, mientras otro devuelve una pantalla blanca sin formato y una línea corta en el cuerpo HTML. Mismo síntoma, distinto origen.

2. Reproduce el error de forma controlada

Prueba la URL exacta que falla, no solo la página de inicio. Un 500 en /checkout puede deberse a un campo de formulario, un hook de plugin o una regla de ruta, mientras que la portada funciona bien. Si el problema solo aparece en 1 URL, la búsqueda se acota mucho.

Repite la solicitud variando 3 cosas: navegador, dispositivo y momento. Si falla en Chrome en escritorio pero no en Safari móvil, podrías estar ante una ruta de script o un caso límite de caché. Si solo falla después de importar una newsletter o a las 2 a. m., el reloj también es una pista.

Haz la prueba sin complicarte. Una solicitud, un cambio, un resultado. Luego prueba la misma URL con un estado de sesión distinto, porque los usuarios autenticados a veces activan rutas de código que los invitados nunca tocan. Eso es especialmente común en sitios con paneles de administración o áreas de miembros.

Lleva un registro simple: URL, hora, acción y respuesta. Cuatro campos bastan. Cuando tengas 3 o 4 entradas, empezarán a verse patrones.

3. Revisa el registro de errores del servidor web para encontrar el primer punto de falla

El registro de errores suele ser el primer lugar al que mirar después de que la página falla dos veces. Haz coincidir la marca de tiempo del 500 con la entrada de registro más cercana y luego lee la línea anterior y la posterior. La primera línea suele decir más que la página de error.

Busca un nombre de script, un módulo, un aviso de permisos o un tiempo de espera del upstream. Un error fatal de PHP puede nombrar directamente el archivo. Un error del servidor web puede mencionar un directorio inexistente, un destino de rewrite incorrecto o una conexión denegada a un proceso backend.

Un hábito útil: copia la hora exacta de la solicitud fallida y compárala con los registros de acceso y de errores. Si el sitio está muy activo, el evento “más cercano” todavía puede estar desfasado unos segundos, así que revisa también la ruta de la solicitud y el código de estado. Un solo ID de solicitud, si tu pila lo añade, puede ahorrarte una búsqueda larga.

Cuando el registro mencione un plugin, una biblioteca o un módulo, detente ahí un momento. Lee el contexto alrededor. Una línea sobre “allowed memory size exhausted” apunta a límites de recursos, mientras que una línea de “permission denied” apunta a problemas de propiedad o modo, aunque ambos se muestren como 500.

4. Busca disparadores de límites de recursos y tiempos de espera

Los errores 500 suelen aparecer cuando el servidor se queda sin algo básico. La memoria es uno. El tiempo de ejecución es otro. Los cupos de workers son un tercero. Cuando cualquiera de ellos se satura, la solicitud puede fallar antes de que la página termine de construirse.

El agotamiento de memoria en PHP es un caso clásico. Una exportación de informes, un redimensionado de imágenes o una importación de productos puede pedir más memoria de la que el proceso tiene disponible, y el resultado puede ser un 500 en lugar de una advertencia amable. Si la falla empieza durante solicitudes grandes y desaparece cuando baja la carga, este es un sospechoso fuerte.

Comprueba también los límites de tiempo de ejecución. Un script que tarda demasiado en bucle puede agotar el tiempo y dejar al servidor limpiando el desorden. Eso puede pasar durante importaciones, tareas cron o una llamada lenta a una API que espera a otro servicio. Basta con una dependencia lenta.

La saturación de workers o procesos es más fácil de pasar por alto porque el sitio puede verse sano con poco tráfico. Luego llegan 20 solicitudes a la vez, la cola se llena y las nuevas peticiones empiezan a fallar. Algunos planes de hosting también imponen límites por cuenta en CPU, procesos de entrada o I/O, así que el problema puede estar en el plan mismo y no en el código.

Si tu pila tiene monitorización, revisa si los 500 aumentan con picos de tráfico. Un 500 que aparece solo durante una campaña, un despliegue o una ventana de copias de seguridad suele ser un problema de carga con otro nombre. Aquí es donde lo que cambió en la monitorización de sitios web después de puede ayudar a enfocar el tipo de alertas que necesitas a continuación.

5. Verifica permisos de archivos y carpetas fuera del CMS

No todos los 500 vienen de la aplicación. Los archivos pueden quedar propiedad del usuario equivocado después de un despliegue, una sincronización o una migración. Los permisos de las carpetas también pueden desviarse. Un solo cambio en el modo de un directorio puede bloquear escrituras en caché, registros o cargas y provocar una falla en tiempo de solicitud.

Revisa primero los lugares que la gente suele olvidar: cargas, archivos temporales, archivos de configuración, artefactos de despliegue y directorios de registros. Si una de esas rutas no es escribible por el usuario del servidor web, el sitio puede fallar en cuanto intente guardar un archivo de sesión o crear una entrada de caché. Es un problema pequeño con un resultado muy ruidoso.

Los problemas de propiedad son especialmente comunes después de migrar de un host a otro. Un archivo puede tener los bits de permiso correctos pero el propietario incorrecto, lo cual sigue bloqueando el proceso. Este es el tipo de detalle que hace que un 500 parezca irracional hasta que miras fuera del CMS e inspeccionas directamente la capa del servidor.

No “arregles” permisos abriendo todo de par en par. Un chmod 777 rápido puede ocultar el problema, pero también crea un lío de seguridad y normalmente tapa el verdadero desajuste de propiedad. Si necesitas una base de seguridad para el servidor después de cambios, la guía más amplia de seguridad del sitio web merece estar cerca mientras pruebas.

6. Revisa cambios recientes del servidor o del despliegue

Mira hacia atrás 1 despliegue, 1 cambio de host o 1 edición de configuración. Los 500 suelen empezar justo después de un cambio de versión de PHP, una reescritura del servidor web, una nueva regla de redirección o una actualización de un cron. Si el problema comenzó tras una migración, la migración en sí puede ser el desencadenante.

Los saltos de versión de PHP pueden sacar a la luz código antiguo que antes pasaba sin hacer ruido. Un módulo que funcionaba en una versión puede fallar en otra. Lo mismo ocurre con directivas del servidor web que el mes pasado se aceptaban pero ahora provocan un error cuando el servidor lee la configuración. Una sola línea puede causar el daño.

Las reglas de seguridad son otra causa frecuente. Una regla de WAF, una nueva condición de firewall o un cambio de endurecimiento del servidor pueden bloquear una solicitud que parece sospechosa, aunque sea legítima. Aquí es donde llevar un registro de cambios gana siempre a la memoria, porque la gente suele olvidar la actualización “pequeña” que rompió la ruta.

Si hubo un despliegue, compara la última versión que funcionaba con la actual. Revisa primero 3 cosas: archivos de configuración, reglas de enrutamiento y cualquier nueva tarea en segundo plano. El problema muchas veces no está en la funcionalidad que lanzaste, sino en el efecto secundario que se lanzó con ella.

7. Restaura el servicio con la reversión más pequeña y segura

La reversión debe ser limitada. Desactiva primero el cambio más reciente del lado del servidor, no todo el sistema. Revierte un archivo de configuración, una regla o un paso del despliegue a la vez para ver cuál movimiento devuelve el sitio. Si deshaces todo de golpe, pierdes la pista.

Empieza por el elemento de menor riesgo que cambió al final. Si apareció una nueva regla de redirección 20 minutos antes de la falla, coméntala y vuelve a probar. Si se alteró un ajuste de PHP, devuelve ese valor a su estado anterior y compruébalo de nuevo. El objetivo es restaurar el servicio, no hacer una limpieza espectacular.

Para despliegues de código, ten lista una copia segura y revierte solo la versión afectada. Para la configuración del servidor, guarda el archivo actual antes de editarlo para poder comparar línea por línea. Suena básico porque lo es, y lo básico evita las caídas más largas.

A veces la reversión mínima y segura no es técnica en absoluto. Si un cron está inundando el servidor cada 5 minutos, pausa la tarea y observa el sitio. Si un script de copias de seguridad está agotando recursos, mueve el horario antes de tocar la aplicación. Al sitio no le importa por qué el servidor está cansado.

8. Evita que el mismo 500 vuelva a aparecer

Configura monitorización de registros para que el primer 500 repetido se vea antes de que se quejen los clientes. Un único error aislado es una cosa. Cinco seguidos desde la misma ruta son un patrón. Haz que la alerta señale la ruta, la marca de tiempo y el texto del error.

Haz pruebas en staging antes de producción. Una copia de staging detecta malas ediciones de configuración y desajustes de versiones que de otro modo golpearían primero al tráfico real. Mantén la pila lo más parecida posible a producción, porque un ajuste del servidor que parece inocente en un entorno de prueba puede fallar en el real.

Lleva los cambios en un solo lugar. Eso incluye ediciones de configuración, actualizaciones de plugins, cambios de PHP, ajustes de cron y modificaciones de reglas de seguridad. Si ya estás documentando los cambios del sitio, el blog de ostohlo tiene material relacionado en el blog de ostohlo studio, que puede ser útil cuando necesitas un registro y no confiar en la memoria.

Las alertas importan más cuando se repiten. Si la misma respuesta 500 vuelve después de cada despliegue o de cada pico de tráfico, sube el umbral de revisión y deja una nota breve del incidente con 3 datos: qué cambió, dónde falló y qué lo solucionó. Esa nota se convierte en tu respuesta más rápida la próxima vez, sobre todo cuando el siguiente fallo llegue durante una ventana de despliegue que no esperabas.