¿Qué es el Error 502 (Bad Gateway)?

El 502 existe desde la primera especificación de HTTP/1.0, el RFC 1945 de mayo de 1996. Hoy lo define el RFC 9110, «HTTP Semantics», de junio de 2022, en su apartado 15.6.3, que sustituye a las versiones anteriores de HTTP/1.1.

Gateway y proxy son los dos papeles del servidor intermedio: recibe la petición del visitante, la reenvía a otro servidor, el de origen, y devuelve su respuesta. Una CDN, un balanceador de carga o un servidor web como nginx delante de PHP cumplen ese papel. Cada uno muestra el 502 con su propia página, pero el código es el mismo.

En una web moderna, una petición atraviesa varias capas: la CDN, a veces un balanceador, el servidor web y la aplicación, que a su vez consulta la base de datos. Cada capa es cliente de la siguiente. El 502 lo genera la capa que esperaba una respuesta y recibió algo que no puede usar: una conexión cortada, una respuesta vacía o incompleta.

Las causas que describen los fabricantes, cada uno en su documentación:

• El servidor de origen se ha caído, está sobrecargado o tiene un fallo de red, según la página de Cloudflare sobre los errores 502 y 504.
• La aplicación termina la conexión antes de responder. En nginx aparece en el registro como «upstream prematurely closed connection». Maxim Dounin, desarrollador de nginx, explicó en 2012 en la lista de correo del proyecto que suele deberse a un fallo del servidor de origen o a un proceso cortado por un límite de memoria, CPU o tiempo de ejecución.
• La pasarela no encuentra o no alcanza al servidor de origen, por ejemplo porque un DNS personalizado no resuelve su nombre o un sondeo de estado falla. Así lo describe Microsoft para Azure Application Gateway.
• El origen envía contenido comprimido roto o una longitud de contenido errónea. Según Cloudflare, eso produce un 502 generado por la propia Cloudflare.

El texto del error ayuda poco. Lo útil es saber qué capa lo ha generado, y hay tres pistas.

La primera son las cabeceras de la respuesta. La cabecera Server indica el software que respondió, y Via, según el RFC 9110, señala los intermediarios por los que pasó el mensaje. Cloudflare añade Cf-Ray, con el centro de datos que atendió la petición.

La segunda es la página de error. Cloudflare documenta que un 502 con su logotipo viene del servidor de origen, que se lo pasó así, y que una página en blanco sin logotipo la genera Cloudflare.

La tercera es el registro del servidor web. Si nginx anota que el origen cerró la conexión, el fallo está en la aplicación de detrás, no en nginx.

Una tienda con Cloudflare delante y nginx con PHP en el servidor muestra un 502 en todas las páginas de producto. La respuesta lleva Server: cloudflare y Cf-Ray, y la página tiene el logotipo de Cloudflare: el error viene del origen. En el registro de nginx aparece «upstream prematurely closed connection» a la misma hora, y en el de PHP, un proceso cortado por el límite de memoria: la causa está en la aplicación.

Otro caso: la misma tienda devuelve una página en blanco con 502, sin logotipo. Según Cloudflare, esa respuesta la genera su red, y una causa posible es una compresión defectuosa en el origen.

Desde la terminal, curl -I https://www.example.com/ muestra el código y las cabeceras Server, Via o Cf-Ray. Para saber si el problema está en la CDN o en el origen, hay que repetir la petición directamente contra el servidor de origen, sin pasar por la CDN.

En Google Search Console, el informe de indexación de páginas agrupa estos errores en «Server error (5xx)» (error del servidor). Los 502 esporádicos se ven mejor en las estadísticas de rastreo, en el estado del host: el gráfico de conectividad del servidor marca cuándo no respondió o no dio una respuesta completa.

Nadie elige un 502 como se elige un 503 para un mantenimiento: el 502 es un síntoma. Su única ventaja es diagnóstica. El código ya dice que el fallo está entre dos servidores, y con las cabeceras se acota en qué tramo.

Para el SEO, Google lo trata como cualquier error del servidor. Su documentación sobre códigos de estado describe 500, 502 y 503 con el mismo efecto: los rastreadores de Google reducen el ritmo, la guía para reducir la frecuencia de rastreo precisa que la bajada vale para todo el nombre de host, y las URL indexadas se conservan, «but eventually dropped». Para el 502 no da un plazo. Lo que pasa con un error del servidor que dura días está explicado en la entrada sobre el error 503.

Fuente: RFC 9110 (junio de 2022), apartados 15.6.3 y 15.6.5; Cloudflare, «Cloudflare 5xx errors», «Error 520» y «Error 521» (consultados el 12.11.2026).

El 500 es el fallo genérico del propio servidor, y el 503 dice que el servidor no puede atender ahora por sobrecarga o mantenimiento. Por ejemplo, si el cortafuegos del origen bloquea las IP de Cloudflare, Cloudflare muestra un 521 en lugar de un 502.

Ninguna de las fuentes consultadas dice qué causa es la más frecuente, así que afirmaciones como «un 502 casi siempre es culpa del hosting» no tienen respaldo. La documentación de Cloudflare enumera fallos tanto del origen como de su propia red.

Para el 502 tampoco hay un plazo publicado. Google no dice cuántos días de 502 tolera antes de retirar una URL; escribe que las URL acaban saliendo («eventually») si el error persiste. Solo para el 503 y el 429, su página sobre errores de rastreo habla de más de dos días.

• Comprueba con curl qué cabeceras trae el 502 y si la página lleva el logotipo de la CDN.
• Repite la petición contra el origen, sin la CDN.
• Busca en el registro del servidor web la misma hora y el mensaje del proxy.
• Revisa en el registro de la aplicación si un proceso se cortó por memoria, CPU o tiempo.
• Compara el tiempo de espera del proxy con lo que tarda la aplicación; Microsoft cita el tiempo de espera superado entre las causas de 502 en Azure Application Gateway.
• Al terminar, revisa en Search Console el estado del host en las estadísticas de rastreo.
• Si solo visitas la página: recarga pasados unos minutos.

• Guarda los registros del servidor web y de la aplicación con la misma zona horaria, para cruzarlos.
• Si un mantenimiento va a cortar el origen, devuelve un 503 a propósito en lugar de dejar que la CDN muestre un 502.

• Buscar el fallo en la CDN cuando su propia página dice que el error viene del origen.
• Tratar un 502 como un problema del navegador del visitante.
• Dar por hecho que Google trata el 502 con más suavidad que el 500 o el 503.

Esta entrada se redactó en noviembre de 2026 con ayuda de IA. Los datos proceden de los RFC 1945 y 9110, de la documentación de Google sobre códigos de estado y frecuencia de rastreo, de la ayuda de Search Console y de la documentación de MDN, Cloudflare, Microsoft y nginx. Se revisó antes de publicarse y no contiene datos de clientes.