Checkliste zur Fehlerbehebung bei benutzerdefinierten Domains (DNS & SSL)

Was „benutzerdefinierte Domain funktioniert nicht“ normalerweise bedeutet

„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:

• Eine „Domain nicht gefunden“-Seite
• Die Domain lädt die falsche Website
• Eine „unsichere“ Warnung, obwohl HTTPS aktiviert ist
• Weiterleitungsschleifen (Hin‑ und Herspringen zwischen http und https oder zwischen Root‑Domain und www)

Meistens ist nur eine Sache falsch:

• DNS zeigt auf den falschen Ort oder der benötigte Eintrag fehlt
• Das Hosting‑Ziel ist nicht für diesen Hostnamen konfiguriert (der Server erkennt deine Domain nicht)
• SSL wurde noch nicht ausgestellt, wurde für einen anderen Hostnamen ausgestellt oder kann nicht ausgestellt werden, weil DNS nicht passt
• Caching verdeckt deine Änderungen (Browser‑Cache, DNS‑Resolver‑Cache oder alte TTL‑Werte)

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 kleinen DNS‑Konzepte, die wichtig sind (ohne Fachchinesisch)

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.

DNS‑Eintragstypen in einfachen Worten

Das machen die wichtigsten Eintragstypen:

• A: zeigt einen Namen auf eine IPv4‑Adresse (z. B. 203.0.113.10)
• AAAA: zeigt einen Namen auf eine IPv6‑Adresse
• CNAME: zeigt einen Namen auf einen anderen Hostnamen (häufig für www)
• TXT: speichert Text für Verifikation und Sicherheit (Eigentumsprüfungen, SPF usw.)

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.

Schritt‑für‑Schritt: Ein einfacher Entscheidungsbaum zur Ursachenisolierung

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:

1. Löst die Domain überhaupt auf? Wenn du NXDOMAIN (oder „Domain nicht gefunden“) siehst, fehlt der Eintrag, du bearbeitest die falsche DNS‑Zone oder die Nameserver sind nicht dort, wo du denkst.
2. Wenn sie auflöst, zeigt sie auf das richtige Ziel? Wenn die Seite lädt, aber die falsche Website, eine Parkseite oder ein alter Server erscheint, ist das A/AAAA/CNAME‑Ziel falsch oder ein verbliebener Eintrag hat Priorität.
3. Wenn sie korrekt zeigt, ist der Fehler nur HTTPS? Wenn HTTP funktioniert, HTTPS aber eine Zertifikatwarnung zeigt, ist SSL möglicherweise noch in Ausstellung, der Hostname stimmt nicht mit dem Zertifikat überein oder die Plattform wartet, bis DNS sich gesetzt hat.
4. Funktioniert es auf einem Gerät oder Netzwerk, aber nicht auf einem anderen? Behandle das als Caching oder Propagation.
5. Brechen Redirects (www vs Apex)? Wenn 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.

Schritt 1: Bestätige Hostname und erwartetes Ziel

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:

• Kopiere die aktuellen DNS‑Einträge für den Hostnamen, den du änderst
• Notiere vorhandene A, AAAA, CNAME und TXT‑Einträge
• Notiere das TTL

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.

Schritt 2: Wähle den richtigen DNS‑Eintragstyp (A, AAAA, CNAME, TXT)

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:

• Ein CNAME auf einem Namen, der gleichzeitig andere Record‑Typen hat
• Mehrere A‑ oder AAAA‑Einträge für denselben Namen, obwohl nur einer beabsichtigt war
• Alte Einträge, die für www oder die Root‑Domain übrig geblieben sind
• TXT‑Einträge, die am falschen Hostnamen erstellt wurden

Schritt 3: Verifiziere die Nameserver, damit du am richtigen Ort editierst

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.

Bestätige die autoritativen Nameserver

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:

• Wenn dein DNS‑Host dir Nameserver wie ns1... und ns2... gibt, müssen diese exakten Werte beim Registrar eingetragen sein.
• Wenn du kürzlich den DNS‑Provider gewechselt hast, bestätige, dass der Wechsel abgeschlossen ist, bevor du weitere Einträge änderst.
• Wenn eine Plattform „vorgeschlagene DNS‑Einträge“ anzeigt, ist das normalerweise nur eine Anleitung. Du musst die Einträge beim autoritativen DNS‑Provider hinzufügen.

Warum „Ich habe es aktualisiert, aber nichts hat sich geändert“ passiert

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.

Schritt 4: Propagation‑ und Cache‑Checks, die wirklich helfen

„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:

• Teste im Heim‑ oder Büro‑WLAN und dann über mobile Daten
• Bitte jemanden in einem anderen Netzwerk zu testen
• Nutze ein privates Fenster (um zwischengespeicherte Redirects auszuschließen)
• Starte dein Gerät neu oder leere lokal den DNS‑Cache, wenn du weißt, wie
• Überprüfe den exakten Hostnamen (Root vs www)

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.

