Causas Subyacentes y Soluciones para el Error “Demasiadas Redirecciones”

El error "Too Many Redirects" — mostrado en los navegadores como ERR_TOO_MANY_REDIRECTS y correspondiente a un bucle de redirección HTTP — ocurre cuando un servidor web y un cliente entran en una cadena circular de redirecciones que nunca se resuelve en un destino final. El navegador cancela la solicitud después de superar su umbral de redirecciones (normalmente 20 saltos en Chrome) y muestra este error en lugar de cargar la página.

Esto no es un fallo de red vago. Es un fallo determinista causado por una configuración incorrecta específica en las reglas de su servidor, configuración SSL, valores de la base de datos del CMS, configuración del CDN o datos de redirección en caché. Cada instancia tiene una causa raíz rastreable, y cada causa raíz tiene una solución precisa. Esta guía las analiza todas con la profundidad técnica necesaria para resolver el problema de forma permanente — ya sea que esté ejecutando un sitio WordPress, una aplicación personalizada o una pila de servidor sin procesar en un entorno de VPS Hosting.

Qué ocurre realmente durante un bucle de redirección

Cuando un navegador solicita una URL, el servidor puede responder con un código de estado 301 Moved Permanently, 302 Found o 307 Temporary Redirect apuntando a una nueva ubicación. El navegador sigue ese encabezado de ubicación, realiza otra solicitud y espera una respuesta 200 OK en algún punto de la cadena.

Un bucle de redirección se forma cuando:

• La URL A redirige a la URL B, y la URL B redirige de vuelta a la URL A (bucle de dos saltos)
• La URL A redirige a la URL B, que redirige a la URL C, que redirige de vuelta a la URL A (bucle de múltiples saltos)
• Una sola URL se redirige a sí misma (bucle autorreferencial)

Los navegadores no realizan bucles indefinidamente. Chrome y Firefox terminan después de aproximadamente 20 redirecciones y muestran ERR_TOO_MANY_REDIRECTS. Safari muestra "Safari Can't Open the Page." El comportamiento HTTP subyacente es idéntico en todos ellos.

Causas raíz y soluciones precisas

1. Reglas de redirección mal configuradas en .htaccess o Nginx

La causa técnicamente más común son las reglas de reescritura conflictivas o circulares en la capa de configuración del servidor.

Ejemplo de Apache .htaccess con un bucle roto:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Esta regla redirige /page a /page — un bucle autorreferencial. De manera similar, dos reglas que redirigen entre /old-url y /new-url en direcciones opuestas causarán el mismo fallo.

Cómo diagnosticar:

Abra su archivo .htaccess y rastree manualmente cada directiva RewriteRule y Redirect. Busque cualquier regla donde el patrón de destino pueda coincidir con el origen de otra regla.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Para Nginx, el problema equivalente aparece en bloques server o location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Audite su configuración de Nginx con:

nginx -T | grep -A3 "return 301|rewrite"

Solución: Asegúrese de que cada regla de redirección tenga un origen y destino únicos y no superpuestos. Use el indicador [L] en Apache para detener el procesamiento de reglas una vez que se encuentre una coincidencia. En Nginx, prefiera return 301 sobre rewrite para mayor claridad y para evitar encadenamientos no deseados.

2. Configuración incorrecta de la redirección HTTP a HTTPS

Esta es la causa más común en entornos de alojamiento modernos, particularmente después de agregar un Certificado SSL sin actualizar la configuración a nivel de aplicación.

El patrón de fallo se ve así:

• El servidor web fuerza todo el tráfico HTTP a HTTPS mediante .htaccess o la configuración de Nginx
• La aplicación (por ejemplo, WordPress) tiene su opción siteurl o home configurada como http:// en la base de datos
• La aplicación entonces redirige las solicitudes HTTPS de vuelta a HTTP
• El bucle es: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Redirección HTTPS correcta en Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Redirección HTTPS correcta en Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Problema crítico: Si está detrás de un balanceador de carga o proxy inverso (incluido Cloudflare), el servidor backend puede no ver HTTPS directamente. El proxy termina SSL y reenvía la solicitud como HTTP a su origen. Su servidor entonces ve %{HTTPS} = off y redirige a HTTPS nuevamente — creando un bucle.

