ERR_TOO_MANY_REDIRECTS: qué causa un bucle de redirección y cómo solucionarlo

Qué significa ERR_TOO_MANY_REDIRECTS

Una redirección le dice al navegador "la página que quieres está en otro sitio, ve allí en su lugar". Una única redirección, o incluso dos o tres seguidas, es normal: un dominio pelado que reenvía a www, o una URL antigua que reenvía a su reemplazo. Un bucle ocurre cuando una URL redirige a una segunda URL que redirige de vuelta a la primera, o a sí misma. Como el navegador nunca llega a una página que realmente devuelva contenido, corta la cadena y muestra el error en lugar de quedarse colgado para siempre.

Cómo aparece el error

Chrome y Edge muestran "This page isn't working - redirected you too many times" con el código de error ERR_TOO_MANY_REDIRECTS. Firefox muestra "The page isn't redirecting properly". Safari dice "Safari can't open the page because too many redirects occurred".

curl con el flag -L sigue las redirecciones igual que lo hace un navegador, y mostrar cada salto revela exactamente dónde se repite el bucle:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Ese patrón, http a https y de vuelta a http, es la forma más habitual con diferencia que toma este error. curl se detiene solo por su propio límite por defecto (50 redirecciones) en lugar de seguirlo para siempre, y las líneas location repetidas hacen el bucle evidente sin necesidad de abrir siquiera un navegador.

Qué causa un bucle de redirección

• Un desajuste HTTP-a-HTTPS entre un proxy o CDN y el origen. Este es el caso clásico. Si el modo SSL/TLS de Cloudflare está fijado en Flexible, Cloudflare termina TLS en el borde y se conecta al origen por HTTP plano. Si el servidor de origen también tiene una regla que redirige cada petición HTTP a HTTPS (un ajuste de seguridad habitual por defecto), el origen devuelve al navegador hacia HTTPS, Cloudflare degrada de nuevo a HTTP en el siguiente salto, y los dos ajustes pelean para siempre.
• Reglas de www y sin-www que se apuntan entre sí. Una regla redirige el dominio pelado a www, y una regla aparte, a menudo añadida más tarde por otro administrador o un plugin distinto, redirige www de vuelta al dominio pelado.
• Un desajuste de siteurl o home en WordPress. Si la URL configurada del sitio en la base de datos no coincide con la URL que realmente usan los visitantes (una URL de staging que quedó por ahí, un desajuste de esquema tras añadir SSL), WordPress sigue redirigiendo hacia el valor configurado.
• Cookies que el servidor espera pero nunca recibe, o una redirección de inicio de sesión que falla en silencio. Una página que redirige a visitantes sin autenticar a un paso de inicio de sesión, que luego redirige de vuelta a la misma página porque la cookie de sesión nunca se llegó a fijar (a menudo bloqueada por las reglas de cookies de terceros de un navegador o por un atributo Secure/SameSite ausente), entra en bucle indefinidamente.
• Reglas de barra final o de prefijo de idioma que entran en conflicto. Una regla añade una barra final, otra la quita; una regla añade un prefijo de idioma según el locale del navegador, otra lo quita para las URL canónicas, y las dos se anulan entre sí.
• Una capa de caché sirviendo una redirección obsoleta. Un CDN o un proxy inverso tenía en caché un 301 antiguo que apuntaba a una URL que, tras un cambio posterior, redirige de vuelta a la original.

Cómo saber de quién es la culpa

Si el bucle ocurre para todos los visitantes en todas las redes, es un problema de configuración del servidor o del CDN, no algo local. Si solo te ocurre a ti, borra primero las cookies del sitio, ya que una cookie de sesión mala o caducada causa una gran parte de los bucles de un solo visitante. Ejecutar una comprobación HTTP desde varias ubicaciones lo resuelve en una sola petición: si la misma cadena de redirecciones (o el mismo fallo) aparece desde todas las ubicaciones, la solución está del lado del servidor.

Cómo corregir ERR_TOO_MANY_REDIRECTS

Si eres el visitante

1. Borra las cookies del sitio. En Chrome, pulsa el icono del candado o de ajustes junto a la barra de direcciones, abre los ajustes del sitio, y borra las cookies y los datos del sitio solo para ese dominio.
2. Prueba una ventana de incógnito o privada. Esto descarta una extensión del navegador o una cookie guardada como causa sin tocar tu perfil habitual.
3. Prueba con otra red, como datos móviles en lugar de wifi. Algunos proxies corporativos o de proveedor de internet reescriben peticiones de formas que crean un bucle solo en esa red.
4. Borra la caché del navegador por si la propia respuesta de redirección quedó en caché desde antes de que se arreglara el sitio.

Si administras el sitio

