WordPress: demasiadas redirecciones — Solución de bucles www/https/Cloudflare

Cambiaste “una pequeña opción” —quizá alternaste el SSL de Cloudflare, forzaste HTTPS o cambiaste el prefijo www— y ahora el sitio rebota como una bola: el navegador muestra Demasiadas redirecciones, el inicio de sesión no se mantiene y tu monitor de disponibilidad se volvió poeta.

Los bucles de redirección rara vez son misteriosos. Son simplemente sistemas distribuidos haciendo lo que les dijiste en cuatro lugares distintos y en el orden equivocado. Desenredémoslo con diagnósticos de grado producción, no con clics a ciegas.

Qué significa realmente “Demasiadas redirecciones”

Un navegador solicita una URL, recibe un redireccionamiento 301/302/307/308, lo sigue y sigue recibiendo redireccionamientos hasta alcanzar un límite (a menudo alrededor de 20–30 saltos). El error es el navegador protegiéndose de un bucle infinito. El bucle puede ocurrir en varias capas:

• Aplicación: WordPress cree que debería ser HTTPS o con www, y emite redirecciones.
• Servidor web: reglas de reescritura de Nginx/Apache fuerzan HTTPS o el host canónico, a menudo con una regex que atrapa todo.
• Borde/CDN: “Always Use HTTPS” de Cloudflare, Transform Rules, Page Rules o Workers redirigen antes de llegar al origin.
• Balanceador de carga / proxy inverso: la terminación TLS + cabeceras proxy ausentes hace que el origin piense que las peticiones son HTTP aunque el cliente use HTTPS.

Los bucles suelen seguir uno de estos patrones:

• HTTP ↔ HTTPS ida y vuelta: el borde dice “usa HTTPS”, el origin dice “no, usa HTTP”.
• www ↔ dominio apex ida y vuelta: una capa fuerza www y otra fuerza sin www.
• Conflicto esquema + host: HTTPS sin-www → HTTPS www → HTTP www → HTTP sin-www → …
• Bucle por cookies/sesiones: especialmente en /wp-admin o el checkout de WooCommerce cuando las cookies seguras y la detección de esquema discrepan.

Aquí tienes un modelo mental fiable: un bucle de redirección es una política de canonicalización en conflicto distribuida en sistemas que no comparten estado.

Topología del bucle de redirección: dónde nace el bucle

Depurar redirecciones es más rápido cuando mapeas la ruta de la petición:

1. Cliente → borde de Cloudflare (reglas, modo SSL, comportamiento HSTS, caché)
2. Cloudflare → Origin (esquema que usa Cloudflare para conectar, cabeceras que añade)
3. Puerta de entrada del origin (vhost y reglas de reescritura de Nginx/Apache)
4. PHP/WordPress (SiteURL/Home, wp_redirect(), plugins, lógica de is_ssl())
5. Salida (¿se reescriben los encabezados Location? ¿se cachean? ¿se mezclan?)

Cuando ves “Demasiadas redirecciones”, no buscas “la opción”. Buscas dos opiniones en conflicto sobre la URL canónica. Elimina una opinión.

Guion rápido de diagnóstico

Si estás de guardia, no tienes tiempo para filosofía. Haz esto en orden.

1) Observa la cadena de redirección desde fuera

Usa una herramienta que muestre cada salto, esquema, host y código de estado. Tu objetivo: identificar el punto de conmutación donde cambia (http→https o www→apex).

2) Identifica si Cloudflare está en el bucle

Si las respuestas incluyen cabeceras de Cloudflare (o tu DNS está proxied con la nube naranja), asume que Cloudflare puede estar reescribiendo o cacheando redirecciones. Determina el modo SSL configurado y cualquier característica de “forzar HTTPS”.

3) Evita Cloudflare para probar el comportamiento del origin

Consulta el origin directamente (o mediante override de hosts) con la misma cabecera Host. Si el origin por sí solo entra en bucle, arregla origin/WordPress. Si el origin está limpio, el bucle está en Cloudflare (o entre Cloudflare y origin por desacuerdo de modo SSL).

4) Decide una política de URL canónica

Elige exactamente un host canónico (www o apex) y exactamente un esquema (HTTPS). Luego aplícalo en un solo lugar —preferiblemente en el borde o en el servidor web—, no en WordPress y además en tres plugins.

5) Verifica cabeceras proxy y detección de esquema en WordPress

Si TLS termina antes del origin, WordPress debe conocer el esquema original vía cabeceras como X-Forwarded-Proto. Sin eso, WordPress piensa que es HTTP y “amablemente” redirige a lo que cree correcto.

