Le lien de vérification pointe vers localhost:3000 ? Voici la solution

Pourquoi votre lien de vérification mène à localhost:3000, et comment le corriger

Vous vous inscrivez en préproduction, l’e-mail arrive, vous cliquez sur le lien et obtenez « Ce site est inaccessible » sur localhost:3000. L’e-mail n’est pas cassé : votre app y place une adresse de développement.

Mis à jour le 18 octobre 2026

Ce qui se passe

Chaque e-mail de vérification, de lien magique, d’invitation et de réinitialisation contient un lien vers votre app. Votre fournisseur d’authentification ou votre framework construit ce lien à partir d’un paramètre : l’URL du site, une URL de redirection ou l’hôte configuré pour votre service d’envoi. Si ce paramètre indique encore http://localhost:3000, chaque e-mail pointe vers l’ordinateur du développeur.

Parfois le lien lui-même est hébergé, par exemple https://yourproject.supabase.co/auth/v1/verify?..., et seule la page vers laquelle il redirige ensuite est locale. La vérification réussit, puis le navigateur est envoyé vers localhost:3000 et échoue. Ce cas passe facilement inaperçu, car l’e-mail semble correct.

Corriger dans Supabase (y compris les apps Lovable sur votre propre projet Supabase)

Dans le tableau de bord Supabase, ouvrez Authentication → URL Configuration.
Définissez Site URL sur votre adresse en ligne, comme https://your-app.lovable.app ou votre propre domaine. Un nouveau projet Supabase commence avec http://localhost:3000 ici.
Ajoutez chaque autre environnement utilisé (préproduction, domaines de prévisualisation, localhost pour le développement) dans Redirect URLs. Les jokers sont pris en charge pour les déploiements de prévisualisation.
Si votre code transmet emailRedirectTo ou redirectTo lors de l’inscription ou de la connexion, construisez cette valeur à partir du site courant, par exemple window.location.origin, ou d’une variable d’environnement. Une redirection absente de la liste autorisée revient à la Site URL.
Si vous avez personnalisé les modèles d’e-mail, vérifiez qu’ils utilisent les variables d’URL de confirmation ou d’URL du site du modèle plutôt qu’une adresse codée en dur.

Corriger dans Firebase Authentication

Vérifiez l’URL de redirection que votre code transmet dans ses paramètres de code d’action lors de l’envoi des liens de vérification ou de connexion. Elle doit venir de l’environnement, pas d’un http://localhost codé en dur.
Ajoutez votre domaine en ligne dans Authentication → Settings → Authorized domains.

Corriger dans d’autres stacks

Auth.js / NextAuth : définissez l’URL de déploiement (AUTH_URL, ou NEXTAUTH_URL sur les anciennes versions) là où votre hébergeur ne la déduit pas.
Ruby on Rails : définissez config.action_mailer.default_url_options avec le bon host dans la configuration de chaque environnement.
Django : construisez les liens à partir de la requête ou du framework Sites, et vérifiez que le domaine du site n’est plus example.com ou localhost.
Laravel : définissez APP_URL pour chaque environnement.
Autre : cherchez localhost:3000 dans le code et déplacez-le dans une variable d’environnement.

Sur un simulateur ou émulateur de téléphone

Le simulateur iOS partage le réseau de votre ordinateur, donc les liens localhost s’y ouvrent. L’émulateur Android, non : il accède à votre ordinateur via 10.0.2.2, donc un lien vers localhost:3000 n’ouvre rien. Pour un émulateur, faites pointer les liens de l’app vers http://10.0.2.2:3000, ou mieux, vers une adresse de préproduction accessible aux deux. Plus de détails dans Apps mobiles.

Comment Proxy Mail QA le signale

Quand un lien d’un e-mail de test pointe vers une adresse locale, ou y redirige après vérification, Proxy Mail QA le signale sur la ligne Accounts (« Redirige vers localhost:3000 ») et l’explique dans la boîte de réception. Vous voyez d’un coup d’œil que l’environnement est mal configuré, avant que quelqu’un ne signale « la vérification ne marche pas ».

Si vous testez volontairement une version locale, choisissez C’est mon environnement de développement. Les liens vers cet hôte ne sont plus signalés dans ce projet, et les vérifications d’e-mail les acceptent. Vous pouvez annuler cela dans les paramètres du projet. Un agent de codage peut marquer l’hôte lui-même avec l’outil MCP mark_dev_host, et une suite de tests avec POST /v1/project/dev-hosts (markDevHost dans le client Node.js, mark_dev_host dans le helper Python).

Essayez-le lors de votre prochain test d’inscription

Offre gratuite, sans carte bancaire. Créez une adresse et regardez arriver le code ou le lien.

Créer un compte gratuitOuvrir l'application

Questions

Pourquoi le lien fonctionne-t-il pour le développeur mais pas pour moi ?

localhost signifie toujours « cet ordinateur ». Sur l’ordinateur du développeur, son serveur de développement tourne, donc le lien s’ouvre. Sur toute autre machine, rien n’écoute, donc il échoue.

Un lien localhost est-il parfois correct ?

Oui, quand vous testez volontairement une version locale et que le serveur de développement tourne sur l’ordinateur depuis lequel vous cliquez. Dans Proxy Mail QA, marquez cet hôte comme environnement de développement et ses liens ne seront plus signalés dans ce projet.

J’ai corrigé le paramètre. Pourquoi les anciens e-mails renvoient-ils encore vers localhost ?

L’adresse est écrite dans chaque e-mail au moment de l’envoi. Demandez un nouvel e-mail après avoir modifié le paramètre ; les anciens gardent leurs anciens liens.

Quels liens Proxy Mail QA signale-t-il ?

Les liens vers localhost, 127.0.0.1, 0.0.0.0, les adresses de réseau privé comme 192.168.x.x, et les noms se terminant par .local, .test ou .localhost, ainsi que les liens hébergés qui redirigent vers l’un d’eux après vérification, comme redirect_to de Supabase ou continueUrl de Firebase.