To fix Shopify Cloudflare Error 1000, deal with the domain's leftover "custom hostname" record in the old provider's CDN account: either clean it up on both sides with that provider, or move DNS to your registrar panel and bypass the CDN layer. In Shopify migrations, this record is the most common cause; the DNS records are usually correct.
In the platform migration projects we manage at Nodus Works, we occasionally run into an error that is rare but 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, based on a real Ticimax to Shopify migration, we walk through how this error works, how to diagnose it and two possible solutions.
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 are meant to help teams facing the same error get to the right layer in minutes.
Why Is This Error Rarely Seen?
Error 1000 is not a random error you run into during everyday DNS management; in Shopify migrations, its most common cause is the same domain being defined as a "custom hostname" in the CDN layer of two different providers at the same time. This overlap almost only happens during platform migrations, when a new definition is added before the old one has been fully removed. Other causes Cloudflare lists are an A record pointing to a Cloudflare IP, a reverse proxy that sends the request back to Cloudflare, X-Forwarded-For or CF-Connecting-IP header issues, an SNI mismatch and a missing custom hostname definition at the SaaS provider.
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 diagnose the issue correctly, you first need to 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) are a separate set of DNS records, 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 error was coming not from DNS but from the CDN layer that Shopify sits behind. 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 we went through the zone records 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). They were signs 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 prevents this on purpose. Adding the new platform isn't 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"). Deactivation and propagation at the CDN layer aren't instant; 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. Our Shopify domain connection guide covers domain connection and SSL validation step by step.
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, leftover records are 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. Adding the new one isn't enough; the old one has to be released.
- Write an actionable request for the other party. An error message, measurement evidence and a clear request together shorten the time to resolution.
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 draws on hands-on experience to diagnose and resolve DNS/CDN conflicts like these within hours.
Frequently Asked Questions
What does Cloudflare Error 1000 mean?
It means the domain resolves to an IP address that Cloudflare doesn't allow and that creates a conflict. In Shopify migrations, the most common cause is the same domain being defined as a "custom hostname" in the CDN layer of two different providers at the same time; there are also other causes involving A records, reverse proxies, headers and SNI. 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, you don't need an extra CDN proxy layer. With this method you give up extra Cloudflare features like WAF and caching, but the risk of conflicts disappears completely.
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 an error that may look intimidating at first glance but has 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, contact our team to learn more about our Shopify migration and transition services.
