ERR_TOO_MANY_REDIRECTS: cómo solucionarlo (todos los navegadores)

¿Qué es ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS significa que la página envió tu navegador a otra dirección más de 20 veces sin llegar a cargar: un bucle de redirección. Chrome muestra «Esta página no funciona» y «La página example.com te ha redirigido demasiadas veces.» (en español de Latinoamérica: «example.com te redireccionó demasiadas veces.»), Edge muestra el mismo código de error, Firefox dice «La página no está redirigiendo adecuadamente» y Safari, «Safari no puede abrir la página».

Si solo visitas el sitio, borra las cookies de ese sitio y recarga: cuando el sitio funciona para todos los demás, la causa habitual es una cookie obsoleta. Si es tu sitio, el bucle casi siempre se debe a que HTTPS (o www) se fuerza en dos lugares a la vez, con más frecuencia el modo Flexible SSL de Cloudflare más una redirección HTTPS en el servidor.

El límite es el mismo en todas partes porque lo fija el estándar Fetch que implementan los navegadores: «If request's redirect count is 20, then return a network error.» (cuando una solicitud acumula 20 redirecciones, termina con un error de red). El bucle en sí suele ser dos respuestas 301 o 302 que apuntan una a la otra: la URL A te envía a la URL B, la URL B te devuelve a la A, y el navegador deja de contar en 20.

¿Qué causa los bucles de redirección?

Los bucles de redirección ocurren cuando dos o más reglas de redirección entran en conflicto entre sí. El servidor envía al navegador a una URL, y esa URL lo envía de vuelta. Estas son las causas más comunes:

• Configuración incorrecta de SSL/HTTPS — La causa más común. Tu servidor fuerza HTTP a HTTPS, pero tu CDN o balanceador de carga se conecta al origen por HTTP, creando un bucle: CDN → HTTP → el servidor redirige a HTTPS → el CDN elimina HTTPS → HTTP → bucle
• Cloudflare Flexible SSL — El modo Flexible SSL de Cloudflare envía las solicitudes a tu servidor de origen por HTTP. Si tu origen también tiene una redirección HTTP a HTTPS, se genera un bucle infinito entre Cloudflare y tu servidor
• Reglas conflictivas en .htaccess — Múltiples reglas de redirección en .htaccess que se contradicen, como una regla forzando www y otra forzando sin www simultáneamente
• Desajuste de URLs en WordPress — Dirección de WordPress (URL) y Dirección del sitio (URL) en Ajustes > Generales no coinciden, o una usa HTTP mientras la otra usa HTTPS
• Cookies obsoletas del navegador — Cookies antiguas que contienen instrucciones de redirección o datos de sesión que fuerzan al navegador a una URL que ya no existe o se ha movido
• Redirecciones en caché del CDN o proxy — Tu CDN almacenó en caché una redirección 301 antigua que ahora entra en conflicto con la configuración actual del servidor
• Conflictos en la configuración del servidor — Archivos de configuración de Nginx o Apache con bloques de redirección que compiten, como redirigir tanto en el bloque del servidor como en .htaccess simultáneamente
• Bucles de inicio de sesión en aplicaciones web — una página de inicio de sesión que redirige a sí misma a los visitantes sin sesión, o una cookie de sesión que el navegador se niega a guardar (OAuth, Supabase Auth, NextAuth). Consulta la solución 8

Cómo diagnosticar un bucle de redirección

Antes de probar soluciones, identifica la cadena de redirección exacta. Esto te indica exactamente qué URLs están involucradas y qué reglas de redirección causan el bucle.

Método 1: usa curl para rastrear las redirecciones

La forma más rápida de ver una cadena de redirección es con curl en tu terminal. La opción -I obtiene solo las cabeceras, -L sigue las redirecciones y --max-redirs limita cuántas seguir:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Si ves las mismas dos URLs alternándose en las cabeceras Location, has confirmado un bucle de redirección. Fíjate en los códigos de estado: 301 es una redirección permanente que los navegadores guardan en caché, y 302 una redirección temporal que no se guarda en caché salvo que la respuesta lo indique.

Fíjate también en el esquema de cada cabecera Location: un bucle entre las versiones http:// y https:// de la misma URL es el patrón más común y apunta directamente a un ajuste de SSL.

Método 2: pestaña Red de DevTools del navegador

También puedes rastrear las redirecciones visualmente en Chrome DevTools:

