Fehlerbehebung bei Umleitungsschleifen für benutzerdefinierte Domains: www, Apex, Cookies, TLS

Was kaputt geht, wenn du eine Domain spät hinzufügst

Eine benutzerdefinierte Domain hinzuzufügen, nachdem deine App bereits unter einer Standard-URL funktioniert, klingt einfach. In der Praxis erinnert sich die App oft an die alte Adresse. Dein Domain-Provider, die Hosting-Schicht, CDN/Proxy und App-Einstellungen können alle versuchen zu helfen, indem sie Traffic umleiten. Wenn zwei Stellen sich nicht einig sind, bleiben Nutzer zwischen URLs hängen.

Die ersten Anzeichen sind meist klar:

• Seiten, die sich immer wieder neu laden
• "Zu viele Weiterleitungen"-Fehler
• Eine Startseite, die nur manchmal lädt

Login ist ein weiteres klassisches Symptom. Ein Nutzer meldet sich an, wird zurück zur App geschickt und landet wieder auf dem Login, weil das Session-Cookie nicht haften bleibt.

Späte Domain-Änderungen brechen häufiger, weil du bereits funktionierende Annahmen eingebaut hast. Redirect-Regeln wurden für die ursprüngliche URL erstellt (z. B. eine Plattform-Preview-Domain). Cookies waren auf den alten Host beschränkt. TLS- und Sicherheits-Einstellungen galten für einen Hostnamen, aber nicht für den anderen.

Eine kleine Abweichung kann mehrere Symptome gleichzeitig auslösen. Zum Beispiel kann das Erzwingen von HTTPS beim CDN, während die App ebenfalls HTTPS erzwingt (und beide www unterschiedlich auf die Apex umschreiben), eine Schleife erzeugen. Gleichzeitig kann ein Cookie mit www.example.com gesetzt sein, während Nutzer auf example.com landen — dann schlägt das Login fehl, selbst wenn die Redirects äußerlich „richtig“ aussehen.

Ein häufiges Szenario: dein KI-erstellter Prototyp lief auf einer Replit-URL. Du fügst später www.yourapp.com hinzu, änderst DNS, und plötzlich sehen die einen Nutzer Redirect-Fehler und die anderen können nicht angemeldet bleiben.

Das Ziel ist simpel: eine kanonische URL (entweder www oder Apex), die stabil bleibt, Sessions erhält und sauber über HTTPS lädt.

Wichtige Begriffe: www, Apex, Redirects, Cookies und TLS

Redirect-Schleifen sind selten ein großer einzelner Fehler. Meist sind es ein paar kleine Einstellungen, die sich widersprechen.

Apex-Domain vs. www-Subdomain: Die Apex-Domain ist der Root-Name, z. B. example.com. Die www-Variante ist eine Subdomain, z. B. www.example.com. Beide können auf dieselbe App zeigen, aber du solltest eine als kanonische Adresse wählen.

Redirect: Ein Redirect sagt dem Browser "geh dorthin". Zum Beispiel das Weiterleiten von example.com auf www.example.com. Eine Redirect-Schleife entsteht, wenn der Browser zwischen zwei Adressen (oder Regeln) hin- und herspringt, z. B. www -> Apex -> www -> Apex, bis er aufgibt.

Redirect-Schleifen treten oft auf, wenn deine App in eine Richtung umleitet, aber eine andere Schicht (Hosting, CDN, Proxy, Plattform-Einstellungen) zurückleitet.

TLS/SSL: TLS ist das, was das Schlosssymbol im Browser anzeigt. Es verschlüsselt den Verkehr und belegt, dass die Seite zum Hostnamen passt. Wenn TLS fehlt, für den falschen Host ausgestellt ist (nur www aber nicht Apex oder umgekehrt) oder mit alten HTTP-Regeln gemischt wird, können Browser Nutzer warnen, Anfragen blockieren oder wichtige Dateien nicht laden.

