Cómo solucionar 'ERR_TOO_MANY_REDIRECTS'

ERR_TOO_MANY_REDIRECTS significa que el navegador siguió una cadena de redirecciones que nunca se resuelve —más comúnmente URL A → URL B → URL A— y abandonó tras alcanzar su límite interno de saltos.

Si te has encontrado con este error, probablemente cambiaste alguna configuración de proxy o SSL y luego observaste cómo cada solicitud rebotaba entre dos URLs en lugar de cargarse. Es un error desesperante precisamente porque la página funcionaba bien hace una hora y nada parece estar obviamente roto. No es un bug del navegador ni un fallo transitorio; indica que dos o más reglas de redirección en tu stack no coinciden sobre a dónde debe apuntar una URL. Esta guía prioriza el diagnóstico: primero trazas el bucle antes de tocar ninguna configuración y luego corriges la causa raíz real, que para la mayoría de los desarrolladores es un desajuste de protocolo detrás de un proxy o CDN, no un plugin de WordPress.

¿Qué significa ‘ERR_TOO_MANY_REDIRECTS’?

Un bucle de redirecciones ocurre cuando tu sitio responde continuamente a una URL con una redirección hacia otra que eventualmente vuelve a apuntar a la primera, de modo que el navegador nunca alcanza una respuesta 200 final. Los navegadores limitan el número de saltos que seguirán: Chromium y Firefox se detienen en 20, y Safari se detiene antes, momento en el que abandonan la solicitud y muestran un error.

El mensaje varía según el navegador, por lo que cualquiera de estos describe la misma condición:

Las redirecciones en sí son respuestas 3xx ordinarias, generalmente 301 o 302, cada una con una cabecera Location. En un bucle, los mismos dos valores de Location se alternan hasta que el navegador abandona.

Diagnostica primero: traza la cadena de redirecciones

Antes de cambiar ninguna configuración, traza la cadena desde la línea de comandos. curl -I -L https://yourdomain.com imprime las cabeceras de respuesta para cada salto, y un bucle aparece como las mismas dos URLs repitiéndose en líneas Location: sucesivas. En el manual de curl, -I (--head) obtiene solo las cabeceras y -L (--location) sigue cada cabecera Location hasta la siguiente URL.

Un origen con bucle produce una salida como esta:

HTTP/2 301
location: https://app.example.com/

HTTP/2 301
location: http://app.example.com/

HTTP/2 301
location: https://app.example.com/
...
curl: (47) Maximum (50) redirects followed

La alternancia http:// ↔ https:// aquí es la firma de un bucle por desajuste de protocolo. Si también quieres los cuerpos de respuesta, usa curl -sSL -o /dev/null -D - https://yourdomain.com, que vuelca todas las cabeceras descartando el cuerpo.

Alternativas sin instalación: la pestaña Network de las DevTools del navegador muestra la misma cadena de 301/302 con cada Location, y la extensión Redirect Path o un verificador de redirecciones en línea renderizará la cadena para una URL. En cualquier salida que uses, busca la URL que se repite: ese par repetido es el bucle.

La causa #1 para desarrolladores: bucles HTTP↔HTTPS por terminación SSL

El bucle de redirecciones más común que encuentran los desarrolladores no es un plugin. Es un desajuste de protocolo: un proxy o CDN termina TLS y reenvía HTTP plano a tu origen, tu aplicación ve http, redirige a https, y el ciclo se repite indefinidamente. El navegador habla HTTPS con el edge; el edge habla HTTP con tu aplicación; tu aplicación “amablemente” redirige de vuelta a HTTPS.

En Cloudflare, configurar SSL/TLS en Flexible mientras tu origen también fuerza HTTPS garantiza un bucle, porque Flexible siempre envía HTTP al origen. El desencadenante suele ser el interruptor independiente “Always Use HTTPS” aplicado sobre Flexible. La solución: instala un certificado en el origen y luego cambia el modo a Full (strict). El conjunto de modos actual es Off, Flexible, Full, Full (strict) y Strict, no los “tres modos” que describen las guías más antiguas.