La solución es verificar el encabezado X-Forwarded-Proto en su lugar:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Incompatibilidad del modo SSL entre Cloudflare y el CDN

Si está usando Cloudflare u otro CDN frente a su servidor de origen, el modo de cifrado SSL/TLS debe coincidir con el estado real del certificado de su origen.

El escenario de bucle más común en Cloudflare: El modo SSL está configurado como Flexible, y el servidor de origen tiene una regla .htaccess que fuerza HTTP a HTTPS. Cloudflare envía HTTP al origen, el origen redirige a HTTPS, Cloudflare recibe esa redirección, envía HTTP nuevamente — bucle infinito.

Solución: Configure el modo SSL de Cloudflare como Full (Strict) y asegúrese de que su origen tenga un certificado válido. Alternativamente, si debe usar Flexible, elimine la redirección HTTP→HTTPS de su servidor de origen por completo y deje que Cloudflare la gestione mediante una Page Rule o el interruptor "Always Use HTTPS".

También deshabilite Automatic HTTPS Rewrites en Cloudflare si su origen ya gestiona las redirecciones — tener ambos activos duplica la lógica de redirección.

4. Incompatibilidad en la configuración de URL de WordPress

WordPress almacena sus URL canónicas en dos campos de base de datos: siteurl (la URL de instalación del núcleo de WordPress) y home (la URL pública). Cuando estos valores entran en conflicto con las reglas de redirección del servidor o entre sí, un bucle es casi inevitable.

Verificar los valores actuales mediante WP-CLI:

wp option get siteurl
wp option get home