Schritt 5: SSL‑Timing und warum „warte etwas“ manchmal richtig ist

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:

1. Setze die korrekten DNS‑Einträge.
2. Warte, bis sie von mehreren Orten korrekt aufgelöst werden.
3. Führe erforderliche Verifikationen durch (oft ein TXT‑Eintrag).
4. Lasse die Zertifikatsausstellung abschließen.

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:

• Noch in Ausstellung: HTTP kann funktionieren, HTTPS zeigt aber ein temporäres Standardzertifikat oder eine Meldung wie „nicht gültig“.
• Fehlkonfiguriert: Du siehst eine andere Website, eine ISP‑Parkseite oder DNS‑Lookup schlägt fehl (NXDOMAIN).

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.

Wie du jeden Schritt prüfst (ohne zu raten)

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.

DNS‑Antworten gegen dein erwartetes Ziel prüfen

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.

Browserverhalten prüfen (HTTP, HTTPS und Redirects)

Öffne sowohl http:// als auch https:// für Apex und www. Du willst eine klare „Hauptdomain“ und eine saubere Weiterleitung.

• Wähle eine kanonische Domain (entweder Apex oder www) und leite die andere darauf weiter.
• Vermeide Ping‑Pong‑Redirects (A leitet zu B, dann wieder zu A).
• Wenn HTTP funktioniert, HTTPS aber fehlschlägt, ist SSL entweder noch in Ausstellung oder DNS zeigt noch auf etwas Unerwartetes.

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.

Häufige Fehler, die Stunden kosten

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.

• Ändere Einträge nicht alle paar Minuten.
• Mische nicht alte und neue Ziele gleichzeitig.
• Warte, bis Caches sich gesetzt haben, bevor du Ergebnisse bewertest.

Kleine, ruhige Änderungen schlagen ständiges Herumpfuschen.

Ein realistisches Beispiel: www funktioniert, die Root‑Domain nicht

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:

• Nameserver falsch oder unerwartet? Zuerst das beheben.
• Nameserver korrekt, aber example.com hat keinen Eintrag (oder zeigt woanders hin)? Korrigiere den Apex‑Eintrag.
• Einträge sehen korrekt aus, aber Verhalten unterscheidet sich nach Gerät oder Netzwerk? Warte auf Propagation und lösche Caches.
• DNS löst korrekt auf, aber HTTPS schlägt fehl oder steckt fest? SSL wartet auf konsistentes DNS.

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.

Schnelle Checkliste, die du in 5 Minuten abarbeiten kannst

Wenn eine Domain‑Einrichtung scheitert, kommen die meisten Lösungen aus ein paar schnellen Prüfungen. Mach diese, bevor du etwas anderes änderst.

• Bestätige, dass du DNS am richtigen Ort bearbeitest (stimme dein Dashboard mit den autoritativen Nameservern der Domain ab).
• Verifiziere Hostname und Ziel genau (keine fehlende Subdomain, keine zusätzlichen Punkte). Vergleiche deinen Eintragstyp (A, AAAA, CNAME, TXT) mit dem, was dein Host erwartet.
• Entferne Konflikte (CNAME zusammen mit anderen Einträgen am gleichen Namen, oder alte A‑ und AAAA‑Einträge, die du nicht mehr brauchst).
• Prüfe aus zwei Blickwinkeln (Mobile‑Daten und WLAN). Wenn eines funktioniert und das andere nicht, ist es meistens Caching oder Propagation.
• Respektiere TTL. Wenn TTL 300 Sekunden ist, warte 5–10 Minuten, bevor du ein Urteil fällst. Wenn TTL 3600 ist, rechne näher an einer Stunde.

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.

Nächste Schritte: Mache die Domain‑Einrichtung für jeden Launch wiederholbar

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.

Eine einfache Domain‑Setup‑Notiz‑Vorlage

Bewahre sie in deinen Projektdokumenten auf und fülle sie aus, bevor du DNS anfasst:

• Domains und Hostnamen (Root, www und alle Subdomains)
• Erwartete Eintragstypen und Ziele (A, CNAME, TXT) und woher sie stammen
• Wo DNS bearbeitet wird (welcher Provider) und die aktiven Nameserver
• SSL‑Erwartungen (wer stellt aus, wie sieht „bereits“ aus)
• Verifikationsschritte, die du laufen lässt (Tool und erwartetes Ergebnis)

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.

Wann du eskalieren solltest (und an wen)

Wenn du DNS bestätigt hast und trotzdem Fehler siehst, höre auf zu raten und eskaliere mit Belegen:

• Der Registrar zeigt gesperrte Nameserver oder du kannst sie nicht ändern
• DNS‑Änderungen erscheinen nach dem erwarteten TTL‑Fenster nirgends
• SSL schlägt lange nach korrekter DNS‑Auflösung fehl (denke Stunden, nicht Minuten)
• Du siehst widersprüchliche Einträge, die du nicht entfernen kannst (Provider‑UI‑Fehler oder gesplittetes DNS)

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.