Bucle de redirección: cómo encontrar y arreglar ERR_TOO_MANY_REDIRECTS

Un bucle de redirección es una cadena de redirecciones HTTP que nunca aterriza: la URL A envía al navegador a la URL B, B lo devuelve a A, y tras unos veinte saltos el navegador deja de intentarlo e imprime ERR_TOO_MANY_REDIRECTS. No hay nada roto en la página de destino. Dos reglas simplemente no están de acuerdo sobre dónde debería vivir la URL, y cada una sigue deshaciendo a la otra.

Una redirección en bucle es uno de los pocos errores web que nombra su propia causa, siempre que mires lo correcto. No el navegador, no la página de error, y desde luego no la caché: la cadena de redirección. Cada salto lleva una cabecera Location, y las dos direcciones que siguen repitiéndose son las dos reglas que necesitas reconciliar. Esta guía recorre el diagnóstico en un solo comando, las causas detrás de casi todos los ciclos de redirección que he tenido que desenredar, y la solución que no crea silenciosamente un segundo bucle en otro sitio. Si la familia de redirecciones en sí resulta confusa, tipos de redirecciones de URL es el mapa; esto es la versión de resolución de problemas.

Qué significa realmente ERR_TOO_MANY_REDIRECTS

Los navegadores siguen redirecciones en tu nombre, pero no para siempre. Cada cliente mantiene un presupuesto de saltos y abandona la solicitud cuando se agota: Chrome se detiene en 20 y no te deja cambiarlo, Firefox trae el mismo valor por defecto bajo network.http.redirection-limit, y curl permite 50 antes de quejarse. El estándar deja el número abierto. RFC 9110 solo dice que un cliente debería detectar e intervenir en redirecciones cíclicas, que es la manera educada que tiene la especificación de decir que todo navegador necesita un disyuntor.

Esa distinción importa para el diagnóstico, porque el error no prueba que exista un ciclo en absoluto. Una cadena de veintiún saltos distintos sin repeticiones dispara exactamente el mismo mensaje que dos URL rebotando para siempre. Ambos casos merecen arreglarse, pero solo uno de ellos tiene un par de direcciones que reconciliar. La referencia de redirecciones de MDN cubre ambas formas, y la diferencia práctica aparece en cuanto imprimes la cadena.

Una cosa más que la página de error oculta: una redirección permanente queda en caché en el navegador. Si el bucle se construyó con respuestas 301, los visitantes siguen en bucle localmente incluso después de arreglar el servidor, hasta que esa entrada de caché caduca o la borran. Ese único hecho es la razón por la que pruebo los cambios de redirección con un 302 y solo asciendo a 301 una vez que la cadena está bien, un hábito que redirecciones 301 vs 302 argumenta a fondo.

Traza la cadena de redirección con un solo comando

Sáltate el navegador. La lectura más rápida de cualquier bucle de redirección es la terminal, porque curl imprime cada salto en lugar de colapsarlos en una sola página de error:

curl -sIL https://example.com | grep -E '^HTTP|^[Ll]ocation'

Obtienes una línea de estado y una cabecera Location por salto, en orden. Léela de arriba a abajo y aparece uno de tres patrones. Dos URL alternándose significa un ciclo genuino, y el par nombra ambas reglas culpables. Una larga marcha de URL distintas significa una cadena que alguien fue apilando a lo largo de los años, cada salto legítimo por sí solo. Y una cadena que se resuelve bien en la terminal pero sigue fallando en un navegador significa que el bucle lo provocan las cookies, ya que curl no envía cookies por defecto.

Ese último caso merece su propia comprobación, porque es el que hace que la gente le eche la culpa al DNS durante toda una tarde:

curl -sIL -c jar.txt -b jar.txt https://example.com/account | grep -E '^HTTP|^[Ll]ocation'

Con un almacén de cookies adjunto, un bucle de inicio de sesión o de consentimiento se reproduce en la línea de comandos, donde puedes ver exactamente qué endpoint sigue estableciendo y luego rechazando la sesión. En el navegador, la vista equivalente es el panel Network con "Preserve log" activado, que evita que los saltos anteriores se borren cuando la página navega. Si prefieres no abrir una terminal en absoluto, nuestro comprobador de enlaces traza la cadena en el navegador e imprime el código de estado en cada salto.

Las causas detrás de casi todos los ciclos de redirección

Una vez que puedes ver la cadena, la causa suele ser una entre un puñado reducido. El par de URL que se repite te dice a qué capa mirar: el esquema alternando apunta a la terminación de TLS, el nombre de host alternando apunta a una regla de host canónico, y una ruta que gana y pierde una barra apunta al orden de las reescrituras.