6) Purga caches que recuerdan la redirección equivocada

Cloudflare puede cachear redirecciones. También los navegadores. También los plugins de caché de WordPress. Tu arreglo puede ser correcto y aún verse roto hasta que se purguen o eviten las caches.

Datos interesantes y contexto (porque la historia se repite)

• Hecho 1: La cabecera HTTP Host (virtual hosting) se generalizó a finales de los 90; antes muchos servidores asumían un sitio por IP. Las redirecciones basadas en Host se hicieron mucho más comunes después de eso.
• Hecho 2: 301 (Moved Permanently) es rutinariamente cacheado por navegadores e intermediarios. Un 301 malo puede perseguirte más que un 302 malo.
• Hecho 3: El modo “Flexible” de Cloudflare existe para sitios sin TLS en el origin, pero también es una forma clásica de crear bucles HTTP↔HTTPS cuando el origin fuerza HTTPS.
• Hecho 4: WordPress almacenó históricamente URLs canónicas en dos opciones—siteurl y home—y que no coincidan sigue siendo una de las formas más rápidas de inventar un bucle.
• Hecho 5: HSTS no redirige usando respuestas del servidor; actualiza las peticiones dentro del navegador. Eso es excelente para seguridad y confuso para “¿por qué todavía va a https?”.
• Hecho 6: Los códigos de redirección cambiaron con HTTP/1.1: 307 y 308 se introdujeron para preservar la semántica del método (POST sigue siendo POST). Algunos proxies todavía los manejan mal en casos límite.
• Hecho 7: Los patrones tempranos de “forzar SSL en admin” de WordPress preceden a los proxies con terminación TLS; muchos snippets asumen que el origin ve HTTPS y fallan detrás de balanceadores modernos.
• Hecho 8: Los CDN empezaron como aceleradores de estático; ahora incorporan lógica completa de petición/respuesta (Workers, reglas en el borde). Es poder—y también tres lugares extra donde puedes redirigir accidentalmente.

Una cita operativa que vale la pena tener en un post-it:

idea parafraseada — John Allspaw: “Los postmortems sin culpas funcionan porque se enfocan en cómo el sistema hizo posible la falla, no en quién apretó el botón.”

Tareas prácticas: comandos, salida esperada y decisiones

Estas tareas son la columna vertebral del diagnóstico real. Cada una incluye (a) comando, (b) qué significa la salida, (c) la decisión siguiente. Ejecútalas desde un shell que controles.

Task 1: Get the redirect chain (headers only)

cr0x@server:~$ curl -sS -I -L -o /dev/null -w '%{url_effective}\n%{http_code}\n' https://example.com
https://www.example.com/
200

Significado: Con -L, curl siguió redirecciones. La URL efectiva es donde terminaste. El código HTTP al final es la respuesta final.

Decisión: Si nunca llegas a 200 y curl falla con “maximum redirects followed”, captura la lista completa de saltos a continuación (Task 2). Si aterrizas en un host/esquema distinto al esperado, encuentra dónde ocurre la canonicalización.

Task 2: Print every hop (Location headers)

cr0x@server:~$ curl -sS -D - -o /dev/null http://example.com | sed -n '1,20p'
HTTP/1.1 301 Moved Permanently
Date: Fri, 26 Dec 2025 12:00:00 GMT
Location: https://example.com/
Server: cloudflare
CF-RAY: 8abc1234abcd1234-LHR

Significado: Puedes ver si la redirección es generada por Cloudflare (cabecera Server, CF-RAY) o por el origin.

Decisión: Si Cloudflare emite la redirección, inspecciona reglas/SSL mode en Cloudflare primero. Si no, ve a la configuración del origin.

Task 3: Ask curl to show the whole redirect trace

cr0x@server:~$ curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' -I https://example.com
301 https://www.example.com/

Significado: El servidor devolvió una redirección y curl te indica la siguiente URL.

Decisión: Si redirect_url cambia esquema/host inesperadamente, identifica qué capa es responsable evitando Cloudflare (Task 6/7).

Task 4: Check whether the browser is doing HSTS upgrades (from server side, infer)

cr0x@server:~$ curl -sS -I https://example.com | grep -i strict-transport-security
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Significado: HSTS está habilitado. Los navegadores pueden forzar HTTPS incluso si escribes HTTP.

