Qué promete el 503, y qué no
Un 503 es el servidor diciendo "existo, te he entendido, vuelve más tarde". A diferencia de un 500, no afirma que algo se haya roto, y a diferencia de un 502, no trata sobre una conversación fallida con una máquina más atrás. Es un rechazo con un "por ahora" implícito.
Ese "por ahora" es la razón por la que 503 es el código correcto para el mantenimiento planificado y para la sobrecarga, y el código equivocado para cualquier cosa permanente. Los buscadores lo tratan como temporal y volverán, que es exactamente lo que quieres durante un despliegue y exactamente lo que no quieres en una página que has retirado — esa es un 410 o un 301.
Causa 1 — el origen se ha quedado sin capacidad
Todo servidor tiene un techo de trabajo concurrente: hijos de PHP-FPM, workers de aplicación, conexiones a la base de datos. Cuando se alcanza el techo, un stack bien configurado rechaza el trabajo nuevo rápidamente con un 503 en lugar de aceptarlo y agotar el tiempo de espera. Eso es el sistema comportándose correctamente bajo presión, aunque parezca un fallo.
Cómo reconocerlo. Los 503 siguen al tráfico: aparecen en los picos y desaparecen cuando el pico pasa. Tu origen está en pie todo el tiempo y responde al instante a una petición que hagas en un momento tranquilo.
Qué ayuda de verdad. Subir el número de workers mueve el techo y normalmente traslada el cuello de botella a la memoria o a la base de datos. La solución duradera es dejar de mandarle trabajo repetido al origen en absoluto: cachea las páginas que se puedan cachear, dales un TTL lo bastante largo como para que importe, y deja que el edge absorba el pico. Una campaña que derrite un origen a 200 peticiones por segundo suele ser 195 peticiones para el mismo puñado de páginas.
Causa 2 — modo de mantenimiento
Las herramientas de despliegue y los plugins de CMS ponen el sitio detrás de una página de mantenimiento y devuelven 503 mientras trabajan. Este es el comportamiento correcto y el código es el adecuado.
Hay dos cosas que pueden salir mal. La primera es un modo de mantenimiento que nunca se desactiva — un despliegue fallido deja el archivo de bandera en su sitio y el sitio sirve 503 mucho después de que el trabajo terminara. La segunda es una página de mantenimiento servida con un 200, que les dice a los rastreadores que el aviso de mantenimiento es tu contenido real y merece ser indexado.
Si el modo de mantenimiento está activo más de unos minutos, añade una cabecera Retry-After. Cuesta una línea y es la diferencia entre un rastreador que se retira educadamente y uno que decide que tu sitio no es fiable.
Causa 3 — un rate limit rechazó la petición
El rate limiting rechaza las peticiones que llegan más rápido que el umbral configurado. Según el software y su configuración, el rechazo llega como 429 Too Many Requests o como 503 — nginx, por ejemplo, rechaza las peticiones limitadas con 503 a menos que se le diga que use otro código.
Esto importa cuando estás leyendo registros: una ráfaga de 503 que afecta a un cliente, una ruta o un user agent, mientras todo lo demás se sirve con normalidad, es un rate limit haciendo su trabajo y no un problema de capacidad. La solución es mirar quién está chocando con el límite. Si es un scraper, el límite está funcionando. Si es tu propia app móvil consultando un endpoint cada segundo, el límite es correcto y la app está equivocada.
Causa 4 — el edge no tiene ningún origen para este hostname
Este es el que hace perder una tarde, y no tiene nada que ver con tu servidor.
Cuando el DNS de un hostname apunta a un edge de CDN pero ese hostname no se ha configurado en el edge — la cuenta todavía no existe, no se añadió el hostname de entrega, o una errata puso el registro en el nombre equivocado — el edge no tiene ningún origen al que preguntar. No puede devolver 502, porque no hubo ninguna conversación fallida. Devuelve 503 con una página que dice que no hay ningún servicio configurado para este dominio.
La secuencia que lo produce es siempre la misma: alguien cambia el DNS primero y termina la configuración del panel después, o cambia el DNS de www mientras el hostname se añadió como el dominio a secas. El sitio "se cae" en el momento en que el DNS se propaga, el origen está perfectamente sano, y la solución lleva un minuto en cuanto dejas de mirar a la máquina equivocada.
Cómo reconocerlo al instante. Lee la página de error en lugar de solo el código de estado. La página de "ningún servicio configurado" de un CDN es inconfundible y nombra el problema. Luego comprueba que el hostname en tu panel coincide exactamente con el nombre en el registro DNS, incluyendo el www.
Qué enviar, y qué deberían ver los visitantes
Si eres tú quien devuelve el 503, hay dos cosas que lo hacen mucho menos costoso.
Envía Retry-After. Ya sea un número de segundos o una fecha HTTP. Los rastreadores lo respetan, los clientes bien escritos lo respetan, y convierte un rechazo en un horario.
Sirve algo humano. La página de error del proxy por defecto no le dice nada al visitante y parece rota. Una página de marca propia con una frase sobre lo que está pasando es muy poco trabajo para una gran diferencia en cómo se vive un incidente.
Y si el contenido es cacheable, un CDN puede seguir sirviendo la copia cacheada mientras el origen rechaza — que es la diferencia entre "el sitio fue lento durante diez minutos" y "el sitio estuvo caído durante diez minutos".
Cómo configurarlo
Guías paso a paso en el centro de ayuda:
Preguntas frecuentes sobre 503 Service Unavailable
¿Es 503 mejor o peor que 502?
Es más informativo. Un 503 es un rechazo deliberado, así que algo en el trayecto está funcionando lo bastante bien como para decidir. Un 502 significa que falló una conversación con la máquina de detrás. En la práctica, un 503 suele ser más a menudo un asunto de capacidad o configuración que controlas, y un 502 más a menudo un origen roto.
¿Un 503 perjudica mi posicionamiento en buscadores?
No si es realmente temporal. Los buscadores tratan el 503 como "vuelve más tarde", por eso es el código correcto durante el mantenimiento. Un 503 que dura días es otro asunto: las páginas acabarán siendo descartadas. Añade Retry-After para que el rastreador sepa qué esperar.
Me sale 503 justo después de apuntar el DNS al CDN. ¿Y ahora qué?
Comprueba la página de error. Si dice que no hay ningún servicio configurado para el dominio, el hostname todavía no está configurado en el edge — el origen no está implicado. Añade el hostname exacto en el panel, incluyendo o excluyendo el www para que coincida con el registro DNS, y el 503 desaparece en cuanto la configuración llega a los edges.
¿Puedo cachear un 503?
No deberías, o solo por segundos. Un 503 cacheado sigue rechazando visitantes después de que la causa haya desaparecido. Sirve las respuestas de error con un TTL muy corto y purga la ruta en cuanto apliques la solución.
¿Cómo evito los 503 bajo carga sin un servidor más grande?
Reduce lo que llega al origen. Cachea lo que se pueda cachear con un TTL que sobreviva a un pico de tráfico, asegúrate de que la clave de caché no se fragmente por parámetros de tracking, y mantén límites de rate limiting en los endpoints que atraen tráfico automatizado. Un servidor más grande sube el techo; cachear elimina la mayoría de las peticiones que empujaban contra él.