O consultar la base de datos directamente:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Ambos valores deben usar el mismo protocolo (https://) y el mismo formato de dominio (con o sin www) que impone la configuración de su servidor.

Solución mediante WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Solución mediante wp-config.php (anula los valores de la base de datos, útil cuando no puede acceder al panel de administración):

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Conflictos de plugins: Los plugins de gestión de redirecciones (Redirection, Simple 301 Redirects, el módulo de redirección de Yoast SEO) pueden crear reglas de redirección almacenadas en la base de datos que entran en conflicto con las reglas a nivel de servidor. Renombre temporalmente el directorio de plugins para aislar el problema:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Reactive los plugins uno a uno después de confirmar que el bucle ha desaparecido.

5. Caché del navegador y redirecciones 301 en caché

Los navegadores almacenan en caché las respuestas 301 Moved Permanently de forma agresiva — por diseño. Si previamente se sirvió una redirección 301 para una URL y luego se cambió el destino de la redirección, el navegador puede seguir la redirección antigua en caché, que puede apuntar a un destino que ahora genera un bucle.

Este es un escenario particularmente engañoso porque el bucle puede no reproducirse en un navegador nuevo o en otro dispositivo, lo que lleva a los administradores a concluir incorrectamente que el servidor está bien.

Pasos de diagnóstico:

1. Abra la URL en una ventana de incógnito/privada (sin datos en caché)
2. Pruebe con curl para omitir completamente el caché del navegador:

curl -I -L --max-redirs 10 https://example.com

1. Use un rastreador de cadenas de redirección en línea (por ejemplo, redirect-checker.org o httpstatus.io) para ver cada salto en el lado del servidor

Solución: Limpie el caché del navegador y las cookies para el dominio afectado. En Chrome: Configuración > Privacidad y seguridad > Borrar datos de navegación > seleccione Imágenes y archivos en caché + Cookies.

Para el caché del lado del servidor (Varnish, Redis, OPcache o un plugin de caché como W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Conflictos de redirección www vs. no-www

Una fuente de bucles de redirección frecuentemente ignorada es el manejo inconsistente del subdominio www. Si su servidor redirige www.example.com a example.com y simultáneamente redirige example.com a www.example.com, tiene un bucle.

Verifique su DNS actual y la configuración de redirección:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Configuración correcta de Apache (no-www canónico):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Asegúrese de que esta regla no esté emparejada con otra regla que redirija la versión no-www de vuelta a www.

7. Cookies corruptas o en conflicto

Algunas aplicaciones usan cookies para gestionar el estado de redirección (por ejemplo, redirecciones de inicio de sesión, detección de idioma, marcos de pruebas A/B). Si una cookie almacena un destino de redirección que a su vez desencadena otra redirección, el bucle es impulsado por la lógica de la aplicación en lugar de la configuración del servidor.

Diagnóstico: Pruebe la URL con todas las cookies borradas para ese dominio. En Chrome DevTools (F12), vaya a Application > Storage > Cookies, seleccione el dominio y elimine todas las entradas. Recargue la página.

Si el error desaparece después de borrar las cookies, el problema está en la sesión de su aplicación o en la lógica de redirección, no en la configuración del servidor.

Comparación: Escenarios comunes de bucles de redirección y sus soluciones

Flujo de trabajo de diagnóstico sistemático

Antes de tocar cualquier archivo de configuración, siga esta secuencia para aislar la causa:

Paso 1 — Reproducir sin caché:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Esto muestra cada salto de redirección y el código de respuesta final. Si ve las mismas URLs repitiéndose, ha confirmado el bucle e identificado qué URLs están involucradas.

Paso 2 — Verificar los registros de errores del servidor:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Paso 3 — Aislar la capa:

• Si el bucle desaparece cuando comenta las reglas .htaccess, el problema está en la configuración de Apache
• Si desaparece cuando omite Cloudflare (pruebe mediante IP directa), el problema está en la configuración del CDN
• Si desaparece cuando renombra el directorio de plugins, el problema está en un plugin de WordPress
• Si desaparece en modo incógnito pero no en modo normal, el problema es el caché del navegador o las cookies

Paso 4 — Validar el enlace del certificado SSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Un certificado inválido o no coincidente puede causar fallos en la redirección HTTPS que se manifiestan como bucles.

Prevención de bucles de redirección en producción

Una vez resuelto, estas prácticas previenen la recurrencia:

• Use una única regla de redirección canónica que gestione tanto HTTP→HTTPS como www→no-www en un solo paso, no dos reglas separadas que puedan interactuar
• Pruebe las cadenas de redirección antes de implementar usando curl -L o un verificador de redirecciones en línea después de cualquier cambio de configuración
• Configure las redirecciones 301 solo cuando sean permanentes — use 302 durante las pruebas para que los navegadores no almacenen en caché la redirección
• Documente cada regla de redirección en su .htaccess o configuración de Nginx con comentarios en línea que expliquen la intención
• Monitoree con herramientas de tiempo de actividad que sigan cadenas de redirección y alerten cuando el número de saltos supere un umbral

Para equipos que gestionan múltiples sitios en un VPS con cPanel, el módulo de Redirecciones de cPanel proporciona una interfaz visual para gestionar las reglas de redirección, pero escribe en .htaccess — verifique siempre el resultado manualmente después de usar la interfaz gráfica.

Si está ejecutando un sitio de alto tráfico o múltiples dominios, un Servidor Dedicado le brinda control total sobre la configuración de Nginx o Apache a nivel de sistema, eliminando las restricciones de entornos compartidos que pueden complicar la depuración de redirecciones.

Para sitios que usan Paneles de Control VPS como Plesk o DirectAdmin, las reglas de redirección pueden gestionarse tanto a través de la interfaz del panel como directamente en los archivos de configuración — verifique ambas ubicaciones para asegurarse de que no se contradigan entre sí.

Lista de verificación técnica de puntos clave

Use esto como lista de verificación previa al diagnóstico de ERR_TOO_MANY_REDIRECTS:

• [ ] Ejecute curl -v -L --max-redirs 25 para mapear la cadena completa de redirecciones antes de tocar cualquier configuración
• [ ] Confirme que tanto siteurl como home en WordPress coincidan con el protocolo y dominio que impone su servidor
• [ ] Verifique que el modo SSL de Cloudflare sea Full (Strict) si su origen tiene un certificado válido
• [ ] Compruebe que .htaccess o la configuración de Nginx use X-Forwarded-Proto en lugar de %{HTTPS} cuando esté detrás de un proxy
• [ ] Asegúrese de que las redirecciones www y no-www sean unidireccionales — solo una forma canónica
• [ ] Deshabilite temporalmente todos los plugins relacionados con redirecciones y reactive uno a la vez
• [ ] Limpie el caché del navegador y pruebe en modo incógnito para descartar respuestas 301 en caché
• [ ] Inspeccione las cookies de la aplicación en busca de estado de redirección que pueda estar generando un bucle
• [ ] Valide que el certificado SSL sea válido y esté correctamente vinculado al dominio
• [ ] Después de corregir, use 302 temporalmente antes de cambiar a 301 para evitar volver a almacenar en caché una redirección rota

Preguntas frecuentes

¿Cuál es la diferencia entre ERR_TOO_MANY_REDIRECTS y un código de estado HTTP 310?

ERR_TOO_MANY_REDIRECTS es un error del lado del cliente del navegador que se activa después de que el navegador supera su límite de seguimiento de redirecciones (normalmente 20). HTTP 310 es un código de estado raramente utilizado que significa "Too Many Redirects" a nivel de protocolo. En la práctica, casi todos los errores de bucle de redirección que se encuentran en producción son el ERR_TOO_MANY_REDIRECTS del lado del navegador — no una respuesta 310 emitida por el servidor.

¿Por qué el bucle de redirección aparece solo en algunos navegadores o dispositivos pero no en otros?

La razón más común es una redirección 301 en caché almacenada en el navegador que apunta a un destino ahora inválido. Dado que las respuestas 301 se almacenan en caché indefinidamente de forma predeterminada, un navegador que visitó previamente la URL puede seguir una cadena de redirección obsoleta. Probar en modo incógnito o en un dispositivo nuevo omite este caché y revela el comportamiento actual del servidor.

¿Cómo soluciono un bucle de redirección en WordPress cuando no puedo acceder al panel de administración?

Agregue las siguientes líneas directamente a wp-config.php para anular los valores de URL de la base de datos, luego acceda al panel de administración para corregir la configuración correctamente:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Alternativamente, actualice los valores directamente en la base de datos usando wp-cli o una consulta MySQL directa contra la tabla wp_options.

¿Puede un bucle de redirección afectar el posicionamiento SEO?

Sí. Un bucle de redirección no devuelve ninguna respuesta 200 OK, lo que significa que Googlebot no puede rastrear ni indexar la URL afectada. Si el bucle afecta a su página de inicio o páginas de destino clave, resultará en la desindexación con el tiempo. Además, cualquier valor de enlace 301 que pase a través de la URL en bucle se pierde efectivamente. Resolver el bucle rápidamente y verificar la rastreabilidad en Google Search Console es esencial.

¿Cómo evito que Cloudflare cause bucles de redirección con mi configuración SSL?

Configure el modo de cifrado SSL/TLS de Cloudflare como Full (Strict) en el panel SSL/TLS. Esto garantiza que Cloudflare se comunique con su origen a través de HTTPS usando un certificado validado, eliminando el bucle HTTP↔HTTPS que el modo Flexible crea cuando el servidor de origen también impone HTTPS. Además, deshabilite "Automatic HTTPS Rewrites" si su origen o .htaccess ya gestiona la redirección de HTTP a HTTPS para evitar la lógica de doble redirección.