Understanding Cloudflare 523 Origin Is Unreachable: When There's No Route to Your Server
523 Origin Is Unreachable is the most fundamental failure in the Cloudflare 52x family: it's not that your server refused a connection, and it's not that your server took too long to answer — there's simply no network path from Cloudflare to your origin's IP address at all. This is a routing problem, not an application problem, which means the fix usually lives in DNS records or network configuration rather than anything your web server or app is doing. This post covers what Cloudflare's docs say about 523, the specific AWS trap they call out by name, and how it differs from 521 and 522.
What Is a 523?
A 523 means Cloudflare's network could not find a route to your origin's IP address — the request never even got as far as attempting a TCP connection with your server.
Not a standard code. 523 has no RFC and no IANA registry entry — same as the rest of the 52x family, it exists only because Cloudflare's proxy architecture introduces a Cloudflare-to-origin network hop that a directly-accessed server never has.
Cloudflare's documentation states it plainly:
This error occurs when Cloudflare cannot contact your origin web server. — Cloudflare documentation, Error 523
And they're specific about where in the network stack the failure happens:
This typically occurs when a network device between Cloudflare and the origin web server does not have a route to the origin's IP address. — Cloudflare documentation, Error 523
In plain English: somewhere between Cloudflare's edge and your origin, a router, gateway, or network device simply doesn't know how to get a packet to your origin's IP. That's a categorically earlier failure than 521 or 522 — those both assume the network path exists and something happens (or doesn't) once a packet arrives. 523 means the packet has nowhere to go in the first place.
The AWS Routing Trap
Cloudflare's documentation calls out one specific, well-known cause by name, because it's common enough to warrant its own paragraph:
In AWS environments, a common cause is an overly broad route such as 172.0.0.0/8 in a VPC route table. Cloudflare uses public IP ranges in 172.64.0.0/13, and a broad route can accidentally capture traffic intended for Cloudflare. — Cloudflare documentation, Error 523
Here's what's actually happening: AWS VPCs sometimes end up with a broad route covering 172.0.0.0/8 (an overly generous superset of the RFC 1918 172.16.0.0/12 private range — most of that /8 is actually public address space). Cloudflare, unrelated to that private range, happens to use public IPs inside 172.64.0.0/13 — a numerically overlapping but entirely different, publicly-routable block. If a VPC's route table sends everything in 172.0.0.0/8 toward a private destination (a NAT gateway, a peered VPC, an internal appliance) instead of out to the internet, return traffic destined for Cloudflare's public IPs gets silently swallowed by that broad private route instead of reaching the internet gateway. The origin never even sees the connection attempt — which is exactly the signature of a 523.
This is a good example of why 523 debugging often has nothing to do with your web server at all: the server could be perfectly healthy, and the problem is entirely in how a router or route table decides where to send packets.
Diagnosing a 523
Cloudflare's resolution steps focus on routing and DNS, not application health:
- Confirm the origin IP in your Cloudflare DNS records is correct. Cloudflare's docs recommend: "Confirm the correct origin IP address is listed for A or AAAA records within your Cloudflare DNS app." A stale record pointing at an IP your origin no longer has is one of the simplest explanations for "no route."
- If you're on AWS, review your VPC route tables specifically. Per Cloudflare's guidance: "In AWS, review VPC route tables and make sure you are not sending 172.64.0.0/13 toward a private destination. If required, add a more specific route for 172.64.0.0/13 to your Internet Gateway." A more specific route takes priority over the broad
172.0.0.0/8catch-all, letting Cloudflare's actual IP range route correctly while leaving your intended private routing untouched. - Get an MTR or traceroute from your origin toward a Cloudflare IP. Cloudflare's support process specifically asks for "an MTR or traceroute from your origin web server to a Cloudflare IP address that most commonly connected to your origin web server before the issue occurred" — identifiable from your own origin's connection logs. This surfaces exactly where in the path the route breaks down.
- Investigate general internet routing issues between your origin and Cloudflare, if the above doesn't turn up an obvious culprit — this can include the origin's own network interface being down, a hosting provider outage, or an upstream ISP routing problem outside either your or Cloudflare's control.
523 vs. 521 vs. 522
| Code | Meaning | Where the failure sits |
|---|---|---|
| 521 Web Server Is Down | Origin actively refused the connection | Network path exists; the origin (or something in front of it) said no |
| 522 Connection Timed Out | No response within Cloudflare's connection timeout | Network path exists; nothing answered in time |
| 523 Origin Is Unreachable | No route to the origin's IP at all | Network path doesn't exist — the packet has nowhere to go |
| 503 Service Unavailable | Standard-HTTP way for a reachable server to decline a request | Server answered deliberately — the opposite situation from 523 |
The ordering matters for triage: if you're not sure which of the three you're facing, 523 is the one where you should look at DNS records and routing tables first, before touching firewalls (521's territory) or origin load (522's territory) — because if there's no route, none of the origin-side fixes will matter until the path exists.
Common Pitfalls
- Debugging application code or server load for a routing failure. A 523 means the request never reached your origin's network interface — there's nothing in your application logs to find, because your application never saw the request.
- Overlooking a stale A/AAAA record after an IP change. If your origin's IP changed (new host, new instance, provider migration) and the Cloudflare DNS record wasn't updated, every request is being routed toward an address that no longer belongs to your server.
- Not checking VPC route table specificity on AWS. A broad private route like
172.0.0.0/8silently overlapping Cloudflare's172.64.0.0/13public range is exactly the kind of misconfiguration that looks like an outage but is actually one overly generous CIDR block. - Assuming 523 and 521 are interchangeable "origin down" errors. They point to different layers — 521 implies the network path works and something rejected the connection; 523 implies there's no path at all. Conflating them sends you looking at firewall rules when the actual problem is a routing table.
Wrapping Up
523 is Cloudflare telling you there's no network path to your origin's IP address — a routing-level failure that sits earlier in the stack than a refused connection or a timeout. The rules of thumb:
- 523 = no route exists. It's more fundamental than 521 (refused) or 522 (timed out) — the packet never has anywhere to go.
- Verify the origin IP in your Cloudflare DNS records first — a stale A/AAAA record is a common, simple cause.
- On AWS, check for an overly broad
172.0.0.0/8VPC route swallowing Cloudflare's172.64.0.0/13public range — a documented, specific trap. - An MTR or traceroute from the origin to a known-good Cloudflare IP is the diagnostic Cloudflare support will ask for if DNS and routing checks don't resolve it.
For more, see our pages on 523 Origin Is Unreachable, 520 Web Server Returns Unknown Error, 521 Web Server Is Down, and 522 Connection Timed Out, plus our 521 post and the standard-HTTP 503 Service Unavailable deep-dive.