Cloudflare Error 523: Origin Is Unreachable. Finding the Broken Route

Cloudflare documents 523 as: "This error occurs when Cloudflare cannot contact your origin web server", and the common cause as "a network device between Cloudflare and the origin web server does not have a route to the origin's IP address" (Cloudflare: Error 523). The page reads "Origin is unreachable" and carries the 523 status.

It sits one step earlier than its neighbours. With 521 the origin host answered and refused; with 522 packets went out but nothing came back in time. With 523 the path itself is broken: the address Cloudflare has for your origin is not reachable from its network. That makes the origin IP in DNS and the routing around your server the first things to check, not the web server.

The AWS case comes straight from Cloudflare's own resolution notes: Cloudflare uses public addresses in 172.64.0.0/13, which an overly broad route for 172.0.0.0/8 captures by mistake (Error 523 resolution).

1. Read the origin address Cloudflare uses. Proxied records resolve to Cloudflare, so dig will not show it; open the DNS tab, or list records with the API:

   curl -s -H "Authorization: Bearer $CF_API_TOKEN" \
     "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records?name=example.com" | grep -o '"content":"[^"]*"'

2. Compare with the server's real address. On the origin: ip -4 addr show scope global and curl -s https://ifconfig.me (the public address, which differs behind NAT).
3. Test reachability of that address from outside your network:

   curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null
   # * connect to 203.0.113.10 port 443 failed: No route to host

   "No route to host" or a timeout from several networks confirms a routing problem.
4. Trace from the origin toward Cloudflare, as Cloudflare asks: pick a Cloudflare IP that connected recently (from your access logs) and run mtr -rwc 50 104.16.0.1, using an address from your own logs rather than this example.
5. On AWS, inspect the VPC route table for routes broader than intended and add a specific route for 172.64.0.0/13 to the Internet Gateway if needed.
6. For servers without a public IP, publish them with Cloudflare Tunnel rather than pointing a proxied record at a private address.

Most 523 incidents follow a change: a move to a new VPS, a new load balancer, a re-created cloud instance with a fresh public IP, or a home server whose provider assigned a new address overnight. In each case the site worked until the address changed, and the proxied record kept pointing at the old one. Two habits prevent the repeat. First, after any migration, compare the address in every proxied A and AAAA record with the new server, including records for subdomains such as api or www that are easy to forget. Second, for servers on dynamic addresses, do not rely on manual DNS edits at all: either update the record automatically through the Cloudflare API when the address changes, or run Cloudflare Tunnel, which needs no inbound address. Keep the old server reachable for a while after a move, so a missed record shows up as old content rather than as an outage.

curl -s -o /dev/null -w '%{http_code}\n' --resolve example.com:443:203.0.113.10 https://example.com/
# 200
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/
# 200

Both requests, direct to the origin and through Cloudflare, must succeed, and the 523 count in Error Analytics must stop growing. The HTTP status checker shows what the proxied URL returns from outside your network; the traceroute tool helps when you need a path from a network other than your own.

• Cloudflare 521 — reachable, but the connection is refused
• Cloudflare 522 — the connection attempt timed out
• Cloudflare 1016 — the origin hostname does not resolve
• ERR_ADDRESS_UNREACHABLE — the browser version of "no route to host"
• Cloudflare 520–530 overview — all origin errors compared