• Paso 1 — Abre Chrome DevTools con F12 o Ctrl+Shift+I (Mac: Cmd+Option+I)
• Paso 2 — Ve a la pestaña Network y marca Preserve log (esto conserva las entradas entre redirecciones)
• Paso 3 — Carga la página que produce el error
• Paso 4 — Observa la secuencia de solicitudes. Cada redirección aparece como una entrada separada con estado 301 o 302. La columna Location muestra a dónde apunta cada redirección

La pestaña Network muestra la cadena completa de redirecciones en orden cronológico. Verás el patrón: normalmente dos o tres URLs repitiéndose en un ciclo. Usa el Verificador de encabezados HTTP de DNS Robot para inspeccionar las cabeceras de respuesta desde fuera de la caché de tu navegador.

Método 3: verificador de redirecciones online

Si no tienes terminal, pega la URL en el Verificador de redirecciones de DNS Robot. Sigue cada salto desde nuestro servidor, muestra cada código de estado y cada cabecera Location, y avisa cuando la cadena vuelve sobre sí misma. Funciona sin las cookies de tu navegador, así que te dice al instante si el bucle es del sitio o de tu navegador.

Solución 1: borrar cookies y caché del navegador

Comienza con la solución más sencilla. Las cookies obsoletas o las redirecciones almacenadas en caché de tu navegador pueden causar bucles incluso cuando la configuración del servidor es correcta. Esto es especialmente común después de que un sitio migra de HTTP a HTTPS: las cookies antiguas pueden seguir referenciando URLs HTTP.

Borrar cookies en Chrome

Borra las cookies del sitio específico en lugar de todas las cookies, así conservas tus sesiones en otros sitios:

• Paso 1 — Haz clic en el icono del candado (o icono de ajustes) en la barra de direcciones junto a la URL
• Paso 2 — Haz clic en Configuración del sitio
• Paso 3 — Haz clic en Eliminar datos para eliminar las cookies y los datos en caché solo de ese sitio
• Paso 4 — Recarga la página

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

O bórralo todo para todos los sitios: pulsa Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete) para abrir Eliminar datos de navegación, marca Cookies y otros datos de sitios y Archivos e imágenes en caché, elige Desde siempre y haz clic en Eliminar datos.

Borrar cookies en Firefox y Safari

Firefox: Presiona Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), marca Cookies y datos del sitio y Archivos y páginas temporales en caché, establece el intervalo de tiempo en Todo y haz clic en Limpiar.

Safari: Ve a Safari > Ajustes > Privacidad > Gestionar datos de sitios web, busca el dominio afectado, selecciónalo y haz clic en Eliminar. Luego vacía la caché con Cmd+Option+E.

Si borrar las cookies lo soluciona, una regla de redirección cambió hace poco en el servidor y tu navegador aún conservaba el estado anterior. Los visitantes con sesiones nuevas quizá nunca vean el error.

Gmail, Google Drive o accounts.google.com «te ha redirigido demasiadas veces»

Cuando Chrome muestra «Esta página no funciona» con «La página accounts.google.com te ha redirigido demasiadas veces.» y el enlace «Prueba a eliminar las cookies.» (en Latinoamérica: «accounts.google.com te redireccionó demasiadas veces.» e «Intenta borrar las cookies.»), o el mensaje nombra mail.google.com o drive.google.com, el bucle está entre las páginas de inicio de sesión de Google y las cookies de tu navegador, no en un sitio roto. El inicio de sesión de Google solo funciona si el navegador conserva las cookies de Google, así que cualquier cosa que las bloquee o las reescriba te hace dar vueltas:

• Borra solo las cookies de Google — abre chrome://settings/content/all (Todos los sitios), busca google.com, elimina sus datos y vuelve a iniciar sesión. Como explica la ayuda de Google, después tendrás que volver a iniciar sesión en tu cuenta de Google en ese navegador
• Permite las cookies de Google — quita google.com de cualquier lista de sitios que no pueden usar cookies y, si bloqueas las cookies de terceros, añade [*.]google.com a Sitios que pueden usar cookies de terceros (Chrome: Configuración → Privacidad y seguridad → Cookies de terceros)
• Cierra sesión en todas las cuentas y entra con una sola — varias cuentas con la sesión iniciada, o una cuenta de trabajo que delega el inicio de sesión en la página de acceso de la empresa, pueden rebotar entre ambas
• Desactiva las extensiones de cookies y privacidad — las extensiones que borran o reescriben cookies durante el inicio de sesión son un desencadenante habitual. Chrome mantiene las extensiones desactivadas en modo incógnito salvo que las permitas, así que prueba primero una ventana de incógnito

