Vorschau funktioniert, Live‑Site fehlerhaft: Was zu prüfen ist

Was „Vorschau funktioniert“ vs „Live schlägt fehl“ wirklich bedeutet

Ein Vorschau‑Link ist eine temporäre Version deiner App, die in einer kontrollierten Umgebung vom Builder oder Host läuft. Er verwendet oft eine Standarddomain, Voreinstellungen und eine „freundlichere“ Umgebung, in der weniger Regeln stören.

Eine Live‑Site ist deine echte Domain mit Produktions‑Einstellungen. Browser behandeln sie anders: Cookies gehören zur Domain, HTTPS‑Regeln greifen, und deine App muss mit dem richtigen Backend und den richtigen Berechtigungen sprechen.

Wenn also jemand sagt „Vorschau funktioniert, Live schlägt fehl“, bedeutet das meist, dass die App in der Demo gut aussieht und dann bricht, wenn sie den echten Domain‑Regeln unterliegt.

Das Versagen kann sich auf ein paar typische Arten zeigen: eine leere Seite oder ein endloser Spinner, eine Login‑Schleife (einloggen und zurück zum Login geschickt werden), Buttons, die nichts tun weil API‑Aufrufe fehlschlagen, fehlende Daten obwohl die UI geladen ist, oder Fehler, die nur auf der Live‑Domain auftreten.

„Funktioniert“ kann irreführend sein. Viele KI‑erstellte Apps „funktionieren“ in der Vorschau, weil die UI gerendert wird. Die wichtigen Teile schlagen in Produktion oft leise fehl: API‑Requests, Authentifizierung, Uploads, Zahlungen oder Datenbankabfragen.

Ein einfaches Beispiel: In der Vorschau ruft deine App eine API über eine Test‑URL und permissives CORS auf, sodass Anfragen erfolgreich sind. Auf der Live‑Domain werden dieselben Aufrufe blockiert, oder die App zeigt noch auf localhost. Die Seite lädt, aber es erscheinen keine Daten.

Darum ist die erste Frage nicht „lädt sie?“, sondern „gelangen die Netzwerkaufrufe auf der Live‑Domain erfolgreich durch?“ Wenn du ein AI‑generiertes Prototyp übernommen hast, findet ein schneller Code‑Audit (wie ihn FixMyMess bietet) oft die Diskrepanz schnell: eine falsche Environment‑Variable, eine Cookie‑Einstellung, die an die Vorschau‑Domain gebunden ist, oder eine HTTPS‑Regel, die die Vorschau nicht durchgesetzt hat.

Domain‑Unterschiede, die das Verhalten ändern

Wenn die Vorschau funktioniert, Live aber nicht, nimm den Hostnamen früh ins Visier. Browser behandeln app-preview.example und example.com als unterschiedliche Ursprünge, selbst wenn der Code identisch ist. Das ändert, welche Cookies gesendet werden, welche Sicherheitsregeln gelten und welche URLs deine App aufrufen darf.

Eine häufige Falle ist, von einer temporären Vorschau‑Domain auf eine echte Domain zu wechseln und anzunehmen, dass alles übernommen wird. Tatsächlich sind viele Einstellungen an eine exakte Origin (Schema + Host + Port) gebunden. Ein einzelnes Zeichen kann funktionierende Features in defekte verwandeln.

Subdomain vs Apex: kleine Änderung, große Auswirkung

Der Wechsel von app.example.com zu example.com (oder umgekehrt) kann Verhalten kaputtmachen, das von der Domain‑Sichtweite abhängt. Cookies können so gesetzt werden, dass sie auf dem anderen Host nie auftauchen. Einige Auth‑Setups erwarten auch eine spezifische Domain für Callbacks und erlaubte Origins.

Das gleiche gilt für www vs non‑www. Wenn deine Live‑Site von www.example.com auf example.com umleitet, kann die App zwar laden, aber das Login fehlschlagen, weil der Auth‑Provider eine andere Callback‑URL sieht als die registrierte.

