How do you fix Cloudflare 523 origin unreachable?

Verify that Cloudflare DNS points to the current public origin IP, remove broken AAAA records if IPv6 is not reachable, test the origin from outside the provider network, and check provider firewalls, security groups, routes, and upstream network incidents.

How is 523 different from 522?

A 523 usually means Cloudflare cannot route to the origin address. A 522 means Cloudflare can try the origin path but the connection or response times out.

Question

How to fix Cloudflare 523 origin unreachable

Updated June 7, 2026

523 usually means Cloudflare cannot route traffic to the origin address in your DNS record. The origin may be running perfectly from inside your cloud provider, but Cloudflare's edge cannot reach the public IP. That makes 523 a routing and reachability problem before it is an application problem.

The common trap is checking only from the server itself. A local curl localhost proves the service is alive; it does not prove the public route from Cloudflare to the origin IP works.

Fast diagnosis order

Verify the origin public IP currently attached to your server or load balancer.
Verify Cloudflare DNS A/AAAA records point to the expected address.
Test direct origin reachability from outside your VPC/network.
Check network ACL, security group, and upstream firewall allow rules.
Check whether IPv6 is published but not actually reachable.

What makes 523 different

A 522 timeout can happen when the origin is reachable but slow or silently dropping connections. A 523 is more fundamental: the address Cloudflare is trying to use is not reachable from Cloudflare's network. That often happens after server migration, IP recycling, provider firewall changes, broken BGP/routing, or an accidental AAAA record.

Cloudflare's 5xx troubleshooting guidance also points owners toward logs on load balancers, caches, proxies, and firewalls between Cloudflare and the origin. For 523, those middle layers are especially important because the application may never see the failed request.

Commands operators usually run first

# DNS answers (what Cloudflare records currently return)
dig +short llmsfile.com A
dig +short www.llmsfile.com A
dig +short llmsfile.com AAAA
dig +short www.llmsfile.com AAAA

# Route and direct origin checks
ip route
curl -I --connect-timeout 8 http://ORIGIN_IP
curl -I --connect-timeout 8 https://ORIGIN_IP -k

# If origin only serves by hostname/SNI
curl -I --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com/

# From the origin, confirm the public address really belongs to this host
ip addr
curl -s ifconfig.me

Evidence to collect before editing DNS

Current Cloudflare DNS values: A and AAAA records for apex and www, including any stale records.
Provider console IP: the public IP attached to the VM, load balancer, or floating IP.
Outside-network curl: a test from a different ISP or cloud region, not from the origin itself.
Firewall layers: OS firewall, cloud security group, provider ACL, load balancer listener, and any upstream DDoS rule.

Typical 523 root causes

Stale DNS after migration: records still point to the old origin IP.
Private address leak: DNS accidentally points to RFC1918/private IP.
Cloud firewall drift: ingress rules changed and now block Cloudflare-to-origin traffic.
Origin NIC or route issue: host is up but path from the internet is broken.
Broken IPv6 path: AAAA exists, but the origin does not actually accept IPv6 traffic.
Floating IP detached: the DNS record is correct historically, but the address is no longer bound to the server.

Cloudflare DNS check matrix

A record exists, direct curl fails: origin path/firewall issue, not a DNS typo.
A record resolves to old IP: update DNS and re-verify with fresh dig.
Only AAAA exists but IPv6 origin is unavailable: remove/repair AAAA path.
Origin IP works by HTTP but not HTTPS: this is probably TLS/listener configuration; check whether the browser error is actually 525 or 526.
Origin works from one country but not another: ask the hosting provider about route filtering, regional firewall rules, or upstream network incidents.

Small production example

A site is moved from one VM to another. The new VM serves the app, and curl localhost works, but Cloudflare still returns 523. dig shows the apex domain still points to the old floating IP, while curl ifconfig.me on the new host shows a different public IP. The fix is not restarting Caddy or Nginx; it is updating the Cloudflare A record, waiting for propagation, and confirming the new IP is reachable from outside the provider network.

Fix order that avoids downtime

Confirm the intended origin IP and keep the old origin alive if possible.
Update stale A/AAAA records in Cloudflare DNS.
Remove broken AAAA records until IPv6 is actually serving the same site.
Open only required ports, usually 80 and 443, from Cloudflare and your own admin IPs.
Re-test apex, www, robots.txt, and sitemap from a network outside the origin provider.

After-fix validation

Public pages return 200/301/304 through Cloudflare.
No recurring 523 on homepage, /robots.txt, and top question pages.
Logs show stable crawler access instead of edge-unreachable errors.

Useful references: Cloudflare 5xx troubleshooting docs and the LLMs File 52x checklist generator.

If the origin is reachable but requests time out, continue with Cloudflare 522 timeout troubleshooting.

Generate full 523 checklist