Fix Cloudflare error 522 on a Coolify server

Error 522 means Cloudflare gave up connecting to your server. These commands find where the connection stops on a Coolify VPS, and each result tells you where to look next.

What 522 means

Cloudflare defines two timeouts that produce this code. Before a connection exists, it sends a SYN and gets no SYN+ACK within 19 seconds. After a connection exists, it sends the request and gets no acknowledgment within 90 seconds. Both happen at the TCP level, below anything your application returns.

Cloudflare's connection errors and where to look for each on a Coolify server
Code	Cloudflare's definition	Where to look on Coolify
521	The origin refused the connection	coolify-proxy stopped, or nothing listening on the port
522	Timed out connecting, or no acknowledgment of the request	A firewall, a wrong IP, an overloaded or powered-off server
523	No route to the origin's IP	The network path, or the IP in the DNS record
524	Connected, but no HTTP response within 125 seconds by default	A slow application or a busy server

Why the app is rarely the cause

Every domain on a Coolify server goes through the coolify-proxy container, which is Traefik by default. It accepts traffic on ports 80 and 443 and forwards it to the app over a Docker network. While the proxy runs, it completes the connection with Cloudflare itself. Traefik returns 404 when no router matches, 502 when it can’t reach the app, and 503 when no server is ready. Coolify’s fallback page is a 503 for stopped, deploying or unhealthy resources. Each of those is an HTTP answer, so Cloudflare got through.

A stopped proxy normally doesn’t cause a 522 either. With nothing listening, the server refuses the connection, and Cloudflare reports 521. For a 522, packets have to go missing on the way, or the machine has to be too busy or powered off to answer.

Step 1: check the port and the IP

Your SSL/TLS mode decides which port Cloudflare connects to. Flexible always uses HTTP, on port 80. Full and Full (strict) follow the visitor’s scheme, so HTTPS visitors reach port 443 and plain HTTP visitors reach port 80, unless Always Use HTTPS redirects them first.

Coolify’s Cloudflare guide has you allow only port 443 from Cloudflare’s ranges, and it also turns on Always Use HTTPS. With that setting off, or the mode on Flexible, Cloudflare’s connections to port 80 hit the closed firewall. A 522 on http:// URLs while https:// works points here.

Next, compare the proxied A record in Cloudflare’s DNS tab with the IPv4 address in your hosting provider’s panel. A rebuilt or moved VPS can leave the old address behind, and Cloudflare lists that mismatch as a cause. When a record has both an IPv4 and an IPv6 origin, Cloudflare prefers IPv4, so the A record comes first.

Step 2: test the origin directly

Run this from your own computer with your domain and server IP. --resolve sends the request to your server and keeps the real hostname, so Traefik picks the right route. -k skips the certificate check, because a certificate problem is a separate error, covered in Cloudflare 526 with Full (strict) SSL. To test port 80, use example.com:80: and an http:// URL.

curl -sSk -o /dev/null -w '%{http_code}\n' --connect-timeout 20 \
  --resolve example.com:443:203.0.113.10 https://example.com/
echo "exit: $?"

Exit 28 and code 000 after 20 seconds: no SYN+ACK came back, the same thing Cloudflare sees. Look for a wrong IP, a provider firewall or a dead server.
Exit 7 and code 000 almost at once: the connection failed without waiting. The error text says whether it was refused or had no route. A refusal means nothing is listening on the port or a firewall rule rejects it, so check the proxy next.
Any HTTP status, including 404, 502 or 503: your network reaches the proxy. If Cloudflare still gets a 522, something treats Cloudflare’s addresses differently from yours, so go on to steps 4 and 5.

If your firewall admits only Cloudflare’s ranges, exit 28 from your own computer is expected and tells you nothing. Skip to step 4.

Step 3: check the proxy on the server

docker ps -a --filter name=coolify-proxy \
  --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
docker logs --tail 50 coolify-proxy
curl -sSk -o /dev/null -w '%{http_code}\n' --connect-timeout 5 \
  --resolve example.com:443:127.0.0.1 https://example.com/

The container should be Up with 80 and 443 in the Ports column. If it has stopped, or the local curl prints 000, open Servers, your server, then Proxy in Coolify, read Logs and restart it from there. Starting the proxy through Coolify writes its saved configuration to disk, so edits made only on disk can be overwritten.