Solución 2: verificar la configuración SSL/HTTPS

La mala configuración de SSL es la causa número 1 de los bucles de redirección. El escenario más común es un conflicto entre tu CDN/proxy y tu servidor de origen sobre si usar HTTP o HTTPS.

Esto es lo que suele salir mal: tu CDN se conecta al origen por HTTP (porque gestiona la terminación SSL), pero el origen tiene una redirección de HTTP a HTTPS. El origen envía al CDN de vuelta a HTTPS, el CDN lo elimina y envía HTTP de nuevo — bucle infinito.

Un certificado roto en la misma configuración muestra otro error distinto; consulta ERR_SSL_PROTOCOL_ERROR y «La conexión no es privada».

• Verifica tu certificado SSL — Usa el Verificador SSL de DNS Robot para comprobar que tu certificado es válido, no está caducado y cubre el dominio correcto
• Haz coincidir los protocolos — Si tu CDN gestiona la terminación SSL, elimina la redirección HTTP a HTTPS en tu origen, o configura el CDN para conectarse al origen por HTTPS
• Revisa los ajustes de forzar HTTPS — Si tienes tanto una redirección a nivel de servidor (Nginx/Apache) COMO una a nivel de CDN para forzar HTTPS, elimina una de ellas
• Verifica la cabecera X-Forwarded-Proto — Cuando estás detrás de un proxy, tu origen debería comprobar esta cabecera en lugar del protocolo de conexión directo para determinar si la solicitud original fue HTTPS

Solución 3: solucionar bucles de redirección de Cloudflare

Cloudflare es el desencadenante más común porque su modo de cifrado decide si llega a tu servidor por HTTP o por HTTPS. La página de solución de problemas de Cloudflare (actualizada en septiembre de 2026) enumera cinco ajustes que generan un bucle, cada uno frente a algo que hace tu servidor de origen:

La solución habitual para un bucle de redirección de Cloudflare: cambia tu modo de cifrado SSL/TLS de Flexible a Full o Full (Strict). Esto le indica a Cloudflare que se conecte a tu origen por HTTPS, eliminando el bucle HTTP a HTTPS.

Solución paso a paso para Cloudflare

• Paso 1 — Inicia sesión en el panel de Cloudflare
• Paso 2 — Selecciona tu dominio
• Paso 3 — Ve a SSL/TLS > Overview
• Paso 4 — Cambia el modo de cifrado a Full (strict) si tu origen tiene un certificado válido (un certificado gratuito de Cloudflare Origin CA cuenta), o a Full solo si es autofirmado
• Paso 5 — Ve a SSL/TLS > Edge Certificates y verifica si Always Use HTTPS está activado. Si tu origen ya redirige a HTTPS, desactívalo para evitar una doble redirección
• Paso 6 — Revisa las Page Rules y Redirect Rules en busca de redirecciones de URL conflictivas
• Paso 7 — Purga la caché de Cloudflare: ve a Caching > Configuration > Purge Everything

Solución 4: corregir reglas de redirección en .htaccess (Apache)

En servidores Apache, .htaccess es la ubicación más común para las reglas de redirección, y también el lugar más frecuente donde se originan los bucles de redirección. Reglas conflictivas, redirecciones duplicadas o verificaciones de condición faltantes pueden crear bucles.

• Busca redirecciones HTTPS duplicadas — Si tu panel de hosting (cPanel, Plesk) fuerza HTTPS, elimina la redirección manual de .htaccess
• Verifica las condiciones RewriteCond — Cada RewriteRule que redirige debe tener un RewriteCond que evite que se active en URLs que ya coinciden. Sin esto, la regla se ejecuta en cada solicitud incluyendo la redirigida
• Cuidado con la bandera [L] — La bandera [L] significa 'última regla' pero solo para el paso actual. Si existe otro .htaccess en un subdirectorio, se ejecuta de nuevo. Usa [END] en Apache 2.4+ en su lugar
• Verifica las cabeceras de proxy — Detrás de un CDN, usa %{HTTP:X-Forwarded-Proto} en lugar de %{HTTPS} para detectar el protocolo original

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Si no estás seguro de qué regla causa el bucle, renombra temporalmente .htaccess a .htaccess.bak y prueba si el sitio carga. Si funciona, el problema está en tu archivo .htaccess. Reactiva las reglas una por una hasta encontrar la que causa el problema.

