Nutze diese Checkliste zur Fehlerbehebung bei benutzerdefinierten Domains, um DNS‑Einträge, Propagation‑Verzögerungen und SSL‑Timing zu diagnostizieren – mit einfachen Prüfschritten.
„Benutzerdefinierte Domain funktioniert nicht“ ist ein Sammelbegriff für ein paar verschiedene Ausfälle. Dein Browser zeigt das Symptom, nicht die Ursache. Bevor du etwas änderst, benenne genau, was du siehst.
Typische Symptome sind:
Meistens ist nur eine Sache falsch:
Bevor du mit der Fehlerbehebung beginnst, stelle sicher, dass du Zugriff auf zwei Orte hast: dort, wo du DNS‑Einträge bearbeiten kannst (Registrar oder DNS‑Provider), und dort, wo du die Domain auf der Hosting‑Seite anbindest. Wenn du beispielsweise eine auf Koder.ai bereitgestellte App mit einer benutzerdefinierten Domain verbindest, brauchst du DNS‑Zugriff für die Domain und die Domain‑Einstellungen in der Hosting‑/Deployment‑Konfiguration der App.
Einige Fehler sind sofort behoben (z. B. ein Tippfehler). Andere dauern. DNS‑Änderungen können eine Weile brauchen, und SSL wird normalerweise erst abgeschlossen, wenn DNS korrekt zeigt und die Domain erreichbar ist. Ziel ist es, das Raten zu stoppen und jede Ebene nacheinander zu bestätigen.
Die meisten Domain‑Probleme lassen sich auf eine Diskrepanz zwischen (1) dem Hostnamen, den du testest, (2) wo DNS verwaltet wird, und (3) worauf der Eintrag tatsächlich zeigt zurückführen. Sobald diese drei übereinstimmen, ist SSL meistens der letzte Schritt.
Domains haben zwei gebräuchliche Formen: die Root‑Domain (example.com, auch Apex genannt) und Subdomains (www.example.com, app.example.com). Sie sind verwandt, können aber unterschiedliche DNS‑Einträge haben. Es ist also normal, dass www funktioniert, während die Apex‑Domain fehlschlägt oder umgekehrt.
Nameserver entscheiden, wer für deine DNS‑Zone zuständig ist. Wenn du eine Domain bei einer Firma gekauft hast, die Nameserver aber auf eine andere Firma zeigen, musst du DNS dort bearbeiten, wo die Nameserver hinzeigen. Viele „Ich habe es aktualisiert, aber nichts hat sich geändert“‑Situationen passieren, weil die Einträge im falschen Dashboard editiert wurden.
Das machen die wichtigsten Eintragstypen:
TTL ist der „Wie lang cachen?“‑Timer. Niedrigere TTL bedeutet, Caches aktualisieren schneller. Höhere TTL bedeutet, du musst möglicherweise länger warten, selbst nachdem du den Eintrag korrigiert hast. Dass man den alten Wert eine Weile sieht, kann normal sein.
Wenn eine benutzerdefinierte Domain fehlschlägt, lässt sie sich meistens in eine von vier Kategorien einordnen: DNS löst nicht auf, DNS zeigt auf den falschen Ort, SSL ist nicht bereit oder es schlägt nur bei einigen Leuten fehl wegen Caching.
Verwende diesen Entscheidungsbaum:
www funktioniert, die Root‑Domain aber nicht (oder umgekehrt), hast du wahrscheinlich nur einen Hostname konfiguriert oder widersprüchliche Redirect‑Regeln.Arbeite schneller, indem du den genauen Hostnamen notierst, der fehlschlägt (Apex vs www), und die exakte Fehlermeldung. Auf Hosting‑Plattformen, die Domains und Zertifikate automatisieren, sagt der Unterschied zwischen „Host nicht gefunden“ und „Zertifikat ausstehend“, ob du DNS‑Einträge korrigieren oder einfach auf SSL nach korrektem DNS warten musst.
Viele Domain‑Fehler beginnen mit einer einfachen Unstimmigkeit: Du hast DNS für einen Hostnamen eingerichtet, testest aber einen anderen.
Schreibe zuerst den exakten Hostnamen auf, den du live haben willst. Die Root‑Domain sieht aus wie example.com. Eine Subdomain wie www.example.com oder app.example.com. Das sind getrennte DNS‑Einträge, daher bedeutet „www funktioniert“ nicht automatisch, dass die Root‑Domain funktioniert.
Finde als Nächstes das erwartete Ziel von deiner Hosting‑Plattform. Manche Hosts geben eine IP‑Adresse vor (für einen A‑ oder AAAA‑Eintrag). Andere geben einen Ziel‑Hostnamen an (für einen CNAME). Wenn dein Host in einer Domain‑Setup‑Ansicht einen Wert anbietet, betrachte diesen als die Quelle der Wahrheit.
Bevor du etwas änderst, halte fest, was aktuell gesetzt ist. Halte es einfach:
Stelle außerdem sicher, dass du die richtige DNS‑Zone bearbeitest. Es ist leicht, die falsche Domain, die falsche Umgebung oder das falsche Provider‑Konto zu aktualisieren.
Viele Probleme entstehen einfach durch den falschen Eintragstyp für den Hostnamen, den du verbinden willst. Trenne zwei Fälle: die Root‑Domain (example.com) und eine Subdomain (www.example.com). Sie verhalten sich bei vielen DNS‑Providern unterschiedlich.
Ein A‑Record zeigt einen Namen auf eine IPv4‑Adresse. Viele Setups nutzen einen A‑Record für die Root‑Domain, weil einige Provider kein CNAME am Apex erlauben. Wenn dein Host dir eine IP gibt, ist ein A‑Record meist korrekt.
Ein AAAA‑Record ist die IPv6‑Variante. Ein verirrter AAAA‑Record, der auf ein altes Ziel zeigt, kann verwirrendes „bei mir geht’s“-Verhalten erzeugen, weil manche Besucher IPv6 nutzen, andere IPv4. Wenn dein Host kein IPv6‑Ziel angibt, behebt das Entfernen eines falschen AAAA‑Eintrags oft inkonsistente Fehler.
Ein CNAME zeigt eine Subdomain auf einen anderen Hostnamen (oft für www). Er ist nützlich, wenn der Host von dir verlangt, auf einen benannten Endpunkt zu zeigen, der sich hinter den Kulissen ändern kann.
Ein TXT‑Record dient der Verifikation und Challenges (einschließlich einiger SSL‑Prüfungen). Häufige Fehler sind das Anlegen des TXT am falschen Namen (Root vs _acme-challenge vs eine Subdomain), zusätzliche Leerzeichen oder das Einfügen des falschen Werts.
Schau vor dem Weitergehen nach Konflikten. Das sind die häufigsten Problemursachen:
Viele „benutzerdefinierte Domain funktioniert nicht“ Fälle haben nichts mit dem Wert des Eintrags zu tun. Sie entstehen, weil der Eintrag an der falschen Stelle hinzugefügt wurde. Wenn deine Domain die Nameserver von Provider A nutzt, bewirken Änderungen im Dashboard von Provider B nichts, selbst wenn die Einträge dort korrekt aussehen.
Prüfe, welche Nameserver deine Domain tatsächlich verwendet. Das siehst du meist in den Domain‑Einstellungen deines Registrars unter „Nameserver“. Für eine zweite Meinung kannst du DNS direkt von deinem Rechner fragen:
dig NS example.com
Die von diesem Befehl zurückgegebenen Nameserver sind die autoritativen.
Ein schneller Annäherungscheck:
ns1... und ns2... gibt, müssen diese exakten Werte beim Registrar eingetragen sein.Wenn du Einträge beim falschen Provider aktualisierst, siehst du oft zwei Dashboards, die nicht übereinstimmen. Nur die autoritativen Nameserver zählen.
Achte außerdem auf Verzögerungen nach einem Nameserver‑Wechsel beim Registrar. Während des Übergangsfensters können Ergebnisse je nach Teststandort inkonsistent aussehen. Wenn Nameserver sich noch ändern, pausiere weitere Eintragsänderungen, bis die Nameserver stabil sind, und fahre dann fort.
„Propagation“ ist kein Schalter. Es ist eine Kette von DNS‑Caches (ISP, Mobilfunkanbieter, öffentliche Resolver und deine eigenen Geräte), die sich mit unterschiedlicher Geschwindigkeit aktualisieren. Deshalb kann deine Domain für eine Kollegin funktionieren, aber nicht für dich.
TTL (Time to Live) sagt Caches, wie lange sie eine Antwort behalten dürfen. Wenn das alte TTL 1 Stunde war, werden einige Leute den alten Wert bis zu einer Stunde lang sehen. Das Senken des TTL hilft nur, wenn du es vor der Änderung gemacht hast.
Um Caching‑Verzögerungen von echten Fehlern zu trennen, mach ein paar schnelle Prüfungen:
Wenn der Eintrag an allen getesteten Orten falsch ist (falsche IP, fehlendes www, alter CNAME), korrigiere ihn. Wenn die Einträge an den meisten Orten korrekt aussehen, aber ein Netzwerk weiterhin den alten Wert zeigt, ist es meist ein Cache‑Delay.
SSL‑Zertifikate scheitern meist aus einem Grund: Der Zertifikatsanbieter kann die Domain nicht validieren, bis DNS konsistent auf den richtigen Ort zeigt.
Die normale Reihenfolge ist einfach:
Häufige Stolperfallen sind leicht zu übersehen. Ein falscher A‑ oder CNAME‑Zielwert schickt Validierungsprüfungen an den falschen Server. Ein veralteter AAAA‑Record kann deinen funktionierenden A‑Record für einige Besucher überlagern, sodass HTTPS nur für sie fehlschlägt. Fehlende erforderliche TXT‑Einträge können verhindern, dass eine Plattform ein Zertifikat ausstellt.
Nutze Symptome, um „noch in Ausstellung“ von „fehlkonfiguriert“ zu unterscheiden:
Während du wartest, ändere nicht ständig die Einträge. Jede Änderung setzt die Uhr zurück und kann eine geteilte Welt erzeugen, in der verschiedene Netzwerke unterschiedliche Antworten sehen. Setze die korrekten Einträge einmal und überprüfe dann Auflösung und Verifikation, bis das Zertifikat ausgestellt ist.
Wenn du eine Plattform wie Koder.ai nutzt, ist der sicherste Ablauf gleich: Bestätige, dass DNS auf das erwartete Ziel zeigt, entferne falsche AAAA‑Einträge, falls vorhanden, und gib SSL Zeit, nachdem DNS stabil ist.
Gute Fehlerbehebung ist meist Vergleich: Was du siehst vs. Was du erwartest. Verlass dich nicht auf „es lädt auf meinem Handy“. Nutze wiederholbare Prüfungen.
Verwende ein DNS‑Lookup‑Tool (wie nslookup oder dig) und bestätige, dass der zurückgegebene Wert dem entspricht, was du beabsichtigst (eine IP für A oder AAAA, ein Hostname für CNAME, ein Token für TXT).
# Apex (Root) Domain
dig example.com A
dig example.com AAAA
# www Subdomain
dig www.example.com CNAME
# TXT (wird oft für Verifikation genutzt)
dig example.com TXT
Prüfe beide Namen, die du nutzt: die Apex (example.com) und www (www.example.com). Es ist üblich, dass einer korrekt ist, während der andere noch auf etwas Altes zeigt.
Öffne sowohl http:// als auch https:// für Apex und www. Du willst eine klare „Hauptdomain“ und eine saubere Weiterleitung.
www) und leite die andere darauf weiter.Wenn die Ergebnisse je nach Netzwerk unterschiedlich sind, siehst du wahrscheinlich Caching oder Propagation. Führe ein kleines Log: Was du geändert hast, wo du es geändert hast, die Uhrzeit und was du beobachtet hast.
Die meisten DNS‑ und SSL‑Probleme sind keine Rätsel. Es sind kleine Fehler, die dich dazu bringen, das falsche zu prüfen oder Dinge zu schnell zu ändern, um ein klares Ergebnis zu erhalten.
Die häufigste Zeitfalle ist das Bearbeiten von DNS an zwei Orten. Das passiert oft nach einem Nameserver‑Wechsel: Du aktualisierst Einträge beim Registrar, aber DNS wird tatsächlich anderswo gehostet (oder umgekehrt). Alles sieht in einem Dashboard korrekt aus, aber öffentlich ändert sich nichts.
Ein weiterer Klassiker ist der Versuch, ein CNAME auf die Root‑Domain zu setzen bei einem Provider, der das nicht unterstützt. Möglicherweise brauchst du stattdessen einen A‑Record oder einen ALIAS/ANAME‑ähnlichen Eintrag, falls dein DNS‑Provider das anbietet.
IPv6 kann ebenfalls Probleme machen. Ein alter AAAA‑Record kann einige Besucher zum falschen Server schicken, während andere korrekt über IPv4 landen.
Sei vorsichtig mit „nur für alle Fälle“‑Einträgen. Mehrere A‑Records können wie unbeabsichtigtes Load‑Balancing wirken, wenn eines der Ziele falsch ist, besonders beim Zeigen einer benutzerdefinierten Domain auf eine gehostete App.
Eine letzte Regel: Setze die Uhr nicht immer wieder zurück.
Kleine, ruhige Änderungen schlagen ständiges Herumpfuschen.
Du startest eine neue App und richtest sowohl example.com als auch www.example.com ein. Nach ein paar Minuten lädt www.example.com problemlos, aber die Root‑Domain zeigt einen DNS‑Fehler, lädt eine alte Seite oder HTTPS bleibt ausstehend. Dieses Muster ist verbreitet und hat meist eine kleine Ursache.
Beginne mit der langweiligen Frage: Bearbeitest du DNS am richtigen Ort? Wenn deine Domain bei einem Anbieter registriert ist, DNS‑Nameserver aber bei einem anderen liegen, kannst du stundenlang Einträge ändern, ohne dass sich öffentlich etwas ändert. Prüfe zuerst die Nameserver und öffne dann das DNS‑Panel des Providers, auf den diese Nameserver zeigen.
Vergleiche anschließend die beiden Hostnamen. www ist typischerweise ein CNAME. Die Root‑Domain ist komplizierter: Viele Provider erlauben kein CNAME am Apex, daher braucht sie oft einen A‑Record auf eine IP oder einen ALIAS/ANAME‑artigen Eintrag, falls der Provider das unterstützt.
Ein Entscheidungsweg, der praktisch funktioniert:
example.com hat keinen Eintrag (oder zeigt woanders hin)? Korrigiere den Apex‑Eintrag.Das korrekte Endergebnis ist unspektakulär: Beide example.com und www.example.com führen zur selben App, eine Domain ist kanonisch (die andere leitet darauf weiter) und HTTPS ist gültig.
Wenn eine Domain‑Einrichtung scheitert, kommen die meisten Lösungen aus ein paar schnellen Prüfungen. Mach diese, bevor du etwas anderes änderst.
Nachdem DNS klar korrekt ist, prüfe dann SSL. Viele Plattformen stellen das Zertifikat erst aus, nachdem sie die Domain konsistent auf das erwartete Ziel auflösen konnten. Wenn du zu früh prüfst, kannst du eine normale Verzögerung fälschlich als Fehler werten.
Wenn du eine benutzerdefinierte Domain zu einer bereitgestellten App auf Koder.ai hinzufügst, betrachte die Domain‑Einrichtungsseite als Referenz für das erwartete Ziel und prüfe den Status erst erneut, nachdem DNS Zeit zur Propagation hatte.
Der schnellste Weg, DNS‑ und SSL‑Fehler zu vermeiden, ist eine kurze „Domain‑Setup‑Notiz“ für jedes Projekt. Das ist ein wiederverwendbares Runbook, das du beim nächsten Launch kopieren kannst.
Bewahre sie in deinen Projektdokumenten auf und fülle sie aus, bevor du DNS anfasst:
Während des Launches mache eine Person zum DNS‑Owner. DNS bricht am häufigsten, wenn zwei Personen gleichzeitig „fixen“ (zum Beispiel eine ändert Nameserver, während eine andere Einträge bearbeitet).
Auf der Hosting‑Seite plane sichere Rückschritte. Wenn deine Plattform Snapshots oder Rollbacks unterstützt, mache vor dem Ändern des Routings ein Snapshot, damit du schnell zum letzten bekannten guten Zustand zurückkehren kannst. Wenn du auf Koder.ai arbeitest, kannst du Planning Mode nutzen, um die Domain‑Schritte aufzuschreiben, sie in der richtigen Reihenfolge anzuwenden und bei Bedarf zurückzusetzen.
Wenn du DNS bestätigt hast und trotzdem Fehler siehst, höre auf zu raten und eskaliere mit Belegen:
Wenn du eskalierst, füge Hostname, erwartete Einträge, aktuelle Resolver‑Ergebnisse und Zeitstempel bei. Das macht aus langsamem Hin‑und‑Her eine schnelle Lösung.
Es bedeutet meist, dass eine Schicht in der Kette nicht stimmt: DNS löst nicht auf, DNS zeigt auf das falsche Ziel, der Server/Host erkennt deinen Hostnamen nicht oder HTTPS/SSL wurde noch nicht ausgestellt. Beginne damit, die genaue Fehlermeldung aufzuschreiben und den exakten Hostnamen, den du eingegeben hast (Apex vs www).
Weil example.com (die Apex‑Domain) und www.example.com separate Hostnamen mit eigenen DNS‑Einträgen sind. Häufig ist für www ein funktionierender CNAME vorhanden, während die Apex‑Domain keine A‑Record hat, den falschen A‑Record hat oder das DNS‑Provider‑Setup eine CNAME‑Lösung am Root nicht unterstützt.
Prüfe die Nameserver der Domain beim Registrar und vergleiche sie mit dem DNS‑Provider, den du bearbeitest. Nur der Provider, der in den aktiven Nameservern steht, ist autoritativ; Änderungen an anderen Stellen wirken sich nicht auf das öffentliche Internet aus.
Nutze einen A‑Record, wenn dein Host dir eine IPv4‑Adresse gibt, einen AAAA‑Record nur bei einer IPv6‑Adresse, und einen CNAME, wenn dein Host dir einen anderen Hostnamen vorgibt (häufig für www). TXT‑Einträge dienen der Verifikation und Challenges und müssen genau am vom Host angegebenen Namen angelegt werden.
Ein veralteter oder falscher AAAA‑Record kann einige Besucher per IPv6 zu einem alten Server schicken, während andere über IPv4 korrekt ankommen, was zu „bei mir geht’s“‑Verwirrung führt. Wenn dein Host kein IPv6‑Ziel angegeben hat, ist das Entfernen eines falschen AAAA‑Eintrags oft die einfachste Lösung.
Meistens wurde nur ein Hostname auf der Hosting‑Seite konfiguriert (nur Apex oder nur www) oder es gibt widersprechende Redirect‑Regeln, die zwischen HTTP/HTTPS oder Apex/www hin und her springen. Wähle einen kanonischen Hostnamen, konfiguriere beide Hostnamen und sorge für genau eine saubere Weiterleitung.
Ja. Wenn DNS von mehreren Orten aus konsistent auf das erwartete Ziel zeigt, kann die Ausstellung des Zertifikats trotzdem Zeit brauchen. SSL wird in der Regel erst ausgestellt, wenn die Domain verlässlich auf das richtige Ziel aufgelöst wird. Änderungen am DNS zurückzuholen und neu zu setzen verlängert den Prozess.
TTL bestimmt, wie lange Resolver eine Antwort cachen. Selbst nach einer Korrektur sehen manche Netzwerke alte Werte, bis das TTL‑Fenster abläuft. Teste von zwei verschiedenen Netzwerken (z. B. WLAN und Mobilfunk) und vermeide ständige DNS‑Änderungen, damit du die Propagation sauber beobachten kannst.
Benutze reproduzierbare Prüfungen wie dig oder nslookup, um zu bestätigen, dass die A/AAAA/CNAME/TXT‑Werte dem erwarteten Ziel entsprechen, und teste dann sowohl http:// als auch https:// für Apex und www. Wenn ein Netzwerk andere DNS‑Antworten zeigt als ein anderes, handelt es sich meist um Caching; zeigen alle Netzwerke die falschen Antworten, ist es eine Konfigurationsfehler.
Bei Koder.ai: Nutze die Domain‑Einrichtungsseite der App als Referenz für das erwartete DNS‑Ziel, passe DNS exakt beim autoritativen Provider an, warte auf Propagation bevor du SSL prüfst, und verwende Snapshots/Rollback beim Anpassen des Routings in einer Live‑Umgebung, um schnell zum letzten bekannten guten Zustand zurückzukehren.