Caídas de sitios web: errores de servidor 500, 502 y 504 y cómo solucionarlos

Las caídas de sitios web suelen producirse cuando el servidor no puede procesar una solicitud, cuando una capa intermedia no recibe una respuesta válida o cuando se supera el tiempo máximo de espera. El error 500 normalmente indica un fallo interno general relacionado con la aplicación o con la configuración del servidor; el error 502 señala que un proxy o gateway ha recibido una respuesta no válida desde el backend; y el error 504 significa que la respuesta del servidor de origen no llegó a tiempo. Para resolver el problema de forma estable no basta con recargar la página: hay que interpretar correctamente el código de error, revisar los logs del servidor, medir el consumo de recursos, depurar errores de PHP o de la aplicación, eliminar cuellos de botella en la base de datos y escalar la infraestructura de hosting según las necesidades reales de tráfico.

Para una persona que visita la web, estos errores se traducen en una página en blanco, una tienda que no carga o un sitio inaccesible. Para una empresa, en cambio, pueden significar ventas perdidas, pérdida de confianza y señales SEO debilitadas. En proyectos con baja tolerancia a la interrupción, como tiendas online, sitios corporativos, portales de noticias o sistemas de reservas, los errores 5xx pueden convertirse en pérdida de ingresos en cuestión de minutos. En esta guía veremos cómo distinguir los errores 500, 502 y 504, cómo hacer un diagnóstico rápido y qué medidas aplicar para evitar que el problema se repita.

¿Por qué hay que tomarse en serio las caídas de sitios web?

Una caída web no es solo una incidencia técnica. Afecta directamente a la experiencia de usuario, a la tasa de conversión, a la percepción de marca y a la visibilidad en buscadores. Google suele tolerar interrupciones puntuales de corta duración; sin embargo, los errores 5xx recurrentes pueden desperdiciar presupuesto de rastreo, hacer que las páginas importantes se rastreen con menos frecuencia y provocar fluctuaciones en los rankings.

En la práctica, los errores 5xx deben abordarse en dos niveles. El primero es la intervención urgente: devolver la web a un estado accesible. El segundo es el análisis de causa raíz: descubrir por qué el mismo fallo vuelve a aparecer cuando aumenta el tráfico, cuando se ejecuta un cron, después de actualizar un plugin o cuando crece la carga de la base de datos. Reiniciar un servicio puede dar un alivio temporal, pero si el origen del problema no se corrige, el error puede regresar unas horas después.

Por ejemplo, en una tienda basada en WooCommerce, durante una campaña el uso de CPU puede subir al 95 %, la cola de PHP-FPM puede llenarse y la base de datos puede bloquearse con consultas lentas. En ese escenario, los visitantes podrían ver errores 500 o 504. Instalar únicamente un plugin de caché quizá no sea suficiente; conviene evaluar en conjunto la optimización de consultas, un plan de hosting más potente, CDN, caché de objetos y límites de recursos. Al revisar opciones de alojamiento para proyectos en crecimiento, se pueden comparar Paquetes de hosting web Hostragons y, para proyectos que necesitan más recursos, Hostragons Soluciones de servidor VPS.

Diferencias clave entre los errores 500, 502 y 504

Los errores 500, 502 y 504 pertenecen a la misma familia 5xx, pero no significan lo mismo. Un diagnóstico equivocado lleva a una intervención equivocada. La siguiente tabla resume de forma rápida las diferencias más habituales.

Esta distinción es especialmente importante en arquitecturas con Nginx, Apache, LiteSpeed, PHP-FPM, Node.js, proxy inverso, CDN y balanceadores de carga. Un usuario puede ver un 502 en el navegador cuando el problema real es que el servicio PHP-FPM se ha detenido. Del mismo modo, un 504 puede no venir del servidor web, sino de una API externa de pagos que tarda más de 30 segundos en responder.

500 Internal Server Error: causas y pasos para solucionarlo

¿Qué significa el error 500?