Cookies und Login-Sessions: Cookies sind kleine Datenstücke, die der Browser für eine Seite speichert, oft um dich eingeloggt zu halten. Cookies sind strikt in ihrem Geltungsbereich. Häufige Fallstricke sind:

• Cookie Domain: Ein für www.example.com gesetztes Cookie funktioniert nicht verlässlich auf example.com.
• Secure: Viele Auth-Cookies sollten nur über HTTPS gesendet werden.
• SameSite: Beeinflusst Anmeldeflüsse, besonders bei Redirects oder Drittanbieter-Providern.

Wenn sich deine App nach dem Login sofort wieder auf die Anmeldeseite schickt, ist ein Cookie-Domain-Mismatch eine der ersten Vermutungen.

Warum Redirect-Schleifen mit www und Apex passieren

Eine Schleife bedeutet meist, dass mehrere Redirect-Regeln gleichzeitig greifen. Eine Regel sagt "geh zu https", eine andere sagt "geh zu www" und eine dritte sagt "zurück zur Apex". Jede Regel kann für sich vernünftig aussehen. Zusammen erzeugen sie ein Bounce, aus dem der Browser nicht herauskommt.

Der häufigste Auslöser ist, dass mehr als eine Stelle zur gleichen Zeit Redirects macht. Deine App könnte HTTPS erzwingen, dein Hosting-Dashboard www erzwingen und ein CDN oder Framework könnte den Host umschreiben.

Die Reihenfolge spielt auch eine Rolle. Wenn HTTP -> HTTPS zuerst passiert und dann www -> Apex (oder umgekehrt), kannst du unbeabsichtigt zwischen zwei "kanonischen" URLs hin- und herspringen. Das ist leicht zu erzeugen, wenn du eine Domain spät hinzufügst und Einstellungen aus älteren Umgebungen übernimmst, ohne zu prüfen, wie sie sich kombinieren.

Proxy-Verwirrung ist eine weitere häufige Ursache. Deine App bekommt möglicherweise Traffic über HTTP vom Platform-Origin, obwohl Nutzer über HTTPS zugreifen. Fehlen Proxy-Header wie X-Forwarded-Proto oder werden sie ignoriert, denkt die App, sie müsse auf HTTPS upgraden, und die Plattform legt dann wieder eigene Regeln drauf.

Gecachte Redirects können das Problem zufällig wirken lassen. Browser cachen 301-Antworten, und CDNs können sie ebenfalls cachen. Du korrigierst die Regeln, aber deine Testmaschine hält weiterhin an einer alten Weiterleitung fest.

Ein paar schnelle Schritte zur Eingrenzung:

• Teste in einem privaten Fenster, um Browser-Cache-Effekte zu reduzieren.
• Prüfe eine einzelne Anfrage in den DevTools (Netzwerk) und lies die Location-Header.
• Deaktiviere vorübergehend Redirects entweder in der App oder beim Host, um die "extra" Regel zu entdecken.
• Bestätige, dass Proxy-/Forwarded-Header so gesetzt sind, wie deine App es erwartet.

Schritt für Schritt: Eine kanonische Domain wählen und Redirects reparieren

Eine Redirect-Schleife bedeutet meist, dass zwei (oder mehr) Schichten darüber streiten, wo deine Seite "sein sollte". Die schnellste Lösung ist, eine kanonische URL zu wählen und alle anderen Versionen darauf zu verweisen.

Entscheide zuerst, ob du die Apex- oder die www-Variante als wahre Adresse willst. Beides ist in Ordnung. Konsistenz ist entscheidend — in DNS, TLS, App-Einstellungen und Redirects.

Eine einfache 5-Schritte-Lösung

