ERR_TOO_MANY_REDIRECTS

Qué significa este error y cómo reconocerlo

• El navegador muestra “Esta página no funciona — [domain] te ha redirigido demasiadas veces” o el código de error ERR_TOO_MANY_REDIRECTS.
• La barra de direcciones cambia repetidamente entre HTTP y HTTPS, o entre los hostnames www y no-www, antes de que el navegador deje de cargar la página.
• Puede fallar todo el sitio, o el problema puede limitarse a una URL, el área de administración, las sesiones iniciadas o determinados dispositivos.
• El problema suele comenzar después de activar HTTPS, añadir una CDN o un reverse proxy, cambiar el hostname canónico o instalar un plugin de redirecciones o SSL.
• Borrar las cookies puede cambiar temporalmente el comportamiento cuando intervienen la autenticación o la lógica de sesión, pero no soluciona un conflicto de redirecciones en el servidor.

Causas principales, ordenadas por probabilidad

1. Reglas HTTP/HTTPS en conflicto — una capa redirige HTTP a HTTPS mientras otra redirige incorrectamente HTTPS de vuelta a HTTP. Esto ocurre habitualmente cuando un proxy o una CDN termina TLS, pero el origen no reconoce que la solicitud original era segura.
2. Discrepancia en el modo SSL/TLS de la CDN — una CDN puede usar HTTP para conectarse a un origen que fuerza HTTPS. El origen redirige a HTTPS, pero la CDN repite la solicitud HTTP al origen, creando un bucle.
3. Reglas canónicas www y no-www en conflicto — la CDN, el servidor web, el CMS o un plugin pueden no coincidir sobre qué hostname es el canónico.
4. Gestión incorrecta del proxy o del protocolo reenviado — la aplicación puede no confiar en el proxy configurado o no procesar correctamente X-Forwarded-Proto o una cabecera equivalente, por lo que trata repetidamente una solicitud segura como HTTP.
5. Caché de redirecciones obsoleta — un navegador, una CDN, un reverse proxy o una caché de páginas puede seguir sirviendo una redirección anterior a la corrección de la configuración.
6. Reglas duplicadas de la aplicación o de plugins — los plugins de forzado de SSL, inicio de sesión, mantenimiento o redirecciones pueden entrar en conflicto con las reglas del servidor.
7. Problemas de configuración de cookies o sesiones — unos atributos Secure, de dominio o de ruta incorrectos pueden provocar redirecciones de autenticación solo para algunos usuarios, especialmente para visitantes con la sesión iniciada.

Cómo solucionarlo

1. Captura primero la cadena de redirecciones

Usa una solicitud de solo lectura desde un terminal, sustituyendo el marcador de posición por el hostname afectado:

curl -IL https://[your-hostname]

Esto solicita las cabeceras y sigue las redirecciones. Registra cada valor de Location: y cada código de estado HTTP. Prueba la URL exacta que falla, su versión HTTP y las formas www y no-www cuando corresponda. El panel Network del navegador proporciona evidencias similares.

Busca patrones como estos:

• HTTPS → HTTP → HTTPS
• no-www → www → no-www
• una URL que se redirige repetidamente a sí misma
• una redirección a una URL de inicio de sesión o canónica que inmediatamente redirige de vuelta

No empieces borrando cachés ni cambiando varios ajustes a la vez. La cadena ayuda a identificar qué capa requiere atención.

2. Corrige un bucle HTTP/HTTPS o de la CDN

Si una CDN o un reverse proxy gestiona la conexión HTTPS pública, revisa su modo SSL/TLS y el certificado y la configuración HTTPS del origen. El modo de conexión entre la CDN y el origen debe coincidir con lo que admite el origen. En Cloudflare, un origen que admite HTTPS correctamente generalmente requiere Full o Full (strict) en lugar de Flexible cuando el propio origen fuerza HTTPS.