reglas https detrás de un proxy que termina el TLS

Esta es la redirección infinita más común de la web moderna, y apareció en el momento en que los proxies empezaron a terminar el TLS delante de los orígenes. El proxy acepta una solicitud HTTPS del visitante, y luego obtiene tu origen por HTTP sin cifrar. Tu origen ve una solicitud insegura, hace lo que le dijiste que hiciera, y redirige a HTTPS. El proxy sirve esa redirección, recibe la petición de nuevo, obtiene el origen por HTTP otra vez, y así sucesivamente. Cloudflare documenta exactamente este fallo bajo su modo de cifrado flexible, y cualquier otro proxy tiene la misma trampa bajo otro nombre.

Hay dos soluciones limpias. Cambia el proxy a un modo de cifrado completo para que hable con tu origen por TLS, que es la respuesta correcta en casi todos los casos. O, si el salto al origen realmente tiene que quedarse sin cifrar, haz que la regla del origen lea la cabecera X-Forwarded-Proto en lugar de la conexión bruta, para que deje de redirigir solicitudes que ya eran seguras en el edge.

www y el apex sin ponerse de acuerdo sobre qué host gana

Una regla de host canónico está bien. Dos de ellas, escritas en momentos distintos por personas distintas, son un bucle. La versión clásica tiene una configuración de servidor que envía el apex a www mientras la configuración de la aplicación devuelve www al apex, y ambas están seguras de tener razón. Lo verás al instante en la cadena: example.com a www.example.com a example.com, para siempre.

Elige un host, aplícalo en exactamente un lugar, y elimina la otra regla en lugar de intentar que se pongan de acuerdo. Lo mismo se aplica a una reescritura de barra final o de minúsculas: cuando dos reglas normalizan la misma URL en direcciones opuestas, obtienes un ciclo de redirección aunque cada regla sea razonable por separado.

el ajuste de URL del CMS o de la aplicación que ya no coincide

La mayoría de las aplicaciones almacenan su propia dirección canónica, y ese campo es una regla de redirección con un nombre amigable. Cambia el dominio, mueve a un entorno nuevo, o restaura una instantánea de base de datos desde otro host, y la aplicación empieza a redirigir cada solicitud a una dirección que redirige de vuelta. Como el ajuste vive en la base de datos en lugar de en la configuración de tu servidor web, sobrevive a la auditoría de configuración que acabas de hacer, que es lo que hace que sea tan molesto de encontrar.

La firma es una cadena que abandona tu nombre de host actual y nunca vuelve a él. Corrige la dirección almacenada al dominio que realmente estás sirviendo, y luego vacía cualquier caché de aplicación o de página que haya capturado la incorrecta.

bucles de cookies y sesión que solo afectan a usuarios con sesión iniciada

Aquí las reglas son inocentes y el estado es el problema. Una puerta redirige a los visitantes no autenticados a una página de inicio de sesión, la página de inicio de sesión devuelve a los autenticados, y una cookie de sesión que no se puede leer en el dominio de destino deja a ambos lados convencidos de que el otro debería encargarse. Los avisos de consentimiento provocan la misma forma cuando la propia redirección que establece la cookie de consentimiento está bloqueada.

La pista es la misma que en la sección anterior: una ventana privada limpia funciona, o curl sin almacén de cookies se resuelve con normalidad. Revisa el dominio de la cookie y el alcance de Path, sus atributos Secure y SameSite frente al esquema que realmente estás sirviendo, y si se está estableciendo en el apex mientras se lee en www.

Los bucles de redirección rara vez son misteriosos una vez que tienes la cadena en pantalla, pero sí que se comen una tarde cuando adivinas en lugar de trazar. Si prefieres controlar la capa de redirección en lugar de discutir con ella, el plan gratuito de Elido te da enlaces cuyo destino es un único valor almacenado que puedes reapuntar, con cada salto registrado.

Arréglalo sin crear un segundo bucle

La reparación en sí es corta, y el orden importa más que la sintaxis. Cambia una regla, y vuelve a trazar. Cambiar tres y recargar no te dice nada sobre cuál importaba, y he visto a un equipo perder una hora así en un bucle causado por una regla que ya habían arreglado en el primer intento.

1. Elimina o invierte exactamente una de las dos reglas que nombró la cadena, para que una solicitud pueda alcanzar un 200 en un solo salto.
2. Vuelve a ejecutar el trazado con curl -sIL y confirma que la cadena ahora es como mucho una redirección, sin ningún nombre de host repetido.
3. Borra la caché del navegador, o prueba en una ventana privada, porque cualquier 301 que sirvieras antes sigue en caché localmente y simulará un fallo que ya no existe.
4. Solo entonces asciende las redirecciones temporales a permanentes, una vez que la forma de la cadena esté asentada.