Solución 5: solucionar bucles de redirección en WordPress

Los bucles de redirección en WordPress suelen originarse en tres fuentes: URLs desajustadas en los Ajustes, conflictos entre plugins o valores incorrectos en wp-config.php. Si no puedes acceder al panel de WordPress por el bucle de redirección, necesitarás corregirlo directamente a través de la base de datos o los archivos de configuración.

Verificar los ajustes de URL de WordPress

WordPress tiene dos configuraciones de URL que deben coincidir: Dirección de WordPress (URL) y Dirección del sitio (URL) en Ajustes > Generales. Si una usa http:// y la otra usa https://, o una tiene www. y la otra no, obtendrás un bucle de redirección.

Si no puedes acceder al panel de administración, establece las URLs directamente en wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Desactivar plugins para encontrar conflictos

Los plugins de redirección y caché son culpables frecuentes. Plugins como Redirection, Yoast SEO, Really Simple SSL, WP Super Cache y W3 Total Cache pueden agregar reglas de redirección que entran en conflicto con la configuración de tu servidor o CDN.

Si no puedes acceder al panel de administración, desactiva todos los plugins por FTP o SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Si desactivar los plugins soluciona el error, reactívalos uno por uno para identificar el plugin conflictivo. Los culpables más comunes son los plugins SSL que agregan redirecciones HTTP a HTTPS cuando tu servidor o CDN ya lo gestiona.

Solución 6: corregir redirecciones a nivel de servidor (Nginx y Apache)

Los archivos de configuración del servidor pueden contener reglas de redirección que entran en conflicto con las redirecciones a nivel de aplicación (WordPress, .htaccess) o los ajustes del CDN.

Nginx: buscar conflictos de redirección

Los bucles de redirección en Nginx suelen ocurrir cuando el bloque del servidor HTTP redirige a HTTPS, pero algo en el bloque HTTPS redirige de vuelta a HTTP. Revisa la configuración de tu sitio:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Ejecuta nginx -t después de editar para detectar errores de sintaxis y luego systemctl reload nginx para aplicar el cambio sin tiempo de inactividad.

Apache: verificar redirecciones en VirtualHost

En Apache, verifica tanto la configuración del VirtualHost como .htaccess. Una redirección en la configuración del VirtualHost más una redirección en .htaccess crea una doble redirección que puede generar un bucle:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Elimina las redirecciones duplicadas: mantén la redirección en un solo lugar. La mejor práctica es gestionar las redirecciones HTTPS en la configuración del VirtualHost (no en .htaccess) porque las reglas de VirtualHost se procesan una vez por solicitud mientras que .htaccess se procesa en cada solicitud.

Solución 7: solución de problemas específicos del navegador

Si el error solo aparece en un navegador, es probable que se trate de una redirección en caché o un conflicto con una extensión, no de un problema del servidor.

Chrome: borrar HSTS y el pool de sockets

Chrome almacena en caché las políticas HSTS (HTTP Strict Transport Security) que fuerzan HTTPS. Si un sitio envió previamente una cabecera HSTS pero ya no usa HTTPS correctamente, Chrome seguirá redirigiendo a HTTPS incluso después de borrar las cookies.

• Borrar caché HSTS — Ve a chrome://net-internals/#hsts, introduce el dominio en Delete domain security policies y haz clic en Delete
• Vaciar pools de sockets — Ve a chrome://net-internals/#sockets y haz clic en Flush socket pools para borrar cualquier conexión en caché
• Borrar caché DNS — Ve a chrome://net-internals/#dns y haz clic en Clear host cache (más métodos en cómo vaciar la caché DNS)
• Probar en Incógnito — Abre una ventana de Incógnito (Ctrl+Shift+N) y prueba la URL. Si funciona en Incógnito pero no en la ventana normal, una redirección en caché o una extensión es la causa

Soluciones para Firefox y Safari

Firefox: Escribe about:config en la barra de direcciones, busca network.http.redirection-limit y verifica que valga 20 (el valor por defecto). Un valor más bajo, puesto a mano o por una directiva empresarial, hace que las redirecciones fallen antes. También prueba borrar los datos del sitio: Ajustes > Privacidad y seguridad > Administrar datos > busca el dominio > Eliminar lo seleccionado.

