Cloudflare error 523 "Origin is unreachable": find the dead route to your server

Short answer: Cloudflare error 523 “Origin is unreachable” means Cloudflare has an IP address for your origin, from your DNS record, but no network path to it: the packets never reach a machine that could accept or refuse them. Unlike 521 and 522, it is rarely about your web server. Check, in this order: the A and AAAA records in the Cloudflare dashboard against your server’s real public addresses (an old IP, a private 192.168.x.x address, or a dead AAAA record on a name without an A record are the classics), whether the server is on the network at all, and whether a route on the server or at your provider swallows Cloudflare’s traffic.

# The public addresses this server really has, as Cloudflare sees them
curl -s -4 https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='
curl -s -6 https://www.cloudflare.com/cdn-cgi/trace | grep '^ip='

# Skip Cloudflare and connect to the origin IP from your DNS record
curl -skv -o /dev/null --connect-timeout 10 --resolve example.com:443:203.0.113.10 \
  https://example.com/ 2>&1 | grep -E 'Trying|connect|Connected|timeout'

Compare the ip= lines with the A and AAAA records on the DNS page of the Cloudflare dashboard (on a server with several addresses, they show the one it uses outbound). Public DNS lookups only return Cloudflare’s own addresses for a proxied record, so the dashboard is the only place that shows what Cloudflare dials. If the -6 command prints nothing, the server has no working IPv6, and an AAAA record for it is a dead end. In the second test, replace example.com and 203.0.113.10 with your name and the address from the record; for an IPv6 address use brackets: --resolve example.com:443:[2001:db8::10].

What 523 means, next to 521, 522 and 1016

Every 52x error is about the second leg: Cloudflare’s connection to your server. Per Cloudflare’s error 523 documentation, a 523 happens when a network device between Cloudflare and the origin has no route to the origin’s IP. The test from your own machine fails the same way, which is how you tell the codes apart:

In practice, whether a dead path shows as 522 or 523 depends on one detail: a router that silently drops the packets leaves Cloudflare waiting for a timeout, while a router that answers with an ICMP “unreachable” message tells it there is no route. So the same fault, a switched-off server for instance, can show either code. Once TCP connects, the 520 and 524 family takes over.

Cause 1: the DNS record holds the wrong address

Cloudflare’s own troubleshooting starts here, and so should you. Open the DNS page in the dashboard and check every proxied A and AAAA record for the failing name, apex and www separately. The usual mistakes:

• An old IP after a move or reinstall. The server was rebuilt or moved and got a new address; the record still names the old one. If nobody uses that address any more, the provider’s router often answers “host unreachable”: a textbook 523. If it now belongs to someone else, you get a 521, 522 or a stranger’s site instead.
• A private address. 10.x.x.x, 172.16.0.0–172.31.255.255 and 192.168.x.x only exist inside a LAN. They turn up when someone copies the address from ip addr on a server behind NAT, a home server or a cloud VM with a separate public IP. Cloudflare needs the public address; for a box at home, that means a port forward on the router, or Cloudflare Tunnel, which needs no inbound port at all.
• A CNAME to a retired endpoint. A proxied CNAME to a provider host name, such as an old load balancer or platform address, still resolves but leads to an address nobody uses. Check the target with dig +short TARGET_HOSTNAME; if it resolves to nothing at all, Cloudflare shows error 1016 instead.
• A typo, or a second record nobody remembers. Two A records on one name are round-robin: per Cloudflare’s round-robin documentation, it picks one and retries the others when one fails. A dead entry next to a good one therefore tends to cost time rather than fail outright. Delete it anyway.

A quick test of the address from your record: enter it with port 443 in our open port checker. It refuses private and reserved addresses outright, which is itself the answer for a 192.168 record, and for a public address it reports whether TCP 443 answers from our network in Amsterdam.

Cause 2: an AAAA record for IPv6 the server does not have

An AAAA record survives a reinstall, a move to a new host or a change of network configuration, while the server’s IPv6 address does not. Per Cloudflare’s IPv6 compatibility page, Cloudflare prefers the IPv4 address when a proxied name has both an A and an AAAA record, so a stale AAAA next to a working A rarely causes a 523 on its own. It bites on a name that has only an AAAA record: an A record deleted during a move, or a server set up for IPv6 alone. Check on the server whether it has a global IPv6 address and a route to Cloudflare’s IPv6 ranges:

ip -6 addr show scope global
ip -6 route get 2606:4700::1

2606:4700::/32 is one of the IPv6 ranges Cloudflare publishes. On a server without working IPv6 the first command prints nothing and the second prints this, real output from a server with IPv4 only:

RTNETLINK answers: Network is unreachable

Either configure IPv6 properly (address and default route from your provider’s panel), or replace the AAAA record with an A record for the server’s IPv4 address. Visitors lose nothing: Cloudflare still answers them over IPv6 at its edge and connects to your server over IPv4. If you keep the AAAA, confirm it from outside with the --resolve test using the IPv6 address, from a machine that has IPv6.