Die Domain‑Mismatchs, die am häufigsten sofort Fehler verursachen, sind:

• www vs non‑www (Redirects ändern die finale URL)
• Apex‑Domain vs Subdomain (Cookie‑Scope und erlaubte Origins unterscheiden sich)
• unterschiedliche Vorschau‑Hostnames pro Deploy (hardcodierte URLs stimmen nicht mehr überein)
• Staging‑ vs Produktions‑Domains (Auth und API‑Einstellungen zeigen auf den falschen Ort)
• trailing slash oder Pfadunterschiede in Callback‑URLs (einige Provider behandeln sie als unterschiedlich)

Ein schnelles Beispiel: deine Vorschau läuft auf einer temporären Domain, und der Login‑Provider ist auf diesen Callback konfiguriert. Du launcht auf www.yourapp.com, der Provider lehnt den Callback ab und Nutzer sehen eine leere Seite oder eine Schleife zurück zum Login. Nichts in der UI erklärt warum.

Das passiert besonders oft bei KI‑gebauten Apps, weil Domains an mehreren Stellen hardcodiert werden (Frontend, Backend, Auth‑Einstellungen). FixMyMess findet häufig mehrere Stellen, an denen ein einziger Hostname exakt übereinstimmen muss, damit Produktion wie die Vorschau funktioniert.

Environment‑Einstellungen: der stille Produktions‑Brecher

Vorschau‑Umgebungen „funktionieren oft einfach“, weil die Plattform stillschweigend Defaults bereitstellt. Deine Live‑Site tut das normalerweise nicht. Diese Lücke ist ein Hauptgrund, warum die Vorschau funktioniert, Produktion aber nicht, selbst wenn der Code gleich ist.

Ein typisches Muster ist, dass die Vorschau eine Fallback‑API‑URL, eine Demo‑Datenbank oder einen permissiven Auth‑Modus injiziert. Produktion erwartet reale Werte. Fehlen diese, läuft die App weiter, verhält sich aber seltsam: Buttons tun nichts, Seiten zeigen leere Zustände oder jede Anfrage schlägt fehl.

Die häufigsten env‑Probleme in Produktion sehen so aus:

• Eine erforderliche Variable fehlt (API‑Basis‑URL, Auth‑Secret, Datenbank‑URL, Zahlungs‑Keys).
• Ein Wert ist gesetzt, aber falsch (Dev‑Endpoint, Test‑Key, alte Staging‑Domain).
• Variablen sind an einer Stelle gesetzt, aber an einer anderen gelesen (gesetzt im Hosting‑Dashboard, aber der Build erwartet eine .env zur Build‑Zeit).
• Namen stimmen nicht exakt (NEXT_PUBLIC_API_URL vs NEXT_PUBLIC_API_BASE).
• Der Wert hat einen subtilen Tippfehler (extra Slash, falsche Region, falsche Client‑ID).

Eine weitere Falle ist, wo die Variable verwendet wird. Client‑seitige Variablen landen im Browser und müssen sicher sein, offengelegt zu werden. Server‑seitige Variablen bleiben auf dem Server, aber nur, wenn der Code wirklich serverseitig läuft. KI‑gebauten Apps passieren manchmal Geheimnis‑Lecks ins Frontend. Das kann in der Vorschau „funktionieren“ und in Produktion versagen, wenn Keys rotiert werden oder Sicherheitsregeln greifen. Es ist auch ein echtes Sicherheitsrisiko.

Um ein env‑Problem schnell zu finden, prüfe Live‑Logs und die Browserkonsole auf:

• Fehler, die undefined oder null erwähnen
• 401/403 Antworten (falscher Key, falsche Audience, falscher Issuer)
• Requests, die an den falschen Host gehen (Dev‑Domain taucht in Produktion auf)
• Build/Start‑Fehler wie „Missing required env var"

