Quién dice en realidad "bad gateway"
El código de estado lo genera lo que sea que esté delante de tu aplicación, no la aplicación misma. Una petición viaja visitante → edge del CDN → tu servidor de origen → (a menudo) tu servidor de aplicación, y cualquier salto que haga de proxy hacia el siguiente puede producir un 502 sobre el salto que viene después. Eso importa porque la página que estás viendo la escribe el proxy: si tu aplicación hubiera respondido, aunque fuera con un error, estarías viendo tu propia página 500 en su lugar.
Así que un 502 es una afirmación sobre una conversación que falló, y la pregunta útil es siempre la misma: ¿qué dos máquinas estaban hablando, y qué salió mal entre ellas?
502 vs 504: la distinción que todos se saltan
Estos dos se usan indistintamente en artículos de blog y no deberían.
504 Gateway Timeout significa que el proxy conectó bien y luego esperó. Tu origen aceptó la petición y nunca terminó de responder dentro del tiempo límite. Las causas habituales son una consulta lenta a la base de datos, una llamada a una API externa sin su propio timeout, o un pool de procesos lleno y en cola.
502 Bad Gateway significa que no hubo ninguna respuesta utilizable que esperar. La conexión fue rechazada, o fue aceptada y luego cortada, o los bytes que volvieron no eran una respuesta HTTP válida.
Si estás viendo 504, mira cuánto tarda tu aplicación. Si estás viendo 502, mira si tu aplicación está respondiendo siquiera.
Causa 1 — el origen rechazó la conexión
El proxy abrió una conexión TCP a tu origen y obtuvo un rechazo inmediato o ninguna ruta en absoluto. No había nada escuchando en ese puerto, o un firewall descartó el paquete.
Qué lo produce en la práctica: el servidor web o el contenedor está detenido; está escuchando en 127.0.0.1 en lugar de en la interfaz pública; el puerto en la configuración de tu origen no coincide con el puerto en el que está el servicio; un firewall del host o un grupo de seguridad bloquea las direcciones IP del CDN.
Cómo confirmarlo. Desde fuera de tu propia red, pregúntale al origen directamente y envía la cabecera Host que usa tu sitio — un origen que sirve varios sitios de lo contrario responderá por el equivocado o rechazará:
curl -sI -H "Host: example.com" http://ORIGIN_IP/
Si ese curl falla de la misma manera, el CDN está reportando la verdad y la solución está en el origen. Si ese curl tiene éxito mientras el edge ve un rechazo, la diferencia casi siempre es una regla de firewall que te permite a ti y no al edge.
Causa 2 — el origen cerró la conexión antes de tiempo
La conexión fue aceptada, y luego murió antes de que volviera una respuesta completa. Este es el 502 más común en stacks de PHP y Node bajo carga.
Qué lo produce: un pool de PHP-FPM con todos los workers ocupados, de modo que las conexiones nuevas las acepta el backlog del kernel y luego se descartan; un worker que alcanzó su límite de memoria y fue matado a mitad de la respuesta; un proceso de aplicación que colapsó en esa petición concreta; un desajuste de keepalive donde el origen cierra las conexiones inactivas antes de lo que el proxy espera para reutilizarlas.
Cómo confirmarlo. Mira el propio registro de errores del origen en el momento del 502 — este es el único caso en el que el origen tiene una historia clara que contar. Un Premature end of script headers, una línea de segfault, o un aviso de PHP-FPM server reached pm.max_children nombran la causa directamente. Si los 502 se concentran en los picos de tráfico en lugar de aparecer al azar, estás ante un agotamiento del pool, no un error.
Causa 3 — la negociación TLS con el origen falló
Si el proxy habla con tu origen por HTTPS, la negociación puede fallar por razones que no tienen nada que ver con el certificado que ven tus visitantes. El edge tiene el certificado público; la conexión detrás de él es una conversación aparte con su propio certificado.
Qué lo produce: el certificado del origen caducó y nadie se dio cuenta porque el certificado público se renueva automáticamente; el origen sirve varios nombres y necesita SNI para elegir el correcto; el origen solo acepta versiones de TLS o cifrados que el proxy no ofrece; el certificado cubre www.example.com pero el proxy conecta pidiendo example.com.
Cómo confirmarlo.
openssl s_client -connect ORIGIN_IP:443 -servername example.com </dev/null | head -20
Lee la cadena y las fechas. En cdn.com.tr el edge envía SNI al origen, así que un certificado válido para el hostname que configuraste negociará; uno que solo sea válido para el vhost por defecto no lo hará.
Causa 4 — la respuesta no era HTTP válido
Más rara, y satisfactoria de encontrar. El origen respondió, pero lo que volvió no se pudo interpretar: una línea de cabecera más larga que el búfer del proxy, una línea de salida suelta impresa antes de las cabeceras (un aviso de PHP, una marca de orden de bytes en un archivo incluido), una respuesta que declara un Content-Length que no coincide con el cuerpo, o un volcado de fallo en texto plano servido por el puerto 443.
Cómo confirmarlo. Consulta el origen directamente y mira los bytes en crudo en lugar de una página renderizada:
curl -sv -H "Host: example.com" http://ORIGIN_IP/ -o /dev/null
Si la primera línea de vuelta no es HTTP/1.1 ..., lo has encontrado. La solución está en tu aplicación o en su almacenamiento en búfer de salida, y el proxy tenía razón al rechazarlo.
Qué hacer cuando un CDN está delante
Un CDN cambia el diagnóstico de dos maneras útiles.
Las páginas cacheadas siguen sirviéndose. Un visitante que pide algo que ya está en la caché del edge lo recibe incluso mientras el origen está caído, así que un 502 parcial — algunas páginas rotas, otras bien — suele significar que el origen está en pie pero falla en las rutas no cacheadas, que normalmente son las dinámicas.
Ganas un segundo punto de vista. El edge ve tu origen desde fuera, continuamente. Si el edge reporta 502 y tu propio navegador alcanza el origen, la diferencia entre esas dos peticiones es el error: un firewall que te permite a ti, un registro DNS que apunta a otro sitio en tu caso, o un certificado que solo coincide con el nombre que tú resulta que estás usando.
En cdn.com.tr, las reglas de entrega te permiten mantener un TTL de caché más largo en las rutas que pueden tolerarlo, que es lo que convierte un incidente de origen en un sitio degradado en lugar de uno muerto. Eso merece configurarse antes de necesitarlo, no durante.
El 502 que no tiene nada que ver con tu origen
Un caso merece mención propia porque hace perder horas. Si tu DNS apunta a un edge de CDN pero el hostname todavía no se ha configurado en ese edge, no vas a obtener un 502 — vas a obtener un 503 con una página que dice que no hay ningún servicio configurado para este dominio. Eso es el edge diciéndote que no tiene ni idea de a qué origen preguntar.
La gente ve una página de error justo después de cambiar el DNS, asume que el origen está roto, y empieza a reiniciar servicios que nunca estuvieron implicados. Comprueba primero el código de estado: 502 significa que el edge probó tu origen y falló; ese tipo de 503 significa que el edge nunca tuvo un origen que probar.
Preguntas frecuentes sobre 502 Bad Gateway
¿Un 502 es culpa mía o del CDN?
Normalmente ninguno de los dos — es del origen. El CDN reporta el fallo que experimentó; no se lo inventa. La excepción que merece comprobarse es la conectividad: si el firewall del origen bloquea las direcciones IP del edge, el origen está sano para ti e inalcanzable para el CDN, y la solución es una regla de permiso en lugar de algo en la aplicación.
¿Por qué me sale un 502 solo a veces?
Los 502 intermitentes casi siempre significan capacidad, no configuración. Un pool de procesos lleno durante los picos, un worker que se está reciclando, o un origen que cierra las conexiones keepalive antes de lo que el proxy espera, producirán errores que van y vienen mientras una prueba sencilla desde tu portátil pasa siempre.
¿Sirve de algo actualizar la página?
Te dice algo. Si al actualizar funciona, el fallo es intermitente y estás ante un problema de capacidad o de un worker concreto. Si cada actualización falla igual, es configuración — una conexión rechazada, un puerto equivocado, un certificado de origen caducado — y actualizar no lo va a cambiar.
¿Cómo distingo un 502 de un 504 sin ver el código de estado?
Por cuánto esperaste. Un 504 te hace esperar hasta el timeout, normalmente decenas de segundos, porque el proxy está esperando de verdad una respuesta. Un 502 suele llegar rápido, porque una conexión rechazada o rota falla al instante.
¿Puedo mostrarles a mis visitantes algo mejor que la página de error por defecto?
Sí, y deberías hacerlo. Un CDN sirve contenido cacheado desactualizado o una página de error de marca propia en lugar de la del proxy por defecto, lo que convierte una caída en una experiencia peor de lo habitual en lugar de una rota. Configúralo antes de un incidente, porque durante uno no te va a sobrar atención.