Deine lovable custom domain ist in den Einstellungen angehängt — Besucher sehen Zertifikatswarnungen, nur HTTP oder DNS-Fehler, während *.lovable.app weiter funktioniert.
Branding war der letzte Schritt vor dem Launch. Du hast die Domain gekauft, in Lovable oder Vercel eingetragen und dieselbe App unter deinem Namen erwartet. Stattdessen zeigt der Browser Deine Verbindung ist nicht privat, oder die Domain löst nie auf. Die Vorschau auf dem Standard-Host lädt noch. Production auf deinem Namen nicht. SSL und DNS sind das Tor — nicht dein React-Code.
Was du bei hängender lovable custom domain siehst
Fehler zeigen sich an der Kante, bevor dein App-Bundle läuft.
- Zertifikatsfehler oder Nicht sicher. HTTPS scheitert. Chrome oder Safari blockiert die Seite.
- Domain nicht gefunden. NXDOMAIN oder falscher Server — DNS zeigt nie auf den Host, den Lovable oder Vercel erwartet.
- Läuft per HTTP, bricht bei HTTPS. Mixed Content oder Redirect-Schleifen bei halb bereitgestelltem SSL.
- Login nur auf Custom Domain kaputt. Supabase vertraut noch dem alten
lovable.app-Origin. - Env-Vars fehlen auf neuem Host. Verbundenem Vercel-Projekt fehlen Keys für Production-Alias.
- Alte Registrar-Parking-Seite. CNAME zeigt noch auf Default-Parking des Domain-Shops.
Die Standard-Lovable-URL kann laufen, während deine lovable custom domain scheitert. Das bestätigt DNS oder TLS — keinen kaputten Component-Tree. Gegen die lovable deploy-Checkliste für Auth und Env auf dem neuen Origin prüfen.
Warum die KI DNS und SSL nicht für dich konfiguriert hat
Lovable erzeugt Anwendungscode. Es loggt sich nicht bei deinem Registrar ein. Custom Domains leben in Hosting-Einstellungen und DNS-Panels außerhalb des Chats. Die KI erwähnt „Domain hinzufügen“ in einer Zusammenfassung. CNAME-Records bei Namecheap, Cloudflare oder IONOS kann sie nicht anlegen.
SSL stellt dein Host aus, nachdem DNS beweist, dass du die Domain kontrollierst. Falscher Record-Typ, Apex-vs-www-Verwechslung oder alter A-Record auf einen alten Server stoppt die Zertifikatsgenerierung. Der Editor sieht nicht, dass dein Registrar noch auf Parking zeigt.
Auth und Env verschärfen es. Code shippt mit window.location.origin oder hardcodierten Vorschau-URLs. Supabase Site URL listet vielleicht nur project.lovable.app. OAuth in Google Cloud erlaubt nur diesen Host. Deine lovable custom domain lädt statische Assets, Auth-Callbacks werden abgelehnt.
GitHub und Vercel verbinden fügt eine Schicht hinzu. Die Domain hängt an Vercel. Production-Env-Vars müssen für dieses Projekt existieren — nicht nur in der Lovable-Vorschau. Siehe vercel env vars, wenn die Custom-URL eine Hülle mit undefined Keys lädt.
Propagations-Verzögerungen täuschen ungeduldige Launches vor. DNS kann Minuten bis achtundvierzig Stunden brauchen — je nach Registrar-TTL. SSL bleibt pending, bis der Host korrekte Records sieht. Auth auf halb provisionierter Domain zu testen verbrennt einen weiteren Nachmittag.
Deine lovable custom domain in DNS und Hosting fixen
- Apex oder www wählen. Entscheiden, ob Nutzer
yourapp.comoderwww.yourapp.comöffnen. Eines als Primary; das andere redirecten. - Lovable- oder Vercel-Domain-Einstellungen öffnen. Exakte CNAME- oder A-Record-Werte aus dem Dashboard kopieren. Nicht aus altem Tutorial raten.
- DNS beim Registrar bearbeiten. Konflikt-Records entfernen. www per CNAME auf Host-Target. Für Apex: A-Records oder ALIAS wie der Host dokumentiert.
- Auf Propagation warten. DNS-Lookup-Tool nutzen. Name muss auf erwartetes Target zeigen, bevor du SSL beschuldigst.
- Zertifikatsbereitstellung anstoßen. In Vercel oder Lovable-Hosting Verify oder Refresh klicken. Status sollte von pending auf valid wechseln.
- HTTPS erzwingen. Automatische HTTPS-Redirects aktivieren.
https://im privaten Fenster testen. - Supabase Site URL und Redirect URLs aktualisieren. Custom-Origin neben Lovable-Default hinzufügen. Google- oder GitHub-OAuth-Domains anpassen, falls genutzt.
- Production-Env-Vars bestätigen. Jedes Secret, das die App liest, muss für Production auf dem verbundenen Host existieren. Nach Änderungen redeployen.
- Aus Lovable republishen, wenn Code Hosts hardcodet. Nach
lovable.app-Strings suchen und wo nötig durch dynamischen Origin ersetzen.
Standard-Lovable-URL in Redirect URLs behalten, bis die Custom Domain stabil ist. Vorschau zu früh entfernen bricht Tests.
Checkliste vor Launch auf deiner lovable custom domain
- DNS-Lookup zeigt den von Lovable oder Vercel genannten Host
- HTTPS lädt ohne Zertifikatswarnungen
- HTTP leitet auf HTTPS um
- Supabase Site URL enthält den Custom-Origin
- Redirect URLs listen Custom Domain und Lovable-Default
- OAuth-Provider erlauben Callbacks für den neuen Host
- Production-Env-Vars auf Vercel oder verbundenem Host gesetzt
- Login und ein API-Call auf der Custom-URL im privaten Fenster erfolgreich
FAQ
Warum zeigt meine lovable custom domain kein SSL?
TLS-Zertifikate werden ausgestellt, nachdem DNS korrekt auf deinen Host zeigt. Falscher CNAME, alte Records beim Registrar oder HTTP-only-Setup blockieren die Bereitstellung. Bis das Zertifikat gültig ist, warnen oder blockieren Browser bei HTTPS.
Muss ich Supabase für eine lovable custom domain anpassen?
Ja. Custom-Origin zu Site URL und Redirect URLs hinzufügen. OAuth-Provider brauchen die neuen Callback-Pfade. Auth, die noch auf den Standard-Lovable-Host zeigt, bricht Login auf deiner Domain.
Wie lange dauert SSL bei einer lovable custom domain?
Nach DNS-Propagation stellen die meisten Hosts ein Zertifikat in Minuten bis wenigen Stunden aus. Bleibt es länger als 24 Stunden pending: CNAME oder A-Records prüfen, alte Records entfernen, Domain im Hosting-Dashboard bestätigen.