1. Wähle den kanonischen Host: Entscheide dich für https://example.com oder https://www.example.com. Schreib es auf.
2. Wähle einen Ort für Redirects: Führe Redirects, wenn möglich, nur in einer Schicht aus (Edge/CDN, Load Balancer oder App). Mehrere Schichten sind die typische Ursache für Schleifen.
3. Erstelle eine Regel: Leite den nicht-kanonischen Host auf den kanonischen Host weiter, unter Beibehaltung von Pfad und Query-String. Vermeide zusätzliche "Aufräum"-Regeln, bis das Grundszenario funktioniert.
4. Lass die App die kanonische Host erzeugen: Prüfe Einstellungen wie Base URL, Public URL, Site URL und Auth Callback URL. Wenn die App absolute Links mit falschem Host baut, springen Nutzer zwischen Domains.
5. Teste aus einem sauberen Browserzustand: Nutze ein privates Fenster oder ein frisches Profil, damit alte Cookies und gecachte Redirects das Verhalten nicht verschleiern.

Nachdem du die Redirect-Regel gesetzt hast, bestätige, dass nicht gleichzeitig in der App weitergeleitet wird (z. B. "HTTPS erzwingen" und gleichzeitig eine Edge-Regel, die Protokoll/Host umschreibt). Ein Redirect reicht.

Ein schneller Check: Tippe beide Varianten (www und Apex) in die Adressleiste. Du solltest jedes Mal auf derselben finalen URL landen, mit höchstens einem Redirect. Wenn es hin- und her springt, leitet noch etwas anderes um und muss entfernt oder deaktiviert werden.

Cookie-Domain-Probleme, die Login und Sessions kaputtmachen

Wenn Login auf einem Host (z. B. www.example.com) funktioniert, auf dem anderen (example.com) aber nicht, sind meist Cookies der Grund. Typische Anzeichen sind andauernde "bitte einloggen"-Bildschirme, Sessions, die nach einem Refresh verschwinden, oder Nutzer, die ausgeloggt werden, wenn sie zwischen Hosts wechseln.

Ein häufiger Fehler ist, das Cookie-Domain-Attribut falsch zu setzen. Wenn du Domain=www.example.com setzt, wird dieses Cookie nicht an example.com gesendet (und deckt andere Subdomains nicht ab). Wenn du eine gemeinsame Session über Subdomains brauchst, benötigst du in der Regel Domain=example.com (die Apex). Wenn kein Teilen nötig ist, sind host-spezifische Cookies (kein Domain-Attribut) oft sicherer, weil sie nicht an andere Subdomains geleakt werden können.

HTTPS-Änderungen können Sessions ebenfalls brechen. Nach einer späten Domain-Migration stellen Apps oft auf HTTPS um und erzwingen Redirects. Wenn das Session-Cookie kein Secure hat, verweigern Browser möglicherweise das Senden auf HTTPS-Anfragen. Wenn SameSite zu restriktiv ist, können Cross-Site-Schritte wie OAuth-Anmeldeflüsse oder Rückkehrseiten von Zahlungen stillschweigend fehlschlagen, sodass der Nutzer auf einem Tab "eingeloggt" und auf dem anderen anonym erscheint.

Subdomains sind eine weitere Falle: app.example.com und api.example.com müssen möglicherweise beim Cookie-Scope übereinstimmen. Wenn dein Frontend ein Auth-Cookie erwartet, das von der API gesetzt wurde, müssen beide kompatible Domains verwenden, und deine CORS- sowie Credentials-Einstellungen müssen Cookies erlauben.

Um zu prüfen, was passiert, öffne die DevTools deines Browsers und kontrolliere:

• Welche Cookies nach dem Login gesetzt werden und deren Domain, Path, SameSite und Secure-Werte
• Ob das Cookie auf www und Apex erscheint
• Ob Requests einen Cookie-Header zeigen oder der Browser das Cookie fallen lässt

Cookie-Probleme werden oft fälschlich für Redirect-Probleme gehalten. Manchmal ist die Redirect-Kette in Ordnung, aber die Session bleibt nicht bestehen, sodass die App Nutzer wieder zum Sign-in schickt.