Beispiel: Login funktioniert in der Vorschau, weil ein Vorschau‑Callback verwendet wird, aber Produktion zeigt noch auf die Vorschau‑Domain. Der Auth‑Provider lehnt ab und Nutzer sehen 401 oder eine Login‑Schleife.

Wenn du ein KI‑generiertes Repo geerbt hast und nicht weißt, woher ein Wert kommt, kann FixMyMess ein kostenloses Code‑Audit durchführen und auflisten, was fehlt oder falsch konfiguriert ist, bevor du etwas änderst.

HTTPS, Redirects und Mixed‑Content‑Probleme

Eine Vorschau kann funktionieren, weil sie auf einer Plattform‑Domain mit einer bekannten, guten Konfiguration läuft. Beim Wechsel auf die eigene Domain wird der Browser strenger. Kleine Fehlkonfigurationen können verhindern, dass die App lädt, sich einloggt oder APIs aufruft.

HTTPS ist strenger als die meisten Vorschau‑Setups

HTTPS ist nicht nur das Schloss‑Symbol. Es ändert, was der Browser erlaubt. Requests können blockiert werden, Cookies verhalten sich anders, und Redirects können Schleifen erzeugen, die in der Vorschau nie aufgetaucht wären.

Ein typisches Beispiel: die Live‑Site lädt über https://, aber die App ruft noch http://api.example.com auf. In der Vorschau fällt das vielleicht nicht auf, weil alles auf derselben Plattform‑Domain läuft oder Warnungen leichter zu übersehen sind.

Mixed Content: der stille Blocker

Mixed Content entsteht, wenn eine HTTPS‑Seite irgendetwas über HTTP lädt (API‑Calls, Bilder, Skripte). Moderne Browser blockieren solche Requests oft, was die App „kaputt“ erscheinen lässt, ohne offensichtliche On‑Screen‑Fehler.

So prüfst du schnell:

• Öffne die Live‑Site (nicht die Vorschau).
• Öffne die Browserkonsole und lade neu.
• Suche nach „Blocked mixed content“ oder ähnlichen Fehlern.
• Prüfe den Netzwerk‑Tab auf Anfragen, die blockiert, abgebrochen oder in Redirects hängen.

Redirects, HSTS und Schleifen

Redirect‑Schleifen entstehen oft, wenn mehrere Ebenen widersprüchliche Regeln haben. Zum Beispiel:

• die App erzwingt HTTPS, aber die Hosting‑Plattform macht das bereits
• ein CDN erzwingt www, aber die App erzwingt non‑www
• HSTS ist aktiviert, sodass der Browser HTTP nicht mehr versucht

Dann kann die Seite flackern, endlos neu laden oder vor dem Ausführen deines Codes fehlschlagen.

Zertifikate sind ebenfalls wichtig. Ist das Zertifikat ungültig oder noch nicht für die Custom‑Domain ausgestellt, blockieren einige Browser Requests oder verhindern, dass Sign‑in‑Flows korrekt öffnen.

Wenn die Konsole voller Mixed‑Content‑Warnungen und Redirect‑Fehler ist, beginnt FixMyMess typischerweise damit, jede Anfrage zu kartieren, die die App live macht, und behebt dann HTTPS‑URLs und Redirect‑Regeln, damit Produktion sich wie die Vorschau verhält.

Cookies und Authentifizierung: warum Logins auf Live fehlschlagen

Wenn Vorschau funktioniert, aber Live nicht, bricht oft zuerst das Login. Die Vorschau fühlt sich „normal“ an, aber die Live‑Domain ändert, wie der Browser Cookies, Redirects und Session‑Speicherung behandelt.

Cookies sind an eine Domain gebunden. Läuft die Vorschau auf einer Plattform‑Domain und die Live‑Site auf deiner Custom‑Domain, kann der Browser das Session‑Cookie nicht mehr senden, obwohl du keinen Code geändert hast.

Cookie‑Flags, die die meisten Überraschungen verursachen

Drei Einstellungen entscheiden, ob dein Login‑Cookie den Umzug in die Produktion übersteht:

• Domain‑Scope: ein Cookie, das für preview.example-host.com gesetzt wurde, wird nicht zu www.yourdomain.com gesendet. Hardcodierte Cookie‑Domains funktionieren oft in der Vorschau und scheitern in Produktion.
• SameSite: Redirect‑basierte Logins (Google, GitHub, Magic Links) können brechen, wenn SameSite=Strict das Cookie auf dem Rückweg blockiert. Lax ist für einfache Flows oft sicherer.
• Secure: Secure‑Cookies werden nur über HTTPS gesendet. Hat deine Live‑Site einen HTTP‑Zwischenschritt (oder eine komplizierte Redirect‑Kette), bleibt das Cookie möglicherweise nie kleben.

Typische Symptome:

• Login „gelingt“, aber du landest wieder auf der Login‑Seite
• du bekommst eine Schleife: einloggen, Redirect, wieder einloggen
• es funktioniert einmal im Inkognito‑Fenster, dann nicht mehr
• es funktioniert in der Vorschau, aber nur auf der echten Domain nicht

OAuth und gehostete Auth: erlaubte Origins und Redirect‑URIs

Auth‑Provider vertrauen deiner Custom‑Domain nicht automatisch. Vorschau‑Umgebungen sind manchmal standardmäßig freigeschaltet, während deine echte Domain das nicht ist. Der Provider lehnt dann den Callback ab, oder deine App erhält zwar den Callback, scheitert aber beim Code‑Exchange, weil die Origin nicht stimmt.

Beispiel: Vorschau verwendet https://random-preview-host.com und der Provider ist dafür konfiguriert. Du wechselst zu https://app.yourdomain.com, aber der Provider erlaubt noch nur die Vorschau‑Origin. Der Redirect sieht zwar korrekt aus, aber du landest auf einer leeren Seite, einem Error‑Toast oder wieder beim Login.

Bevor du Code änderst, führe diese Checks in den DevTools durch:

• Bestätige, dass die Live‑Site vollständig HTTPS ist ohne HTTP‑Zwischenschritt.
• Prüfe den Set‑Cookie Header (Domain, SameSite, Secure, Ablaufdatum).
• Verifiziere, dass das Cookie unter dem Live‑Domain‑Storage erscheint und bei der nächsten Anfrage gesendet wird.
• Bei OAuth: bestätige, dass die Live‑Domain in den erlaubten Origins und Redirect/Callback‑Einstellungen gelistet ist.

Kaputte Auth ist eine häufige FixMyMess‑Reparatur. Wir verfolgen Cookie und Redirect‑Pfad End‑to‑End und beheben die mismatchenden Einstellungen, damit das Login auf der Live‑Domain zuverlässig funktioniert.

CORS und API‑Aufrufe, die nur auf Live blockiert werden

Manchmal lädt die UI, aber alle Datenaufrufe schlagen fehl, weil der Browser dein Frontend nicht deine API anrufen lässt. Diese Verweigerung ist CORS (Cross‑Origin Resource Sharing). Kurz gesagt: der Browser blockiert, dass eine Website Requests an eine andere Domain sendet, es sei denn, der Server erlaubt das ausdrücklich.

Das passiert auf Live häufiger als in der Vorschau, weil Vorschau‑Hosts manchmal „special‑cased“ sind. Deine API könnte Requests von der Vorschau‑Domain erlauben, aber nicht von deiner echten Domain.

Wie CORS‑Fehler aussehen

In der Konsole oder im Netzwerk‑Tab siehst du „blocked by CORS policy“ oder eine Preflight‑Anfrage, die fehlschlägt. Ein Preflight ist eine automatische OPTIONS‑Anfrage, die der Browser zuerst schickt, um zu fragen: „Ist das erlaubt?“

