Error 523 means Cloudflare cannot contact your origin web server at all. Cloudflare's documentation describes the typical cause as a network device between Cloudflare and the origin that has no route to the origin's IP address. That makes it different from a refused connection (521) or a timeout (522): with a 523, there is nowhere to send the packets in the first place.
The visitor sees a Cloudflare page headed "Origin is unreachable." The edge works, and your origin or the network path to it does not. For the overview of all 52x errors, see Cloudflare 520-526 errors explained.
What causes a 523
The documented causes are short:
- The origin IP in your Cloudflare DNS record has no route. The address may be private, reserved, unassigned, or withdrawn by your provider.
- A routing problem between Cloudflare and the origin, at your host or on the internet path.
- An over-broad route on AWS. A VPC route table entry such as
172.0.0.0/8can capture traffic meant for Cloudflare's172.64.0.0/13range and send it to a private destination instead of the internet.
In practice, the most common field cases are a wrong A or AAAA record after a migration, and a cloud network with a route that swallows Cloudflare's addresses.
If you are a visitor
You cannot repair a routing fault. Retry after a few minutes. If it persists, tell the site owner the time and Ray ID. The Cloudflare Error Checker shows whether the site is returning a Cloudflare error right now.
If you are the site owner
Step 1: check the record Cloudflare uses to reach the origin
Open the DNS tab in Cloudflare and read the value of the A or AAAA record for the failing hostname. It should be the origin's public address. Common mistakes:
- A private address (
10.x.x.x,172.16.x.xto172.31.x.x,192.168.x.x) copied from an internal network. - A documentation or reserved range such as
192.0.2.0/24,198.51.100.0/24or203.0.113.0/24. - An old address from a previous host or a cloud instance that has since been replaced.
- An AAAA record pointing to an IPv6 address the server no longer has, while the A record is correct.
Inspect what the public DNS shows with the DNS Checker. If the proxy hides the real value (orange cloud), read it in the dashboard rather than from dig.
Step 2: confirm the address is live and who owns it
ping -c 3 ORIGIN_IP
traceroute -n ORIGIN_IP # or: mtr -n -r -c 20 ORIGIN_IPUse the IP Lookup and ASN Lookup tools to check that the address belongs to your intended provider. Some hosts do not answer ICMP, so a failed ping alone proves little; follow it with a port test on 80 or 443 using the Port Checker. If the address belongs to a different company than your host, the record is wrong.
Step 3: check IPv6 as well as IPv4
If the zone has an AAAA record, Cloudflare may try it. Verify the server is configured on that address and that the web server listens on [::]:443:
ip -6 addr show scope global
sudo ss -tlnp | grep ':443'
curl -6 -skI --resolve example.com:443:[YOUR_IPV6] https://example.com/Remove a stale AAAA record if you do not run IPv6.
Step 4: the AWS route table trap
Cloudflare's documentation calls out this scenario: a VPC route table has a route like 172.0.0.0/8 that points to a private destination (a peering connection, VPN, transit gateway or similar). Cloudflare's 172.64.0.0/13 range falls inside it, so replies to Cloudflare never reach the internet. The fix per the docs is to make sure traffic for 172.64.0.0/13 is not sent to a private destination, and if needed add a more specific route for that range that targets your Internet Gateway.
Inspect your routes with the AWS CLI:
aws ec2 describe-route-tables --filters Name=vpc-id,Values=vpc-0123456789abcdef0 \
--query 'RouteTables[].Routes[].[DestinationCidrBlock,GatewayId,VpcPeeringConnectionId,TransitGatewayId]'Look for a CIDR that covers 172.64.0.0/13. The same pattern can occur on any cloud or on-premises network where a broad private route catches public Cloudflare addresses, so check your own routing on other platforms too.
Step 5: escalate with evidence
If DNS and routing are right, tell your hosting provider the error details and ask for an MTR or traceroute from the origin to a Cloudflare IP that recently connected to it. You can find such an address in the origin server's access logs. Provide this to Cloudflare Support if the provider finds nothing.
523 compared with neighbors
| What happens | Code |
|---|---|
| No route to the origin IP | 523 |
| Packets sent, no answer in time | 522 |
| Connection refused | 521 |
| Hostname could not be resolved | 530 with a 1xxx code |
Next steps
- Review the record with the DNS Checker.
- Confirm ownership of the origin IP with the Website Hosting Checker.
- Test connectivity with the Port Checker.
- Read Cloudflare DNS and SSL modes for correct record setup.
- Learn how DNS records work in DNS explained for website owners.
FAQ
Is a 523 always a DNS mistake?
No, but a wrong record is the first thing to rule out. The other main cause is a routing problem at your host or in your cloud network.
Does 523 mean my server is off?
Not necessarily. A powered-off server usually looks like a timeout or refusal. 523 points to a missing route to the address.
Why would an AWS site start failing without any change on my side?
A routing change, such as a new peering or VPN route covering Cloudflare's range, can start capturing traffic for 172.64.0.0/13. Review recent route table edits.
Can I fix this from the Cloudflare dashboard?
Only if the cause is a wrong DNS record. Routing problems must be fixed at the origin network or by your host.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.