Soluciones para bucles de redirección en dominios personalizados: www, apex, cookies y TLS

Qué se rompe cuando añades un dominio tarde

Agregar un dominio personalizado después de que tu app ya funciona en una URL por defecto parece simple. En la práctica, la app a menudo sigue “recordando” la dirección antigua. Tu proveedor de dominio, la capa de hosting, el CDN/proxy y la configuración de la app pueden intentar ayudar redirigiendo el tráfico. Si dos lugares no están de acuerdo, los usuarios pueden quedarse rebotando entre URLs.

Los primeros signos suelen ser obvios:

• Páginas que se recargan una y otra vez
• Errores de “Too many redirects”
• Una página principal que solo carga a veces

El inicio de sesión es otro síntoma clásico. Un usuario inicia sesión, regresa a la app y aterriza de nuevo en la pantalla de login porque la cookie de sesión no se mantiene.

Los cambios de dominio tardíos son más propensos a romper porque ya tienes suposiciones funcionando. Las reglas de redirección se crearon para la URL original (por ejemplo, un dominio de vista previa de la plataforma). Las cookies estaban limitadas al host antiguo. TLS y las configuraciones de seguridad se emitieron para un nombre de host y no para el otro.

Un desajuste pequeño puede provocar varios síntomas a la vez. Por ejemplo, forzar HTTPS en el CDN mientras la app también fuerza HTTPS (y ambos reescriben www hacia el apex de forma distinta) puede crear un bucle. Mientras tanto, si tu dominio de cookie está en www.example.com pero los usuarios aterrizan en example.com, el login puede fallar aunque las redirecciones parezcan “correctas”.

Un escenario común: tu prototipo generado por IA funcionó en una URL de Replit. Añades www.yourapp.com después, apuntas el DNS y de repente la mitad de tus usuarios ven errores de redirección y la otra mitad no puede permanecer logueada.

El objetivo es directo: una URL canónica (o www o apex) que sea estable, mantenga sesiones y cargue correctamente por HTTPS.

Términos clave: www, apex, redirecciones, cookies y TLS

Los bucles de redirección rara vez son un gran fallo único. Normalmente son unos pocos ajustes pequeños que no coinciden.

Dominio apex vs subdominio www: el dominio apex es la raíz, como example.com. La versión www es un subdominio, como www.example.com. Ambos pueden apuntar a la misma app, pero debes elegir uno como la dirección canónica.

Redirección: una redirección le dice al navegador “ve allí en su lugar”. Por ejemplo, enviar example.com a www.example.com. Un bucle de redirección ocurre cuando el navegador queda rebotando entre dos direcciones (o dos reglas), como www -> apex -> www -> apex, hasta que el navegador se rinde.

Los bucles suelen ocurrir cuando tu app redirige de una forma y otra capa (hosting, CDN, proxy, configuración de la plataforma) redirige de vuelta.

TLS/SSL: TLS es lo que muestra el candado en el navegador. Cifra el tráfico y demuestra que el sitio coincide con su nombre de host. Si falta TLS, se emitió para el host equivocado (solo www y no el apex, o viceversa), o hay reglas HTTP antiguas mezcladas, los navegadores pueden advertir a los usuarios, bloquear peticiones o fallar en cargar archivos importantes.

Cookies y sesiones de login: las cookies son pequeños datos que el navegador guarda para un sitio, a menudo usados para mantener la sesión iniciada. Las cookies son estrictas sobre dónde aplican. Los problemas más comunes son:

• Dominio de la cookie: una cookie establecida para www.example.com no funcionará de forma fiable en example.com.
• Secure: muchas cookies de autenticación solo deben enviarse por HTTPS.
• SameSite: afecta los flujos de inicio de sesión, especialmente con redirecciones o proveedores terceros.

Si tu app “te loguea” y luego de inmediato te devuelve a la pantalla de inicio de sesión, un desajuste del dominio de la cookie es una de las primeras cosas que debes comprobar.

Por qué ocurren bucles con www y apex

Un bucle suele significar que varias reglas de redirección se están ejecutando. Una regla dice “ir a https”, otra dice “ir a www” y una tercera dice “volver al apex”. Cada regla puede tener sentido por separado. Juntas, pueden crear un rebote del que el navegador no puede escapar.

El desencadenante más común es tener más de un sitio haciendo redirecciones al mismo tiempo. Tu app puede forzar HTTPS, tu panel de hosting puede forzar www y un CDN o una configuración del framework puede reescribir el host.

El orden también importa. Si HTTP -> HTTPS ocurre primero y luego www -> apex ocurre después (o al revés), puedes terminar rebotando entre dos URL “canónicas”. Esto es fácil de introducir cuando añades un dominio tarde y copias configuraciones de entornos antiguos sin verificar cómo se combinan.

