Errores HTTP: qué significan 500, 502, 503 y 504
Errores HTTP: qué significan 500, 502, 503 y 504
Cuando intentas entrar a una página y aparece una pantalla en blanco con un número grande y un mensaje en inglés, la reacción habitual es la confusión: ¿la página se cayó?, ¿es mi conexión?, ¿rompí algo yo? Esos números no son aleatorios: son códigos de estado HTTP, la forma estándar en la que un servidor web le comunica al navegador (y a ti) qué pasó con tu solicitud. Entender qué significa cada código convierte un problema misterioso en un diagnóstico concreto. Y aunque existen decenas de códigos, la gran mayoría de los errores que verás en un sitio web pequeño se reduce a cuatro: 500, 502, 503 y 504. En este artículo explicamos qué son los códigos HTTP, qué indica cada uno de esos cuatro errores, en qué se diferencian y qué pasos puedes seguir para solucionarlos.¿Qué son los códigos de estado HTTP?
Cada vez que abres una página, tu navegador envía una solicitud HTTP al servidor donde está alojado el sitio. El servidor procesa esa solicitud y responde con un código de tres dígitos que resume el resultado: si todo salió bien, si la página se movió de dirección, si la solicitud estaba mal hecha o si el servidor no pudo completarla. Esos códigos están definidos en estándares abiertos mantenidos por el IETF y se agrupan por el primer dígito. Esa primera cifra no es un detalle menor: te dice de inmediato de qué lado está el problema. Los códigos que empiezan por 4 señalan que algo falló en la solicitud que enviaste; los que empiezan por 5, que el fallo está del lado del servidor. Esa distinción es la clave para no perder tiempo buscando el problema en el lugar equivocado.Los cinco grupos de códigos HTTP
Existen cinco grupos, y conocerlos te permite interpretar cualquier código que encuentres, aunque no lo hayas visto antes:- 1xx: informativos. El servidor recibió la solicitud y sigue procesándola. Son temporales y rara vez los verás como usuario.
- 2xx: éxito. La solicitud se procesó correctamente. El más conocido es el 200 OK, que significa que la página se cargó sin problemas.
- 3xx: redirecciones. El recurso se movió y el navegador debe ir a otra dirección. Ejemplos típicos son el 301 (movido permanentemente) y el 302 (movido temporalmente).
- 4xx: errores de cliente. El servidor entendió la solicitud, pero no puede cumplirla porque el error está en lo que se pidió. El más famoso es el 404 (página no encontrada), junto con el 400 (solicitud incorrecta) y el 403 (acceso prohibido).
- 5xx: errores de servidor. El servidor falló al intentar cumplir una solicitud que, en principio, era válida. Aquí viven el 500, el 502, el 503 y el 504, los protagonistas de este artículo.
Los códigos más comunes y qué significan
Antes de entrar en detalle con los errores 5xx, vale la pena tener una visión completa de los códigos que más aparecen en la práctica. Esta tabla resume los siete que verás con más frecuencia:| Código | Significado | Causa común | Solución básica |
|---|---|---|---|
| 200 | Éxito: la página se cargó correctamente. | Ninguna; es la respuesta normal. | No requiere acción. |
| 301 | Redirección permanente a otra URL. | La página cambió de dirección. | Actualiza enlaces y marcadores a la nueva URL. |
| 404 | No se encontró el recurso solicitado. | URL mal escrita, enlace roto o página eliminada. | Corrige o redirige el enlace; revisa la ortografía de la URL. |
| 500 | Error interno del servidor. | Fallo en el código, en la configuración o en los permisos. | Revisa los registros de error y la última actualización. |
| 502 | Respuesta inválida de un servidor intermedio o superior. | El servidor de aplicaciones o PHP-FPM se detuvo. | Reinicia los servicios y verifica que estén activos. |
| 503 | Servicio no disponible temporalmente. | Mantenimiento, sobrecarga o límites de recursos. | Espera, revisa el uso de recursos o reactiva el sitio. |
| 504 | La puerta de enlace agotó el tiempo de espera. | Un script o un proceso tarda demasiado en responder. | Aumenta el tiempo límite u optimiza el proceso lento. |
500 Internal Server Error: el servidor falló por dentro
El error 500 Internal Server Error es el más genérico de todos. El servidor recibió una solicitud válida, intentó procesarla y falló por una razón que él mismo no puede especificar. Por eso el mensaje es tan poco útil: es la forma que tiene el servidor de decir que algo se rompió y no sabe exactamente qué. En sitios web pequeños, las causas más frecuentes son errores de programación, como un error de sintaxis en PHP o un plugin incompatible con la versión actual de la plataforma; archivos de configuración dañados, como un .htaccess con una directiva inválida; permisos incorrectos en archivos o carpetas; o un límite de memoria del servidor que se agotó al procesar una tarea pesada. También es común que aparezca justo después de una actualización: se actualizó el tema, el plugin o el núcleo del sitio y algo dejó de ser compatible. Qué hacer ante un 500:- Identifica cuándo empezó. Si el error apareció tras una actualización o un cambio reciente, el culpable más probable es ese cambio.
- Revisa los registros de error (logs). En la mayoría de los paneles de hosting encontrarás los logs de error del sitio. Allí suele aparecer la línea exacta del archivo que falla.
- Activa la visualización de errores temporalmente si tienes acceso al código, solo en un entorno de desarrollo: te indicará el archivo y la línea del problema.
- Comprueba los permisos de archivos y carpetas, y el contenido del archivo .htaccess.
- Reinicia el servicio de tu sitio (Apache, PHP-FPM o el servicio de aplicaciones) desde el panel de control.
- Si el sitio está en un hosting compartido y no encuentras la causa, contacta al soporte y envíale el error tal como aparece, junto con la hora en que empezó.
502 Bad Gateway: el mensajero no logró comunicarse
El error 502 Bad Gateway indica un problema de comunicación entre dos servidores. La mayoría de los sitios web tienen una capa intermedia: un servidor proxy o una puerta de enlace (por ejemplo, Nginx) que recibe la solicitud del visitante y la reenvía al servidor que realmente genera la página (por ejemplo, Apache o PHP-FPM). Cuando ese servidor de aplicaciones no responde o responde de forma inválida, la puerta de enlace devuelve un 502. La diferencia clave con el 500 es que el sitio en sí puede estar perfectamente bien: el código no tiene errores. El problema es que el proceso que debería ejecutarlo se detuvo, se reinició a mitad de la petición o no está escuchando. Las causas típicas incluyen un PHP-FPM caído, un servidor de aplicaciones detenido, un reinicio en curso, un firewall que bloquea la conexión entre servicios o un pico de carga que dejó al proceso sin recursos. Qué hacer ante un 502:- Verifica que los servicios estén activos. Desde el panel de hosting comprueba que PHP-FPM, Apache o el servicio de aplicaciones esté en ejecución, y reinícialo si hace falta.
- Prueba de nuevo en unos minutos. Muchos 502 son transitorios y desaparecen solos cuando el servicio se reinicia.
- Revisa los logs del servidor y de errores para ver si algún proceso se cayó por falta de memoria o por una falla.
- Si usas un proxy o un CDN como Cloudflare, comprueba que el servidor de origen esté accesible y que el firewall no bloquee sus conexiones.
- Si los servicios se caen repetidamente, el problema suele ser de recursos: contacta al soporte del hosting para revisar los límites de tu plan.
503 Service Unavailable: el servicio no está disponible ahora mismo
El 503 Service Unavailable significa que el servidor está vivo y funcionando, pero no puede atender la solicitud en este momento. A diferencia del 500, aquí el servidor sí sabe por qué no responde: está en mantenimiento, está sobrecargado o se está reiniciando. Este código tiene dos caras. Una es legítima e incluso deseable: muchos sitios activan una página de mantenimiento que devuelve un 503 mientras se actualizan, para que los visitantes sepan que el sitio volverá y para que los buscadores no indexen una página a medio construir. La otra cara es la problemática: un pico de tráfico que supera la capacidad del servidor, un proceso que consume toda la memoria o una base de datos saturada que deja al sitio sin poder responder. Qué hacer ante un 503:- Comprueba si el mantenimiento es intencional. Si tú (o alguien de tu equipo) está actualizando el sitio, el 503 es normal: espera a que termine y retira el modo de mantenimiento.
- Revisa el uso de recursos. Entra al panel de hosting y mira el consumo de CPU, memoria y conexiones de los últimos minutos. Si está al límite, el servidor está rechazando solicitudes para no colapsar.
- Espera unos minutos antes de insistir. Si fue un pico de tráfico o un reinicio, el sitio debería volver por sí solo.
- Reinicia el servicio si el estado de sobrecarga se mantiene.
- Si el 503 aparece con frecuencia, tu plan de hosting se quedó corto: habla con el soporte sobre aumentar recursos o cambiar de plan.
504 Gateway Timeout: la espera se agotó
El 504 Gateway Timeout aparece cuando la puerta de enlace sí logró comunicarse con el servidor de aplicaciones, pero este tardó demasiado en responder y se superó el tiempo máximo de espera. En otras palabras: el servidor intermedio hizo la pregunta, esperó el tiempo permitido y, al no recibir respuesta, le dijo al navegador que el tiempo se acabó. Aquí está la diferencia práctica con el 502: en el 502 la respuesta es inválida o nunca llega; en el 504 la respuesta simplemente llega demasiado tarde. Eso suele significar que hay un proceso lento detrás: un script que tarda más de lo que permite la configuración (por ejemplo, el tiempo máximo de ejecución de PHP), una consulta muy pesada a la base de datos, un servicio externo que no responde o un servidor saturado que pone cada petición en una cola larga. Qué hacer ante un 504:- Vuelve a cargar la página. Si el sitio responde en la segunda o tercera carga, el problema fue un pico puntual.
- Identifica el proceso lento. Revisa los logs y las consultas lentas de la base de datos: suele haber un script concreto que se ejecuta durante mucho tiempo.
- Aumenta los tiempos límite. Si usas Nginx como proxy, revisa directivas como proxy_read_timeout o fastcgi_read_timeout, y también el tiempo máximo de ejecución de PHP. Hazlo con cuidado: alargar el límite no arregla la causa, solo da más tiempo.
- Optimiza antes que parchear. Una consulta que tarda sesenta segundos se soluciona mejor con un índice en la base de datos o con una caché que con un límite de trescientos segundos.
- Si no tienes acceso a esa configuración, el soporte del hosting puede ayudarte a ajustar los tiempos o a identificar el proceso que satura el servidor.
Cómo diferenciar los cuatro errores 5xx
Cuando tu sitio muestra un error 5xx, esta regla rápida te ayuda a ubicar el problema:- 500: el servidor falló al ejecutar la aplicación. Revisa el código, los logs y la última actualización.
- 502: la puerta de enlace no obtuvo una respuesta válida del servidor de aplicaciones. Reinicia y verifica los servicios.
- 503: el servidor está disponible pero no puede atender ahora. Suele ser mantenimiento o sobrecarga.
- 504: la puerta de enlace obtuvo una respuesta, pero demasiado tarde. Busca el proceso lento y aumenta u optimiza los tiempos.
Orden de actuación ante un error 5xx
Si no sabes por dónde empezar, sigue este orden: cubre primero los casos más probables y deja el soporte del hosting como último recurso, no como primera opción.- Comprueba si el error es general. Prueba desde otra red, desde el móvil o en una ventana de incógnito. Si solo te falla a ti, puede ser un problema local (incluso una caché del navegador que guardó la página de error).
- Reinicia. Detén y vuelve a iniciar el servicio de tu sitio desde el panel de hosting. Una porción importante de los errores 5xx se resuelve con un reinicio.
- Revisa los logs. Los registros de error del panel suelen señalar el archivo y la línea exacta del problema.
- Revisa los recursos. La CPU y la memoria al límite explican muchos errores 502, 503 y 504.
- Deshaz el último cambio. Si el error llegó después de una actualización, vuelve a la versión anterior de ese plugin, tema o configuración.
- Contacta al soporte del hosting con toda la información: qué error ves, desde cuándo, qué cambiaste antes y qué dicen los logs. En un hosting compartido, algunos ajustes (como los tiempos de proxy o la configuración del servidor) solo los puede tocar el proveedor.