Bei den von Nodus Works betreuten Plattform-Migrationen stoßen wir selten, aber doch gelegentlich auf einen Fehler, der für stundenlange Verwirrung sorgen kann: Cloudflare Error 1000 – DNS points to prohibited IP. Dieser Fehler tritt auf, wenn die Verwaltung der Domain und die Ebene des Content Delivery Networks (CDN) ineinandergreifen und ein Mechanismus, der normalerweise im Hintergrund arbeitet, in einen Konflikt gerät. Im Folgenden analysieren wir die Anatomie dieses Fehlers, den wir bei einer tatsächlichen Migration von Ticimax zu Shopify erlebt haben, und zeigen zwei Lösungswege auf.
Error 1000 – DNS points to prohibited IP
Ray ID: a175cd759d42514e • 2026-07-07 09:25:33 UTC
"…it is resolving to an IP address that is creating a conflict within Cloudflare's system."
Da diese Fehlermeldung das Wort „DNS“ enthält, ist die erste Reaktion der meisten, die DNS-Einträge komplett neu zu schreiben. Die Daten von Nodus Works zeigen jedoch, dass die DNS-Einstellungen in den meisten dieser Fälle bereits korrekt sind; das eigentliche Problem liegt nicht auf der DNS-Ebene, sondern in einem Konflikt bei der CDN-Inhaberschaft. Die folgenden Schritte wurden zusammengestellt, damit Teams, die auf denselben Fehler stoßen, innerhalb weniger Minuten die richtige Ebene identifizieren können.
Warum tritt dieser Fehler so selten auf?
Error 1000 ist kein Fehler, der bei der täglichen DNS-Verwaltung zufällig auftritt; damit er erscheint, muss dieselbe Domain gleichzeitig bei zwei verschiedenen Anbietern als „Custom Hostname“ in der CDN-Ebene definiert sein. Diese Überschneidung tritt fast ausschließlich bei Plattform-Migrationen auf, wenn der Eintrag beim alten Anbieter nicht vollständig entfernt wurde, bevor der neue hinzugefügt wurde.
Wenn ein Shop von einer Plattform (z. B. Ticimax) zu einer anderen (z. B. Shopify) umzieht und der „Custom Hostname“-Eintrag im alten CDN-Konto nicht gelöscht wird, lehnt Cloudflare die Anfrage ab, sobald die neue Plattform versucht, dieselbe Domain zu ihrer eigenen CDN-Ebene hinzuzufügen. Dies ist keine „alltägliche“ Störung, sondern ein migrationsspezifischer Grenzfall (Edge Case). Genau deshalb ist es schwierig, bei einer Suche nach dem Fehlernamen eine klare Lösung zu finden.
Architektur des Falls: Wie sah das Setup aus?
Um das Problem korrekt zu diagnostizieren, muss zunächst eine genaue Karte der Umgebung erstellt werden; die folgende Tabelle fasst den Status der vier Komponenten in diesem Fall zusammen.
Das entscheidende Detail hierbei war, dass die E-Mail-Ebene vollkommen intakt war. Da E-Mail-Einträge (MX, SPF, DKIM) eine andere DNS-Untergruppe nutzen, war das Funktionieren dieser Ebene der erste Beweis dafür, dass das Problem auf den Web-/CDN-Bereich eingegrenzt werden konnte.
Diagnoseprozess: Wie grenzen wir das Problem auf die richtige Ebene ein?
Die richtige Diagnosemethode besteht darin, nicht dorthin zu schauen, wohin die Fehlermeldung zeigt, sondern dorthin, wo die Beweise hinführen. Bei Nodus Works folgen wir in solchen Fällen einem festen Drei-Schritte-Prozess: Messen, wohin das DNS tatsächlich zeigt, bestimmen, welche Ebene den Fehler erzeugt, und die Quelle des Konflikts finden.
Schritt 1: Wohin zeigt das DNS tatsächlich?
Der erste Schritt besteht darin, direkt abzufragen, wie die Domain live aufgelöst wird. Die folgende Tabelle zeigt die in diesem Fall festgestellten Einträge und deren Status.
Alle Einträge waren korrekt und befanden sich im Modus „DNS only“; das bedeutet, das DNS verwies auf den richtigen Ort. Diese Messung reichte aus, um die Hypothese eines „falschen Eintrags“ auszuschließen.
Schritt 2: Auf welcher Ebene entsteht der Fehler?
Bei der Untersuchung der HTTP-Antwort-Header zeigte sich, dass nicht das DNS den Fehler verursachte, sondern die CDN-Ebene, auf der Shopify aufsetzt. Die Anfrage erreichte Shopify, wurde jedoch auf Netzwerkebene abgewiesen, bevor sie die Anwendung erreichte. Wäre die Domain keinem Shop zugeordnet gewesen, wäre eine Seite wie „Shop nicht gefunden“ erschienen; bei dem erhaltenen Fehler handelte es sich jedoch um einen Konflikt auf Netzwerkebene. Der Fehlertext selbst bestätigte dies: "creating a conflict within Cloudflare's system."
Schritt 3: Woher stammt der Konflikt?
Beim Durchsuchen der Zone-Einträge fielen zwei „fremde“ Einträge auf: ein _cf-custom-hostname TXT-Eintrag mit einem Inhaberschafts-Verifizierungsschlüssel und ein geproxter _acme-challenge CNAME-Eintrag (Zertifikatsverifizierung). Diese beiden waren Überbleibsel davon, dass die Domain noch in der CDN-„Custom Hostname“-Konfiguration des alten Anbieters (Ticimax) registriert war.
Wichtiger Hinweis: Eine Domain kann nicht gleichzeitig in zwei verschiedenen CDN-Konten als „Custom Hostname“ definiert sein. Die Cloudflare-Infrastruktur verhindert dies bewusst; es reicht nicht aus, die neue Plattform hinzuzufügen, die Definition auf der alten Plattform muss zwingend entfernt werden.
Grundursache: Dieselbe Domain in zwei CDN-Konten
Die Ursache des Problems ist nicht das DNS, sondern ein Konflikt bei der CDN-Inhaberschaft zwischen zwei Anbietern: Während die neue Plattform (Shopify) die Domain als Custom Hostname in ihre CDN-Ebene aufnehmen wollte, war dieselbe Domain im CDN-Konto des alten Anbieters (Ticimax) noch immer als Eigentum hinterlegt. Da die Cloudflare-Infrastruktur nicht zulässt, dass derselbe Hostname in zwei verschiedenen Konten als aktiver Custom Hostname geführt wird, lautete das Ergebnis Error 1000.
Zu vermeidendes Risiko: Der am häufigsten übersehene Schritt bei Plattformumzügen ist das Löschen des CDN-/Custom-Hostname-Eintrags beim alten Anbieter. Dieser Eintrag wirkt oberflächlich harmlos, da er die Website optisch nicht beeinflusst; sobald die neue Plattform jedoch versucht, dieselbe Domain hinzuzufügen, hält er die Domain faktisch als „Geisel“.
Lösung 1: Beidseitige Bereinigung (unter Beibehaltung der aktuellen Einrichtung)
Wenn Sie Cloudflare weiterhin als DNS-/CDN-Ebene nutzen möchten, müssen Sie den Konflikt beidseitig bereinigen. Dies ist der Weg, der die bestehende Einrichtung beibehält, aber mehr manuelle Schritte erfordert.
- Ihre eigene DNS-Seite: Löschen Sie die vom alten Anbieter verbliebenen _cf-custom-hostname TXT- und _acme-challenge CNAME-Einträge. Das Entfernen dieser Einträge macht auch die Verifizierung der alten Inhaberschaft ungültig; Custom Hostnames erfordern eine ständige Validierung und fallen mit der Zeit automatisch weg, wenn diese nicht mehr bestätigt werden kann.
- Seite des alten Anbieters (Ticimax): Die eigentliche Inhaberschaft liegt in deren CDN-Konto. Fordern Sie sie auf, die Domain vollständig aus ihren Custom-Hostname-Konfigurationen zu entfernen.
- Verifizierung und erneute Verbindung: Nachdem beide Seiten bereinigt wurden, verifizieren Sie die Verbindung erneut über die Domain-Einstellungen von Shopify („Verify connection“). Die Deaktivierung und Verbreitung auf der CDN-Ebene erfolgt nicht sofort; dies kann von einigen Stunden bis zu einigen Tagen dauern.
Tipp: Formulieren Sie Ihre Anfrage an den alten Anbieter präzise und handlungsorientiert: Geben Sie den genauen Wortlaut der Fehlermeldung an und stellen Sie klar, dass das DNS bereits korrekt konfiguriert ist und der Konflikt auf der CDN-Ebene liegt. Wir bei Nodus Works haben die Erfahrung gemacht, dass allgemeine Support-Anfragen ohne Belege tagelang dauern, während Anfragen, die durch Fehlermeldungen und DNS-Messungen untermauert sind, innerhalb weniger Stunden bearbeitet werden.
Lösung 2: Die CDN-Ebene umgehen (Der sicherste Weg)
Die Ursache des Konflikts liegt darin, dass die Domain über eine CDN-Ebene für „Custom Hostnames“ geleitet wird. Wenn Sie diese Ebene nicht benötigen, ist die sicherste Lösung, sie vollständig zu entfernen.
- Übertragen Sie die DNS-Verwaltung der Domain von Cloudflare auf das DNS-Panel Ihres Domain-Registrars.
- Leiten Sie die Einträge direkt auf die von Shopify geforderten Ziele: die Root-Domain auf die Shopify-IP (A-Record) und das www-Subdomain auf shops.myshopify.com (CNAME).
- Definieren Sie die MX-, SPF- und DKIM-Einträge für E-Mails im selben Panel neu.
Auf diese Weise wird die Domain in keinem Drittanbieter-CDN mehr als „Custom Hostname“ geführt. Da Shopify seine eigene SSL- und Bereitstellungsebene bereitstellt, ist keine zusätzliche Proxy-Ebene erforderlich. Dieser Ansatz beseitigt das Konfliktrisiko grundlegend; im Gegenzug verzichten Sie jedoch auf die zusätzlichen Funktionen von Cloudflare wie Caching, Rule Engine und WAF. Den schrittweisen Ablauf der Domain-Verknüpfung und SSL-Validierung haben wir in unserem Leitfaden zur Domain-Anbindung an Shopify ausführlich behandelt.
Lösung 1 oder Lösung 2? Ein Vergleich
Die Wahl zwischen beiden Wegen hängt davon ab, ob Sie die Zusatzfunktionen von Cloudflare (Caching, WAF, Rule Engine) benötigen. Die folgende Tabelle vergleicht beide Ansätze anhand von vier Kriterien.
Gelernte Lektionen
- Unterscheiden Sie zwischen Symptom und Grundursache. Die Fehlermeldung verwies auf das „DNS“, doch das Problem lag nicht dort; suchen Sie auf der Ebene, die durch die Beweise belegt wird.
- Notieren Sie sich auch die funktionierenden Ebenen. Dass der E-Mail-Verkehr reibungslos funktionierte, war der entscheidende Hinweis, um das Problem auf die Web-/CDN-Ebene einzugrenzen.
- Bei Migrationen sind veraltete Einträge das tückischste Risiko. Validierungs- oder Zertifikatseinträge, die beim alten Anbieter verblieben sind, wirken harmlos, können die Domain aber faktisch blockieren.
- Eine Domain kann nicht gleichzeitig in zwei CDN-Konten existieren. Es reicht nicht, etwas Neues hinzuzufügen; das Alte muss zwingend entfernt werden.
- Formulieren Sie eine handlungsorientierte Anfrage an die Gegenseite. Die Kombination aus Fehlermeldung, Messnachweis und einer klaren Anforderung verkürzt die Lösungszeit.
Schnell-Checkliste für Migrationen
- Aktualisieren Sie MX-, SPF-, DKIM- und Verifizierungs-Einträge und testen Sie den E-Mail-Versand.
- Stellen Sie sicher, dass die Web-Einträge (Root + www) auf das korrekte Ziel und den richtigen Proxy-Modus eingestellt sind.
- Lassen Sie die Domain aus der CDN-/Custom-Hostname-Konfiguration des alten Anbieters entfernen.
- Bereinigen Sie die verbleibenden _cf-custom-hostname- und _acme-challenge-Einträge des alten Anbieters.
- Verifizieren Sie die Domain-Verbindung auf der neuen Plattform erneut; planen Sie für die Verbreitung einige Stunden bis wenige Tage ein.
- Wenn Sie keine CDN-Ebene benötigen, ziehen Sie in Betracht, das DNS direkt über das Registrar-Panel zu verwalten.
Für weitere häufige Fehler, die während des restlichen Migrationsprozesses im Bereich DNS und SSL auftreten können, können Sie einen Blick auf unseren Shopify-Migrationsleitfaden werfen. Die eigenständige Diagnose solcher CDN-Konflikte kann Stunden in Anspruch nehmen; wenn bei einem Live-Shop in einer Krisensituation schnelles Eingreifen erforderlich ist, diagnostiziert und löst unser technischer Shopify-Support- und Wartungsservice solche DNS/CDN-Konflikte dank unserer Praxiserfahrung innerhalb weniger Stunden.
Häufig gestellte Fragen
Was bedeutet der Cloudflare-Fehler 1000?
Dies bedeutet, dass dieselbe Domain gleichzeitig bei zwei verschiedenen Anbietern als "Custom Hostname" in der CDN-Ebene definiert ist. Sobald Cloudflare diesen Konflikt erkennt, lehnt es die Anfrage auf Netzwerkebene ab und gibt den Fehler "DNS points to prohibited IP" aus.
Wird dieser Fehler tatsächlich durch den DNS-Eintrag verursacht?
In der Regel nein. In den meisten Fällen sind die DNS-Einträge (A, CNAME, AAAA) korrekt; das Problem liegt im Eigentumskonflikt auf der CDN-Ebene. Ein komplettes Neuschreiben des DNS löst den Fehler in diesem Fall nicht.
Wie lange dauert die Behebung des Fehlers 1000?
Dies kann je nach Support des alten Anbieters einige Stunden bis wenige Tage in Anspruch nehmen. Die Deaktivierung und Propagierung auf der CDN-Ebene erfolgt nicht in Echtzeit, daher sollte die Überprüfung in regelmäßigen Abständen erneut durchgeführt werden.
Ist es sicher, die DNS-Verwaltung über das Registrar-Panel statt über Cloudflare abzuwickeln?
Ja, da Shopify sein eigenes SSL-Zertifikat und seine eigene Bereitstellungsschicht bereitstellt, ist keine zusätzliche CDN-Proxy-Ebene erforderlich. Diese Methode bedeutet zwar, dass Sie auf zusätzliche Funktionen von Cloudflare wie WAF und Caching verzichten, eliminiert jedoch das Risiko von Konflikten vollständig.
Was soll ich tun, wenn der alte Anbieter sich weigert, den CDN-Eintrag zu entfernen?
In diesem Fall müssen Sie Lösung 2 anwenden (DNS-Verwaltung auf das Registrar-Panel übertragen). Sie können die Domain direkt auf Shopify umleiten, ohne von der Zustimmung des alten Anbieters abhängig zu sein.
Warum sind _acme-challenge- und _cf-custom-hostname-Einträge problematisch?
Diese Einträge haben zwar keinen sichtbaren Einfluss auf die Website, sind jedoch der Beweis dafür, dass die Domain noch immer im alten CDN-Konto registriert ist. Solange sie nicht gelöscht werden, verhindern sie, dass die neue Plattform dieselbe Domain in ihre eigene CDN-Ebene aufnimmt.
Fazit
Der Fehler 1000 wirkt auf den ersten Blick beängstigend, hat aber eine klare Ursache: dieselbe Domain ist gleichzeitig in zwei verschiedenen CDN-Konten hinterlegt. Dies ist ein seltenes, aber vollständig lösbares Szenario, das typisch für Plattformmigrationen ist. Mit einer systematischen Diagnose und einem Eingriff auf der richtigen Ebene lässt sich selbst der hartnäckigste Fehler in wenige klare Schritte unterteilen. Ob Sie die bestehende Konfiguration durch eine beidseitige Bereinigung beibehalten oder die CDN-Ebene umgehen und das DNS direkt verwalten: Entscheidend ist, das Problem an der Wurzel und nicht nur an den Symptomen zu packen.
Wenn Sie bei Ihrem eigenen Migrationsprozess auf einen ähnlichen DNS/CDN-Fehler gestoßen sind oder eine Migration von Anfang bis Ende sicher planen möchten, können Sie sich über unseren Shopify-Migrations- und Umzugsservice informieren, indem Sie unser Team kontaktieren.