Dos trampas esperan al final de esa lista. HSTS es una: una vez que un host ha enviado una cabecera Strict-Transport-Security, los navegadores actualizan cada solicitud a HTTPS por su cuenta, así que una regla de origen que también fuerza HTTPS ahora es redundante y puede convertir una mala configuración del proxy en un bucle que no puedes reproducir sin borrar la entrada HSTS. La otra es la caché delante del bucle. Una CDN que cacheó un 301 seguirá sirviéndolo felizmente después de que el origen deje de enviarlo, por lo que una purga pertenece a la solución y no a después de ella. Vale la pena recortar en la misma pasada las cadenas largas que nunca hacen bucle: cada salto adicional es otra oportunidad para que se pierda una cadena de consulta, que es exactamente cómo desaparecen los parámetros UTM en GA4, y es parte de por qué los enlaces cortos no tienen que perjudicar el SEO mientras se mantengan a un solo salto de profundidad.

Cuando el bucle está en un enlace corto

Los enlaces cortos añaden un lugar más donde puede formarse un ciclo, y no es la redirección del acortador. Un enlace corto es un único salto almacenado: entra el slug, sale el destino. El bucle aparece cuando el destino apunta de vuelta, lo cual ocurre más a menudo de lo que parece. Alguien edita un enlace de campaña para que apunte a una landing page, la landing page tiene una regla antigua que redirige a la URL corta porque esa era la dirección canónica de difusión el trimestre pasado, y ahora los dos rebotan. Ambos saltos se comportan exactamente como están configurados.

En la misma cadena aparecen dos variantes más. Una es un par de enlaces cortos apuntándose mutuamente tras una edición masiva, normalmente por una importación desde una hoja de cálculo donde la columna de destino contenía URL cortas en lugar de finales. La otra es un dominio personalizado que sigue resolviendo hacia un host que redirige de vuelta al acortador, lo cual es un resto de DNS más que un problema de enlace, y dominios personalizados para enlaces cortos cubre cómo deberían verse los registros. En los tres casos, la solución es configurar el destino a la página final en lugar de a otra redirección, algo que puedes hacer sin tocar nada ya impreso o publicado.

Como el destino está almacenado en lugar de estar incrustado en la URL, nada de esto necesita una reimpresión. Ese es todo el argumento a favor de los enlaces gestionados, y enlace corto que no funciona es la guía de triaje más amplia cuando el síntoma no es específicamente un bucle.

Evita que el próximo llegue a producción

Los bucles de redirección son un fallo de deriva de configuración, así que las soluciones duraderas son las aburridas. Mantén la decisión de host canónico en un único lugar y trata cualquier segunda regla que toque el esquema o el nombre de host como un fallo a primera vista. Traza las redirecciones nuevas con curl -sIL antes de anunciarlas, no después de que alguien reporte una página en blanco. Si los enlaces importan para los ingresos, ponles una comprobación: un trazado programado que falle cuando la cadena supere un salto detecta la deriva mucho antes de que lo haga un cliente, y monitorización de redirecciones de enlaces muestra cómo se ve eso conectado a alertas reales.

El hábito más amplio es tratar los destinos como datos que puedes auditar. Prevención del link rot cubre la misma disciplina para enlaces que dejan de resolver silenciosamente, y es la misma comprobación semanal en cualquier caso. Honestamente, la mayoría de los bucles que he visto los provocaron dos personas competentes que arreglaron el mismo problema en una capa distinta, con un mes de diferencia. Escribe la regla una sola vez y el bucle deja de ser posible.

Lee la serie insignia

Este artículo pertenece al cluster de ingeniería. Para la forma de la propia ruta de redirección, alcanzar un p95 por debajo de 15 ms en redirecciones cubre lo que cuesta un único salto bien comportado, y tipos de redirecciones de URL cubre qué código de estado corresponde a cada caso antes de que empieces a apilar reglas.

Relacionado en el blog

• Tipos de redirecciones de URL: 301, 302, 307, 308 y más
• Redirecciones 301 vs 302: cuál deben usar los enlaces cortos
• ¿Tu enlace corto no funciona? Diagnostícalo con un solo comando
• Dominios personalizados para enlaces cortos: el recorrido de DNS y TLS
• Vulnerabilidades de redirección abierta y cómo prevenirlas
• Monitorización de enlaces cortos con Sentry y Datadog