How is Error 1000 different from Error 1016 or 523?

They fail at different stages. Error 1016 means Cloudflare's edge could not resolve your origin hostname to any IP at all — the name lookup failed. Error 523 means the edge resolved an IP but couldn't route to it — the origin is unreachable. Error 1000 means the edge resolved an IP just fine, recognized it as one of Cloudflare's own, and refused to connect. 1000 is the only one of the three where the target IP is the problem, not its reachability.

Why is pointing an A record at a Cloudflare IP a problem?

Because it creates a loop. A visitor hits Cloudflare's edge, the edge looks up your origin, finds another Cloudflare IP, and would have to hand the request back to itself. Cloudflare refuses rather than spin in a circle. The usual mistake is running dig against your already-proxied hostname, seeing a 104.x or 172.6x.x address, and pasting that back into the DNS record as the 'origin' — but that address is Cloudflare, not your server.

I use Cloudflare Tunnel or a SaaS provider and still get 1000. Why?

Two known cases. With Cloudflare Tunnel, the hostname should route through the tunnel, not through a manually added A/AAAA record pointing at a Cloudflare IP — remove the stray proxied record. With a SaaS provider that runs Cloudflare for SaaS on their own IP space (BYOIP), your CNAME resolves into Cloudflare's network, so the fix is on their side: ask them to confirm your custom hostname is provisioned. You can't fix a BYOIP loop from your own DNS panel.

Views: 107

Error 1000 DNS Points to Prohibited IP (Cloudflare)

Error 1000: your Cloudflare DNS record points at a Cloudflare IP, not your origin. Find the looping A record in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Cloudflare returns Error 1000: DNS points to prohibited IP. The edge looked up where to send the request, found one of Cloudflare’s own IP addresses, and refused to connect rather than loop back into itself.

Symptoms

Every request to the site shows the Cloudflare 1000 error page, not just some routes.
It started right after you edited a DNS record, switched origins, or added a proxy in front.
A DNS lookup of your origin hostname returns a Cloudflare address (commonly a 104.x or 172.64–172.71.x range) instead of your real server IP.
The site was fine, you “fixed” the origin IP by copying what dig showed, and it broke immediately.

What Error 1000 Actually Means

Cloudflare’s edge is a reverse proxy: a visitor connects to Cloudflare, and Cloudflare connects onward to your origin. For that second hop to work, the origin address in your DNS record has to be your server — a real host that isn’t Cloudflare. Error 1000 fires when that address is a Cloudflare IP. The edge would have to forward the request to itself, so it stops and returns 1000 instead of chasing its own tail.

The trap that catches almost everyone is the same one. You want to know your origin IP, so you run dig yourdomain.com — but that hostname is already proxied through Cloudflare, so dig returns Cloudflare’s anycast IP, not your server’s. You paste that 104.x address back into the A record as the “origin,” and now the record literally points Cloudflare at Cloudflare. The lookup that was supposed to reveal your origin only ever showed you the mask in front of it.

This is worth separating cleanly from its neighbors, because the error pages look similar and the fixes are completely different. Error 1016 is a resolution failure — the edge can’t turn your origin hostname into any IP. Error 523 is a routing failure — the IP resolves but nothing answers. Error 1000 is neither: the IP resolves perfectly and Cloudflare recognizes it as its own. The address is valid; it’s just forbidden as an origin.

Top 3 Causes

An A record pointing at a Cloudflare IP - The direct version of the trap above. Your Cloudflare DNS A record holds a 104.x or 172.6x.x address instead of your actual origin server IP. Fix it by setting the record to the real origin address your host gave you — the one you’d SSH into — not anything Cloudflare returned.
A double-proxy loop through another reverse proxy - Your record points at a second reverse proxy (an nginx box using proxy_pass, another CDN) that then forwards the request back into Cloudflare. The request bounces Cloudflare → proxy → Cloudflare. Replace the proxy hop with a direct origin address, or move the redirect logic to an HTTP redirect at the origin instead of a proxy pass.
A SaaS or Tunnel setup resolving into Cloudflare’s network - The record points at a SaaS provider running Cloudflare for SaaS on their own advertised IP space (BYOIP), or a stray manual record collides with a Cloudflare Tunnel. Either way the target lands inside Cloudflare. Header edge cases do this too: an incoming request carrying a CF-Connecting-IP header, two X-Forwarded-For headers, or an X-Forwarded-For over 100 characters will also trigger 1000.

Diagnose with DechoNet

DNS Lookup on your origin hostname (or the raw A record value) to see the actual IP it resolves to. If that IP sits in a Cloudflare range — 104.16.0.0/13, 172.64.0.0/13, and similar — you’ve found the loop. The record is pointing Cloudflare back at Cloudflare, and that’s the whole bug.

Resolution Checklist

Find your real origin IP — from your hosting panel or /etc/hosts on the box, not from a dig of the proxied domain. That lookup only ever shows Cloudflare.
In the Cloudflare DNS panel, set the A (or AAAA) record to that real origin IP. If you don’t have a stable origin IP, that’s a signal to use a Cloudflare Tunnel instead of a manual record.
Run a DNS Lookup on the value you just entered and confirm it is not in a Cloudflare range.
If a second reverse proxy sits in the path, remove the loop — point Cloudflare straight at the true origin, or convert the proxy hop into an origin-side HTTP redirect.
For a SaaS-hosted hostname, stop editing your own DNS and contact the provider to confirm the custom hostname is provisioned on their Cloudflare for SaaS setup.
Re-test. The 1000 page clears as soon as the record points at a non-Cloudflare address the edge can actually reach.

When to Escalate

If the record already points at a legitimate, non-Cloudflare origin and you still get 1000, look upstream for a header-injection cause (a CF-Connecting-IP or duplicate X-Forwarded-For added by a proxy in front of Cloudflare) and escalate to whoever owns that layer.
If your hostname resolves into a SaaS provider’s Cloudflare for SaaS deployment, the fix is entirely on their side — escalate to their support with the exact hostname and the 1000 error, because no change in your own DNS panel can resolve a BYOIP loop.