Résoudre les boucles de redirection de domaine personnalisé pour www, domaine apex, cookies et TLS

Ce qui casse quand vous ajoutez un domaine tardivement

Ajouter un domaine personnalisé après que votre app fonctionne déjà sur une URL par défaut semble simple. En pratique, l'app garde souvent la « mémoire » de l'ancienne adresse. Votre fournisseur de domaine, la couche d'hébergement, le CDN/proxy et les réglages de l'app peuvent tous essayer d'aider en redirigeant le trafic. Si deux endroits ne sont pas d'accord, les utilisateurs peuvent se retrouver coincés à rebondir entre des URL.

Les premiers signes sont généralement évidents :

• Pages qui se rechargent sans fin
• Erreurs « Trop de redirections »
• Une page d'accueil qui ne se charge que parfois

La connexion est un autre symptôme classique. Un utilisateur se connecte, est renvoyé vers l'app, puis retombe sur l'écran de connexion parce que le cookie de session ne persiste pas.

Les changements tardifs de domaine cassent plus facilement parce que vous avez déjà des hypothèses de fonctionnement en place. Des règles de redirection ont été écrites pour l'URL d'origine (comme un domaine de preview). Les cookies ont été limités à l'ancien hôte. TLS et les paramètres de sécurité ont été émis pour un nom d'hôte mais pas pour l'autre.

Un petit désaccord peut déclencher plusieurs symptômes à la fois. Par exemple, forcer HTTPS au niveau du CDN alors que l'app force aussi HTTPS (et que les deux réécrivent www vers l'apex de manière différente) peut créer une boucle. Pendant ce temps, si votre domaine de cookie est www.example.com mais que les utilisateurs atterrissent sur example.com, la connexion peut échouer même si les redirections semblent « correctes ».

Un scénario courant : votre prototype généré par IA fonctionnait sur une URL Replit. Vous ajoutez www.yourapp.com plus tard, pointez le DNS, et soudain la moitié de vos utilisateurs voient des erreurs de redirection et l'autre moitié ne reste pas connectée.

L'objectif est simple : une URL canonique (soit www, soit l'apex) qui reste stable, maintient les sessions et se charge proprement en HTTPS.

Termes clés : www, apex, redirections, cookies et TLS

Les boucles de redirection ne sont rarement une grosse défaillance unique. Ce sont généralement quelques petits réglages qui ne sont pas alignés.

Domaine apex vs sous-domaine www : le domaine apex est le nom racine, comme example.com. La version www est un sous-domaine, comme www.example.com. Ils peuvent tous deux pointer vers la même app, mais vous devriez en choisir un comme adresse canonique.

Redirection : une redirection dit au navigateur « va là-bas à la place ». Par exemple, envoyer example.com vers www.example.com. Une boucle de redirection se produit quand le navigateur reste coincé à rebondir entre deux adresses (ou deux règles), comme www -> apex -> www -> apex, jusqu'à ce qu'il abandonne.

Les boucles surviennent souvent lorsque votre app redirige d'un côté, mais qu'une autre couche (hébergement, CDN, proxy, réglage de la plateforme) redirige dans l'autre sens.

TLS/SSL : TLS est ce qui affiche le cadenas dans le navigateur. Il chiffre le trafic et prouve que le site correspond à son nom d'hôte. Si TLS manque, est émis pour le mauvais hôte (seulement www mais pas l'apex, ou inversement), ou est mélangé avec d'anciennes règles HTTP, les navigateurs peuvent alerter les utilisateurs, bloquer des requêtes ou refuser silencieusement de charger des fichiers importants.

Cookies et sessions de connexion : les cookies sont de petites données que le navigateur stocke pour un site, souvent utilisées pour vous garder connecté. Les cookies sont stricts quant à l'endroit où ils s'appliquent. Les erreurs courantes sont :

• Domaine du cookie : un cookie défini pour www.example.com ne fonctionnera pas de manière fiable sur example.com.
• Secure : beaucoup de cookies d'auth doivent être envoyés uniquement sur HTTPS.
• SameSite : affecte les flux de connexion, surtout lorsque des redirections ou des fournisseurs tiers sont impliqués.