La confusión del proxy es otra causa frecuente. Tu app puede recibir tráfico por HTTP desde la plataforma (la conexión de origen), aunque los usuarios visiten por HTTPS. Si cabeceras proxy como X-Forwarded-Proto faltan o se ignoran, la app piensa que debe subir a HTTPS y la plataforma vuelve a aplicar sus propias reglas.

Las redirecciones cacheadas pueden hacer que el problema parezca aleatorio. Los navegadores cachean respuestas 301 y los CDNs también pueden hacerlo. Arreglas las reglas, pero tu máquina de pruebas sigue en bucle porque aún respeta una redirección antigua.

Algunas formas rápidas de acotar el problema:

• Prueba en una ventana privada para reducir efectos de caché del navegador.
• Revisa una solicitud en Network de DevTools y lee las cabeceras Location.
• Desactiva temporalmente las redirecciones en la app o en el host para encontrar la regla “extra”.
• Confirma que las cabeceras proxy/forwarded estén como tu app espera.

Paso a paso: elige un dominio canónico y arregla las redirecciones

Un bucle de redirección suele significar que dos (o más) capas discuten sobre dónde “debe” vivir tu sitio. La solución más rápida es elegir una URL canónica y hacer que todas las demás versiones apunten a ella.

Primero, decide si quieres el apex o la versión www como la dirección verdadera. Cualquiera está bien. La consistencia es lo que importa en DNS, TLS, ajustes de la app y redirecciones.

Una solución simple en 5 pasos

1. Elige el host canónico: escoge https://example.com o https://www.example.com. Escríbelo.
2. Elige un solo lugar para redirigir: haz redirecciones en una sola capa si es posible (edge/CDN, balanceador o la app). Varias capas suelen causar bucles.
3. Crea una regla única: redirige el host no canónico al host canónico, conservando la misma ruta y query string. Evita reglas de “limpieza” adicionales hasta que lo básico funcione.
4. Haz que la app genere el host canónico: revisa ajustes como base URL, public URL, site URL y auth callback URL. Si la app crea enlaces absolutos con el host equivocado, los usuarios rebotarán entre dominios.
5. Prueba desde un estado de navegador limpio: usa una ventana privada o un perfil nuevo para que viejas cookies y redirecciones en caché no oculten el comportamiento real.

Después de configurar la redirección, confirma que no estés forzando también redirecciones dentro de la app (por ejemplo, “enforce HTTPS” junto con una regla en el edge que también reescribe protocolo/host). Una redirección basta.

Una comprobación rápida: escribe ambas variantes (www y apex) en la barra de direcciones. Debes aterrizar en la misma URL final cada vez, con a lo sumo una redirección. Si cambia de un lado a otro, algo sigue redirigiendo y debe eliminarse o desactivarse.

Problemas de dominio de cookie que rompen el login y las sesiones

Si el login funciona en un host (por ejemplo, www.example.com) pero falla en otro (example.com), normalmente son las cookies. Señales comunes: pantallas infinitas de “por favor inicia sesión”, sesiones que desaparecen tras un refresh o usuarios que se desconectan al moverse entre hosts.

Un error frecuente es establecer Domain de la cookie en el lugar equivocado. Si pones Domain=www.example.com, esa cookie no se enviará a example.com (ni cubrirá otros subdominios). Si necesitas una sesión compartida entre subdominios, normalmente debes usar Domain=example.com (el apex). Si no necesitas compartir, las cookies solo para el host (sin atributo Domain) suelen ser más seguras porque no se filtran a otros subdominios.

Los cambios a HTTPS también pueden romper sesiones. Tras una migración tardía, las apps suelen cambiar a HTTPS y comenzar a forzar redirecciones. Si la cookie de sesión no tiene Secure, los navegadores pueden negarse a enviarla en peticiones HTTPS. Si SameSite es demasiado estricto, pasos cross-site como OAuth o páginas de retorno de pago pueden fallar silenciosamente, dejando al usuario “logueado” en una pestaña y anónimo en otra.

Los subdominios añaden otra trampa: app.example.com y api.example.com pueden necesitar acordar el ámbito de la cookie. Si tu frontend espera una cookie de auth que estableció la API, ambos deben usar dominios compatibles y tus ajustes de CORS y credenciales deben permitir que las cookies se incluyan.

Para confirmar lo que ocurre, abre DevTools y comprueba:

• Qué cookies se crean tras el login, y sus valores Domain, Path, SameSite y Secure
• Si la cookie aparece en ambos hosts, www y apex
• Si las peticiones muestran un encabezado Cookie siendo enviado, o si el navegador lo está descartando

Los problemas de cookies a menudo se confunden con problemas de redirección. A veces la cadena de redirecciones está bien, pero la sesión no se mantiene, así que la app sigue enviando a los usuarios a iniciar sesión.

