How to Fix Cloudflare Error 530 (Origin DNS Error)

By ErrorFix · Updated October 18, 2026 · 7 min read

What Error 530 means

When a request arrives at Cloudflare's edge, the first thing Cloudflare does is resolve the origin server's DNS record: it reads the A, AAAA, or CNAME record for the hostname and connects to that address to fetch the page. Error 530 fires when that resolution fails — the record for the requested hostname doesn't exist, points at an address Cloudflare can't use, or chains through a CNAME to an external domain that itself doesn't resolve. Cloudflare has nowhere to send the request, so it stops at the edge and serves the 530 error page instead.

It's important to know what 530 is not. It isn't the site being down: a 521 means the origin refused the connection and a 522 means it timed out, both of which require the origin to have a resolvable address in the first place. A 530 never gets that far — resolution failed before any connection was attempted. And the 530 itself is just the HTTP status code your browser sees; the real diagnosis is the 1xxx code printed on the Cloudflare error page, which in the vast majority of cases is Error 1016, Origin DNS Error. Fix the 1016 and the 530 disappears with it.

Common causes

• No DNS record for the exact hostname: the classic trigger — the apex domain has an A record but nobody ever created one for www (or vice versa), or a subdomain's record was never added, so Cloudflare resolves nothing.
• A CNAME pointing to an external domain that doesn't resolve: the record exists but its target is broken — the external hostname was deleted, typo'd, or its own DNS lapsed, breaking the whole chain.
• Load Balancer origins with unresolvable hostnames: origin pool entries listed by hostname that can't be resolved via DNS, with no IP-based fallback pool to catch the failure.
• Recently deleted or edited records: a record removed during cleanup or a typo introduced during a bulk edit; the site worked minutes ago and now 530s everywhere.
• Negative DNS caching after the record was fixed: resolvers that cached the "does not exist" answer keep serving the old failure for the length of its TTL, making a correct record look broken.

How to fix Error 530 — step by step

Step 1 is for visitors — and it's mostly about not wasting your time. Steps 2 through 6 are for site owners, who are the only ones who can fix this.

1. Visitor: confirm the 530 is a site-side DNS failure, not your connection. Error 530 is generated by Cloudflare's edge when it cannot resolve the origin server's DNS record — your request never reaches the website's server, so nothing on your device can fix it. Try the site on a different network and check a down-detector: if the 530 shows everywhere, the site's own DNS is broken. Do not reinstall your browser or reset your router; the fix belongs to the site owner, whose contact page is the right next step.
2. Site owner: read the 1xxx code printed on the error page. The number 530 is only the HTTP status code — the real diagnosis is the 1xxx code printed on the Cloudflare error page itself, usually Error 1016 (Origin DNS Error). That tells you Cloudflare cannot resolve the A or CNAME record for the hostname being requested. Always fix the named 1xxx error, not the 530 status: 530 is the symptom, the 1xxx code is the disease.
3. Site owner: check the Cloudflare DNS tab for the exact hostname. Sign in to the Cloudflare dashboard, open the domain, and go to DNS > Records. Look for a record matching the exact hostname in the failing URL — apex and www are separate records, and subdomains are separate too. The most common cause of a 530/1016 is that no A, AAAA, or CNAME record exists for that exact hostname, or the record is there but points to an address that cannot be used. If you recently deleted or edited records, check the audit log to see what changed.
4. Site owner: verify that CNAME targets resolve end-to-end. If the hostname uses a CNAME, the target it points to must itself resolve — Cloudflare returns 530/1016 when a CNAME points at an external domain that cannot be resolved. Run dig +short on the full CNAME chain from your terminal, or use any public DNS lookup tool, and follow each link until you reach an IP address. If the chain breaks at any link, that broken link is the record you need to repair or replace.
5. Site owner: add or correct the record so the origin resolves. Add a missing A record pointing at the origin server's real public IP, or correct a broken CNAME so its target resolves. If you use Cloudflare Load Balancer, check the origin pools: origins listed by hostname must resolve via DNS, and you can add a fallback pool configured with a plain origin IP as a backup so traffic keeps flowing when hostname resolution fails. Keep the record proxied (orange cloud) unless you have a specific reason to go DNS-only.
6. Site owner: purge cache, wait for propagation, and verify. In the Cloudflare dashboard go to Caching > Configuration and click Purge Everything so no cached 530 page keeps serving. DNS changes on Cloudflare's authoritative nameservers take effect fast, but resolvers that cached the missing record may hold the negative answer for its TTL — usually minutes. Then verify: run dig +short on the hostname and confirm it returns the origin IP, reload the page in a private window, and confirm the 530 is gone.

Did this fix it? Quick checklist

• The exact failing hostname has a valid A record or a CNAME that resolves end-to-end to a real IP
• Apex and www records are checked separately — the fix went on the record that was actually failing
• Load Balancer pools (if any) have a fallback pool with a plain origin IP
• Cloudflare's cache is purged and the page reloads clean in a private window after the old TTL expired

If the 530 cleared for you but some visitors still see it, that's stale negative DNS on their side — resolvers cached the missing record for its TTL, and it expires on its own. If the 530 appeared right after you touched DNS records, audit the exact hostnames those edits touched, including addon domains and staging subdomains, because a cleanup that deleted one needed record produces exactly this error. And if you manage DNS for clients, make a dig check of every hostname part of your go-live routine: a thirty-second lookup catches a missing record before visitors ever see the 530.