Skip to content
Rescue 404

Cloudflare Errors

Cloudflare error 523

Advanced Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

523

Cloudflare Error 523 means Cloudflare cannot reach your origin’s IP at the routing/address level—verify the proxied A/AAAA (or CNAME target) points at the current host IP and that the network path to that origin is not blackholed before treating it like a refused connection or timeout.

523 is an origin-unreachable Cloudflare 5xx: the edge cannot contact the configured origin address, which is different from 521 (connection refused) and 522 (connection timed out). This guide focuses on wrong DNS targets, stale IPs after migrations, IPv6 mismatches, and provider routing problems that clear 523 fastest.

Advanced

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • Error 523 occurs when Cloudflare cannot contact your origin web server. (Cloudflare Error 523)
  • Cloudflare documents cases where 523 appears when the path to the origin IP has no usable route, or the configured address cannot be contacted. (Cloudflare Error 523)
  • Confirming the correct origin IP on A or AAAA records in Cloudflare DNS is a primary resolution step for 523. (Cloudflare Error 523)

What the error means

When a hostname is orange-cloud proxied, visitors hit Cloudflare first, and Cloudflare opens its own connection to the origin IP listed in DNS (or resolved from a CNAME). Error 523 means Cloudflare cannot contact that origin—commonly because something on the path (router, firewall, or provider network) has no usable route to that destination IP, or the DNS target itself is wrong or unreachable. That differs from 521, where the origin actively refuses the TCP connection, and from 522, where the handshake attempt times out. WordPress plugins almost never “cause” 523; the DNS record and the host network path do.

Common symptoms

  • Visitors see Cloudflare’s “Error 523: Origin is unreachable” page with a Ray ID
  • Problem affects orange-cloud hostnames while grey-cloud or direct-IP tests behave differently
  • Cloudflare DNS A/AAAA still points at an old hosting IP after a migration
  • Host confirms the server is up, but traceroute/MTR from the origin toward Cloudflare fails oddly
  • Only some records fail (www vs apex) when one still has a stale IP
  • IPv6 (AAAA) is set while the origin does not actually route IPv6, or the reverse
  • Issue started right after changing hosts, load balancers, or Cloudflare DNS records

Most likely causes

  1. 01 Cloudflare A/AAAA records point to an incorrect, retired, or never-assigned origin IP
  2. 02 CNAME target hostname no longer resolves to a reachable address
  3. 03 Host or intermediate routing failure that leaves no usable path to the origin IP from Cloudflare’s network
  4. 04 Overly broad VPC/cloud route tables that blackhole traffic involving Cloudflare ranges
  5. 05 Origin IP changed after migration/rebuild and Cloudflare DNS was not updated
  6. 06 AAAA record publishes IPv6 while the origin network does not accept that path
  7. 07 Firewall or null-route at the host network layer makes the IP unreachable from Cloudflare’s vantage points

What changed before the problem started

  • Hosting migration or server rebuild with a new public IP
  • Manual edit of Cloudflare A/AAAA/CNAME records
  • Load balancer or floating IP reassignment at the host
  • IPv6 enabled or AAAA added without a working IPv6 origin path
  • Cloud provider VPC route table or gateway change
  • Registrar or DNS cutover that left stale origin targets in Cloudflare

Troubleshooting steps

  1. 01

    Confirm it is 523 and note the Ray ID

    Read the Cloudflare error page for 523 and save the Ray ID, hostname, and time. Do not chase PHP or plugin settings for an origin-unreachable code—this is DNS/routing until proven otherwise.

  2. 02

    Verify Cloudflare DNS targets match the current origin IP

    In Cloudflare DNS, confirm each proxied A/AAAA for the failing hostname matches the IP your host documents right now. Remove or correct stale records from the old server. If you use a CNAME, resolve the target and confirm it lands on a live address.

  3. 03

    Compare grey-cloud / direct origin reachability

    Temporarily set the record to DNS only, or curl the origin IP with the correct Host/SNI. If the origin is unreachable even off-Cloudflare, fix hosting/network first. If the origin works direct but proxied requests 523, focus on which address Cloudflare is using and path issues from Cloudflare’s network.

  4. 04

    Check AAAA and dual-stack mismatches

    If an AAAA exists, confirm the origin actually serves that IPv6 path. A published AAAA that blackholes from Cloudflare can produce 523 even when IPv4 would work. Remove or fix broken AAAA records while you stabilize IPv4.

  5. 05

    Ask the host to confirm the public IP and routing

    Send the host the Ray ID, the IP Cloudflare is targeting, and ask them to confirm that IP is still assigned to your account and routable. Migrations and “IP moves” that never update Cloudflare are the most common 523 story.

  6. 06

    Retest after DNS changes and allow short propagation

    After correcting records, purge is not the main lever—DNS and routing are. Retest the proxied hostname in a private window and confirm 523 is gone for both apex and www if both are in use.

When to stop troubleshooting

Escalate when you cannot change Cloudflare DNS, the host will not confirm the current IP/routing, 523 continues after verified correct A/AAAA records, or the site stays down through business hours. Provide the Ray ID, the origin IPs Cloudflare is using, grey-cloud test results, and any MTR output—do not keep flipping SSL modes or plugins for an unreachable-origin error.

Information to collect before requesting help

  • 01 Cloudflare Ray ID from the 523 page
  • 02 Current A/AAAA/CNAME targets in Cloudflare DNS
  • 03 Origin IP(s) documented by the host right now
  • 04 Whether grey-cloud or direct-IP access works
  • 05 Whether AAAA/IPv6 records exist for the hostname
  • 06 Recent migration, IP change, or DNS edits
  • 07 Host traceroute/MTR notes if routing is suspected

How a professional repairs the problem

We verify 523 versus 521/522, reconcile Cloudflare DNS with the live origin IP (including AAAA and CNAME chains), and prove reachability with and without the proxy. When DNS is correct, we escalate routing with the host using Ray IDs and path evidence, fix dual-stack and load-balancer target mistakes, then confirm proxied apex and www load cleanly before closing.

Frequently asked questions

Is Error 523 a WordPress failure? +
Almost never. 523 is Cloudflare failing to reach the configured origin address. Fix DNS targets and host routing before changing themes or plugins.
How is 523 different from Cloudflare 522? +
522 means Cloudflare tried to connect and the attempt timed out. 523 means Cloudflare could not contact/route to the origin address successfully. Wrong or unreachable IPs lean 523; filtered/slow paths often lean 522.
Can a wrong A record alone cause 523? +
Yes. Pointing the orange-cloud record at an old or unused IP is one of the most common 523 causes after migrations.
Should I change SSL/TLS mode to fix 523? +
No. SSL mode does not make an unreachable origin reachable. Correct the IP/routing first; certificate modes matter for 525/526-style failures.
Why does only www show 523? +
Apex and www are separate DNS records. One can still point at the new host while the other remains on a dead IP. Fix each proxied name independently.
Does pausing Cloudflare fix 523? +
Grey-clouding can help you test the origin, but if DNS still points at a bad IP the site stays down. Use pause/DNS-only as a diagnostic, then correct the target and restore the proxy.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.