Cloudflare 522: when the site is fine and the DNS record is wrong
A 522 means Cloudflare could not connect to the address in your DNS record. Often the server is healthy and the record points somewhere else.
What a 522 is
Error 522 is "connection timed out". Cloudflare answered the visitor, tried to open a connection to the address in your DNS record, and nothing answered in time.
There are three common causes:
- The server is down or overloaded.
- A firewall on the server drops connections from Cloudflare.
- The record points at an address that is not your server.
The third is the one that wastes days, because every check you run on the server says it is healthy. It is healthy. Cloudflare is simply knocking on a different door.
How a record ends up wrong
Usually a migration. The site was copied to a new server, the old one was switched off, and the A record in Cloudflare still names the old address. Sometimes the root record was updated and www was not. Sometimes the provider reassigned the address.
The trap is that you cannot see it from outside. With the proxy on, a DNS lookup returns Cloudflare's addresses, not yours:
dig +short example.comThat output is the same whether the record behind it is right or wrong. The origin address is only visible in the Cloudflare dashboard, under DNS for the zone.
Prove the server is fine in one command
Ask your server for the site by name, without DNS and without Cloudflare. Use the server's real public address:
curl -sS -I --resolve example.com:80:203.0.113.10 http://example.com/Run it from your own computer, not from the server. If headers come back, the origin serves the site and its firewall lets the world in on port 80. The fault is between Cloudflare and that address.
Now open the Cloudflare dashboard and compare the A records for the root name and for www with the address you just used. If they differ, you have found it. Change them and leave the proxy on.
If the command hangs from outside but works on the server itself, look at the firewall and at whether ports 80 and 443 are open.
Why monitoring often misses it
A check that runs on the server and asks the server for the site answers a narrower question than the one you care about. It proves this machine's copy works. It says nothing about what a visitor gets.
A 522 is also slow to arrive, because Cloudflare waits before giving up. A monitor with a short timeout records "no answer", which reads like a network blip.
What KLYRN reports
Before 1.0.2, KLYRN's site diagnosis asked only the local question, and for a site in this state it reported nothing wrong. That was a real gap, and it was found the hard way: a domain answering 522 for days while its server was healthy.
Since 1.0.2 the diagnosis also asks what a visitor gets from the domain's public address:
klyrn site diagnose example.comWhen the name does not resolve to the server, it fetches the site by its public name and checks whether a request for the domain arrives at this server at all. If Cloudflare answers with an error in the 520 to 526 range and the request never arrives, the site is reported as down, with this finding: visitors get the Cloudflare error, and it is not this server refusing them.
The evidence shows what the domain resolves to, this server's address, and the public answer. The advice names the record to change: set the A record, and www, to this server's address. The orange cloud can stay on, and the certificate is issued through it afterwards.
There is a quieter version of the same finding. When a domain resolves somewhere else and no proxy error is involved, the diagnosis says visitors are not served by this server. That is expected while a migration waits for its cut-over, and worth knowing at any other time.