How to Fix Cloudflare Error 532 (Origin DNS Points to Cloudflare)
What Error 532 means
When you visit a Cloudflare-protected website, Cloudflare looks up the domain's DNS records, connects to the listed origin server, fetches the page, and serves it to you. Error 532 fires when that lookup goes wrong in a very specific way: the DNS record resolves to an IP address inside Cloudflare's own network. Cloudflare dutifully connects to it — and finds itself. There is no origin server at the other end, just Cloudflare's own infrastructure, so the request loops into a dead end and Cloudflare shows the 532 page.
This is different from the other 5xx Cloudflare codes. A 521 means the origin refused the connection; a 522 means it never answered; a 520 means it answered with garbage. A 532 never gets as far as a real origin at all — the address Cloudflare was given belongs to Cloudflare itself. The mistake is always in the site's DNS records, which makes this one of the easiest Cloudflare errors to diagnose: the fix is a single corrected DNS record, not server surgery. The catch is that only the site owner can make it.
Common causes
- An A or AAAA record containing a Cloudflare IP: the direct cause — someone typed or pasted a Cloudflare address into the origin record, so Cloudflare fetches the site from itself.
- Host migration gone wrong: after moving hosts, the new A record is filled with an IP copied from the Cloudflare dashboard (a Cloudflare IP) instead of the new host's real server IP from its control panel.
- CNAME pointed at a Cloudflare-hosted hostname: a record that points to a hostname which itself resolves into Cloudflare's network, creating the same self-referencing loop one level of indirection deep.
- Duplicated or stale records after a DNS import: zone-file imports and bulk record edits can re-add old records whose IPs are Cloudflare addresses, sitting alongside the correct ones and catching traffic.
- Origin configured through a proxy as the origin: entering an address that is itself behind Cloudflare (for example, a load-balancer or tunnel endpoint's Cloudflare-facing IP) as the DNS origin, so the "server" Cloudflare calls is Cloudflare again.
How to fix Error 532 — step by step
Step 1 is for visitors — and it is mostly about not wasting your time. Steps 2 through 6 are for site owners.
- Visitor: confirm the 532 is a site-side DNS problem, not your connection. Error 532 is generated by Cloudflare's edge before your request ever reaches the site's server, so there is almost nothing a visitor can fix. Try the site on another network or device and check a down-detector service: if the 532 appears everywhere, the site's own DNS is misconfigured and only the site owner can fix it. Do not waste time reinstalling your browser or resetting your router — contact the site's support and point them at their Cloudflare DNS records.
- Site owner: find the DNS record that resolves to a Cloudflare IP. Sign in to the Cloudflare dashboard, open the domain, and go to DNS > Records. Look at the A and AAAA records for the apex domain and www. One of them is resolving to an address inside Cloudflare's own published IP ranges — that is the 532 trigger, because Cloudflare follows the record and fetches the page from its own network instead of your server. A quick terminal check confirms it: run dig +short yourdomain.com and compare the returned IP against Cloudflare's published ranges.
- Site owner: get the real origin server IP from your hosting provider. Open your hosting control panel (cPanel, Plesk, your VPS dashboard, or the host's account area) and note the server's actual IPv4 and IPv6 addresses — usually shown as the server IP, shared IP, or in the account details page. If you recently migrated hosts, use the new host's IP, not the old one; if you are unsure, ask the host's support which IP should be the DNS origin. Never copy an IP from Cloudflare's dashboard into the origin field — that recreates the loop.
- Site owner: correct the A or AAAA record to the real server IP. Back in Cloudflare DNS > Records, edit the offending record and replace the Cloudflare IP with the real origin IP from your host. Keep the proxy status as proxied (orange cloud) — proxying is fine and recommended; the problem was never proxying, it was the destination IP. Save the record. If both apex and www had bad records, fix both, and check any other A records (staging subdomains, mail hosts excluded) that may carry the same wrong IP.
- Site owner: purge the Cloudflare cache and wait for DNS propagation. In the Cloudflare dashboard go to Caching > Configuration and click Purge Everything so no cached 532 page keeps serving. DNS changes in Cloudflare's authoritative nameservers take effect quickly, but visitors' ISPs may cache the old record for up to its TTL — typically minutes to a few hours. If you changed the record recently and still see the 532, wait out the old TTL before assuming the fix failed.
- Site owner: verify the origin resolves correctly with a DNS lookup. Run dig +short yourdomain.com (or nslookup on Windows) and confirm the returned IP is your host's real server IP and no longer a Cloudflare address. Then reload the site through Cloudflare — the 532 should be gone and the real page should load. If the lookup shows the correct IP but the 532 persists, flush your local DNS (ipconfig /flushdns on Windows, or restart the browser) and test from a private window before digging further.
Did this fix it? Quick checklist
- A dig or nslookup on the domain now returns your host's real server IP, not a Cloudflare address
- Both the apex and www A/AAAA records point at the real origin (whichever you use)
- Cloudflare's cache has been purged after the DNS correction
- The site loads through Cloudflare from a private window with local DNS flushed
If the 532 cleared for you but some visitors still see it, that is stale DNS on their side — their ISP cached the old record for the length of its TTL, and it will expire on its own; there is nothing more to fix on the origin. If the 532 appeared immediately after a host migration, audit every record the migration touched, including staging and addon-domain subdomains, because the same wrong IP often gets pasted into more than one record. And if you manage DNS for clients, add a post-migration dig check to your handover routine: catching a Cloudflare-IP origin before the client notices is a thirty-second habit that prevents this error entirely.
Frequently asked questions
What does Cloudflare Error 532 mean?
Error 532 means Cloudflare tried to fetch the website from its origin server, but the domain's DNS record pointed at a Cloudflare IP address instead of the real server. In plain English: the site's DNS sends Cloudflare to itself, so Cloudflare requests the page from its own network and the request goes nowhere. It is always a DNS misconfiguration on the site's side, and the fix is correcting the A or AAAA record to the host's real IP.
Is Error 532 caused by my browser, VPN, or internet connection?
No. Error 532 is raised by Cloudflare's edge network before your request ever touches the site's server, and it is triggered entirely by the site's DNS records pointing at a Cloudflare IP. Your browser, VPN, and connection are irrelevant — you cannot fix it by clearing your cache or switching networks. If you see it everywhere, the site owner's origin DNS record is wrong and only they can correct it.
Why did Error 532 appear right after I changed hosts or DNS?
Host migrations are the classic trigger. During a move it is easy to copy the wrong IP into the A record — for example, grabbing the IP shown in Cloudflare's dashboard (a Cloudflare address) instead of the new host's server IP, or re-adding a record that still points at the old setup's Cloudflare-routed address. Any DNS edit where the origin value ends up being a Cloudflare IP produces a 532. Always take the origin IP from the new host's control panel, then double-check it with a dig lookup before calling the migration done.
I set the A record to my host's IP but still see the 532 — why?
The most likely cause is DNS caching: the old record's TTL has not expired for your ISP or your device, so you are still being sent down the old path. Purge Cloudflare's cache (Caching > Configuration > Purge Everything), wait out the old TTL, and flush your local DNS. Also check that you fixed the right record — apex and www are separate records, and subdomains can each carry the bad IP. A dig +short lookup of the exact hostname you are visiting shows what the internet currently resolves it to.
How do I check whether my origin IP is a Cloudflare IP?
Cloudflare publishes its IPv4 and IPv6 ranges (linked from the dashboard docs), so you can compare directly: run dig +short yourdomain.com and see if the returned address falls inside those ranges. If it does, that record is the problem — replace it with the IP shown in your hosting control panel. After the change, repeat the lookup: the answer should be your host's real IP, and the 532 should clear once caches expire.