Error 522: Connection Timed Out Between the Proxy and Your Origin

Error 522 means the proxy tried to open a connection to your origin server and gave up waiting. The visitor sees a proxy error page, and the request never reached your application at all.

That last part is the important diagnostic clue. A 522 is not your application returning an error; it is your application never being asked. Nothing appears in your access log because no request arrived, which is exactly why people spend an hour reading application logs that were never going to say anything.

There are two distinct timeouts behind this code, and knowing which one you hit narrows the cause considerably.

Table of contents

• The two timeouts, and what each one means
• Cause one: the origin is blocking the proxy
• Cause two: the origin is overloaded or crashed
• Cause three: keepalives, DNS and routing
• A diagnosis order that finds it quickly
• How this fits the rest of the stack
• FAQ

The two timeouts, and what each one means

The proxy raises a 522 in two different circumstances, and they point at different problems.

Before the connection is established. The proxy sends a SYN and does not receive a SYN-ACK within about 19 seconds, having retried at intervals of 1, 1, 1, 1, 1, 2, 4 and 8 seconds. This means packets are being dropped or the port is not accepting connections. Something between the proxy and your server is silently discarding traffic, or nothing is listening.

After the connection is established. The TCP connection opened fine, but the proxy did not receive an acknowledgement of its request within about 90 seconds. This means the server accepted the connection and then failed to respond, which points at an overloaded application, an exhausted worker pool or a request that genuinely takes too long.

The distinction is diagnostically valuable. The first is a network or firewall problem. The second is a capacity or performance problem. They have almost nothing in common except the error code, and treating a capacity problem as a firewall problem wastes a lot of time.

You can usually tell which you have by how it fails: a 522 that appears instantly for every request across the board is the first kind, while one that appears only under load or only on certain slow endpoints is the second.

Cause one: the origin is blocking the proxy

This is the most common cause and the one most likely to appear suddenly on a site that worked yesterday.

Something on the origin is dropping packets from the proxy’s address ranges. Usual suspects: a firewall rule, a security plugin’s automatic blocking, an intrusion prevention system, or a rate limiter that mistook proxy traffic for an attack.

The tell is that packets are dropped rather than rejected. A rejected connection returns immediately and produces a different error; a dropped one produces the 19-second timeout, which is exactly what a default firewall DROP policy does.

Check whether anything has been banned recently:

# Is the port actually listening, and on which address?
sudo ss -tlnp | grep -E ':(80|443)'

# Recent bans from an intrusion prevention system.
sudo fail2ban-client status
sudo iptables -L INPUT -n --line-numbers | head -40

If you firewall your origin to the proxy’s ranges, which you should, confirm your rules match the provider’s current published list. Those lists change, and a rule set written two years ago against a hard-coded list will start dropping traffic from newly added ranges.

Cause two: the origin is overloaded or crashed

The connection opens but nothing comes back within 90 seconds. Something is accepting connections and not serving them.

The usual chain: the application ran out of workers or database connections, requests queue up, response times climb past the timeout, and the proxy gives up. It commonly presents as intermittent 522s under load, escalating to constant.

Check the resource picture on the origin:

# Load, memory pressure and whether anything was killed.
uptime
free -h
dmesg -T | grep -i -E 'out of memory|killed process' | tail

# Established connections and how many are waiting.
ss -s

# Is the application process actually alive?
systemctl status your-app

The out-of-memory check is worth doing early. A process killed by the kernel leaves the port unbound or the application half-dead, and the symptom at the proxy is a 522 with nothing informative in the application log because the application stopped writing to it.

Database connection exhaustion produces this shape too. Every worker is blocked waiting for a connection, so the process is alive and accepting sockets but nothing is being answered. The database connection limits documentation covers the arithmetic for sizing pools against the plan’s ceiling.

Cause three: keepalives, DNS and routing

Three less obvious causes that produce the same code.