El error 500 Internal Server Error indica que el servidor no ha podido procesar la solicitud, pero tampoco puede explicar el fallo con un código más específico. Por eso, el 500 abarca un abanico amplio de posibilidades. Puede aparecer en WordPress, Laravel, desarrollos PHP a medida, proyectos Python o aplicaciones Node.js por motivos muy distintos. Como el mensaje que ve el usuario ofrece poca información, las pistas reales suelen estar en los archivos de log.

Causas más frecuentes del error 500

• Reglas .htaccess incorrectas: Un RewriteRule mal escrito, una redirección infinita o directivas no soportadas pueden provocar un error 500.
• Error fatal de PHP: Una función inexistente, una versión de PHP incompatible, un límite de memoria superado o un tema/plugin defectuoso pueden detener la web.
• Permisos de archivos y carpetas: El servidor puede bloquear archivos PHP con permisos inseguros o incorrectos, como 777 en ubicaciones sensibles.
• Dependencias faltantes: Pueden faltar paquetes de Composer, módulos PHP o archivos de caché del framework.
• Límites de recursos del servidor: Superar CPU, RAM, procesos de entrada o límites de I/O puede interrumpir la solicitud antes de completarse.

¿Cómo se soluciona el error 500?

Lo primero es no actuar a ciegas: reconstruye la línea temporal de cambios. Si el fallo empezó después de actualizar un plugin, modificar un tema, cambiar la versión de PHP, añadir una regla .htaccess o durante un pico de tráfico, la causa se acota mucho. Después, sigue estos pasos:

• 1. Revisa los logs: En cPanel, Plesk o el panel de tu servidor, consulta el archivo error_log. Líneas como fatal error, memory exhausted, permission denied o syntax error suelen apuntar directamente al origen.
• 2. Revierte el último cambio: Desactiva el plugin, tema o fragmento de código añadido recientemente. En WordPress, renombrar temporalmente la carpeta de plugins permite hacer una prueba rápida.
• 3. Prueba el archivo .htaccess: Guarda el archivo con otro nombre de forma temporal y genera reglas predeterminadas. Si el error desaparece, el problema está en una redirección o en una regla rewrite.
• 4. Comprueba la versión y los límites de PHP: Si tu aplicación no es compatible con PHP 8.2, puede generar errores 500. Ajusta memory_limit, max_execution_time y post_max_size según las necesidades del proyecto.
• 5. Corrige permisos de archivos: Como práctica general, se usan permisos 755 para carpetas y 644 para archivos. Para casos especiales, conviene seguir las indicaciones del proveedor de hosting.
• 6. Planifica una restauración desde copia de seguridad: Si la web en producción está totalmente inaccesible, volver al último backup estable puede recuperar el servicio antes de completar el análisis de causa raíz. Aquí las copias de seguridad periódicas son fundamentales.

Si el error 500 se repite con frecuencia, no basta con mirar solo la aplicación. Conviene revisar cuántos procesos PHP se ejecutan al mismo tiempo, cuál es el consumo medio de memoria, cuántas conexiones hay a la base de datos y si existe latencia en el I/O de disco. En entornos de hosting compartido, los límites de recursos pueden quedarse cortos a medida que el sitio crece. En esos casos, puede ser útil valorar Hosting WordPress Hostragons o planes con recursos más aislados.

502 Bad Gateway: cómo entender errores de proxy y upstream

¿Qué significa el error 502?

El error 502 Bad Gateway indica que la capa de gateway o proxy situada entre el cliente y el servicio backend no ha recibido una respuesta válida. En arquitecturas modernas de hosting, Nginx suele funcionar como proxy inverso: dirige peticiones PHP hacia PHP-FPM, solicitudes Node.js hacia el puerto de la aplicación o tráfico hacia otro servicio upstream. Si uno de los servicios de esa cadena está caído, saturado o apuntando a un puerto incorrecto, puede aparecer un error 502.

Causas típicas del error 502

• El servicio PHP-FPM se ha detenido o no se puede acceder al archivo socket.
• La aplicación Node.js, Python o Java no está escuchando en el puerto esperado.
• La definición upstream de Nginx usa una IP, puerto o ruta de socket incorrecta.
• El CDN o el firewall no consigue recibir la respuesta esperada del servidor de origen.
• La RAM del servidor se llena y los procesos del backend se cierran, dejando servicios inaccesibles.