Decisión: Si pruebas comportamiento HTTP, no confíes en una sesión normal del navegador. Usa curl, un perfil de navegador nuevo, o elimina HSTS temporalmente una vez que el sitio esté estable (con cuidado).

Task 5: Resolve DNS to confirm you’re actually using Cloudflare

cr0x@server:~$ dig +short example.com
104.21.12.34
172.67.98.76

Significado: Esas parecen IPs anycast de Cloudflare (no siempre, pero a menudo). Si ves las IPs del origin, puede que no estés proxied.

Decisión: Si está proxied, la configuración de Cloudflare importa. Si el DNS apunta a tu origin, céntrate en origin/WordPress.

Task 6: Bypass Cloudflare by hitting origin IP with Host header

cr0x@server:~$ curl -sS -I --resolve example.com:80:203.0.113.10 http://example.com
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
Server: nginx

Significado: --resolve fuerza a curl a hablar con la IP del origin manteniendo Host: example.com. Esta es la prueba más limpia de “¿Cloudflare es el problema?”.

Decisión: Si el origin mismo redirige en bucle (repite también para HTTPS), arregla origin/WordPress. Si el origin devuelve 200 limpio pero el camino a través de Cloudflare entra en bucle, corrige la configuración de Cloudflare.

Task 7: Test origin HTTPS directly (certificate might not match)

cr0x@server:~$ curl -sS -I -k --resolve example.com:443:203.0.113.10 https://example.com
HTTP/1.1 200 OK
Server: nginx

Significado: -k ignora la validación del certificado. Estás probando comportamiento, no la validez PKI.

Decisión: Si HTTPS→origin devuelve 200 pero Cloudflare en “Flexible” se conecta por HTTP, has encontrado el desajuste. Cambia el modo SSL de Cloudflare (detalles más adelante).

Task 8: Inspect Cloudflare-to-origin scheme assumptions via headers at origin

cr0x@server:~$ sudo tail -n 3 /var/log/nginx/access.log
198.51.100.23 - - [26/Dec/2025:12:01:02 +0000] "GET / HTTP/1.1" 301 169 "-" "Mozilla/5.0" "https"
198.51.100.23 - - [26/Dec/2025:12:01:03 +0000] "GET / HTTP/1.1" 301 169 "-" "Mozilla/5.0" "http"

Significado: Muchos formatos de Nginx incluyen $scheme o campos forward proto. Si ves alternancia “http” y “https” para la misma jornada de cliente, estás en territorio ping-pong.

Decisión: Arregla la aplicación de esquema canónico en una capa y asegúrate de que forwarded-proto sea respetado por WordPress.