Configuraciones TLS que causan advertencias, bloqueos y fallos de carga

Los problemas de TLS a menudo parecen “el sitio está caído”, pero lo real es que el navegador se niega a confiar en lo que ve. Durante un cambio de dominio, puede sentirse inconsistente porque algunos usuarios alcanzan www y otros el apex.

Empieza por lo básico: tu certificado debe cubrir los nombres exactos que sirves. Una incompatibilidad común es tener un certificado solo para www.example.com, mientras que el DNS o las redirecciones aún permiten que usuarios aterricen en example.com (o al revés). Los navegadores tratan esos nombres como distintos.

Saber dónde termina realmente HTTPS

HTTPS puede terminar en distintos puntos: un CDN, un balanceador, un reverse proxy o el servidor de la app. Los problemas aparecen cuando una capa piensa que el tráfico es HTTPS pero la siguiente capa cree que es HTTP. Eso puede causar bucles (la app sigue “subiendo” a HTTPS) y puede romper cookies seguras.

Si no estás seguro, verifica:

• Qué componente tiene el certificado TLS adjunto (CDN, balanceador o servidor)
• Si la app recibe una cabecera del protocolo original (a menudo X-Forwarded-Proto)
• Si la app está configurada para confiar en el proxy
• Si las rutas www y apex se manejan de la misma manera

HSTS y contenido mixto: dos formas sencillas de quedarse atascado

HSTS indica al navegador “usa siempre HTTPS para este dominio”. Si habilitas HSTS antes de que HTTPS esté correcto en todas partes (incluyendo redirecciones, APIs y subdominios), puedes forzar a los usuarios a fallos difíciles de revertir rápidamente.

El contenido mixto es el otro problema silencioso. Si tu HTML carga scripts, imágenes o CSS por http, el navegador puede bloquearlos en una página https. El resultado puede parecer un “botón de login que no hace nada” o “la página carga sin estilos”.

Trampas de configuración de la app: proxies, base URLs, callbacks de auth

Muchos problemas de “redirección” no son solo DNS. Son la app discutiendo con la plataforma de hosting sobre cuál es la URL pública real.

Proxies y las cabeceras en las que tu app confía

Si tu app está detrás de un reverse proxy o CDN (común en hosts gestionados), la petición que llega a tu servidor puede parecer HTTP, incluso cuando el visitante usó HTTPS. Las apps manejan esto con cabeceras como X-Forwarded-Proto y X-Forwarded-Host.

Si tu framework no confía en esas cabeceras, puede pensar que cada petición es insegura y forzar una redirección a HTTPS. Si la plataforma ya está forzando HTTPS, el usuario puede rebotar entre reglas.

También vigila ajustes como “force HTTPS”, “trust proxy” y “secure cookies only”. Son buenos ajustes, pero deben coincidir con cómo tu plataforma termina TLS.

Base URLs, callbacks, CORS e integraciones

Una vez que elijas un host canónico (www o apex), necesitas actualizar todos los lugares que almacenan una URL completa. Si aunque sea uno apunta al host antiguo, puedes tener logins rotos, handshakes OAuth fallidos o llamadas API que fallan sin mucho feedback.

Lugares comunes que requieren atención:

• Base URL de la app (usada para construir enlaces absolutos y redirecciones)
• URLs de callback o redirect de autenticación (los proveedores OAuth son estrictos)
• Orígenes permitidos para CORS (el host del frontend debe coincidir exactamente)
• Endpoints de webhooks (pagos, email, CRM, etc.)
• Variables de entorno como NEXTAUTH_URL, PUBLIC_URL o similares

Ejemplo: tu página de login está en https://www.example.com, pero tu proveedor OAuth está configurado con https://example.com/auth/callback. El proveedor redirige al apex, tu app redirige a www y el proveedor rechaza la respuesta porque la URL de callback ya no coincide.

Errores comunes que empeoran el problema

La mayoría de problemas de dominio empeoran cuando cambias ajustes en tres lugares a la vez. Una redirección que parece inocua en tu app puede competir con una redirección en tu CDN o proveedor de hosting, y acabas con un bucle difícil de detectar.

El patrón “funcionó un minuto y luego volvió a fallar” suele significar que hay caché involucrada. El navegador cachéo una redirección, un proxy cachéo otra y ahora las peticiones toman caminos distintos según dónde empiecen.

Errores que causan más problemas:

• Activar redirecciones en varias capas (panel de hosting, CDN/edge y la app).
• Añadir más redirecciones hasta que una parece funcionar mientras rompe llamadas API, callbacks o assets.
• Olvidar que las cookies de login y los callbacks de auth siguen ligados al dominio antiguo.
• Habilitar HSTS demasiado pronto.
• Probar solo en un perfil de navegador y no ver lo que ven los nuevos usuarios.