Antes de cambiar el modo, confirma que tienes autorización para modificar la CDN y que el origen dispone de un certificado válido para el hostname cuando se utiliza la validación estricta del certificado. Cambiar la configuración TLS de la CDN puede afectar al tráfico activo, así que sigue el proceso de cambios aprobado o los requisitos de la ventana de mantenimiento.

3. Corrige la detección de HTTPS del proxy

Si la aplicación fuerza HTTPS mientras se ejecuta detrás de un proxy, configura la aplicación o el framework para confiar en el proxy previsto y reconocer el protocolo reenviado. Según la plataforma, estos ajustes pueden denominarse trust proxy, proxies de confianza o ajustes de force-SSL.

Confía en las cabeceras de protocolo reenviado únicamente cuando procedan de una ruta de proxy conocida y controlada. No confíes ciegamente en cabeceras enviadas por el cliente en un origen expuesto directamente. Consulta la documentación de la plataforma para conocer el ajuste correcto y vuelve a probar la cadena de redirecciones.

4. Resuelve la discrepancia entre www y no-www

Elige un hostname canónico y documéntalo. Revisa la CDN, la configuración del servidor web, las reglas de .htaccess cuando corresponda, los ajustes de URL del CMS y los plugins de redirecciones.

Mantén una única redirección autorizada para el hostname —por ejemplo, de no-www a www o de www a no-www— y elimina las reglas duplicadas u opuestas. Comprueba todas las variantes HTTP y HTTPS después del cambio. Un ajuste de URL canónica diferente del destino del servidor web puede recrear el bucle incluso cuando HTTPS está configurado correctamente.

5. Revisa el comportamiento de la aplicación, el inicio de sesión y las cookies

Si los usuarios anónimos pueden cargar la página, pero los usuarios con la sesión iniciada no, compara la cadena de redirecciones con y sin la cookie de sesión usando una cuenta de prueba autorizada o una ventana privada. Revisa los plugins de forzado de SSL, inicio de sesión, membresía y redirecciones, junto con la URL del sitio configurada en la aplicación.

Comprueba que las cookies de sesión utilicen el atributo Secure, el dominio y la ruta correctos para el hostname HTTPS elegido. Desactiva o cambia un plugin sospechoso cada vez, siguiendo el proceso de control de cambios. No elimines controles de autenticación o seguridad en un sitio de producción sin un plan de reversión.

6. Purga las redirecciones obsoletas y vuelve a probar

Después de corregir la configuración, purga las entradas relevantes de la CDN, el reverse proxy y la caché de páginas si tienes autorización para hacerlo. Las redirecciones del navegador también pueden persistir, así que vuelve a probar con curl, una ventana privada y, si es necesario, otra red o dispositivo.

Una prueba correcta debe llegar a la página prevista sin una secuencia repetitiva de Location. Comprueba el hostname canónico, el comportamiento de HTTP a HTTPS, el flujo de inicio de sesión y varias URL internas representativas, en lugar de probar únicamente la página de inicio.

Prevención y cómo verificar la solución

• Documenta el hostname canónico y el comportamiento previsto de HTTP a HTTPS antes de añadir una CDN, un reverse proxy, un plugin del CMS o una regla del servidor.
• Cuando sea posible, mantén cada decisión de redirección como autoridad en una sola capa y asegúrate de que las demás capas no emitan una regla opuesta.
• Al colocar un sitio detrás de un proxy, configura de forma deliberada la gestión del proxy de confianza y del protocolo reenviado; no aceptes indiscriminadamente cabeceras de reenvío enviadas por el cliente.
• Prueba la cadena completa de redirecciones después de realizar cambios en HTTPS, el hostname, la CDN, el CMS o los plugins, usando las URL exactas a las que acceden los usuarios.
• Incluye pruebas para usuarios anónimos, usuarios con sesión iniciada, www, no-www, HTTP y HTTPS en las comprobaciones de despliegue cuando esas rutas sean compatibles.
• Purga o versiona las cachés relevantes después de cambiar las redirecciones y verifica el resultado desde una ventana privada o un cliente limpio.

Preguntas frecuentes