Task 9: Verify WordPress SiteURL and Home (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get siteurl
http://www.example.com
cr0x@server:~$ wp option get home
https://example.com

Significado: Estos no deben pelearse entre sí. Aquí discrepan en esquema y host.

Decisión: Decide la URL canónica (por ejemplo https://example.com) y establece ambas a eso (Task 10). También revisa redirecciones codificadas en la configuración del servidor.

Task 10: Fix WordPress SiteURL/Home safely (WP-CLI)

cr0x@server:~$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.
cr0x@server:~$ wp option update home 'https://example.com'
Success: Updated 'home' option.

Significado: WordPress ahora está de acuerdo consigo mismo. Eso elimina una fuente mayor de redirecciones.

Decisión: Reprueba la cadena de redirección (Task 1/2). Si el bucle persiste, está en otro lugar (Cloudflare o servidor web).

Task 11: Find hardcoded WP_HOME/WP_SITEURL in wp-config.php

cr0x@server:~$ grep -nE "WP_HOME|WP_SITEURL" /var/www/html/wp-config.php
82:define('WP_HOME', 'https://www.example.com');
83:define('WP_SITEURL', 'https://www.example.com');

Significado: Estas constantes sobreescriben las opciones en BD. Las actualizaciones con WP-CLI no importarán si están definidas.

Decisión: Edítalas para que apunten a la URL canónica o elimínalas si quieres control desde la BD. Luego vuelve a probar.

Task 12: Check Cloudflare SSL mode symptoms by observing Location header scheme

cr0x@server:~$ curl -sS -I https://example.com | egrep -i 'HTTP/|location:|server:'
HTTP/2 301
location: http://example.com/
server: cloudflare

Significado: Solicitaste HTTPS y Cloudflare respondió con una redirección a HTTP. Eso casi siempre viene de una regla o de una canonicalización equivocada en borde/origin.

Decisión: Revisa “Always Use HTTPS”, Redirect Rules y el modo SSL en Cloudflare. También verifica que el origin no esté reescribiendo cabeceras Location de forma extraña.

Task 13: Nginx: list server blocks and look for return/rewrite

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "server_name|return 301|rewrite" | head
123:    server_name example.com www.example.com;
140:    return 301 https://$host$request_uri;

Significado: Tienes una redirección global a HTTPS usando $host. Si otra capa cambia el host, puedes entrar en bucle.

Decisión: Canonicaliza el host explícitamente (elige uno) en lugar de reflejar $host, y asegúrate de que las opciones de Cloudflare coincidan.

Task 14: Apache: locate RewriteRule forcing scheme/host

cr0x@server:~$ sudo apachectl -t -D DUMP_VHOSTS | head
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)
*:443                  example.com (/etc/apache2/sites-enabled/default-ssl.conf:2)
cr0x@server:~$ grep -RIn "RewriteRule|RewriteCond|Redirect " /etc/apache2/sites-enabled | head
/etc/apache2/sites-enabled/000-default.conf:12:RewriteCond %{HTTPS} !=on
/etc/apache2/sites-enabled/000-default.conf:13:RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Significado: Esto fuerza HTTPS según la visión de Apache de %{HTTPS}. Detrás de un proxy, Apache puede no verlo como on.

Decisión: Enseña a Apache sobre forwarded proto o termina TLS en Apache. De lo contrario seguirá redirigiendo aunque el cliente ya use HTTPS.

Task 15: Confirm what WordPress thinks the request scheme is (PHP snippet via wp-cli eval)

cr0x@server:~$ wp eval 'var_export([ "is_ssl" => is_ssl(), "https_server" => $_SERVER["HTTPS"] ?? null, "xfp" => $_SERVER["HTTP_X_FORWARDED_PROTO"] ?? null ]);'
array (
  'is_ssl' => false,
  'https_server' => NULL,
  'xfp' => 'https',
)

Significado: WordPress ve X-Forwarded-Proto: https pero is_ssl() sigue siendo false, dependiendo de cómo el servidor/PHP gestione el entorno.

Decisión: Implementa manejo de proxies confiables para que WordPress interprete forwarded proto correctamente (detalles en la sección WordPress/proxy). Si no puedes hacerlo de forma segura, aplica la canonicalización en el borde y mantén el origin consistente.

Task 16: Verify Cloudflare cache isn’t serving an old redirect

cr0x@server:~$ curl -sS -I https://example.com | egrep -i 'cf-cache-status|age|location|http/'
HTTP/2 301
location: https://www.example.com/
cf-cache-status: HIT
age: 834

Significado: Cloudflare está sirviendo una redirección cacheada. Tu origin podría ya estar corregido.

Decisión: Purga la caché relevante en Cloudflare y asegúrate de que la nueva redirección canónica sea correcta antes de reintroducir el caching.

Broma 1: Los bucles de redirección son el único tipo de “escalabilidad infinita” que la mayoría de sitios WordPress logra sin siquiera intentarlo.

Causas específicas de WordPress: SiteURL, Home, cookies y admin

1) SiteURL vs Home mismatch

WordPress usa dos URLs que suenan sinónimas porque fueron inventadas en eras distintas para propósitos ligeramente diferentes:

• siteurl: donde residen los archivos core de WordPress (wp-admin, wp-includes).
• home: la raíz pública del sitio.

En la mayoría de instalaciones deberían ser idénticas. Si divergen en esquema o host, WordPress puede “corregirse” a sí mismo con redirecciones. Cuando hay un proxy/CDN de por medio, esa corrección puede colisionar con otras correcciones.

Hacer: establece ambos en la URL canónica a menos que realmente ejecutes el core de WordPress en un subdirectorio.

Evitar: arreglarlo solo en la base de datos mientras wp-config.php lo sobreescribe, o viceversa. Elige una fuente de verdad.

2) FORCE_SSL_ADMIN and “helpful” security plugins

define('FORCE_SSL_ADMIN', true); fuerza SSL en el área de administración. Eso está bien cuando el origin ve HTTPS. Es generador de bucles cuando TLS termina en Cloudflare o en un load balancer y el origin ve HTTP.

Muchos plugins de seguridad replican este comportamiento, a veces con su propia lógica de redirección o configurando cookies con la bandera Secure mientras la app piensa que es HTTP. Así se generan bucles de inicio de sesión donde las credenciales son aceptadas pero la sesión nunca persiste.

3) WordPress behind a reverse proxy: make scheme detection boring