1. Revisa el modo SSL de tu CDN frente a la regla de redirección de tu origen. En Cloudflare, abre SSL/TLS y fija el modo en Full o Full (strict), no en Flexible, siempre que el origen redirija HTTP a HTTPS. Full sigue permitiendo que el origen use un certificado autofirmado; Full (strict) exige uno válido.
2. Confía en la cabecera de protocolo reenviada en lugar de redirigir a ciegas. Cuando un proxy se sitúa delante de tu aplicación, el origen necesita redirigir según X-Forwarded-Proto, no según la conexión en bruto, que siempre parece HTTP visto desde detrás del proxy. En nginx:

   if ($http_x_forwarded_proto = "http") {
       return 301 https://$host$request_uri;
   }

   y asegúrate de que el CDN o el balanceador de carga realmente está fijando esa cabecera en cada petición.
3. Revisa tus reglas de redirección en orden, incluyendo .htaccess, bloques server de nginx, middleware a nivel de aplicación, y cualquier regla de página del CDN, en busca de dos reglas que se apunten entre sí. Un patrón habitual de Apache que entra en bucle detrás de un proxy:

   RewriteCond %{HTTPS} off
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   falla de la misma forma que el caso de nginx de arriba, ya que %{HTTPS} lee la conexión que hace el proxy, no la que hizo el visitante; comprueba %{HTTP:X-Forwarded-Proto} en su lugar.
4. Corrige la URL del sitio en WordPress si aplica: en wp-admin > Settings > General, confirma que tanto la WordPress Address como la Site Address coinciden con la URL que realmente usan los visitantes, protocolo incluido. Si el propio panel de administración es inaccesible por culpa del bucle, fija WP_HOME y WP_SITEURL directamente en wp-config.php.
5. Elige una forma canónica y redirige todo lo demás a ella una sola vez, no en cadena: www o sin www, con barra final o sin ella, una regla por decisión en lugar de varias reglas apiladas por herramientas distintas a lo largo del tiempo.
6. Purga la caché del CDN después de corregir la regla, ya que un 301 o 302 en caché sigue enviando la respuesta antigua hasta que caduca o se purga.

Errores relacionados

• Los códigos de estado de redirección 3xx explica qué significan el 301, 302, 303, 307 y 308.
• 301 frente a 302 cubre cuándo una redirección debería ser permanente frente a temporal, algo que importa para los buscadores y la caché, no solo para los bucles.

Cómo prevenir ERR_TOO_MANY_REDIRECTS

Un bucle de redirección casi siempre lo introduce un cambio de configuración: un CDN nuevo, un certificado SSL nuevo, una actualización de un plugin, o una migración que tocó la URL del sitio. Una comprobación HTTP que vigila el código de respuesta y sigue las redirecciones según un horario detecta un bucle en el momento en que aparece, desde más de 300 puntos de control en 158 ciudades, en lugar de esperar a un ticket de soporte. HostTracker monitoriza sitios web desde 2004 y puede alertar por correo, SMS, llamada de voz, Slack, Telegram y más en el momento en que una comprobación empieza a fallar.

Preguntas frecuentes

¿Cuántas redirecciones permite un navegador antes de rendirse?

Chrome y los navegadores basados en Chromium se detienen en torno a las 20. El límite por defecto de curl con -L es 50. La cifra exacta varía según el cliente, pero cualquiera de ellos acabará deteniéndose en lugar de seguir un bucle para siempre.

¿Por qué el bucle ocurre justo después de mudarme a Cloudflare (u otro CDN)?

Casi siempre por el modo SSL/TLS. El modo Flexible habla HTTP plano con el origen; si el origen insiste en HTTPS, las dos partes se redirigen mutuamente sin fin. Cambiar a Full o Full (strict) normalmente lo resuelve de inmediato.

¿Puede causar esto una extensión del navegador?

Sí, sobre todo extensiones que fuerzan HTTPS, reescriben peticiones, o gestionan cookies. Probar en una ventana de incógnito con las extensiones desactivadas lo descarta rápidamente.

¿Afecta esto al SEO?

Sí. Los rastreadores de los buscadores se rinden ante un bucle de redirección igual que un navegador, y una URL en bucle no se indexará o caerá del índice si antes funcionaba.

Solo veo el error en una página concreta, no en todo el sitio. ¿Qué tiene de distinto?

Revisa si hay una regla específica de esa página: una página que exige inicio de sesión, una redirección antigua en caché para esa única URL, o un desajuste de barra final que solo existe en esa ruta. Compara la cadena de redirección exacta de esa URL con la de una página que funcione usando curl -sIL.

¿Es algo que arreglar una única redirección (como de sin-www a www)?

No, una sola redirección por sí sola es normal y esperada. Solo una cadena que se repite y nunca llega a una respuesta 200 final es el problema que describe este error.