Plan práctico para solucionar un error 502

Ante un 502, el primer objetivo es identificar qué capa de la cadena ha dejado de responder. El siguiente orden de revisión suele dar resultados rápidos en procesos reales de soporte técnico:

• Comprueba el estado de los servicios: Verifica que PHP-FPM, el servidor web, la base de datos y los servicios de la aplicación estén activos. En un VPS o servidor dedicado, puede revisarse con comandos como systemctl status.
• Compara logs del upstream: Revisa el log de errores de Nginx junto con los logs de PHP-FPM o de la aplicación en la misma marca de tiempo. Mensajes como connection refused, upstream prematurely closed connection o no live upstreams son pistas críticas.
• Observa el consumo de recursos: Si la RAM está por encima del 90 % y el sistema usa swap de forma intensa, los servicios pueden dejar de responder. Una carga de CPU muy superior al número de núcleos también genera colas.
• Valida sockets y puertos: Si la configuración de Nginx apunta a 127.0.0.1:9000 pero PHP-FPM escucha en otro socket, el 502 será prácticamente inevitable.
• Prueba la capa CDN: Omite temporalmente el CDN y accede directamente al servidor de origen. Si el problema solo aparece a través del CDN, hay que revisar DNS, SSL o ajustes de conexión al origin.

El error 502 también puede verse afectado por la configuración SSL. Si entre el CDN y el servidor de origen se usa HTTPS, pero el certificado del origin ha caducado o pertenece a otro dominio, pueden aparecer errores de gateway. Para configurar correctamente la capa SSL, se pueden revisar las opciones de Certificados SSL Hostragons y la guía guía de instalación del certificado SSL.

504 Gateway Timeout: cómo resolver de raíz los problemas de tiempo de espera

¿Qué significa el error 504?

El error 504 Gateway Timeout indica que la capa proxy o gateway no ha recibido respuesta del servicio backend dentro del plazo definido. Esto no significa necesariamente que el servicio esté apagado; puede estar funcionando, pero respondiendo demasiado lento. Por eso, el 504 suele apuntar a problemas de rendimiento, base de datos, APIs externas o procesos de larga duración.

Causas habituales del error 504

• Consultas lentas a la base de datos: La falta de índices, los escaneos de tablas grandes o los bloqueos incrementan el tiempo de respuesta.
• Retrasos de APIs externas: Si servicios de pago, logística, CRM o inventario responden lento, la petición web puede quedarse esperando.
• Latencia de red: Si la aplicación y la base de datos están en ubicaciones distintas, la latencia puede volverse crítica.
• Procesos cron o importaciones largas: Importaciones CSV, envíos masivos de correo o generación de informes pueden ralentizar peticiones en vivo.
• Ajustes de timeout insuficientes: Los valores de timeout en Nginx, Apache, PHP-FPM y la aplicación pueden no estar alineados.

¿Cómo corregir un error 504?

En un error 504, aumentar simplemente los valores de timeout suele ocultar el síntoma más que resolverlo. Por ejemplo, dar 120 segundos a una consulta que no termina en 30 segundos puede reducir el número de errores visibles, pero no mejora la experiencia de usuario. El enfoque correcto es medir dónde se produce la lentitud y acelerar ese punto.

• 1. Desglosa el tiempo de respuesta: Mide por separado el tiempo de aplicación, el tiempo de base de datos, el tiempo de APIs externas y el tiempo de espera del servidor.
• 2. Activa el slow query log: En MySQL o MariaDB, registra consultas que tarden más de 1 segundo. Añade índices a consultas lentas recurrentes o cambia su estructura.
• 3. Mueve tareas pesadas al segundo plano: La generación de informes, el procesamiento de imágenes, el envío de correos y la sincronización de stock deben ejecutarse mediante colas.
• 4. Usa caché: La caché de página, la caché de objetos y OPcache reducen considerablemente la carga de procesamiento en aplicaciones dinámicas.
• 5. Alinea los valores de timeout: proxy_read_timeout, fastcgi_read_timeout, max_execution_time y los timeouts de la aplicación no deben contradecirse entre sí.
• 6. Pon límites a las APIs externas: Si una API no responde, no dejes al usuario esperando indefinidamente. Usa estrategias de retry, fallback y timeouts cortos.