Preflights passieren öfter als gedacht. JSON mit custom Headern senden, Methoden wie POST/PUT verwenden oder Credentials (Cookies) mitsenden kann sie auslösen. Wenn der Server OPTIONS nicht korrekt beantwortet, blockiert der Browser den eigentlichen Aufruf – selbst wenn die API in Tools wie curl funktioniert.

Auf der API‑Seite sind die wichtigsten Prüfungen:

• erlaube die exakte Live‑Origin (Schema + Domain + Port)
• wenn du Cookies/Auth‑Header sendest: allow credentials und keinen Wildcard‑Origin verwenden
• erlaube die tatsächlich gesendeten Header (oft Content‑Type, Authorization)
• erlaube die verwendeten Methoden und antworte korrekt auf OPTIONS
• prüfe, ob dein Reverse‑Proxy/CDN in Produktion CORS‑Header entfernt

Ein typisches Szenario: eine KI‑erstellte App ruft api.myapp.com von preview.mytool.app aus auf und es funktioniert. Nach dem Launch läuft das Frontend auf myapp.com, aber die API erlaubt noch nur preview.mytool.app, sodass Login und Speichern im Browser fehlschlagen.

Wenn du festsitzt, findet FixMyMess oft CORS‑Probleme zusammen mit verwandten Blockern (z. B. Cookies, die wegen Credential‑Einstellungen nicht gesendet werden) und verifiziert die Lösung mit echten Browser‑Tests, bevor du neu launchst.

Caching, Service Workers und veraltete Deploys

Manchmal ist nichts im Code „kaputt“. Die Live‑Domain liefert einfach eine ältere Version. Vorschau‑Server umgehen oft die Caching‑Schichten, die deine echte Domain benutzt.

Wenn Caches die falsche Version liefern

Ein CDN oder Browser‑Cache kann alte JavaScript‑Bundles behalten, obwohl neu deployed wurde. Wenn dein Build Dateien wie app.123.js ausgibt, aber das HTML noch app.122.js referenziert, laden Nutzer eine Mischung aus alt und neu. Das Ergebnis wirkt zufällig: Buttons funktionieren nicht mehr, Seiten sind leer oder Fehler sind lokal nicht reproduzierbar.

Typische Anzeichen für Caching oder veraltete Assets:

• die UI sieht nach einem Deploy wie ein älteres Design aus
• JavaScript‑ oder CSS‑Dateien liefern 404 im Netzwerk‑Tab
• Fehler erwähnen fehlende Chunks oder „unexpected token“ in einer JS‑Datei
• nur einige Nutzer sehen das Problem (häufig mobil)
• ein Refresh ändert das Verhalten

Service Workers: eine schlechte Version kann haften bleiben

Hat deine App einen Service Worker (z. B. PWA‑Templates), kann er ein gecachtes Shell der Seite liefern. Eine schlechte Release‑Version kann installiert werden und weiter ausliefern, selbst nachdem du Produktion gefixt hast. Nutzer müssen dann alle Tabs schließen oder der Update‑Flow des Service Workers muss repariert werden.

Eine weitere Falle ist ein Base‑URL‑Wechsel. Wenn du von einer Vorschau‑Subdomain zur echten Domain gewechselt oder den Hosting‑Pfad geändert hast, können statische Asset‑Pfade brechen. Du siehst 404 für Dateien, die existieren, nur nicht unter dem vom Browser angeforderten Pfad.

Schnelle Tests, die Raten vermeiden:

• öffne ein Inkognito‑Fenster und teste die Live‑Site
• mache einen Hard‑Refresh (Ctrl/Cmd + Shift + R)
• deaktiviere Cache in DevTools und lade neu
• achte auf 304/404‑Antworten für JS‑ und CSS‑Dateien
• wenn ein Service Worker existiert: registriere ihn ab und lade neu

Wenn die Live‑Site weiter die falsche Build‑Version ausliefert, kann FixMyMess genau feststellen, ob Caching, Service Worker oder ein Deploy‑Output‑Problem vorliegt, bevor du Stunden mit „Phantom‑Bugs“ verschwendest.

