Warum dein Bestätigungslink auf localhost:3000 führt und wie du das behebst

Was passiert

Jede Bestätigungs-, Magic-Link-, Einladungs- und Reset-E-Mail enthält einen Link zurück zu deiner App. Dein Auth-Anbieter oder Framework baut diesen Link aus einer Einstellung: der Site-URL, einer Redirect-URL oder dem Host, mit dem dein Mailer konfiguriert ist. Steht dort noch http://localhost:3000, zeigt jede E-Mail auf den Computer des Entwicklers.

Manchmal ist der Link selbst gehostet, zum Beispiel https://yourproject.supabase.co/auth/v1/verify?..., und nur die Seite, auf die er danach weiterleitet, ist lokal. Die Bestätigung klappt, dann wird der Browser zu localhost:3000 geschickt und scheitert. Diese Variante übersieht man leicht, weil die E-Mail gut aussieht.

Behebung in Supabase (auch für Lovable-Apps in deinem eigenen Supabase-Projekt)

1. Öffne im Supabase-Dashboard Authentication → URL Configuration.
2. Setz Site URL auf deine Live-Adresse, etwa https://your-app.lovable.app oder deine eigene Domain. Ein neues Supabase-Projekt startet hier mit http://localhost:3000.
3. Füge jede weitere Umgebung (Staging, Preview-Domains, localhost für die Entwicklung) unter Redirect URLs hinzu. Für Preview-Deployments werden Wildcards unterstützt.
4. Wenn dein Code beim Aufruf von Registrierung oder Anmeldung emailRedirectTo oder redirectTo übergibt, bau den Wert aus der aktuellen Site, etwa window.location.origin, oder aus einer Umgebungsvariable. Ein Redirect, der nicht auf der Allowlist steht, fällt auf die Site-URL zurück.
5. Wenn du die E-Mail-Vorlagen angepasst hast, prüf, dass sie die Variablen für Bestätigungs-URL oder Site-URL nutzen statt einer fest codierten Adresse.

Behebung in Firebase Authentication

• Prüf die Continue-URL, die dein Code beim Senden von Bestätigungs- oder Anmeldelinks in den Action-Code-Einstellungen übergibt. Sie sollte aus der Umgebung kommen, nicht aus einem fest codierten http://localhost.
• Füge deine Live-Domain unter Authentication → Settings → Authorized domains hinzu.

Behebung in anderen Stacks

• Auth.js / NextAuth: Setz die Deployment-URL (AUTH_URL, oder NEXTAUTH_URL in älteren Versionen), wo dein Host sie nicht selbst ermittelt.
• Ruby on Rails: Setz config.action_mailer.default_url_options mit dem richtigen host in der Konfiguration jeder Umgebung.
• Django: Bau Links aus dem Request oder dem Sites-Framework und stell sicher, dass die Domain der Site nicht noch example.com oder localhost ist.
• Laravel: Setz APP_URL für jede Umgebung.
• Alles andere: Durchsuch den Code nach localhost:3000 und verschieb es in eine Umgebungsvariable.

Auf einem Handy-Simulator oder -Emulator

Der iOS-Simulator teilt das Netzwerk deines Computers, daher öffnen sich localhost-Links dort. Der Android-Emulator nicht: Er erreicht deinen Computer unter 10.0.2.2, ein Link auf localhost:3000 öffnet also nichts. Lass die Links der App für einen Emulator auf http://10.0.2.2:3000 zeigen oder besser auf eine Staging-Adresse, die beide erreichen. Mehr unter Mobile Apps.

Wie Proxy Mail QA es markiert

Zeigt ein Link in einer Test-E-Mail auf eine lokale Adresse oder leitet nach der Bestätigung dorthin weiter, markiert Proxy Mail QA das in der Zeile unter Accounts („Leitet auf localhost:3000 weiter“) und erklärt es im Posteingang. So siehst du auf einen Blick, dass die Umgebung falsch konfiguriert ist, bevor jemand „Bestätigung kaputt“ meldet.

Wenn du absichtlich einen lokalen Build testest, wähl Das ist meine Dev-Umgebung. Links auf diesen Host werden in diesem Projekt nicht mehr markiert, und die E-Mail-Prüfungen lassen sie durch. In den Projekteinstellungen kannst du das wieder entfernen. Ein Coding-Agent kann den Host selbst mit dem MCP-Tool mark_dev_host markieren, eine Testsuite mit POST /v1/project/dev-hosts (markDevHost im Node.js-Client, mark_dev_host im Python-Helper).