I Get HTTP 522 Error: What I Do to Fix It

When I get an HTTP 522 error, I usually know one thing right away: the problem is not my browser. In most cases, Cloudflare is able to make the connection to my origin server, but the origin server does not respond quickly enough. That is why the page times out and I see the 522 message instead of my website.

For me, this error is frustrating because it can look mysterious at first. The good news is that it is usually very practical to troubleshoot. I do not treat HTTP 522 as a random Cloudflare issue. I treat it as a signal that something in my server stack, firewall, or hosting environment is delaying the response.

The chart above reflects the areas I check first. In my experience, firewall blocks and server overload are the most common reasons I run into this error. I have also seen it caused by stuck services, bad DNS routing, and security settings that accidentally block Cloudflare IPs. Once I stop thinking of it as a generic timeout and start checking the infrastructure piece by piece, the fix becomes much easier.

What HTTP 522 means to me

When I see 522, I think: Cloudflare reached my origin, but the origin did not reply in time. That means the problem is usually somewhere on the server side. It can be a web server issue, a database problem, a firewall restriction, or even a host-level outage. Sometimes the server is technically online, but it is so slow that it behaves like it is down.

I also remind myself that this is different from a DNS error. DNS problems are about finding the server. HTTP 522 is about the server not answering fast enough after the connection is already in progress. That distinction saves me a lot of time when I troubleshoot.

My first troubleshooting checklist

Whenever I face this error, I start with a simple checklist. I do not jump into random fixes because that usually wastes time. I want to confirm whether the origin server is healthy, reachable, and allowed to talk to Cloudflare.

This checklist helps me narrow the issue down quickly. If the server is overloaded, I focus on performance. If the firewall is blocking traffic, I focus on access rules. If the web stack is broken, I restart and inspect the relevant services. If the DNS points somewhere unexpected, I correct the records before doing anything else.

The exact steps I follow

I keep my process simple and repeatable so I can move through it without guessing.

That sequence has saved me a lot of time. I like starting with direct reachability because it tells me whether the origin server is responding outside of Cloudflare. If the direct test fails, I know the server itself needs attention. If the direct test works, I focus on Cloudflare settings, firewall rules, or network filtering.

How I test the firewall angle

One of the first places I look is my firewall. If the server is blocking Cloudflare, I can get a 522 even when everything else looks fine. This is especially common after I tighten security settings, move to a new host, or install a security plugin that is a little too aggressive.

When I suspect that Cloudflare IPs are being blocked, I check the rules and make sure the allowed ranges are in place. A simple example looks like this:

# Example: allow Cloudflare IP ranges in a firewall
# Replace with your server's firewall tool and ruleset

ufw allow from 173.245.48.0/20 to any port 80,443 proto tcp
ufw allow from 103.21.244.0/22 to any port 80,443 proto tcp
ufw allow from 103.22.200.0/22 to any port 80,443 proto tcp
ufw allow from 103.31.4.0/22 to any port 80,443 proto tcp

# Reload firewall rules after updating them
ufw reload

I do not use that exact snippet blindly on every server, but it reminds me of the principle: Cloudflare must be allowed to reach my origin on the web ports I use. If the firewall is too strict, the connection can start but never complete, which leads to the timeout I see as 522.

Why server performance matters so much

Even when my firewall is correct, I can still get an HTTP 522 if the server is too slow. That is why I pay close attention to CPU, memory, disk I/O, and database performance. If one of those is maxed out, the web server may not answer before Cloudflare gives up.

I have seen this happen after traffic spikes, plugin updates, broken cron jobs, and inefficient database queries. A WordPress site with too many heavy plugins can easily behave like this. So can a custom app with slow backend code or a database that is under pressure.

When this happens, I look at the timing of the error. If it starts during traffic peaks, I suspect resource exhaustion. If it starts after a deployment or plugin change, I suspect a code or configuration issue. That pattern usually points me in the right direction.

What I check in the server stack

I do not just check whether the server is “up.” I check the components that actually generate the response. That includes Apache or Nginx, PHP-FPM if I am running PHP, the database service, and any background jobs that may be locking resources.

If one service is stuck, restarting it can sometimes clear the issue. But if the problem returns, I know I need to investigate deeper. I look for long-running requests, errors in the logs, and bottlenecks that slow the application response time. A server can be technically online and still fail to answer fast enough for Cloudflare.

Why DNS and Cloudflare settings still matter

Although HTTP 522 is not a DNS problem in the strict sense, DNS misconfiguration can still contribute to it. If my A or AAAA record points to the wrong origin, I may be sending traffic somewhere that is not prepared to answer. If Cloudflare is proxying the wrong hostname, I can create a delay or a routing mismatch that looks like a timeout.

I always verify that the DNS record points to the correct origin server IP and that the proxy state matches the setup I want. If I recently moved hosting providers or changed IP addresses, I double-check everything. A small record mistake can create a big availability problem.

What I do when I cannot fix it myself

If I have checked the firewall, server load, web services, and DNS but the error still remains, I contact my hosting provider. At that point I want server logs, network status, and any known incidents from their side. Sometimes the problem is not on my application at all. It is a host-level network issue, hardware issue, or an upstream timeout that I cannot see directly.

When I contact support, I give them the exact time the error started, what I changed before it happened, and whether the issue affects all visitors or only some regions. That information helps them investigate faster. I have found that the better my notes are, the faster the resolution usually is.

How I prevent HTTP 522 from coming back

After I fix the error, I do not want to see it again. So I focus on prevention. My main habits are:

• keep the server optimized
• remove heavy or unnecessary plugins
• use caching where appropriate
• monitor CPU, memory, and disk usage
• watch for slow database queries
• keep firewall rules aligned with Cloudflare
• review logs after updates and deployments

I also try not to rely on “it works right now” as proof that everything is healthy. A site can be stable at low traffic and still fail under load. Regular monitoring is what helps me catch that before visitors see the error.

My simple summary of HTTP 522

If I had to reduce it to one sentence, I would say this: HTTP 522 means Cloudflare connected to my origin server, but the origin server did not respond in time.

That is why my fix process always starts with server health, firewall rules, and origin reachability. Once I treat the problem that way, I stop chasing the wrong symptoms and focus on the cause.

The important thing for me is not just getting the site back online once. It is understanding why the timeout happened so I can reduce the chance of it happening again. That is what makes my troubleshooting faster, my site more reliable, and my hosting setup easier to trust.