Schritt‑für‑Schritt: Fehler in 20 Minuten diagnostizieren

Benenne zuerst das genaue Symptom auf der Live‑Site. Ist es eine leere Seite (Page‑Load), eine Seite, die lädt aber keine Daten zeigt (API‑Call), oder ein Login, das in der Vorschau funktioniert, live aber scheitert (Auth/Cookies)? Wenn du das falsche Symptom wählst, verlierst du leicht eine Stunde, indem du dem falschen Pfad nachjagst.

Öffne die Live‑Site in einem frischen privaten Fenster und dann die DevTools. Halte zwei Tabs offen: Konsole und Netzwerk. Die Konsole zeigt die lauten Fehler (rote Einträge). Netzwerk zeigt die erste Anfrage, die tatsächlich bricht.

1) Finde den ersten echten Fehler

In der Konsole suchst du nach Fehlern, die blockierte Requests, CORS, Mixed Content, Redirect‑Schleifen oder fehlende Env‑Variablen erwähnen. Ignoriere Warnungen, bis du den ersten roten Fehler erklärt hast.

Gehe dann ins Network, lade neu und klicke die erste fehlgeschlagene Anfrage (oft ein XHR/fetch). Notiere Request‑URL, Statuscode und Response‑Message:

• 401/403 weist meist auf Auth, Cookies oder Key/Audience/Issuer‑Mismatch hin.
• 404 deutet oft auf eine falsche URL, fehlende Route oder kaputten Asset‑Pfad hin.
• 500 weist auf Server‑Logik oder kaputte Konfiguration hin.
• Anfragen, die nie fertig werden können DNS, HTTPS oder einen vom Browser blockierten Request bedeuten.

2) Vergleiche Vorschau vs Live 1:1

Öffne Vorschau und Live nebeneinander und wiederhole dieselbe Aktion (Seite laden, Login klicken, Daten holen). Vergleiche die fehlschlagende Anfrage:

• URL‑Unterschiede (Domain, Pfad, http vs https)
• Header (fehlendes Authorization, falscher Origin)
• Cookies (nicht gesetzt, nicht gesendet, falsche Domain)
• Response‑Body (unterschiedliche Fehlermeldungen zwischen Vorschau und Produktion)

Wenn die Vorschau api.preview-host.com anruft, Live aber localhost kontaktiert, ist das meist ein Environment‑Variable‑Mismatch, nicht ein zufälliger Produktions‑Bug.

Prüfe abschließend die Produktions‑Env‑Vars in deinem Hosting‑Provider (nicht nur im Repo) und mache einen sauberen Redeploy. Viele KI‑gebauten Apps behalten alte Werte, bis du neu baust und erneut deployst.

Wenn du nach diesen Checks noch festhängst, kann FixMyMess ein kostenloses Code‑Audit durchführen und feststellen, ob es Env‑Vars, Domain/CORS, HTTPS oder Auth ist, und das dann mit menschlicher Verifikation reparieren.

Die häufigsten Fehler, die am meisten Zeit kosten

Wenn jemand sagt „Vorschau funktioniert, Live schlägt fehl“, ist die Ursache meist kein tiefer Bug. Es ist oft eine einfache Konfigurations‑Diskrepanz, die immer wieder übersehen wird.

Die Dauerbrenner

Die meiste Zeit wird verschwendet, weil man Symptombekämpfung betreibt (leerer Bildschirm, fehlgeschlagenes Login, 401s), während die Wurzel ein grundlegendes Konfigurationsproblem ist:

• Auth‑Redirect‑URLs nicht für die echte Domain aktualisiert. Der Provider erlaubt noch den Vorschau‑Hostname, also prallt Produktion ab oder gerät in eine Schleife.
• Vorschau‑URLs im Frontend hardcodiert. Eine einzige verbliebene https://preview-xyz... in API‑Aufrufen, OAuth‑Callbacks oder WebSockets kann Live kaputtmachen.
• Geheimnisse im Browser ausgeliefert. KI‑erstellte Apps packen manchmal private Keys in client‑seitige env vars oder bundle sie in den Build. Das kann Produktion brechen und ist ein Sicherheitsproblem.
• Vorschau und Produktion zeigen auf unterschiedliche Datenbanken. Vorschau nutzt Seed‑Testdaten, Produktion ist leer oder hat ein anderes Schema.
• Fix angewendet, aber nicht wirklich deployed. Build‑Caches, falsche Deploy‑Targets oder fehlende Env‑Updates lassen es so aussehen, als habe die Korrektur nicht funktioniert.

Ein realistisches Beispiel: du behebst das OAuth‑Callback‑Mismatch, aber Live scheitert weiter, weil das Frontend noch die Vorschau‑API‑Base‑URL anruft. Zwei kleine Fehler, ein verwirrendes Ergebnis.

Wie du die Zeitfresser vermeidest

Bevor du Code umschreibst, prüfe Folgendes:

1. Bestätige, dass die Produktions‑Domain überall beim Auth‑Provider eingetragen ist.
2. Suche im Codebase nach dem Vorschau‑Hostname und ersetze ihn durch produktionssichere Konfiguration.
3. Verifiziere, welche Env‑Vars server‑only sind vs. im Browser exponiert werden.
4. Bestätige, dass Produktions‑DB‑Verbindung und Migrationen mit der Vorschau übereinstimmen.
5. Redeploy und leere alle relevanten CDN/Build‑Caches, damit Live das neue Bundle ausliefert.

Bei FixMyMess sind das die ersten Prüfungen bei einer Code‑Diagnose, weil diese Probleme in KI‑Prototypen häufig vorkommen und leicht zu übersehen sind.

Schnelle Checkliste und nächste Schritte

Wenn Vorschau funktioniert, aber die Live‑Site nicht, behandle es als Konfigurationsmismatch, bis das Gegenteil bewiesen ist. Du jagst meistens keinen mysteriösen Bug, sondern eine Differenz zwischen zwei Umgebungen.

Fang auf der Live‑Domain mit den Basics an:

• Bestätige, dass die Live‑Domain auf das richtige Deployment zeigt (richtiges Projekt, richtiger Branch, neuester Build).
• Vergleiche Produktions‑Env‑Vars mit den Vorschau‑Werten (API‑Base‑URL, Auth‑Keys, Callback‑URLs, DB‑URL).
• Lade die Live‑Site mit offener Konsole und suche nach HTTPS‑Warnungen, Redirect‑Schleifen und Mixed‑Content‑Fehlern.
• Teste Auth end‑to‑end auf Live (Signup, Login, Logout, Refresh). „Funktioniert bis zum Refresh“ deutet oft auf Cookie‑ oder Domain‑Einstellungen hin.
• Teste in einem privaten Fenster und auf Mobilgeräten. Alte Cookies, gecachte Assets und Service‑Worker können das echte Problem verbergen.

Ein einfaches Beispiel: in der Vorschau ruft deine App http://api.myapp.local (für Dev ok) auf, aber in Produktion ist die Seite HTTPS und die API HTTP. Der Browser blockiert das. Die UI wirkt bis zum Klick normal, dann versagt alles.

Wenn du es immer noch nicht eingrenzen kannst: hör auf zu raten und lass eine fokussierte Prüfung machen. Die schnellsten Fixes kommen meist aus der gemeinsamen Prüfung von Auth & Cookies, exponierten Geheimnissen und der Gesamtarchitektur (KI‑Prototypen liefern oft verknotete Logik, die erst unter realen Produktionsbedingungen bricht).

Wenn dein Projekt mit Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde und jetzt auf einer echten Domain versagt, ist FixMyMess (fixmymess.ai) genau für diese Situation gebaut: wir diagnostizieren, was zwischen Vorschau und Produktion unterschiedlich ist, und reparieren dann die Codebasis, sodass sie in Produktion standhält.