If the local curl returns a status and step 2 timed out, the proxy works and the block sits between the internet and the container.

Step 4: watch the connection arrive

A packet capture shows where the SYN stops, and it works when the firewall admits only Cloudflare. Replace eth0 with the name after dev in the first command’s output, start the capture, and load the site through Cloudflare from another device. Use port 80 if that is the port Cloudflare connects to.

ip route show default
sudo tcpdump -ni eth0 -c 40 'tcp port 443'

In tcpdump output, Flags [S] is a SYN and Flags [S.] is the server’s SYN+ACK. Cloudflare retries after 1, 1, 1, 1, 1, 2, 4 and 8 seconds, so an unanswered connection shows the same source address and port repeating. Linux hands packets to capture tools before firewall rules run, so a SYN your server drops still appears.

No [S] from Cloudflare’s ranges: the packet never reached the machine. Check the provider firewall and the A record.
[S] with no [S.] going back: the machine got the packet and didn’t answer. Check the firewalls on the server and the load.
[S], [S.] and then normal traffic: the handshake works at this moment. That leaves an intermittent block, the 90-second case, or load.

Step 5: go through the firewalls

Start with the firewall in your hosting provider’s dashboard, which filters traffic before it reaches the server. Coolify needs 80 and 443 open for anything served on a domain. Allow every range on Cloudflare’s list, IPv6 included if you have an AAAA record. Cloudflare calls blocked or rate-limited Cloudflare addresses the most common cause of a 522. Then, on the server:

sudo iptables -L DOCKER-USER -n -v --line-numbers
sudo ufw status verbose
sudo fail2ban-client status

Docker diverts traffic for published ports before it reaches the chains ufw uses, so a plain ufw rule says little about whether coolify-proxy is reachable. Rules for those packets belong in the DOCKER-USER chain. A DROP or REJECT line there with rising packet counts is catching traffic.

The ufw-docker tool makes ufw rules apply to those ports. Coolify warns that a rule tied to a container’s IP stops working when the container gets a new address after a restart, redeploy, update or reboot. If the 522 began right after one of those, look for that rule and rewrite it for ports 80 and 443.

Automatic banning needs a look too. All your visitors now arrive from Cloudflare’s addresses, which can trigger blocking or rate limiting. fail2ban-client status with a jail name lists the addresses that jail has banned.

Step 6: check the load

Cloudflare also lists an overloaded origin that drops requests. By default, Coolify builds an application on the same server that runs it, so a 522 that comes and goes with deploys is worth checking against memory and CPU.

uptime
free -m
sudo dmesg -T | grep -iE 'out of memory|oom-killer'

If builds are the problem, resize the server or add a build server. Cloudflare’s list also includes disabled keepalives. Traefik’s defaults set no limit on keepalive requests or duration, so check that only if someone changed them.

Dotted pixel art of a pale turquoise sea meeting a white sky at a soft horizon.

What to send your host

If every check passes, Cloudflare asks for the error code and message, the time with its timezone, and the URL. For a 522 it also wants an MTR from your server to a Cloudflare IP that often connected before the problem began, which you can find in your server logs. The command is mtr -rw followed by that IP. Origin Analytics, under Speed in the Cloudflare dashboard, shows whether TCP failures cluster on particular paths.

Common questions

Should I turn off the orange cloud?

Only as a short test. A DNS-only record sends visitors straight to your server and publishes its IP. If the site loads, the server is fine and Cloudflare’s addresses are being treated differently. If your firewall admits only Cloudflare, the site will time out for everyone during the test.

Will redeploying the app fix a 522?

Rarely. A redeploy replaces the app container, and a 522 is about the connection that coolify-proxy should have received. It can help indirectly when a stuck build is what’s eating the server’s memory.

Would a Cloudflare Tunnel avoid this?

It removes the inbound connection. cloudflared connects outbound from your server, so Cloudflare no longer opens a connection to port 80 or 443. Coolify has setup guides, and notes that tunnels bypass your firewall rules.

Sources

Where this comes from: the Cloudflare, Coolify, Docker, Traefik, curl and tcpdump documentation listed here and the Linux kernel source, all checked on 8 November 2026. We did not reproduce this error on a server, so the results described are what these documents and TCP behaviour predict. This article was prepared with help from AI.