Un hábito simple de pruebas evita horas de conjeturas: verifica en un perfil nuevo (o incognito), luego en un segundo navegador y después en móvil. Si el comportamiento difiere, probablemente estás luchando con caché, cookies o HSTS, no con la regla de redirección que acabas de cambiar.

Comprobaciones rápidas antes de darlo por arreglado

Antes de dejar de depurar, ejecuta comprobaciones en una ventana normal del navegador (no incógnito) y en una incógnito. Los problemas de redirección y cookies a menudo se ocultan hasta que repites un flujo de login.

Comprobaciones de redirección (la regla “exactamente una vez”)

Escribe cada variante en la barra y observa la URL final. Quieres un salto limpio, no un rebote entre hosts o protocolos.

• http://yourdomain.com debe ir a https:// exactamente una vez.
• http://www.yourdomain.com debe ir a https:// exactamente una vez.
• El host no canónico (www o apex) debe redirigir a tu host canónico exactamente una vez.
• Pegar la URL canónica final otra vez no debe redirigir.

Incluso si un host siempre redirige, ambos deben presentar un certificado válido durante el handshake TLS.

Comprobaciones de sesión y candado

Inicia sesión en el host canónico, luego refresca, cierra la pestaña y vuelve a abrir el sitio. Si te desconecta, sospecha un desajuste de dominio de cookie, ajustes de SameSite o un callback apuntando al host equivocado.

También revisa los indicadores de seguridad del navegador. Debes ver el candado válido en apex y en www (aunque uno redirija inmediatamente). Luego abre un par de páginas clave y confirma que no haya alertas de contenido mixto (por ejemplo, un script o imagen en http://).

Un ejemplo realista: añadir un dominio después de un prototipo generado por IA

Un fundador lanza un prototipo SaaS generado por IA desde una URL de vista previa (como un subdominio de plataforma). Las inscripciones funcionan, el dashboard carga y los pagos pasan una prueba rápida. Luego añaden un dominio personalizado la noche antes de una demo y todo se rompe: el sitio rebota entre www y el apex, el login los vuelve a mandar al sign-in y el navegador muestra advertencias de seguridad.

Lo que cambió no es una sola cosa. El navegador ahora ve un host diferente, así que las cookies pueden dejar de coincidir. Los proveedores OAuth (Google, GitHub, etc.) pueden rechazar la redirección porque la URL de callback cambió. Y la capa de hosting puede empezar a forzar HTTPS mientras la app sigue generando URLs HTTP internamente.

Un plan de recuperación:

• Elige un host canónico (www o apex) y haz que todo apunte allí.
• Pon redirecciones en un solo lugar y busca un solo salto: no canónico -> canónico.
• Ajusta el alcance de las cookies para que coincida con el plan canónico, y marca las cookies de auth como Secure cuando uses HTTPS.
• Actualiza ajustes de auth: callback URLs, orígenes permitidos y cualquier base URL codificada.
• Vuelve a probar en una sesión de navegador limpia para evitar que cookies antiguas oculten el problema real.

Si te encuentras cambiando tres paneles a la vez (config de la app, proveedor de auth, reglas del hosting) y el comportamiento sigue cambiando, pausa y simplifica. Los bucles de redirección y los errores de sesión pueden parecer aleatorios porque una cookie obsoleta o un paso de redirección extra cambia el resultado.

Próximos pasos: asegurar una configuración de dominio estable

Escribe primero tu URL fuente-de-verdad. Incluye esquema y host, por ejemplo https://www.example.com (o el apex). Luego sé explícito sobre la única regla de redirección que quieres: todos los demás hosts deben aterrizar en esa URL exacta con un 301 único.

Después, enumera todos los lugares que pueden redirigir o influir en sesiones: configuraciones de dominio/DNS, reglas de CDN o edge, balanceadores o proxies, base URL de la app y callbacks de auth, y ajustes de cookie/sesión. El objetivo es propiedad simple: un lugar maneja redirecciones, un lugar termina TLS y un lugar define la base pública.

Si la app fue generada por herramientas como Lovable, Bolt, v0, Cursor o Replit, asume que hay valores por defecto ocultos y deriva de configuración. Un prototipo puede funcionar en un host porque el framework detecta URLs automáticamente y luego fallar tras un cambio tardío cuando añades un proxy, un CDN o una política HTTPS más estricta.

Si estás atrapado en un bucle y la base de código está desordenada, FixMyMess (fixmymess.ai) se especializa en diagnosticar y reparar apps generadas por IA, incluyendo reglas de redirección, alcance de cookies/sesiones y configuración TLS/proxy. Una auditoría de código gratuita puede identificar rápidamente los pocos desajustes que están causando toda la reacción en cadena.