Si las peticiones llegan al origin por HTTP pero el usuario está en HTTPS, WordPress necesita saber que el esquema “real” es HTTPS. Típicamente eso se hace mediante:

• X-Forwarded-Proto: https
• CF-Visitor: {"scheme":"https"} (Cloudflare)

En un mundo ideal, tu servidor web establece $_SERVER['HTTPS']='on' cuando confía en las cabeceras del proxy. En el mundo real necesitas conectarlo explícitamente y restringir la confianza a las IPs conocidas del proxy. Si no, le das a atacantes la posibilidad de “pretender que soy https” y creas fallos de seguridad.

4) Cookies and domain/secure flags

Los bucles de redirección alrededor del login suelen venir de cookies con ámbito distinto al hostname actual. Ejemplo: cookie para www.example.com pero el usuario es redirigido a example.com. WordPress no ve la cookie, asume que no estás autenticado, redirige de nuevo, repetir.

De forma similar, si el navegador solo envía cookies Secure sobre HTTPS, pero algo te cambia a HTTP a mitad de cadena, pierdes el estado de sesión y acabas en un bucle que parece “no puede mantenerse conectado”.

Causas específicas de Cloudflare: modos SSL, reglas y caché

1) Cloudflare SSL/TLS modes: the loop factory

Cloudflare tiene varios modos SSL entre visitante↔Cloudflare y Cloudflare↔origin. El modo famoso por fallar:

• Cloudflare “Flexible”: el visitante conecta por HTTPS a Cloudflare, pero Cloudflare conecta al origin por HTTP.
• Tu origin (o WordPress) está configurado para forzar HTTPS.
• El origin responde con 301 Location: https://example.com.
• Cloudflare busca esa URL… pero sigue usando HTTP al origin (porque Flexible), recibe la redirección HTTPS otra vez, y has construido un bucle con entusiasmo empresarial.

Solución: No uses Flexible para WordPress si fuerzas HTTPS en el origin. Usa “Full” o “Full (strict)” con un certificado de origin válido. Si no puedes hacerlo todavía, deja de forzar HTTPS en el origin y deja que Cloudflare lo gestione (pero eso tiene compensaciones de seguridad).

2) “Always Use HTTPS” plus origin HTTPS redirects

La doble imposición no siempre es perjudicial, pero aumenta la complejidad. Si Cloudflare fuerza HTTPS y tu origin también lo fuerza basándose en una detección de esquema imperfecta, aún puedes entrar en bucle.

Mi preferencia: aplicar el esquema en el borde y configurar el origin para servir ambos sin redirigir (o redirigir solo cuando el origin vea con certeza el esquema correcto). Eso reduce carga y mantiene la canonicalización en una capa.

3) www/non-www redirect rules: choose one canonical host

Cloudflare puede hacer redirecciones de host mediante reglas. Tu origin también. WordPress también (basado en su URL almacenada). Si dejas que los tres lo hagan, básicamente pides un desacuerdo a las 2 a.m.

Elige uno:

• Opción A (canonicalización en el borde): Cloudflare gestiona www↔apex y HTTP→HTTPS. El origin sirve contenido sin redirecciones “útiles”.
• Opción B (canonicalización en origin): Nginx/Apache hace redirecciones canónicas. Cloudflare solo hace proxy y cachea.

Yo me inclino por Opción A cuando Cloudflare está delante, porque reduce hits al origin y evita involucrar PHP. Pero hazlo limpio y evita cachear redirecciones malas.

4) Cached redirects and “it’s still broken” theater

Cloudflare puede cachear 301/302. Los navegadores pueden cachear 301 agresivamente. Si pruebas una vez, puedes envenenar tus propios resultados.

Operativamente, confirma el comportamiento con headers que eviten caché o desde un entorno limpio. Y cuando lo arregles, purga la caché del borde después de verificar que el nuevo comportamiento es correcto—purgar demasiado pronto solo amplifica el impacto de un arreglo erróneo.

5) Workers and Transform Rules: the silent redirect authors

En entornos corporativos, a veces el bucle de redirecciones no es una casilla. Es un Worker desplegado hace seis meses para normalizar URLs o establecer cookies. Los Workers pueden reescribir Location, cambiar esquemas y hacer redirecciones condicionales según cabeceras o geo. Eso es poderoso.

También es la razón por la que tu argumento “pero verifiqué Page Rules” no impresionará a tu yo futuro.

Patrones de Nginx/Apache que muerden

Nginx: the $host mirror trap

Esto es común y a menudo incorrecto en despliegues multi-capa:

• return 301 https://$host$request_uri;

Si el Host entrante a veces es www y a veces apex (porque una capa previa lo alterna), estás reflejando ese Host y preservando el conflicto. Mejor: redirige explícitamente a tu host canónico, no a lo que apareció.

Nginx: scheme detection behind proxy

Cuando Nginx está detrás de un proxy, $scheme es el esquema entre proxy y origin, no entre usuario y borde. Si Cloudflare conecta por HTTP, $scheme es http aunque el usuario esté en HTTPS. Si escribes redirecciones basadas en $scheme, podrías redirigir usuarios HTTPS a HTTPS (bien) pero hacerlo para siempre (mal) según cómo el proxy reenvíe.

Apache: RewriteCond %{HTTPS} !=on isn’t proxy-aware

El %{HTTPS} de Apache refleja si Apache mismo negoció TLS. Si TLS se termina upstream, estará off. Apache entonces redirigirá a HTTPS—aunque el usuario ya lo esté. Con un proxy upstream que siempre conecta por HTTP, puedes entrar en bucle.

La solución correcta es una configuración consciente del proxy (y, críticamente, limitar la confianza a las IPs del proxy).

Broma 2: La forma más rápida de encontrar todas las reglas de redirección en tu stack es romper producción y esperar a que cinco equipos juren que ellos no añadieron nada.

Errores comunes: síntoma → causa raíz → solución

Aquí están los patrones que más veo, con acciones correctivas específicas.

1) Síntoma: la petición HTTPS redirige a HTTP (o alterna)

Causa raíz: Regla de Cloudflare forzando HTTP, origin mal configurado para redirecciones canónicas, o «Flexible» SSL interactuando con enforcement HTTPS en origin.

Solución: Usa “Full”/“Full (strict)” cuando el origin fuerza HTTPS. Elimina cualquier regla en el borde que redirija a HTTP. Asegúrate de que el origin no genere Location con HTTP.

2) Síntoma: apex redirige a www, y www redirige a apex

Causa raíz: Reglas canónicas en conflicto en distintas capas (Cloudflare + Nginx + WordPress). O mismatch en SiteURL/Home de WordPress.

Solución: Elige un host canónico. Implementa exactamente una regla de redirección (preferiblemente en el borde o en el servidor web). Establece WordPress home y siteurl al host canónico.

3) Síntoma: /wp-admin sigue redirigiendo a /wp-admin/ (o a login) eternamente

Causa raíz: WordPress no detecta HTTPS correctamente, causando mismatch de cookies/ sesión segura. A veces agravado por plugins de caché.

Solución: Asegura que forwarded proto sea confiable y esté mapeado para que is_ssl() sea correcto. Deshabilita caché para las rutas de admin. Verifica dominio de cookies y host canónico alineados.

4) Síntoma: Funciona cuando Cloudflare está pausado (solo DNS), falla cuando está proxied

Causa raíz: Reglas/SSL mode/caché de Cloudflare o el origin espera TLS directo.

Solución: Alinea el modo SSL (“Full strict” idealmente), revisa reglas en el borde y purga redirecciones cacheadas.

5) Síntoma: Solo algunos usuarios ven el bucle; otros están bien

Causa raíz: 301 cacheado en el navegador, HSTS, lógica específica por región en el borde, o POPs con caché inconsistente.

Solución: Prueba con curl y un perfil de navegador limpio. Purga caché en el borde. Revisa HSTS y evita cambiar esquemas durante la remediación.

6) Síntoma: El bucle aparece tras habilitar “Always Use HTTPS” o un plugin SSL de WordPress

Causa raíz: Enforcement duplicado más detección de proxy incorrecta.

Solución: Quita uno de los enforcers. Si Cloudflare impone HTTPS, desactiva plugins de redirección SSL en WordPress y elimina redirecciones de servidor redundantes salvo que sean necesarias.

Tres microhistorias corporativas desde las trincheras de redirección

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa tenía un sitio marketing WordPress detrás de Cloudflare y un load balancer gestionado. Un desarrollador activó un plugin de hardening que “forzaba HTTPS en todo lugar”. El cambio se aprobó porque sonaba obviamente correcto y el entorno staging no usaba la misma ruta de proxy.

En minutos, la página principal se volvió inalcanzable en navegadores. El monitoreo mostró un pico de respuestas 301. El on-call hizo la verificación clásica: consulte el origin directamente—ok. A través de Cloudflare—bucle de redirección.