No IPv6 at home? Our looking glass runs ping, traceroute and MTR over IPv4 and IPv6 from Amsterdam towards your origin address.

Cause 3: the server is off the network

A server that is switched off, suspended, or has lost its network configuration looks the same from outside: the last router in front of it finds nobody at that address. Many routers then send “host unreachable”, which Cloudflare reports as 523; others stay silent and you get 522. Typical triggers are a stopped or suspended VPS, an expired service, and a change to /etc/network/interfaces or netplan that removed the address or the default route.

Check the power state in your provider’s panel, then log in through its console, not SSH, which needs the same network that is broken. Inside, the address and the default route must be there:

ip -br addr
ip route show default
ip -6 route show default

ip -br addr should list your public address on the main interface as UP, and ip route show default a line starting with default via. If either is missing, revert the last network change and apply it from the console: sudo netplan apply where netplan is used, sudo systemctl restart networking with ifupdown’s /etc/network/interfaces.

One firewall setup imitates this pattern. firewalld, the default on Rocky Linux and AlmaLinux, rejects blocked connections with an ICMP “administratively prohibited” message, and Linux reports that to the client as No route to host, not as a refusal. If the server is up and the outside test still says No route to host, look for https (and http for Flexible) in sudo firewall-cmd --list-all; add it with sudo firewall-cmd --permanent --add-service=https and sudo firewall-cmd --reload. An iptables rule with --reject-with icmp-host-prohibited, as in old CentOS defaults, does the same.

Cause 4: a route swallows Cloudflare’s traffic

The origin can be up, with the right address, and still be unreachable for Cloudflare if traffic for Cloudflare’s ranges is routed somewhere else. Cloudflare’s own example is an AWS VPC route for 172.0.0.0/8 towards a private destination, which also covers Cloudflare’s 172.64.0.0/13; the fix there is a more specific route for 172.64.0.0/13 to the internet gateway. On a VPS the same mistake comes from a VPN client on the origin that takes over the default route, such as WireGuard with AllowedIPs = 0.0.0.0/0 or OpenVPN with redirect-gateway, or a hand-made static route. Depending on whether the wrong path drops or rejects the replies, you see 522 or 523.

Ask the kernel which way it would send packets to each published Cloudflare range:

for net in $(curl -fsS https://www.cloudflare.com/ips-v4); do ip route get "${net%/*}"; done
for net in $(curl -fsS https://www.cloudflare.com/ips-v6); do ip -6 route get "${net%/*}"; done

Every line should name your public interface and your provider’s gateway:

173.245.48.0 via GATEWAY dev eth0 src SERVER_IP uid 0
    cache

A line with dev wg0, dev tun0, a Docker bridge or a private gateway is the culprit. Exclude Cloudflare’s ranges from the VPN, or narrow the route.

Cause 5: a block or routing fault before your server

If the record is right, the server is up, its routes are clean and the --resolve test still fails from outside, the problem sits upstream. The usual cases: the provider null-routed the IP during a DDoS attack, suspended it over an abuse report, or a routing fault cuts off some networks, sometimes only some Cloudflare locations. The cf-ray header of the error page names the location:

curl -sI https://example.com/ | grep -iE '^(HTTP|cf-ray)'

The ID ends in an airport code, for example -FRA for Frankfurt. Ask friends or a remote server elsewhere to run the same command: a 523 in one location and a 200 in another is a routing problem, not a configuration problem. For the provider, Cloudflare recommends an MTR or traceroute from the origin to a Cloudflare IP that connected to it recently. Without the nginx real_ip module, the client addresses in your access log are those Cloudflare IPs:

sudo tail -n 200 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -n 5
sudo mtr -rwbz -c 20 -T -P 443 CLOUDFLARE_IP

-T -P 443 traces with TCP SYNs to port 443, which gets through where ICMP is filtered; on Debian and Ubuntu, mtr comes from the mtr-tiny or mtr package. Send the report, the Ray ID and the time to your provider.

For the other direction, run an MTR towards your origin in the looking glass: the last hop that still answers shows where the path ends.

How to keep 523 away

• Update Cloudflare before you retire a server. Change the A and AAAA records, check that traffic arrives on the new machine, then shut down the old one.
• Publish AAAA only for IPv6 you have tested from outside, and delete it when you move.
• Monitor the origin directly, by IP with the right hostname, not only through Cloudflare, so you learn about a dead origin from your monitor rather than from visitors.
• Keep console access to every origin. On a VMHeaven Linux VPS the VNC console in the panel stays reachable even when networking on the VPS is down, and the panel lists the addresses to put into Cloudflare: IPv4, plus IPv6 where the location has a prefix.

Frequently asked