En un caso real, una página de listado de productos puede filtrar entre 60.000 artículos sin tener índice en el campo de categoría. Durante una campaña, eso puede multiplicar los errores 504. Añadir índices, cachear resultados de filtros y optimizar consultas pesadas puede resolver el problema incluso sin aumentar recursos. Si el crecimiento de tráfico es permanente, entonces sí puede ser necesario escalar la infraestructura.

Lista de comprobación de 10 pasos para un diagnóstico rápido

Cuando una web se cae de repente, actuar de forma desordenada hace perder tiempo. La siguiente lista ayuda a avanzar con método ante errores 500, 502 y 504:

• 1. Comprueba si el error afecta a todos o solo a ti: Prueba desde otra red, conexión móvil y herramientas externas de uptime.
• 2. Verifica el código de estado HTTP: Usa las herramientas de desarrollador del navegador o una comprobación como curl -I https://tudominio.com para ver el código real.
• 3. Lista los últimos cambios: ¿Hubo despliegue de código, actualización de plugins, cambio DNS, renovación SSL, cambio de versión PHP o modificación del servidor?
• 4. Revisa los logs del servidor web: Los registros de errores de Apache, Nginx o LiteSpeed son la primera fuente que conviene leer.
• 5. Analiza los logs de la aplicación: El debug log de WordPress, los logs storage de Laravel o los logs de procesos Node.js suelen indicar el origen del fallo.
• 6. Mide los recursos del servidor: CPU, RAM, espacio en disco, inodes, I/O de disco y número de conexiones deben evaluarse al mismo tiempo.
• 7. Comprueba la base de datos: ¿Se ha alcanzado el límite de conexiones? ¿Hay consultas bloqueadas? ¿Han aumentado las consultas lentas?
• 8. Prueba firewall y CDN: Reglas WAF, filtros antibot o la conexión del CDN con el origin pueden estar funcionando de forma incorrecta.
• 9. Ten preparado el backup: Si se dañó un archivo crítico o una actualización salió mal, necesitas un plan rápido de restauración.
• 10. Redacta un informe de causa raíz: Tras resolver la incidencia, documenta hora, impacto, causa, solución y medidas para prevenir la repetición.

Esta lista es especialmente útil cuando varias personas participan en la resolución. Al contactar con tu proveedor de hosting, compartir la hora del fallo, una URL de ejemplo, el código observado, el último cambio realizado y, si es posible, una captura de pantalla, reduce el tiempo de diagnóstico. Para problemas de acceso relacionados con dominio, DNS o redirecciones, recursos como Consulta de dominio y registro Hostragons y Guía de gestión de DNS también pueden ayudar en el proceso.

Cómo interpretar correctamente los recursos del servidor

Una parte importante de los errores 5xx está relacionada con cuellos de botella de recursos. Sin embargo, una CPU alta no siempre significa código malo; a veces el sistema se ve presionado por más tráfico orgánico del esperado, un ataque de bots, un cron defectuoso o una copia de seguridad pesada. Por eso, las métricas no deben leerse de forma aislada, sino junto con la línea temporal de eventos.

Métricas básicas que conviene vigilar

• Uso de CPU: Un uso sostenido por encima del 80 % aumenta el riesgo de colas y retrasos.
• RAM y swap: Si aumenta el uso de swap, los procesos se ralentizan y pueden dispararse errores 502 y 504.
• I/O de disco: Escritura intensiva de logs, copias de seguridad grandes o procesos de base de datos pueden generar espera de I/O.
• Entry process y conexiones concurrentes: En hosting compartido, los límites de procesos simultáneos pueden terminar en errores 500.
• Conexiones de base de datos: Acercarse al límite max_connections incrementa los errores de aplicación.
• TTFB: Un aumento sostenido del tiempo hasta el primer byte es una alerta temprana antes de errores 504.

Puedes usar un enfoque sencillo por umbrales: si en condiciones normales el TTFB está entre 300 y 600 ms, pero durante una campaña sube a 5 o 10 segundos, hay que planificar capacidad antes de que aparezcan los errores. La monitorización de uptime, el análisis de logs y la medición de rendimiento, usados en conjunto, permiten detectar el problema antes de que escale.