La suposición equivocada fue sutil: creían que el origin vería HTTPS cuando los usuarios usaran HTTPS. No fue así. TLS terminaba en el load balancer, y la conexión desde el balancer al origin era HTTP. WordPress miró $_SERVER['HTTPS'], no vio nada y emitió redirecciones a HTTPS. Cloudflare (en modo Flexible) también hablaba HTTP al origin y persiguió la redirección eternamente.

La solución fue aburrida e inmediata: cambiar el modo SSL de Cloudflare a Full, añadir un certificado de origin válido y quitar la característica de redirección del plugin. La solución a largo plazo fue mejor: un runbook que definiera la propiedad de canonicalización (borde) y una política de confianza de cabeceras proxy en el origin.

Mini-historia 2: La optimización que salió mal

Un equipo quiso “reducir carga en el origin” cacheando más agresivamente en Cloudflare. Alguien habilitó caché de HTML y permitió cachear respuestas 301. Funcionó—hasta que no funcionó.

Una semana después, una campaña de marketing cambió el host canónico de www a apex. Actualizaron las URLs de WordPress y añadieron una redirección de host en el borde. Probó bien en un navegador. Luego llegaron tickets de soporte: mitad del mundo todavía era redirigido al host antiguo y luego rebotaba, llegando al límite de redirecciones.

El fallo no fue la idea de cachear; fue cachear lo equivocado en el momento equivocado. Cloudflare había cacheado redirecciones antiguas en distintos POPs. Algunos clientes habían cacheado un 301 permanentemente también. El sistema quedó inconsistente: distintos usuarios recibían distintas “verdades” sobre la URL canónica, lo que alimentó la propia lógica de redirección de WordPress y dominios de cookies.

La solución incluyó purgas de caché dirigidas, cambiar temporalmente a 302 durante la migración y—lo más importante—reducir los “autores” de redirecciones a una sola capa para evitar deriva acumulada. La recomendación del postmortem fue directa: no cachees redirecciones a menos que hayas operacionalizado cómo invalidarlas.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba varias propiedades WordPress con una plantilla estándar borde/origin. Nada sofisticado: un documento de política de URL canónica, una verificación obligatoria de “cadena de redirección” en la revisión de cambios y un pequeño script que validaba tanto www como apex sobre HTTP y HTTPS antes del despliegue.

Un viernes, una migración DNS movió un dominio a otra cuenta de Cloudflare. La nueva cuenta tenía una regla por defecto: “Always Use HTTPS”. El origin ya forzaba HTTPS, pero lo hacía en Apache con %{HTTPS} !=on. Detrás de Cloudflare, Apache nunca veía HTTPS. Eso debería haber sido un bucle clásico.

No se convirtió en incidente porque sus pruebas preflight lo detectaron inmediatamente. El script mostró que la cadena de redirección nunca alcanzó 200. Bloquearon el cambio, ajustaron Apache para ser proxy-aware (y limitar la confianza), y solo entonces habilitaron la regla de borde.

La lección es irritante pero cierta: la mejor solución de redirección es evitar que el bucle llegue a producción. No es glamorosa. Es fiable.

Listas de verificación / plan paso a paso

Step 0: Decide the canonical URL policy (don’t skip)

• Esquema canónico: HTTPS.
• Host canónico: elige o example.com o www.example.com.
• Una capa de aplicación: borde o origin (no ambas salvo que entiendas la interacción).

Step 1: Capture redirect matrix (4-way test)

Prueba todas las combinaciones y registra dónde termina cada una:

• http + apex
• http + www
• https + apex
• https + www

Quieres que las cuatro acaben exactamente en una URL canónica en 0–2 saltos.

Step 2: Fix Cloudflare SSL mode first when Cloudflare is in front

• Si el origin soporta TLS: usa Full (strict) cuando sea posible; si no, Full.
• Evita Flexible cuando el origin fuerza HTTPS.

Step 3: Remove duplicate redirect logic

• Desactiva plugins de WordPress que “fuerzan SSL” si el borde/origin ya lo hace.
• Elimina reglas de reescritura de Nginx/Apache que fuerzan host si Cloudflare lo hace.
• Mantén SiteURL/Home de WordPress alineados con la URL canónica.

Step 4: Make origin proxy-aware (securely)

• Asegura que el origin establezca el esquema correcto en base a cabeceras de proxy confiables.
• Restringe la confianza a rangos IP de proxies conocidos (IPs de Cloudflare y tu load balancer).
• Valida que is_ssl() retorne true para tráfico HTTPS de usuario.

Step 5: Purge caches and retest