TLS-Einstellungen, die Warnungen, Blockierungen und Ladefehler verursachen

TLS-Probleme sehen oft so aus, als sei die Seite down, tatsächlich weigert sich der Browser aber, dem Gesehenen zu vertrauen. Bei einer Domain-Änderung fühlt es sich inkonsistent an, weil manche Nutzer www und andere die Apex sehen.

Fang mit den Grundlagen an: Dein Zertifikat muss die exakten Hostnamen abdecken, die du bedienst. Ein häufiger Fehler ist, ein Zertifikat nur für www.example.com zu haben, während DNS oder Redirects Nutzer noch auf example.com lassen (oder umgekehrt). Browser behandeln das als unterschiedliche Namen.

Wissen, wo HTTPS tatsächlich endet

HTTPS kann an verschiedenen Stellen terminiert werden: CDN, Load Balancer, Reverse Proxy oder dein App-Server. Probleme entstehen, wenn eine Schicht denkt, Traffic sei HTTPS, die nächste Schicht aber HTTP sieht. Das kann Schleifen verursachen (die App versucht ständig, auf HTTPS zu wechseln) und sichere Cookies kaputtmachen.

Wenn du unsicher bist, prüfe:

• Welche Komponente das TLS-Zertifikat hat (CDN, Load Balancer oder Server)
• Ob die App ein Original-Protokoll-Header empfängt (oft X-Forwarded-Proto)
• Ob die App so konfiguriert ist, dass sie dem Proxy vertraut
• Ob www und Apex identisch gehandhabt werden

HSTS und Mixed Content: zwei Wege, wie du feststeckst

HSTS sagt dem Browser: "verwende immer HTTPS für diese Domain." Wenn du HSTS aktivierst, bevor HTTPS überall korrekt ist (inkl. Redirects, APIs und Subdomains), kannst du Nutzer in Fehlerzustände sperren, die schwer zu beheben sind.

Mixed Content ist das andere stille Problem. Wenn dein HTML Scripte, Bilder oder CSS über http lädt, blockiert der Browser sie eventuell auf einer https-Seite. Das Ergebnis kann aussehen wie "der Login-Button tut nichts" oder "die Seite lädt ohne Styling".

App-Config-Fallen: Proxies, Basis-URLs, Auth-Callbacks

Viele "Redirect"-Probleme sind eigentlich ein Streit zwischen deiner App und der Hosting-Plattform darüber, was die echte öffentliche URL ist.

Proxies und welche Header deine App vertraut

Wenn deine App hinter einem Reverse-Proxy oder CDN sitzt (typisch bei Managed-Hosts), sieht die Anfrage, die deinen Server erreicht, möglicherweise wie reines HTTP aus, obwohl der Besucher HTTPS verwendete. Apps lösen das mit Headern wie X-Forwarded-Proto und X-Forwarded-Host.

Wenn dein Framework diesen Headern nicht vertraut, denkt es, jede Anfrage sei unsicher und erzwingt einen HTTPS-Redirect. Erzwingt die Plattform bereits HTTPS, landen Nutzer im Bounce zwischen Regeln.

Achte auch auf Einstellungen wie "force HTTPS", "trust proxy" und "secure cookies only". Das sind gute Einstellungen, aber sie müssen zur Art passen, wie deine Plattform TLS terminiert.

Basis-URLs, Callbacks, CORS und Integrationen

Sobald du eine kanonische Host-Entscheidung getroffen hast (www oder Apex), musst du jede Stelle aktualisieren, die eine vollständige URL speichert. Wenn auch nur eine Einstellung auf den alten Host zeigt, kannst du kaputte Logins, fehlgeschlagene OAuth-Handshakes oder API-Aufrufe bekommen, die ohne Feedback fehlschlagen.

Häufige Orte, die Aufmerksamkeit brauchen:

• App-Basis-URL (zum Bauen absoluter Links und Redirects)
• Auth-Callback- oder Redirect-URLs (OAuth-Provider sind strikt)
• Erlaubte Origins für CORS (der Frontend-Host muss exakt übereinstimmen)
• Webhook-Endpunkte (Zahlungen, E-Mails, CRM usw.)
• Umgebungsvariablen wie NEXTAUTH_URL, PUBLIC_URL oder ähnliche

Beispiel: Deine Login-Seite ist unter https://www.example.com, aber dein OAuth-Provider ist mit https://example.com/auth/callback konfiguriert. Der Provider leitet zurück zur Apex, deine App leitet zu www weiter, und der Provider lehnt die Antwort ab, weil die Callback-URL nicht mehr übereinstimmt.

Häufige Fehler, die das Problem verschlimmern

Die meisten Domain-Probleme werden schlimmer, wenn du Einstellungen an drei Stellen gleichzeitig änderst. Ein Redirect, der in deiner App harmlos aussieht, kann mit einem Redirect beim CDN oder Hosting-Anbieter kämpfen, und du hast am Ende eine schwer sichtbare Schleife.

Das Muster "es funktionierte kurz, dann brach es wieder" deutet meist auf Caching hin. Der Browser hat einen Redirect gecacht, ein Proxy hat einen anderen gecacht, und jetzt nehmen Anfragen je nach Startpunkt unterschiedliche Pfade.

Fehler, die am meisten Ärger machen:

• Redirects in mehreren Schichten aktivieren (Hosting-Panel, CDN/Edge und App)
• Weitere Redirects hinzufügen, bis eine scheinbar funktioniert, dabei API-Aufrufe, Callbacks oder Assets kaputt machen
• Vergessen, dass Login-Cookies und Auth-Callbacks noch an die alte Domain gebunden sind
• HSTS zu früh aktivieren
• Nur in einem Browser-Profil testen und nicht sehen, was neue Nutzer erleben

Eine einfache Testgewohnheit spart Stunden Rätselraten: prüfe in einem frischen Profil (oder Inkognito), dann in einem zweiten Browser und schließlich auf dem Handy. Wenn das Verhalten unterschiedlich ist, kämpfst du wahrscheinlich mit Cache, Cookies oder HSTS, nicht mit deiner aktuellen Redirect-Regel.

Schnelle Checks, bevor du es als behoben ansiehst

Bevor du aufhörst zu debuggen, führe Checks in einem normalen Browserfenster (nicht inkognito) und in einem Inkognito-Fenster durch. Redirect- und Cookie-Probleme verbergen sich oft, bis du den Login-Fluss wiederholst.

Redirect-Checks (die "genau einmal"-Regel)

Gib jede Variante in die Adressleiste ein und beobachte die finale URL. Du willst einen sauberen Sprung, kein Hin-und-Her zwischen Hosts oder Protokollen.

• http://yourdomain.com sollte genau einmal zu https:// springen.
• http://www.yourdomain.com sollte genau einmal zu https:// springen.
• Der nicht-kanonische Host (www oder Apex) sollte genau einmal auf deinen kanonischen Host weiterleiten.
• Das finale kanonische URL nochmal einzufügen sollte überhaupt nicht weiterleiten.

Selbst wenn ein Host immer weiterleitet, sollten während des TLS-Handshakes beide Hosts ein gültiges Zertifikat präsentieren.

Session- und Schlosssymbol-Checks

Melde dich auf dem kanonischen Host an, lade die Seite neu, schließe den Tab und öffne die Seite erneut. Wenn du ausgeloggt bist, vermute ein Cookie-Domain-Mismatch, SameSite-Einstellungen oder ein Callback, das noch auf den falschen Host zeigt.