Detrás de tu propio proxy o balanceador de carga, haz que la aplicación confíe en la cabecera de protocolo reenviada en lugar de volver a redirigir. El proxy debe enviar X-Forwarded-Proto con el esquema original del navegador, y la aplicación debe leerla en lugar del salto en texto plano. En Express, activa trust proxy para que req.protocol y req.secure reflejen el valor reenviado:

// Trust the first proxy hop, then req.secure reflects X-Forwarded-Proto
app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(301, `https://${req.headers.host}${req.originalUrl}`);
  }
  next();
});

Sin trust proxy, req.secure permanece false detrás de un proxy que termina TLS y este middleware exacto entra en bucle. En Nginx haciendo la redirección en el origen, protege la regla con el esquema reenviado para que no pueda dispararse contra tráfico que ya llegó como HTTPS:

# Only redirect when the edge saw plain HTTP
if ($http_x_forwarded_proto = "http") {
  return 301 https://$host$request_uri;
}

Un bucle en producción que solo se activa para usuarios autenticados o solo detrás del CDN es invisible para una ejecución anónima de curl. Una reproducción de sesión de la sesión afectada muestra qué dos URLs estaban rebotando bajo las cookies y el contexto de edge reales del usuario, reproduciendo la condición que los logs del servidor describen pero no permiten ver.

Bucles por cookies y guardas de autenticación

Las cookies obsoletas y el enrutamiento incorrecto de la autenticación son la segunda gran categoría. Una cookie que almacena un estado de redirección antiguo, o una política HSTS cacheada por el navegador, puede forzar a un cliente concreto a entrar en un bucle mientras el resto carga el sitio sin problemas; ese es el síntoma de “falla en mi ventana normal, funciona en modo incógnito”. Limpia primero las cookies y los datos del sitio para el dominio afectado.

La versión programática es una guarda de autenticación que entra en bucle sobre su propia página de login. Si /login está protegida por la regla de “redirigir usuarios no autenticados a /login”, cada visita rebota de vuelta a /login. Excluye la ruta de login de la guarda. Lo mismo ocurre cuando un manejador de login redirige a una página protegida cuya guarda envía inmediatamente al usuario de vuelta porque la cookie de sesión nunca se estableció (un efecto secundario frecuente del desajuste de req.secure mencionado anteriormente, donde una cookie Secure es rechazada en el salto HTTP del proxy).

Errores en reglas de redirección: dos capas en desacuerdo

Un bucle de redirecciones es casi siempre el resultado de dos capas en desacuerdo sobre la URL canónica (el framework, el servidor web y el CDN, cada uno aplicando una regla diferente), por lo que la solución duradera es gestionar las redirecciones HTTP→HTTPS y www/no-www en exactamente una capa. Casos clásicos: una capa fuerza www y otra lo elimina; una regla cuyo destino sigue coincidiendo con su propia condición; o la misma redirección duplicada en el framework, el host y el CDN.

Los frameworks son una capa de redirección de primera clase, no algo secundario:

• Next.js define redirecciones con async redirects() en next.config.js, donde permanent: true emite 308 y false emite 307. Ten en cuenta que a partir de Next.js 16 la convención del antiguo archivo middleware pasa a llamarse Proxy (proxy.ts); un middleware.ts existente sigue funcionando para casos de uso del Edge runtime, pero está obsoleto y se eliminará en una versión futura, por lo que la lógica de redirección o autenticación que contenga debe migrarse a proxy.ts.
• Nginx usa una directiva return 301: protégela, como se muestra arriba, para que no se vuelva a disparar detrás de un proxy.
• Express usa middleware; mantén exactamente un middleware de redirección HTTPS en la cadena.
• WordPress es un caso particular del mismo patrón: un desajuste entre los ajustes de WordPress Address y Site Address es simplemente dos capas en desacuerdo, que se resuelve haciendo que ambas coincidan.

En el lado del servidor, Apache también puede lanzar un error distinto “request exceeded the limit of 10 internal redirects”, cuyo límite de reescritura interna de 10 es independiente del límite de 20 saltos del navegador, lo que es una pista útil de que el bucle está en .htaccess, no en el cliente. En Cloudflare, coloca la redirección HTTP→HTTPS en una Redirect Rule en el moderno motor de Rules; las Page Rules están siendo eliminadas progresivamente en favor del motor de Rules moderno.