• Purga la caché de Cloudflare para el sitio (o al menos las redirecciones cacheadas).
• Evita la caché del navegador (perfil nuevo / incógnito no siempre basta por HSTS).
• Repite las pruebas con curl y verifica que la URL final sea estable.

Step 6: Put a guardrail in CI/change review

• Añade una prueba automática de cadena de redirección para la matriz 4-way.
• Falla cambios si alguna ruta excede 2 redirecciones o nunca alcanza 200/403/401 según lo esperado.

FAQ

1) ¿Por qué WordPress redirige aunque yo no haya configurado redirecciones?

WordPress aplica URLs canónicas basadas en sus opciones home/siteurl y la interpretación de la petición. Puede redirigir al host/esquema “correcto”, especialmente en rutas de administración.

2) ¿Cuál es la forma más rápida de saber si Cloudflare es la fuente de la redirección?

Comprueba las cabeceras de respuesta por marcadores de Cloudflare (como CF-RAY) y luego evita Cloudflare usando curl --resolve para golpear el origin directamente con la misma cabecera Host.

3) ¿Es Cloudflare “Flexible” SSL alguna vez seguro para WordPress?

Puedes usarlo, pero es frágil. Si tu origin o WordPress alguna vez fuerza HTTPS, Flexible es un riesgo de bucle. En producción, “Full (strict)” es la respuesta adulta.

4) Lo arreglé, pero algunos usuarios aún ven redirecciones erróneas. ¿Por qué?

Los 301 malos se cachean en navegadores y en Cloudflare. Además, HSTS actualiza del lado cliente. Purga la caché del borde y prueba desde un entorno limpio; considera 302 temporales durante transiciones.

5) ¿Dónde debo forzar www/no-www: en WordPress, Nginx o Cloudflare?

Elige uno. Si Cloudflare siempre está delante, la imposición en el borde suele ser la más simple. Si a veces omites Cloudflare (regionales, clientes API), hazlo en el origin. Lo que no debes hacer es imponerl o en los tres.

6) ¿Por qué /wp-admin entra en bucle más que la página principal?

Los flujos de administración dependen de cookies y banderas Secure. Si WordPress piensa que la petición es HTTP puede establecer cookies o redirecciones inconsistentes, causando rebotes de login.

7) ¿Cómo manejo redirecciones sin romper peticiones POST (formularios de checkout)?

Evita redirigir POST si es posible. Si debes redirigir, usa códigos de estado que preserven la semántica del método cuando proceda (307/308), y valida que tu stack de borde/proxy los soporte. A menudo la mejor solución es corregir host/esquema canónico antes de que el usuario envíe.

8) ¿Puede un plugin causar un bucle aunque SiteURL/Home sean correctos?

Sí. Plugins de seguridad, SSL y caché comúnmente añaden redirecciones o cambian el comportamiento de cookies. Desactívalos temporalmente para aislar. Si desactivarlos lo arregla, quita la funcionalidad de redirección del plugin y aplica la canonicalización en otro lugar.

9) ¿Por qué solo falla en redes móviles o países específicos?

Diferentes POPs de Cloudflare pueden servir redirecciones cacheadas distintas, y reglas/Workers geo-específicos pueden comportarse diferente. Trátalo como un problema de caché distribuida: revisa cabeceras, identificadores de POP y purga.

10) ¿Cuál es el “cambio único” que arregla la mayoría de bucles?

Alinea el modo SSL de Cloudflare con la realidad del origin (Full/Full strict) y haz que WordPress coincida en la URL canónica (SiteURL/Home). Luego elimina la lógica de redirección duplicada.

Conclusión: próximos pasos que realmente puedes desplegar

Los bucles de redirección ocurren cuando múltiples capas discuten sobre cuál es la URL “real”. Tu trabajo es detener la discusión.

1. Elige una URL canónica (HTTPS + un host).
2. Prueba dónde está el bucle usando la inspección de saltos con curl y pruebas de bypass al origin.
3. Arregla la capa responsable: modo/ reglas SSL de Cloudflare, reglas de reescritura del origin, o SiteURL/Home y cabeceras proxy de WordPress.
4. Elimina la lógica duplicada de redirección para que no reaparezca con el próximo “pequeño” cambio.
5. Purga redirecciones cacheadas y valida la matriz 4-way (http/https × www/apex) para que aterrice en una URL rápidamente.

Si no haces otra cosa: deja de usar autores de redirección en conflicto. Producción ama la simplicidad. También ama no despertarte a mitad de la noche.