Medidas permanentes en aplicación, base de datos y hosting

Acciones en la capa de aplicación

La calidad y actualización del código son una de las mejores defensas contra las caídas de sitios web. Elimina plugins que no se usan, elige temas y extensiones de fuentes confiables y prueba la compatibilidad con la versión de PHP en un entorno de pruebas. Trabajar en staging en lugar de modificar directamente la web en producción permite detectar errores 500 antes de que lleguen a los usuarios.

• No muestres la depuración al usuario en producción; envíala a archivos de log.
• Antes de actualizar, realiza una copia completa de archivos y base de datos.
• Separa los procesos largos de la petición del usuario.
• Optimiza imágenes y reduce scripts innecesarios.
• Analiza el tráfico de bots; limita bots maliciosos o excesivos mediante WAF.

Acciones en la capa de base de datos

El rendimiento de la base de datos es crítico, especialmente en WordPress, WooCommerce, foros y sistemas de membresía. En sitios con miles de productos, pedidos, comentarios o registros de log, el crecimiento de tablas puede aumentar las consultas lentas. El mantenimiento periódico, la revisión de índices y la limpieza de registros innecesarios reducen el riesgo de errores 504.

• Identifica las consultas más costosas con el slow query log.
• Añade índices adecuados a columnas que se filtran con frecuencia.
• Limpia opciones innecesarias cargadas automáticamente.
• Archiva periódicamente revisiones antiguas, registros temporales y tablas de logs.
• Programa los backups de base de datos en horas de menor tráfico.

Acciones en la capa de hosting

Si la infraestructura de hosting no se elige correctamente, incluso una web bien optimizada puede sufrir en momentos de tráfico alto. Un sitio corporativo básico no tiene las mismas necesidades que una tienda online con mucho tráfico. Deben evaluarse juntos el volumen de visitas, el número de operaciones, la proporción de páginas dinámicas, el uso de correo, el tamaño de la base de datos y los requisitos de seguridad.

• Para sitios pequeños y medianos, pueden bastar planes de hosting fáciles de administrar.
• En sitios con muchas operaciones dinámicas, un VPS con CPU/RAM aisladas suele funcionar mejor.
• En proyectos corporativos, backups periódicos, SSL, WAF y monitorización de uptime deberían ser estándar.
• Los registros DNS deben mantenerse simples y deben eliminarse cadenas de redirección innecesarias.
• Si se usa CDN, el servidor de origen, SSL y las reglas de caché deben estar bien configurados.

Al hacer esta evaluación, mirar solo el espacio en disco puede ser engañoso. Un sitio que usa 2 GB de disco puede consumir más CPU que otro que usa 20 GB si tiene muchos usuarios simultáneos. Por eso, la elección del plan debe basarse en el tráfico real y en la carga de procesamiento, no únicamente en la capacidad de almacenamiento.

¿Qué hacer con los errores 5xx desde el punto de vista SEO?

Los motores de búsqueda no penalizan de inmediato los errores 5xx temporales; aun así, las interrupciones repetidas afectan al rastreo y a la indexación. Si Googlebot recibe con frecuencia respuestas 500, 502 o 504 en páginas importantes, puede reducir la frecuencia de rastreo. Además, si los usuarios hacen clic desde los resultados orgánicos y encuentran una página de error, se pierde confianza y conversión.

Para reducir el riesgo SEO, usa monitorización de uptime en páginas críticas, revisa las estadísticas de rastreo en Search Console y analiza en los logs del servidor los códigos de estado de las peticiones de Googlebot. Si vas a realizar un mantenimiento planificado, una respuesta 503 Service Unavailable breve y correctamente configurada es más saludable que un 500 inesperado. Incluir la cabecera Retry-After en la página de mantenimiento indica a los buscadores cuándo deberían volver a intentarlo.

Especialmente durante migraciones de sitio, cambios de dominio o transiciones a SSL, las redirecciones incorrectas y los problemas de certificado pueden causar incidencias de acceso similares a errores 5xx. Antes de migrar, es buena práctica reducir el TTL del DNS, hacer copias de seguridad, probar en un dominio de test y vigilar logs después del cambio.