Keepalives disabled at the origin. The proxy holds connections open to reuse them. If your origin closes them aggressively or has keepalives disabled, the proxy can attempt to reuse a connection the origin has already discarded, and the request times out. Enable keepalives and set a timeout comfortably above the proxy’s reuse interval.

The DNS record points at the wrong address. Your origin address changed, perhaps after a rebuild or a provider migration, and the proxy is still connecting to the old one. This produces a total, immediate 522 across the whole site and is the first thing to rule out because it takes ten seconds.

# What address is the proxy configured to reach?
# Compare against the server's actual public address.
curl -s https://ifconfig.me

Packet loss on the path. Less common but real, particularly with less well-connected hosting. An MTR from the origin toward a proxy address shows loss and where it starts.

mtr --report --report-cycles 100 <a proxy IP that appears in your logs>

A diagnosis order that finds it quickly

Work outward from the origin, because the fastest checks eliminate the most causes.

1. Is the application up? Check the service status and curl it locally on the origin. If localhost fails, the problem is entirely local and nothing to do with the proxy.
2. Is the port listening on the right address? A service bound only to 127.0.0.1 accepts local connections and refuses everything from outside, which looks identical to a firewall block from the proxy’s perspective.
3. Can you reach the origin from outside? Use a curl with an explicit resolve from a machine elsewhere. If that fails, it is network or firewall.
4. Check the firewall and any auto-banning tool for recent blocks on proxy ranges.
5. Check load, memory and the out-of-memory log for the overload case.
6. Verify the DNS record matches the server’s current address.
7. Only then look at routing with an MTR.

# Step 1 and 2, on the origin itself:
curl -sI http://127.0.0.1:80/ | head -1
sudo ss -tlnp | grep -E ':(80|443)'

# Step 3, from a machine elsewhere:
curl -sv --resolve example.com:443:ORIGIN_IP https://example.com/ 2>&1 | head -20

One structural note: this error exists because there is a network hop between a proxy and an origin you administer. A deployment where the routing is internal to the platform has no such hop to misconfigure, no firewall rules to keep matched against a changing address list, and no keepalive mismatch to diagnose.

How this fits the rest of the stack

Most 522s are a capacity problem wearing a network problem’s clothing, and the fix is usually more headroom or fewer things to keep aligned rather than a cleverer configuration. The RunxBuild hosting calculator is a quick way to see what the next plan up costs, and autoscaling between a floor and a ceiling plan turns the load-driven version of this error into a scaling event rather than an outage.

Useful related references:

• SSL_connect Error 5: What SSL_ERROR_SYSCALL Actually Means
• The 504 Gateway Timeout Error, in Plain English
• Math Domain Error Explained: Meaning and How to Debug
• Database connection limits on RunxBuild

FAQ

What causes a 522 error?

The proxy could not complete a request to your origin in time. Either no connection was established within about 19 seconds, which points at a firewall dropping packets or nothing listening, or the connection opened but no response arrived within about 90 seconds, which points at an overloaded or crashed application.

Is a 522 error my fault or the proxy’s?

Almost always the origin’s. The error means the proxy reached out and your server did not answer in time. Occasional exceptions involve routing problems on the path, but the first place to look is your own firewall, application health and resource usage.

Why does nothing appear in my access log during a 522?

Because no request reached your application. The failure happened at the connection or acknowledgement stage, before your web server logged anything. This is a useful signal: an empty access log during a 522 confirms the problem is below your application rather than inside it.

Can a firewall cause a 522?

Yes, and it is the most common cause. A rule that drops rather than rejects packets from the proxy’s address ranges produces exactly the connection timeout behaviour. Automatic banning tools that mistake proxy traffic for an attack are a frequent culprit, as are firewall rules written against an outdated list of proxy ranges.

How do I fix intermittent 522 errors under load?

Treat it as a capacity problem rather than a network one. Check memory pressure and the out-of-memory log, look at worker and database connection pool exhaustion, and measure response times on your slowest endpoints. Intermittent 522s that correlate with traffic are almost always the 90-second response timeout, not the connection timeout.