¿Cómo prevenir los bucles de redirecciones?

La mayoría de los bucles se introducen con un cambio de configuración, así que realiza los cambios de redirección de forma deliberada. Sigue esta lista de verificación:

1. Una sola capa gestiona cada redirección. Decide si la canonicalización HTTPS y www/no-www reside en el CDN, el servidor web o la aplicación, y elimina los duplicados de las otras dos.
2. Confía en el proxy, no vuelvas a redirigir. Detrás de cualquier salto que termine TLS, lee X-Forwarded-Proto en lugar de forzar HTTPS a ciegas.
3. Vuelve a trazar la cadena después de cada cambio. Ejecuta curl -I -L contra la URL afectada después de cualquier cambio en HTTPS, el dominio o la estructura de URLs, y confirma que termina en un único 200.

La salida más rápida de un bucle de redirecciones es siempre el trazado, no la suposición. Ejecuta curl -I -L contra la URL que falla, encuentra las dos URLs que rebotan en las cabeceras Location, y luego corrige la capa que está redirigiendo a contracorriente, que más frecuentemente es un proxy que entrega HTTP a un origen que insiste en HTTPS.

Preguntas frecuentes

¿Por qué el bucle de redirecciones desaparece en modo incógnito pero no en mi ventana normal del navegador?

El modo incógnito comienza sin cookies almacenadas ni política HSTS cacheada, por lo que un bucle que persiste en la navegación normal pero desaparece en una ventana privada apunta a un estado del lado del cliente, no a una regla del servidor. Una cookie obsoleta con un estado de redirección antiguo, o una política HSTS cacheada que fuerza HTTPS en un origen mal configurado, generará el bucle solo en el perfil afectado mientras otros usuarios cargan el sitio sin problemas. Limpia las cookies y los datos del sitio para el dominio y, si sospechas de HSTS, inspecciona chrome://net-internals/#hsts.

¿Cuál es la diferencia entre Cloudflare Flexible y Full (strict) SSL en relación con los bucles de redirecciones?

Flexible siempre envía HTTP plano desde Cloudflare a tu origen, por lo que si el origen fuerza la redirección de HTTP a HTTPS, la solicitud entra en un bucle infinito. Full (strict) envía HTTPS al origen y valida un certificado de confianza allí, coincidiendo con lo que el origen espera y rompiendo el bucle. Instala primero un certificado válido en el origen y luego cambia el modo SSL/TLS de Flexible a Full (strict). El interruptor independiente 'Always Use HTTPS' aplicado sobre Flexible es un desencadenante habitual.

¿Por qué curl y el navegador muestran un comportamiento de redirección diferente para la misma URL?

curl se ejecuta como un cliente anónimo sin cookies, sin política HSTS cacheada y sin sesión de login, por lo que solo reproduce bucles causados por reglas del servidor o CDN que se aplican a todas las solicitudes. Los bucles que dependen de una cookie específica, una sesión autenticada o un edge concreto del CDN no aparecerán en un trazado anónimo con curl. Para esos casos, captura el contexto real del usuario: las DevTools del navegador en la sesión afectada, o una reproducción de sesión que muestre qué dos URLs estaban rebotando bajo las cookies y el estado de autenticación de ese usuario.

¿Una redirección de Next.js 16 en next.config.js se aplica a la navegación del lado del cliente con Link o router.push?

Al usar el Pages Router, las redirecciones definidas en la función redirects() de next.config.js no se aplican al enrutamiento del lado del cliente mediante Link o router.push a menos que haya un archivo Proxy, anteriormente middleware, presente y que coincida con la ruta. Las redirecciones de next.config.js se ejecutan en el servidor para cargas completas de página y solicitudes iniciales, por lo que las transiciones del lado del cliente pueden saltárselas. En Next.js 16 la convención del archivo middleware pasó a llamarse Proxy (proxy.ts); un middleware.ts existente debería migrarse, ya que la lógica de redirección y autenticación que permanezca allí podría dejar de ejecutarse.