Si votre app « connecte » puis vous renvoie immédiatement à la page de connexion, un mauvais domaine de cookie est l'une des premières choses à vérifier.

Pourquoi les boucles arrivent avec www et l'apex

Une boucle signifie généralement que plusieurs règles de redirection s'exécutent. Une règle dit « aller en HTTPS », une autre dit « aller vers www », et une troisième dit « revenir à l'apex ». Chaque règle peut sembler raisonnable individuellement. Ensemble, elles peuvent créer un rebond dont le navigateur ne sort pas.

Le déclencheur le plus courant est d'avoir plus d'un endroit qui fait des redirections en même temps. Votre app peut forcer HTTPS, votre panneau d'hébergement peut forcer www, et un CDN ou un réglage de framework peut aussi réécrire l'hôte.

L'ordre compte aussi. Si HTTP -> HTTPS se produit d'abord, puis www -> apex vient ensuite (ou l'inverse), vous pouvez accidentellement rebondir entre deux URL « canoniques ». C'est facile à introduire quand vous ajoutez un domaine tard et copiez des réglages d'environnements plus anciens sans vérifier comment ils se combinent.

La confusion des proxies est une autre cause fréquente. Votre app peut recevoir du trafic en HTTP depuis la plateforme (la connexion d'origine), même si les utilisateurs visitent en HTTPS. Si des en-têtes proxy comme X-Forwarded-Proto sont manquants ou ignorés, l'app pense devoir monter en HTTPS, et la plateforme réapplique ensuite ses propres règles.

Les redirections mises en cache peuvent rendre le problème aléatoire. Les navigateurs mettent en cache les réponses 301, et les CDN peuvent aussi les mettre en cache. Vous corrigez les règles, mais votre machine de test continue de boucler parce qu'elle respecte encore une ancienne redirection.

Quelques moyens rapides pour réduire le champ :

• Testez en fenêtre privée pour réduire l'effet du cache du navigateur.
• Vérifiez une requête dans l'onglet Réseau des DevTools et lisez les en-têtes Location.
• Désactivez temporairement les redirections dans l'app ou l'hôte pour trouver la règle « en trop ».
• Confirmez que les en-têtes proxy/forwarded sont définis comme votre app s'y attend.

Étape par étape : choisissez un domaine canonique et corrigez les redirections

Une boucle de redirection signifie généralement que deux (ou plusieurs) couches se disputent l'endroit où votre site « devrait » vivre. La solution la plus rapide est de choisir une URL canonique et de faire en sorte que toutes les autres versions pointent vers elle.

D'abord, décidez si vous voulez l'apex ou la version www comme adresse unique. Les deux conviennent. La cohérence est ce qui importe à travers DNS, TLS, réglages d'app et redirections.

Une correction simple en 5 étapes

1. Choisissez l'hôte canonique : optez pour https://example.com ou https://www.example.com. Notez-le.
2. Choisissez un seul endroit pour rediriger : faites les redirections dans une seule couche si possible (edge/CDN, load balancer ou app). Les couches multiples sont la cause habituelle de boucles.
3. Créez une règle unique : redirigez l'hôte non canonique vers l'hôte canonique en conservant le même chemin et les mêmes query strings. Évitez les règles de « nettoyage » supplémentaires tant que les bases ne fonctionnent pas.
4. Faites générer l'app avec l'hôte canonique : vérifiez les réglages comme base URL, public URL, site URL et auth callback URL. Si l'app construit des liens absolus avec le mauvais hôte, les utilisateurs rebondiront entre domaines.
5. Testez à partir d'un état de navigateur propre : utilisez une fenêtre privée ou un profil neuf pour que les anciens cookies et redirections mises en cache ne masquent pas le comportement réel.

Après avoir mis la redirection en place, confirmez que vous ne forcez pas aussi des redirections à l'intérieur de l'app (par exemple « forcer HTTPS » plus une règle edge qui réécrit aussi le protocole/l'hôte). Une redirection suffit.

Un contrôle rapide : tapez les deux variantes (www et apex) dans la barre d'adresse. Vous devez arriver sur la même URL finale à chaque fois, avec au maximum une redirection. Si ça bascule d'un côté à l'autre, quelque chose redirige encore et doit être retiré ou désactivé.

Problèmes de domaine de cookie qui cassent la connexion et les sessions

Si la connexion fonctionne sur un hôte (par exemple www.example.com) mais échoue sur l'autre (example.com), ce sont généralement les cookies. Signes courants : écrans de connexion sans fin, sessions qui disparaissent après un rafraîchissement, ou utilisateurs déconnectés quand ils passent d'un hôte à l'autre.

Une erreur fréquente est de définir Domain sur la mauvaise valeur. Si vous mettez Domain=www.example.com, ce cookie ne sera pas envoyé pour example.com (et ne couvrira pas d'autres sous-domaines). Si vous avez besoin d'une session partagée entre sous-domaines, il faut généralement Domain=example.com (l'apex). Si vous n'avez pas besoin de partage, les cookies liés à l'hôte seul (aucun attribut Domain) sont souvent plus sûrs car ils ne peuvent pas fuiter vers d'autres sous-domaines.

Les changements vers HTTPS peuvent aussi casser des sessions. Après une migration tardive, les apps forcent souvent HTTPS et commencent à rediriger. Si le cookie de session n'a pas Secure, les navigateurs peuvent refuser de l'envoyer sur des requêtes HTTPS. Si SameSite est trop strict, des étapes cross-site comme les connexions OAuth ou les pages de retour de paiement peuvent échouer silencieusement, laissant l'utilisateur « connecté » dans un onglet et anonyme dans un autre.

Les sous-domaines ajoutent un piège : app.example.com et api.example.com doivent s'accorder sur la portée du cookie. Si votre frontend attend un cookie d'auth défini par l'API, les deux doivent utiliser des domaines compatibles, et vos réglages CORS et d'inclusion des credentials doivent permettre l'envoi des cookies.

Pour confirmer, ouvrez les DevTools du navigateur et vérifiez :

• Quels cookies sont définis après la connexion, et leurs valeurs Domain, Path, SameSite et Secure
• Si le cookie apparaît sur www et l'apex
• Si les requêtes montrent un en-tête Cookie envoyé, ou si le navigateur le laisse tomber

Les problèmes de cookie sont souvent confondus avec des problèmes de redirection. Parfois la chaîne de redirections est correcte, mais la session ne tient pas, donc l'app renvoie les utilisateurs vers la page de connexion.

Paramètres TLS qui causent avertissements, blocages et échecs de chargement

Les problèmes TLS ressemblent souvent à « le site est en panne », mais la vraie cause est que le navigateur refuse de faire confiance à ce qu'il voit. Lors d'un changement de domaine, cela peut sembler incohérent parce que certains utilisateurs atteignent www et d'autres atteignent l'apex.

Commencez par l'essentiel : votre certificat doit couvrir exactement les noms d'hôtes que vous servez. Une erreur courante est d'avoir un certificat pour www.example.com uniquement, tandis que le DNS ou les redirections laissent encore des utilisateurs atterrir sur example.com (ou l'inverse). Les navigateurs considèrent ces noms comme différents.

Sachez où s'arrête réellement le HTTPS

Le HTTPS peut terminer à différents endroits : un CDN, un load balancer, un reverse proxy, ou votre serveur d'app. Les problèmes commencent quand une couche croit que le trafic est HTTPS, mais la suivante croit qu'il est HTTP. Cela peut provoquer des boucles (l'app continue d'« upgrader » vers HTTPS) et casser les cookies sécurisés.

Si vous n'êtes pas sûr, vérifiez :

• Quel composant possède le certificat TLS (CDN, load balancer ou serveur)
• Si l'app reçoit un en-tête de protocole original (souvent X-Forwarded-Proto)
• Si l'app est configurée pour faire confiance au proxy
• Si les routes www et apex sont traitées de la même façon

HSTS et contenu mixte : deux façons simples de rester bloqué

HSTS dit au navigateur « utilisez toujours HTTPS pour ce domaine ». Si vous activez HSTS avant que HTTPS soit correct partout (incluant les APIs et sous-domaines), vous pouvez enfermer les utilisateurs dans des échecs difficiles à annuler rapidement.

Le contenu mixte est l'autre problème silencieux. Si votre HTML charge des scripts, images ou CSS en http, le navigateur peut les bloquer sur une page en https. Le résultat peut ressembler à « le bouton de connexion ne fait rien » ou « la page se charge sans style ».

Pièges de configuration d'app : proxies, base URLs, callbacks d'auth

Beaucoup de problèmes de « redirection » ne concernent pas le DNS. C'est votre app qui se dispute avec votre plateforme d'hébergement sur la vraie URL publique.

Proxies et les en-têtes que votre app doit faire confiance

Si votre app est derrière un reverse proxy ou un CDN (commun sur les hébergements managés), la requête qui atteint votre serveur peut sembler être en HTTP, même si le visiteur utilisait HTTPS. Les apps gèrent cela avec des en-têtes comme X-Forwarded-Proto et X-Forwarded-Host.

Si votre framework ne fait pas confiance à ces en-têtes, il peut penser que chaque requête est non sécurisée et forcer une redirection vers HTTPS. Si la plateforme force déjà HTTPS, l'utilisateur peut rebondir entre les règles.

Faites aussi attention aux paramètres comme « force HTTPS », « trust proxy » et « secure cookies only ». Ce sont de bons réglages, mais ils doivent correspondre à la façon dont votre plateforme termine TLS.

Base URLs, callbacks, CORS et intégrations

Une fois que vous avez choisi un hôte canonique (www ou apex), vous devez mettre à jour tous les endroits qui stockent une URL complète. Si ne serait-ce qu'un seul réglage pointe encore vers l'ancien hôte, vous pouvez obtenir des connexions cassées, des callbacks OAuth échoués ou des appels API qui ratent sans beaucoup d'indication.

Endroits courants à vérifier :

• URL de base de l'app (utilisée pour construire des liens et redirections absolues)
• URLs de callback ou redirection d'auth (les fournisseurs OAuth sont stricts)
• Origines autorisées pour le CORS (l'hôte frontend doit correspondre exactement)
• Endpoints de webhooks (paiements, email, CRM, etc.)
• Variables d'environnement comme NEXTAUTH_URL, PUBLIC_URL ou similaires

Exemple : votre page de connexion est sur https://www.example.com, mais votre fournisseur OAuth est configuré avec https://example.com/auth/callback. Le fournisseur redirige vers l'apex, votre app redirige vers www, et le fournisseur rejette la réponse parce que l'URL de callback ne correspond plus.

Erreurs courantes qui aggravent le problème

La plupart des problèmes de domaine s'aggravent quand vous changez des réglages à trois endroits à la fois. Une redirection qui semble inoffensive dans votre app peut se battre avec une redirection sur votre CDN ou hébergeur, et vous vous retrouvez avec une boucle difficile à repérer.

Le schéma « ça a marché une minute, puis c'est redevenu cassé » signifie généralement que le cache est impliqué. Le navigateur a mis en cache une redirection, un proxy en a mis une autre, et maintenant les requêtes prennent des chemins différents selon leur point de départ.

Erreurs qui causent le plus de problèmes :

• Activer les redirections à plusieurs niveaux (panneau d'hébergement, CDN/edge et app).
• Ajouter des redirections jusqu'à ce qu'une semble marcher, tout en cassant les appels API, callbacks ou assets.
• Oublier que les cookies de connexion et les callbacks d'auth sont encore liés à l'ancien domaine.
• Activer HSTS trop tôt.
• Tester uniquement sur un profil de navigateur et manquer ce que verront les nouveaux utilisateurs.

Une habitude de test simple évite des heures de recherche : vérifiez dans un profil neuf (ou incognito), puis dans un second navigateur, puis sur mobile. Si le comportement diffère, vous vous battez probablement contre du cache, des cookies ou HSTS, pas contre votre dernière règle de redirection.

Vérifications rapides avant de considérer le problème réglé

Avant d'arrêter le debug, faites des vérifications dans une fenêtre normale (non incognito) et dans une fenêtre incognito. Les redirections et problèmes de cookie se cachent souvent jusqu'à ce que vous répétiez un flux de connexion.

Vérifications de redirection (la règle du "exactement une fois")

Tapez chaque variante dans la barre d'adresse et observez l'URL finale. Vous voulez un seul saut propre, pas un rebond entre hôtes ou protocoles.

• http://yourdomain.com doit aller vers https:// exactement une fois.
• http://www.yourdomain.com doit aller vers https:// exactement une fois.
• L'hôte non canonique (www ou apex) doit rediriger vers l'hôte canonique exactement une fois.
• Re-coller l'URL canonique finale ne doit pas provoquer de redirection.

Même si un hôte redirige toujours, les deux hôtes doivent présenter un certificat valide pendant la poignée TLS.

Vérifications de session et du cadenas

Connectez-vous sur l'hôte canonique, puis rafraîchissez, fermez l'onglet et rouvrez le site. Si vous êtes déconnecté, suspectez une incompatibilité de domaine de cookie, des réglages SameSite ou un callback d'auth pointant vers le mauvais hôte.

Vérifiez aussi les indicateurs de sécurité du navigateur. Vous devez voir un cadenas valide sur l'apex et le www (même si l'un redirige immédiatement). Ensuite, ouvrez quelques pages clés et confirmez qu'il n'y a pas d'avertissements de contenu mixte (par exemple, un ancien http:// pour un script ou une image).

Un exemple réaliste : ajouter un domaine après un prototype généré par IA

Un fondateur expédie un prototype SaaS généré par IA depuis une URL de preview (comme un sous-domaine de plateforme). Les inscriptions fonctionnent, le tableau de bord se charge et les paiements passent un test rapide. Puis il ajoute un domaine personnalisé la veille d'une démo et tout casse : le site rebondit entre www et l'apex, la connexion renvoie sans cesse à la page d'auth, et le navigateur affiche des avertissements de sécurité.

Ce qui a changé n'est pas une seule chose. Le navigateur voit un hôte différent, donc les cookies peuvent ne plus correspondre. Les fournisseurs OAuth (Google, GitHub, etc.) peuvent rejeter la redirection parce que l'URL de callback a changé. Et la couche d'hébergement peut commencer à forcer HTTPS alors que l'app génère encore des URLs HTTP en interne.

Un plan de récupération :

• Choisissez un hôte canonique (www ou apex) et faites en sorte que tout pointe vers lui.
• Placez les redirections en un seul endroit et visez un saut unique : non-canonique -> canonique.
• Corrigez la portée des cookies pour correspondre au plan canonique, et marquez les cookies d'auth Secure lors de l'utilisation de HTTPS.
• Mettez à jour les réglages d'auth : URLs de callback, origines autorisées, et toute URL de base codée en dur.
• Re-testez dans une session de navigateur propre pour éviter que d'anciens cookies ne masquent le vrai problème.

Si vous vous surprenez à changer trois tableaux de bord à la fois (config app, fournisseur d'auth, règles d'hébergement) et que le comportement continue de varier, marquez une pause et simplifiez. Les boucles de redirection et les bugs de session peuvent paraître aléatoires parce qu'un cookie périmé ou une étape de redirection en plus change le résultat.

Prochaines étapes : stabiliser la configuration du domaine

Notez d'abord votre URL de référence. Incluez le schéma et l'hôte, par exemple https://www.example.com (ou l'apex). Ensuite, soyez explicite sur la règle de redirection souhaitée : tous les autres hôtes doivent aboutir à cette URL exacte avec un unique 301.

Ensuite, listez tous les endroits qui peuvent rediriger des requêtes ou influencer les sessions : paramètres de domaine/DNS, règles CDN/edge, load balancers ou proxies, URL de base de l'app et callbacks d'auth, et paramètres de cookie/session. Le but est une propriété simple : un endroit gère les redirections, un endroit termine TLS, et un endroit définit l'URL publique.

Si l'app a été générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit, supposez qu'il existe des valeurs par défaut cachées et une dérive de configuration. Un prototype peut fonctionner sur un hôte parce qu'un framework détecte automatiquement des URLs, puis échouer après un changement tardif quand vous ajoutez un proxy, un CDN ou une politique HTTPS plus stricte.

Si vous êtes coincé dans une boucle et que la base de code est confuse, FixMyMess (fixmymess.ai) est spécialisé dans le diagnostic et la réparation d'apps générées par IA, y compris les règles de redirection, la portée des cookies/sessions et la configuration TLS/proxy. Un audit de code gratuit peut rapidement identifier la poignée d'incompatibilités qui déclenchent toute la réaction en chaîne.