In the platform migration projects we manage as Nodus Works, we occasionally encounter an error that, while rare, can cause hours of confusion when it does appear: Cloudflare Error 1000 – DNS points to prohibited IP. This error occurs when the domain management and content delivery network (CDN) layers, which normally operate silently in the background, conflict with one another. Below, we share the anatomy, diagnostic process, and two potential solutions for this error, based on a real-world case of a migration from Ticimax to Shopify.
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."
Because this error message mentions "DNS," most people's first instinct is to rewrite their DNS records from scratch. According to Nodus Works data, in the vast majority of these cases, the DNS is already correct; the real issue is not in the DNS layer, but in a CDN ownership conflict. The steps below were prepared to help teams encountering the same error navigate to the correct layer in minutes.
Why Is This Error Rarely Seen?
Error 1000 is not a random error encountered during daily DNS management; for it to occur, the same domain must be defined as a "custom hostname" in the CDN layer of two different providers simultaneously. This overlap almost exclusively happens during platform migrations when a new definition is added before the old one has been fully removed.
When a store moves from one platform (e.g., Ticimax) to another (e.g., Shopify), if the "custom hostname" record in the old CDN account is not deleted, Cloudflare will reject the request when the new platform attempts to add the same domain to its own CDN layer. This is not an "everyday" failure, but an edge case specific to migrations. That is precisely why it is difficult to find a clear solution when searching for the error by name.
The Architecture of the Case: What Was the Setup?
To correctly diagnose the issue, one must first map out the environment; the table below summarizes the status of the four components in this case.
The most telling detail here was that the email layer was completely healthy. Since email records (MX, SPF, DKIM) use a different DNS subset, the fact that this layer was functioning was the first piece of evidence that narrowed the problem down to the web/CDN side.
Diagnostic Process: How Do We Narrow the Problem to the Right Layer?
The correct diagnostic method is not to go where the error message points, but where the evidence leads. At Nodus Works, we follow a fixed three-step sequence in such cases: measuring where the DNS is actually pointing, determining which layer is generating the error, and finding the source of the conflict.
Step 1: Where Is the DNS Actually Pointing?
The first step is to directly query how the domain is resolving in the live environment. The table below shows the records identified in the case and their statuses.
All records were correct and all were in "DNS only" mode, meaning the DNS was pointing to the right place. This measurement was enough to rule out the "incorrect record" hypothesis.
Step 2: Which Layer Is Generating the Error?
Upon examining the HTTP response headers, it was clear that the party generating the error was not the DNS, but the CDN layer where Shopify resides. The request was reaching Shopify but was being rejected at the network level before it could reach the application. If the domain name were not connected to any store, a "store not found" type of page would have been returned; however, the error received was a network-level conflict. The text of the error itself confirmed this: "creating a conflict within Cloudflare's system."
Step 3: Where Is the Conflict Coming From?
When the zone records were scanned one by one, two "foreign" records stood out: a _cf-custom-hostname TXT record containing an ownership verification key and a proxied _acme-challenge CNAME record (a certificate verification record). These two were traces indicating that the domain name was still registered in the previous provider's (Ticimax) CDN "custom hostname" configuration.
Critical Note: A domain name cannot be defined as a "custom hostname" in two separate CDN accounts at the same time. The Cloudflare infrastructure intentionally prevents this; adding the new platform is not enough, the definition on the old platform must also be removed.
Root Cause: The Same Domain Name in Two CDN Accounts
The source of the problem is not the DNS, but a CDN ownership conflict between two providers: while the new platform (Shopify) wanted to add the domain name to its own CDN layer as a custom hostname, the same domain name was still claimed in the old provider's (Ticimax) CDN account. Since the Cloudflare infrastructure does not allow the same hostname to be an active custom hostname in two separate accounts, the result was Error 1000.
Risk to Avoid: The most frequently overlooked step in platform migrations is deleting the CDN/custom hostname record at the old provider. This record appears harmless because it does not visually affect the site; however, the moment the new platform attempts to add the same domain name, it effectively holds the domain "hostage."
Solution 1: Two-Sided Cleanup (Maintaining the Current Setup)
If you want to continue using Cloudflare as your DNS/CDN layer, you need to clear the conflict from both sides. This is the path that preserves the current setup but requires more manual steps.
- Your own DNS side: Delete the _cf-custom-hostname TXT and _acme-challenge CNAME records left over from the old provider. Removing these records also invalidates the verification of the old ownership; custom hostnames require continuous verification, and when they cannot be verified, they eventually drop off automatically.
- Old provider (Ticimax) side: The actual ownership remains in their CDN account. Request that they completely remove the domain name from their custom hostname configurations.
- Verification and reconnection: Once both sides are cleared, re-verify the connection from Shopify's domain settings ("Verify connection"). The deactivation and propagation at the CDN layer are not instantaneous; they can take anywhere from a few hours to a few days.
Tip: Write your request to the previous provider in an actionable way: clearly state the exact error text, confirm that the DNS is now pointing to the correct location, and specify that the conflict is at the CDN layer. At Nodus Works, we have observed that while generic support tickets sent without evidence take days, tickets supported by error text and DNS diagnostics are processed within hours.
Solution 2: Bypassing the CDN Layer (The Most Definitive Method)
The source of the conflict is the domain passing through a CDN "custom hostname" layer. If you do not need this layer, the most definitive solution is to remove it entirely.
- Move the domain's DNS management from Cloudflare to your domain registrar's own DNS panel.
- Point the records directly to the targets required by Shopify: the root domain to the Shopify IP (A record) and the www subdomain to shops.myshopify.com (CNAME).
- Redefine the MX, SPF, and DKIM records for email in the same panel.
This ensures the domain is not held as a "custom hostname" in any third-party CDN account; since Shopify provides its own SSL and distribution layer, there is no need for an additional proxy layer in between. This approach fundamentally eliminates the risk of conflict, though in return, you forgo the additional caching, rule engine, and WAF features offered by Cloudflare. The step-by-step process of domain connection and SSL validation is covered in our Shopify domain connection guide in detail.
Solution 1 or Solution 2? A Comparison
The choice between the two paths depends on whether you need Cloudflare's additional features (caching, WAF, rule engine). The table below compares the two approaches across four criteria.
Lessons Learned Along the Way
- Separate the symptom from the root cause. The error message said "DNS," but the problem was not with the DNS; go to the layer indicated by the evidence.
- Note the layers that are still working. The fact that email was working fine was the clue that narrowed the problem down to the web/CDN layer alone.
- During migrations, legacy records are now the most insidious risk. Verification/certificate records left over from a previous provider may look harmless, but they can hold your domain hostage.
- A domain cannot live in two CDN accounts at the same time. It is not enough to add the new; the old must be abandoned.
- Write an actionable request for the other party. The combination of an error message, proof of measurement, and a clear request shortens resolution time.
Quick Checklist for Those Migrating
- Update MX, SPF, DKIM, and verification records, then test your email.
- Verify that web records (root + www) are set to the correct destination and the correct proxy mode.
- Have the domain removed from the previous provider's CDN/custom hostname configuration.
- Clear any remaining _cf-custom-hostname and _acme-challenge records from the previous provider.
- Re-verify the domain connection on the new platform; wait anywhere from a few hours to a few days for propagation.
- If you do not need a CDN layer, consider managing DNS directly from your registrar panel.
For other common DNS and SSL errors you may encounter during the rest of the migration process, you can also check out our Shopify migration guide. Diagnosing these types of CDN layer conflicts on your own can take hours; if you need a rapid response during a crisis in a live store, our Shopify technical support and maintenance service diagnoses and resolves these types of DNS/CDN conflicts within hours using field experience.
Frequently Asked Questions
What does Cloudflare Error 1000 mean?
It means the same domain is defined as a "custom hostname" in the CDN layer of two different providers simultaneously. When Cloudflare detects this conflict, it rejects the request at the network level and returns a "DNS points to prohibited IP" error.
Is this error really caused by the DNS record?
Usually, no. In most cases, the DNS records (A, CNAME, AAAA) are correct; the issue is an ownership conflict at the CDN layer. Rewriting the DNS from scratch will not resolve the error in this situation.
How long does it take to resolve Error 1000?
It can take anywhere from a few hours to a few days, depending on the previous provider's support team. Deactivation and propagation at the CDN layer are not instantaneous, so you should retry the verification periodically.
Is it safe to manage DNS through the registrar panel instead of Cloudflare?
Yes, because Shopify provides its own SSL certificate and distribution layer, an additional CDN proxy layer is not required. This method means you will forgo extra Cloudflare features like WAF and caching, but it completely eliminates the risk of conflicts.
What should I do if the previous provider refuses to remove the CDN record?
In this case, you should implement Solution 2 (moving DNS management to the registrar panel). You can point the domain directly to Shopify without being dependent on the previous provider's approval.
Why are _acme-challenge and _cf-custom-hostname records dangerous?
These records do not appear to affect the site, but they are proof that the domain is still claimed in the old CDN account. As long as they are not deleted, they prevent the new platform from adding the same domain to its own CDN layer.
Conclusion
Error 1000 is a error that may look intimidating at first glance but is based on a clear root cause: the same domain being defined in two CDN accounts simultaneously. This is a rare but entirely solvable scenario specific to platform migrations. With systematic diagnosis and intervention at the right layer, even the most daunting error can be reduced to a few clear steps. Whether you maintain your current setup through cleanup on both sides or remove the CDN layer entirely to manage DNS directly, the key is to solve the problem at its source rather than just treating the symptoms.
If you have encountered a similar DNS/CDN error during your own migration process, or if you want to plan your migration securely from start to finish, our Shopify migration and transition services to get more information, you can contact our team.
