Fix Cloudflare Error 1000: DNS Points to Prohibited IP

If your visitors are hitting a plain orange Cloudflare error page instead of your site — "Error 1000: DNS points to prohibited IP" — the good news is it's almost never a Cloudflare outage. It's a DNS record pointing somewhere it shouldn't, and it's usually fixable in five minutes once you know where to look.

Symptom

Instead of your homepage, visitors (and you, if you check) see a Cloudflare-branded page with:

• A big orange header and a Ray ID
• The text "Error 1000: DNS points to prohibited IP"
• No 500, no timeout, no partial page load — just this one screen, every time

It usually shows up right after a DNS change, a server migration, or someone editing a zone file by hand. Sometimes it appears on a subdomain nobody touched in months, because a wildcard or CNAME record quietly resolves to something it shouldn't.

Cause

Cloudflare proxies traffic through its edge network when the orange cloud is turned on for a DNS record. To protect its own infrastructure (and yours) from being tricked into fetching internal or non-routable addresses — a classic SSRF-style abuse pattern — Cloudflare refuses to proxy any record whose "Content" (the IP it points to) falls into a reserved or private range, such as:

In practice this happens because someone:

1. Migrated a site to a new server and pasted the internal IP from a migration script or a screenshot of an internal dashboard, instead of the public IP
2. Copied an example IP from documentation ("point your A record to your server's IP") without swapping in the real one
3. Has a CNAME record chaining to another hostname that itself resolves to a private IP — common in multi-tier setups where an internal load balancer name leaks into a public zone
4. Left a placeholder record (0.0.0.0 or 127.0.0.1) from a template zone file that was never updated

Fix

1. Find the offending record. Log into your Cloudflare dashboard → DNS → Records for the affected domain. Scan the "Content" column for anything starting with 10., 172.16–172.31., 192.168., 127., or 169.254. — that's your culprit. If you're not sure which record is even being hit, check the Ray ID's hostname in the error page URL, or run:

dig yourdomain.com A +short
dig www.yourdomain.com CNAME +short

2. Get your real public server IP. Don't guess it. Pull it from:

• WHM → Server Information (top of the sidebar, "Main IP Address")
• cPanel → General Information panel on the dashboard
• Your SkyServer welcome email or hosting order confirmation
• SSH into the server and run curl -4 ifconfig.me

3. Correct the record. Edit the A record in Cloudflare's DNS tab, replace the bad IP with the real public one, and save. Leave the proxy status (orange cloud) on if you want Cloudflare's CDN/WAF/SSL in front of the site.

Don't just switch the record to grey-cloud (DNS only) as a "fix." A private IP is still unreachable from the public internet whether Cloudflare proxies it or not — you'll trade Error 1000 for a plain connection timeout. The IP itself has to be correct.

4. If it's a CNAME, trace the chain. Point the CNAME at a hostname that itself resolves publicly, or replace it with a direct A record to the correct IP if the intermediate hostname is internal-only and shouldn't be public in the first place.

5. Wait for the edge to pick it up. Cloudflare DNS changes are usually live within a minute or two — this isn't nameserver-level propagation, since Cloudflare is already authoritative for the zone. If the error page persists past 5–10 minutes, do a hard refresh or check from an incognito window; browsers cache error pages more aggressively than you'd expect.

Prevention

• When migrating a site, keep a small note of "old IP → new IP" and double-check the A record against WHM's Server Information panel before you close the ticket, not after a customer reports the error page
• Never copy example IPs straight out of documentation or scripts into a production zone — always substitute the real value
• Periodically audit your zone with dig +short against every A/CNAME record, especially on domains with a lot of subdomains or old records nobody remembers creating
• If you manage DNS for multiple clients, consider a checklist step specifically for "verify public IP" during any server move — it's a five-second check that prevents an embarrassing outage

Frequently Asked Questions

Does Error 1000 mean my site was hacked?

No. It's purely a DNS configuration problem — Cloudflare is refusing to proxy a record because the destination IP is private or reserved. It has nothing to do with malware or intrusion.

Why did this happen on a domain I haven't touched in ages?

Usually a CNAME chain. If your record points to another hostname (rather than a fixed IP) and that hostname's owner changes its target to something private, your domain breaks even though you changed nothing yourself.

Will disabling the Cloudflare proxy (grey cloud) fix it?

It'll make the error page disappear, but only because Cloudflare stops checking the IP — the underlying private address is still unreachable from the internet, so you'll just get a connection timeout instead. Fix the IP, don't just hide the check.

Can this happen with AAAA (IPv6) records too?

Yes. The same logic applies to IPv6 reserved ranges (like fe80::/10 link-local addresses or ::1 localhost). Check your AAAA records the same way if you use IPv6.

How do I know which IP is "correct" for my server?

WHM's Server Information panel and your hosting welcome email are the most reliable sources. If you're on SkyServer VPS or shared hosting, that IP is also listed in your client area under the service details for that plan.