Prüfe auch die Sicherheitsindikatoren des Browsers. Du solltest auf Apex und www ein gültiges Schloss sehen (auch wenn einer sofort weiterleitet). Öffne ein paar wichtige Seiten und bestätige, dass es keine Mixed-Content-Warnungen gibt (z. B. ein altes http://-Script oder Bild).

Ein realistisches Beispiel: Domain nach einem KI-Prototyp hinzufügen

Ein Gründer veröffentlicht einen KI-generierten SaaS-Prototypen unter einer Preview-URL (z. B. einer Plattform-Subdomain). Registrierungen funktionieren, das Dashboard lädt und Zahlungen bestehen einen Schnelltest. Dann fügt er am Vorabend einer Demo eine Custom Domain hinzu und plötzlich bricht alles zusammen: die Seite springt zwischen www und Apex, Login kickt ständig zurück zum Sign-in und der Browser zeigt Sicherheitswarnungen.

Was sich ändert, ist nicht nur eine Sache. Der Browser sieht jetzt einen anderen Host, also passen Cookies nicht mehr. OAuth-Provider (Google, GitHub usw.) lehnen den Redirect ab, weil die Callback-URL sich geändert hat. Und die Hosting-Schicht könnte HTTPS erzwingen, während die App intern noch HTTP-URLs generiert.

Ein Wiederherstellungsplan:

• Wähle eine kanonische Host-Variante (www oder Apex) und richte alles darauf aus.
• Lege Redirects an einer Stelle an und ziele auf einen einzigen Hop: nicht-kanonisch -> kanonisch.
• Passe Cookie-Scope an die kanonische Entscheidung an und markiere Auth-Cookies Secure, wenn du HTTPS nutzt.
• Aktualisiere Auth-Einstellungen: Callback-URLs, erlaubte Origins und alle hardcodierten Basis-URLs.
• Teste erneut in einer frischen Browsersitzung, damit alte Cookies das echte Problem nicht verstecken.

Wenn du dich dabei ertappst, dass du in drei Dashboards gleichzeitig änderst (App-Config, Auth-Provider, Hosting-Regeln) und das Verhalten sich weiter ändert, halte an und vereinfache. Redirect-Loops und Session-Bugs erscheinen oft zufällig, weil ein altes Cookie oder ein zusätzlicher Redirect-Schritt das Ergebnis verändert.

Nächste Schritte: Ein stabiles Domain-Setup festschreiben

Schreibe zuerst deine eine Quelle-der-Wahrheit auf (inkl. Schema und Host), z. B. https://www.example.com (oder die Apex). Formuliere dann explizit die eine Redirect-Regel, die du willst: jede andere Host-Variante soll mit einem einzelnen 301 auf genau diese URL zeigen.

Als Nächstes liste alle Stellen auf, die Redirects auslösen oder Sessions beeinflussen können: Domain/DNS-Einstellungen, CDN-/Edge-Regeln, Load Balancer/Proxies, App-Basis-URL und Auth-Callbacks sowie Cookie-/Session-Einstellungen. Ziel ist einfache Verantwortung: eine Stelle handhabt Redirects, eine Stelle terminiert TLS und eine Stelle definiert die öffentliche Basis-URL.

Wenn die App von Tools wie Lovable, Bolt, v0, Cursor oder Replit generiert wurde, gehe davon aus, dass es versteckte Defaults und Config-Drift gibt. Ein Prototyp kann auf einem Host funktionieren, weil ein Framework URLs automatisch erkennt, und dann nach einer späten Domain-Änderung scheitern, wenn du einen Proxy, ein CDN oder eine strengere HTTPS-Policy hinzufügst.

Wenn du in einer Schleife feststeckst und der Code unordentlich ist, spezialisiert sich FixMyMess (fixmymess.ai) darauf, AI-generierte Apps zu diagnostizieren und zu reparieren — inklusive Redirect-Regeln, Cookie/Session-Scope und TLS/Proxy-Einstellungen. Ein kostenloses Code-Audit kann schnell die wenigen Abweichungen identifizieren, die die ganze Kettenreaktion auslösen.