¿Cuándo deberías contactar con el soporte de hosting?

Algunos errores pueden ser resueltos por la persona que administra la web; otros requieren acceso al servidor y experiencia técnica. Conviene contactar cuanto antes con el soporte de hosting en estos casos:

• El error afecta a todo el sitio y tampoco puedes acceder al panel de administración.
• En los logs aparecen líneas como permission denied, upstream failed o resource limit exceeded.
• PHP-FPM, el servidor web o la base de datos se caen continuamente.
• La web abre al desactivar el CDN, pero devuelve 502 o 504 con el CDN activo.
• Los límites de recursos se llenan con frecuencia y no está claro qué plan conviene.
• El acceso se rompe después de cambios en SSL, DNS o firewall.

Al abrir un ticket de soporte, incluir la siguiente información reduce mucho el tiempo de resolución: hora de inicio del fallo, URLs afectadas, código de error observado, últimos cambios realizados, captura de pantalla, líneas de log si las tienes y si el error es constante o intermitente. Estos datos ayudan al equipo técnico a reproducir el problema y revisar la capa correcta.

Preguntas frecuentes

¿Un error 500 significa que mi sitio ha sido hackeado?

No. Un error 500 por sí solo no indica que la web haya sido hackeada. La mayoría de las veces se debe a un error PHP, conflicto de plugins, regla .htaccess incorrecta, permisos de archivos o límite de recursos. Sin embargo, si el error aparece junto con cambios inesperados en archivos, redirecciones sospechosas o cuentas de usuario desconocidas, conviene realizar un análisis de seguridad.

¿El error 502 Bad Gateway puede deberse al usuario?

Por lo general, no. El error 502 suele indicar un problema de comunicación en la capa del servidor, proxy, CDN o servicio backend. El usuario puede limpiar la caché del navegador y probar desde otra red, pero si el error aparece para todo el mundo, la solución debe buscarse del lado del servidor.

¿Basta con aumentar el timeout para solucionar un 504 Gateway Timeout?

A veces proporciona un alivio temporal, pero no es una solución definitiva. En un 504, el objetivo principal es encontrar la causa raíz: consultas lentas, retrasos de APIs externas, uso intensivo de CPU o procesos demasiado largos. El aumento del timeout debe aplicarse con cuidado y junto con optimización de rendimiento.

¿Los errores 5xx bajan mis posiciones SEO de inmediato?

Las interrupciones breves y poco frecuentes normalmente no generan una pérdida permanente de rankings. Pero si los errores 5xx se repiten, las páginas importantes permanecen inaccesibles durante mucho tiempo o Googlebot recibe errores de servidor de forma regular, la frecuencia de rastreo y el rendimiento orgánico pueden verse afectados.

¿Cuál es el hábito más importante para prevenir caídas de sitios web?

El hábito más importante es combinar monitorización regular y gestión ordenada de cambios. Seguimiento de uptime, copias de seguridad, revisión de logs, pruebas en staging, software actualizado y vigilancia de métricas de recursos, aplicados en conjunto, permiten prevenir gran parte de los errores 500, 502 y 504 antes de que se conviertan en incidencias graves.

Resumen rápido y siguiente paso

Aunque los errores 500, 502 y 504 pertenecen a la misma familia, apuntan a capas distintas: el 500 suele indicar un problema de aplicación o configuración, el 502 un fallo de comunicación entre proxy y upstream, y el 504 un timeout o cuello de botella de rendimiento. La solución adecuada consiste en confirmar el código de error, leer logs, medir recursos, analizar los últimos cambios y aplicar optimizaciones permanentes.

Si en tu sitio se repiten las caídas de sitios web, conviene evaluar en conjunto los recursos de hosting actuales, la configuración SSL y DNS, y el rendimiento de la aplicación. Puedes revisar las soluciones de Hostragons o consultar opciones con el equipo técnico para elegir una infraestructura de alojamiento adecuada a tus necesidades; el objetivo es construir una experiencia web más rápida, segura y resistente a interrupciones.