Safari: Safari muestra «Safari no puede abrir la página» con «Se han producido demasiados redireccionamientos al intentar abrir “example.com”.»; la consola del Web Inspector dice «Load cannot follow more than 20 redirections» (en español: la carga no puede seguir más de 20 redirecciones; este mensaje de WebKit no está traducido, por eso aparece en inglés). Ve a Safari > Ajustes > Privacidad > Gestionar datos de sitios web, busca el dominio y haz clic en Eliminar. Si el bucle continúa, prueba en una ventana privada: si también entra en bucle, el sitio está mal configurado.

Solución 8: bucles de redirección al iniciar sesión en aplicaciones web

En una aplicación web el bucle suele estar en tu propio código: una página que exige un usuario con sesión iniciada redirige a /login, y algo devuelve /login (o el callback de inicio de sesión) de inmediato. La consola del navegador lo muestra como net::ERR_TOO_MANY_REDIRECTS en la solicitud que falla.

• La página de inicio de sesión también está protegida — el middleware de autenticación que se ejecuta en todas las rutas también redirige /login y la ruta de callback a /login. Exclúyelas de la comprobación
• La cookie de sesión nunca se guarda — una cookie con SameSite=None también debe ser Secure, o el navegador la descarta; una cookie definida para el dominio equivocado nunca se devuelve. En ambos casos, cada solicitud sigue pareciendo sin sesión
• La URL de callback no coincide — el proveedor (Google, GitHub, Supabase Auth) envía a los usuarios a un callback que tu aplicación no gestiona, y esa ruta vuelve a redirigir al inicio de sesión
• HTTP frente a HTTPS detrás de un proxy — la aplicación construye sus URLs de redirección con http:// porque ignora X-Forwarded-Proto: el bucle de la solución 2, una capa más arriba

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Comprueba la corrección con el Verificador de redirecciones o curl -IL sin sesión iniciada: una cadena sana termina en la página de inicio de sesión con un 200, no con otra redirección.

Cómo prevenir los bucles de redirección

Una vez que hayas solucionado el error inmediato, sigue estas prácticas para evitar que los bucles de redirección vuelvan a ocurrir:

• Redirige en un solo lugar — Elige una capa para tu redirección HTTPS: el CDN, el servidor web o la aplicación. Nunca redirijas en múltiples capas simultáneamente
• Usa 302 durante las pruebas — Mientras depuras, usa redirecciones 302 (temporales) en lugar de 301 (permanentes). Los navegadores almacenan en caché las 301 agresivamente, dificultando las pruebas de cambios. Cambia a 301 una vez que confirmes que la redirección funciona correctamente
• Siempre prueba con curl — Después de agregar una regla de redirección, ejecuta curl -ILs https://tusitio.com | grep -i 'HTTP/\|location:' para verificar que la cadena de redirección se resuelve con una respuesta 200 final
• Monitoriza con herramientas — Usa el Verificador de encabezados HTTP de DNS Robot regularmente para verificar que tu sitio devuelve una respuesta 200 limpia sin redirecciones inesperadas
• Documenta tus redirecciones — Mantén un registro de todas las reglas de redirección en la configuración del servidor, .htaccess, reglas del CDN y ajustes de la aplicación. Cuando varios miembros del equipo gestionan un sitio, las redirecciones no documentadas son la causa número 1 de los bucles
• Purga la caché del CDN después de cambios — Después de modificar cualquier regla de redirección, purga la caché de tu CDN inmediatamente. Las 301 obsoletas en caché pueden persistir durante días

Una cadena sana tiene uno o dos saltos como máximo (por ejemplo, HTTP → HTTPS → 200 OK). Tres o más suelen indicar una redirección que ya no necesitas.

Impacto SEO de los bucles de redirección

Los bucles de redirección sacan las páginas de la búsqueda. La documentación de rastreo de Google indica que sus rastreadores siguen hasta 10 redirecciones; un bucle nunca llega al contenido, así que Search Console informa de un error de redirección y la URL sale del índice hasta que se corrige el bucle.

Las cadenas largas tienen un coste aunque terminen: cada salto es una solicitud más que el navegador y Googlebot deben hacer antes de que la página pueda cargar, así que apunta los enlaces y las redirecciones directamente a la URL final.

• Indexación perdida — Las páginas atrapadas en bucles de redirección no se indexan y desaparecen completamente de los resultados de búsqueda
• Presupuesto de rastreo desperdiciado — Googlebot gasta su presupuesto de rastreo limitado siguiendo redirecciones en lugar de rastrear contenido real
• Páginas más lentas — cada salto es una solicitud y un viaje de ida y vuelta más antes de que cargue cualquier contenido, y un salto a otro host necesita además una conexión nueva