Cloudflare Error 521: Fix Origin, Firewall & SSL Issues

Cloudflare Error 521: Web Server Is Down means Cloudflare reached the origin network path but the origin refused the connection Cloudflare tried to make.

Cloudflare's current documentation identifies two especially common causes: the origin web server application is offline, or Cloudflare requests are being blocked or rate-limited at the origin.

For most 521 cases, troubleshoot in this order:

1. Record the failing URL, time/timezone and Cloudflare Ray ID.
2. Is the origin web server process running?
3. Is it listening on the port required by the effective SSL/TLS mode?
4. Does the virtual host answer locally on the origin?
5. Are Cloudflare source IP ranges blocked or rate-limited?
6. If direct external-origin testing is allowed, does that path work?
7. Do origin/firewall/system logs show refusals, crashes or resource exhaustion?

Errors 525 and 526 are covered later as related TLS problems, but they are not the same failure as 521.

Last verified: September 26, 2026. Cloudflare error guidance, SSL/TLS behavior and published IP ranges can change; verify production firewall and origin settings against current official Cloudflare documentation.

---

---

1. Cloudflare 521 vs 522 vs 523 vs 502 vs 504

Key distinction: 521 is a refused connection. 522 is a connection timeout. 523 is origin-unreachable. 502/504 usually happen after a web server or proxy is reachable but an upstream application path fails.

---

2. Understand the Cloudflare-to-Origin Connection

When Cloudflare proxying is enabled, the normal request path is:

Visitor
   ↓
Cloudflare Edge
   ↓
Origin Server
   ↓
Web Server / Application

An error can therefore occur even when:

• The Cloudflare edge itself is reachable.
• DNS resolves correctly to Cloudflare.
• The visitor has normal internet access.

The failure may instead be on the connection from Cloudflare to your origin.

---

3. Capture the Error Evidence Before Changing Anything

Before restarting services, editing firewall rules or changing SSL/TLS mode, record enough evidence to correlate the Cloudflare failure with origin logs.

• The exact failing URL.
• Date, time and timezone.
• The visible Cloudflare error code.
• The Cloudflare Ray ID from the error response/page.
• Whether the failure affects every path or only some hostnames/URLs.
• Whether the issue is continuous or intermittent.

A simple request through Cloudflare can expose useful response headers:

curl -sv -o /dev/null https://example.com/ 2>&1 | grep -Ei 'HTTP/|cf-ray|cf-error-type|cf-error-origin|retry-after'

Cloudflare's 2026 error-header documentation says Cloudflare-generated errors can include cf-error-type and cf-error-origin. A 52x value identifies the broad origin-connectivity category; use the actual HTTP status and Ray ID to keep the specific incident anchored.

Cloudflare currently documents a Retry-After value of 120 seconds for retryable 521 responses. That tells automated clients how long to back off; it does not repair the origin refusal.

---

4. What Causes Cloudflare Error 521?

Cloudflare defines Error 521 as a connection refusal from the origin web server. For the current vendor definition and resolution checklist, see Cloudflare's official Error 521 documentation.

The two most common causes are:

• The origin web server application is offline.
• Cloudflare requests are blocked or rate-limited by the origin firewall, security software or hosting layer.

Cloudflare also advises confirming that the origin is actively listening on the port required by the configured SSL/TLS mode: port 80 for Flexible, and port 443 for Full or Full (Strict).

Do not start by assuming that a wrong DNS record, certificate problem, database failure or PHP-FPM issue is itself a 521. Those can produce different symptoms and Cloudflare error codes. Use the refusal evidence to guide the diagnosis, then branch into TLS, DNS or upstream troubleshooting only when the evidence points there.

A. Check Web Server Status

For Nginx:

sudo systemctl status nginx

For Apache on Debian/Ubuntu systems:

sudo systemctl status apache2

On RHEL-family systems the Apache service is commonly named httpd:

sudo systemctl status httpd

For OpenLiteSpeed:

sudo systemctl status lsws

If the service is failed or repeatedly restarting, capture its recent journal/service logs before restarting it. A restart can restore availability while also hiding the timing of the original failure if you never preserve the evidence.

B. Check Listening Ports

sudo ss -lntp | grep -E '(:80|:443)[[:space:]]'

Check which address owns the listener as well as whether the port appears. A service bound only to 127.0.0.1:443, for example, will not accept normal external Cloudflare connections to the server's public interface.

If the expected listener is missing or bound to the wrong interface, inspect the web-server configuration and logs before changing Cloudflare.

---

5. Make Sure Cloudflare IPs Are Not Blocked

Your origin sees proxied visitor traffic arriving from Cloudflare infrastructure rather than directly from every visitor IP.

If a firewall, rate limiter, host security tool, or fail2ban rule blocks Cloudflare addresses, legitimate proxied traffic may be rejected.

Review:

• UFW.
• iptables or nftables.
• CSF.
• Fail2ban.
• Hosting-provider firewalls.
• Security groups.
• Web Application Firewall rules.

Before changing firewall rules, inspect the current policy first. Examples:

sudo ufw status verbose
sudo nft list ruleset
sudo iptables -S

Do not flush or disable the firewall as a first troubleshooting step. That can create a security incident. Identify the blocking rule and update it deliberately.

Also check rate-limit/security layers that can reject Cloudflare even when the base firewall permits it. Examples include Fail2ban jails, CSF/LFD, ModSecurity/WAF rules, hosting-provider DDoS controls and connection/rate limits in the web server itself.

Cloudflare's published IP-range page is the authoritative public list for normal proxied origin connections. Cloudflare also provides an API for retrieving the current IPv4/IPv6 CIDRs. Prefer those live sources over hardcoding a list into an article or long-lived automation.

---

6. Test the Virtual Host Locally on the Origin First

When you have shell access to the origin, first separate web-server/vhost health from the external firewall/network path.

For an HTTPS virtual host on the origin itself:

curl -sv --resolve example.com:443:127.0.0.1 https://example.com/ -o /dev/null

For a Flexible-mode HTTP origin:

curl -sv -H 'Host: example.com' http://127.0.0.1/ -o /dev/null

This tests the listener and hostname routing without depending on the provider firewall or public network path. If HTTPS uses a Cloudflare Origin CA certificate, a generic local trust store may not trust that certificate even though Cloudflare can; distinguish certificate trust from whether the listener/vhost responds.

---

7. Test the External Origin Path Carefully

If your security policy permits your test machine to connect directly to the origin, preserve the hostname and SNI while sending the request to the origin IP:

curl -sv --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null

Replace example.com and 203.0.113.10 with the actual hostname and origin IP.

---

8. Verify the Origin Address After Migrations or IP Changes

Cloudflare must know the correct origin address. A wrong or stale origin address is more directly associated with reachability/routing problems such as 523, but it is still worth checking after migrations or IP changes so you do not troubleshoot the wrong server.

Check the configured A or AAAA records inside Cloudflare DNS and make sure they point to the current server rather than:

• An old VPS.
• A deleted server.
• An incorrect IPv6 address.
• A Cloudflare edge IP.
• A stale migration destination.

Remember that a public DNS lookup of an orange-cloud/proxied hostname normally returns Cloudflare edge addresses, not the origin IP configured in the dashboard. Do not use that public answer alone to conclude which origin Cloudflare is contacting.

Review our DNS Configuration Best Practices guide for A, AAAA, CNAME, TTL, and migration troubleshooting.

---

9. Check IPv4 and IPv6 Origin Paths Separately

If the proxied hostname has both A and AAAA origin records configured, verify that both destinations are intentional and serving the site correctly. A stale or partially configured IPv6 origin can create confusing intermittent behavior when one network path works and the other does not.

Check:

• The A record points to the current IPv4 origin.
• The AAAA record points to a current, reachable IPv6 origin only if the server actually supports that path.
• The web server listens on the intended IPv4/IPv6 interfaces.
• Provider firewalls/security groups cover the protocol family being used.

Do not publish an AAAA origin merely because the server has some IPv6 address; verify routing, listener configuration and firewall policy first.

---

10. Related Error 525: SSL Handshake Failed

Error 525 indicates that Cloudflare reached the origin but could not complete the TLS handshake. Cloudflare documents 525 when the origin handshake fails while the zone is using Full or Full (Strict) SSL/TLS mode.

Possible causes include:

• No usable certificate is installed.
• Port 443, or another configured Cloudflare-supported secure origin port, is unavailable.
• The TLS virtual host is misconfigured.
• SNI handling is incorrect.
• The origin supports incompatible TLS settings.
• The web server terminates the handshake unexpectedly.
• The certificate/key pair is configured incorrectly.

A. Test the Origin TLS Handshake

Use OpenSSL:

openssl s_client -connect 203.0.113.10:443 -servername example.com

This can reveal:

• The certificate presented.
• The certificate chain.
• TLS handshake failures.
• Protocol negotiation.
• Hostname-related configuration problems.

---

11. Cloudflare SSL/TLS Mode Determines the Origin Port and Validation Path

Cloudflare's SSL/TLS encryption mode controls the separate Cloudflare→origin connection. In 2026, Cloudflare is also rolling out Automatic SSL/TLS as the default for eligible/migrated zones; it uses probes to select a safer supported origin mode and does not automatically downgrade to a less secure mode when an origin certificate later breaks.

If your zone uses Custom SSL/TLS, the practical modes relevant to most sites are:

Mode	Cloudflare → Origin	Operational Note
Flexible	HTTP	Origin HTTPS is not used for the proxied connection
Full	Matches the visitor scheme: HTTPS visitor requests use HTTPS to origin	Origin certificate is presented but is not validated like Full (Strict)
Full (Strict)	HTTPS with certificate validation	Use when the origin supports HTTPS on 443 and presents a certificate that satisfies Cloudflare's validation requirements

Enterprise zones can also use Strict (SSL-Only Origin Pull), which always connects to the origin over validated HTTPS.

Avoid switching SSL modes randomly just to make an error page disappear. Check the current/effective mode first, then correct the origin listener/certificate configuration so the intended mode works properly. Cloudflare recommends Full or Full (Strict) where possible.

---

12. Related Error 526: Invalid Origin SSL Certificate

Error 526 occurs when Cloudflare cannot validate the certificate presented by the origin while Full (Strict) is in use. Cloudflare's current guidance includes checking expiration/revocation, hostname coverage, certificate chain completeness, issuer/trust and HTTPS availability on port 443.

Common reasons include:

• The certificate has expired.
• The certificate has been revoked.
• The certificate does not cover the requested hostname.
• The origin sends an incomplete or invalid chain.
• The issuer is not accepted for the configured validation path.
• The wrong certificate is attached to the virtual host.

Check Certificate Dates

You can inspect the certificate presented by the origin:

openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates

---

13. Cloudflare Origin CA vs Public Certificates

If visitors always reach the site through Cloudflare proxying, a Cloudflare Origin CA certificate can be used for the encrypted connection between Cloudflare and the origin.

However, an Origin CA certificate is intended for Cloudflare-to-origin communication. Browsers connecting directly to that origin may not trust it as a normal public web certificate.

A publicly trusted certificate such as one issued through ACME can instead allow both direct browser validation and Cloudflare Full (Strict), depending on your architecture.

Choose the certificate model intentionally rather than mixing them without understanding the trust path.

---

14. Verify Certificate Hostname Coverage

A certificate for:

example.com

does not automatically cover every possible multi-level subdomain.

Verify the Subject Alternative Names on the certificate and make sure the requested hostname is included.

---

15. Check the Certificate Chain

The origin should provide the certificate chain required for validation.

A server configured with only the leaf certificate while omitting necessary intermediate certificates may create validation problems.

For Nginx, make sure the configured certificate file contains the appropriate chain according to your certificate provider's instructions.

For example:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

---

16. Nginx Configuration Checks

For an HTTPS Nginx virtual host, verify:

• The correct hostname appears in server_name.
• The HTTPS listener is configured.
• The correct certificate and private key are loaded.
• The configuration passes syntax validation.

Test configuration:

sudo nginx -t

Then reload only if the test succeeds:

sudo systemctl reload nginx

---

17. Apache and OpenLiteSpeed Checks

For Apache, verify:

• The SSL module is active where required.
• The virtual host is listening on 443.
• The correct certificate files are configured.
• The intended hostname maps to the correct virtual host.

For OpenLiteSpeed or CyberPanel environments, verify:

• The HTTPS listener.
• Virtual-host mapping.
• Certificate and private-key paths.
• Listener-to-domain association.
• Firewall access on 443.

For a broader web-server comparison, see our LiteSpeed vs Nginx vs Apache guide.

---

18. Do Not Use Flexible SSL as a Permanent Fix for Origin HTTPS Problems

Switching to Flexible can sometimes make a site appear reachable because Cloudflare no longer requires HTTPS to the origin.

However, that does not repair:

• A broken origin certificate.
• Incorrect port 443 configuration.
• TLS handshake problems.
• Certificate-chain issues.

It can also create redirect problems when the origin application forces HTTPS without understanding that Cloudflare is using HTTP to the origin.

For a site intended to use encrypted origin connections, fix the origin and use an appropriate Full mode.

---

19. Check for Redirect Loops

SSL-mode changes can produce redirect loops when Cloudflare and the origin disagree about whether a request is already HTTPS.

Check:

• Cloudflare SSL mode.
• WordPress Site URL and Home URL.
• Nginx redirects.
• Apache rewrite rules.
• Application-level HTTPS redirects.
• Reverse-proxy headers.

Do not keep adding redirect rules until the page stops looping. Identify which layer is generating each redirect.

---

20. Check Server Logs

Logs can distinguish between refused connections, TLS errors, application failures and backend problems. Correlate logs with the exact incident timestamp/timezone and Cloudflare Ray ID you recorded earlier.

For Nginx:

sudo tail -f /var/log/nginx/error.log

Also inspect system logs:

sudo journalctl -u nginx --since "30 minutes ago"

Replace the service name when troubleshooting Apache or OpenLiteSpeed.

If the web-server access log contains no request at all for the incident while firewall/security logs show a Cloudflare source IP being rejected, the refusal is likely occurring before the request reaches the HTTP application layer. If the request reaches Nginx/Apache/OpenLiteSpeed and then fails upstream, move to the 502/504 or application diagnostic path instead of continuing to treat it as a pure 521 problem.

---

21. Distinguish Error 521 from 502 and 504

This distinction is especially important for troubleshooting:

• 521: Cloudflare's connection is refused by the origin.
• 502: a reachable gateway or web server receives an invalid response from an upstream service.
• 504: a reachable gateway or web server times out waiting for an upstream service.

If Nginx accepts the request but PHP-FPM, Node.js, an application server or another upstream does not respond correctly, continue with our 502 Bad Gateway and 504 Gateway Timeout guide.

---

22. Origin Resource Exhaustion

A server under severe resource pressure may restart services, refuse new connections, or behave inconsistently. If the server remains reachable but is simply slow, that is a different diagnostic path; use the TTFB guide for server-response latency rather than treating slowness as a 521 by default.

Check:

• CPU usage.
• Available memory.
• Swap activity.
• Disk space.
• Disk I/O.
• Open file limits.
• Connection counts.
• Web-server crashes.
• PHP-FPM worker saturation.

Useful Linux commands include:

free -h
df -h
uptime
top
journalctl -k --since "1 hour ago" | grep -Ei 'oom|out of memory|killed process'

The kernel/OOM command is an example; journal availability and wording vary by distribution. Use resource data to explain a service crash or refusal—do not infer “hosting is too weak” from a single load snapshot.

---

23. Hosting Architecture: When the Server Really Is the Problem

Do not migrate hosts simply because Cloudflare displayed a 5xx error once. A provider migration is justified only when repeated evidence shows the present environment is causing the refusal or cannot provide the control/reliability needed to fix it.

Consider infrastructure changes when measurements show repeated problems such as:

• Insufficient CPU.
• Chronic memory exhaustion.
• Repeated web-server crashes.
• Storage bottlenecks.
• Poor support for required TLS configuration.
• Insufficient control over firewall rules.
• Frequent platform instability.

For the next architectural decision, continue with our Shared vs VPS vs Cloud Hosting comparison.

---

24. Error 521 Troubleshooting Flow

Error 521
   ↓
Capture URL + time/timezone + Ray ID
   ↓
Is nginx/apache/httpd/lsws running?
   ↓
Is the required port listening on the correct interface?
   ↓
Does the hostname/vhost respond locally on the origin?
   ↓
Are Cloudflare IPs blocked or rate-limited?
   ↓
Are A/AAAA origin records correct in Cloudflare DNS?
   ↓
Do logs show refusals, crashes, OOM or restarts?
   ↓
If external direct testing is allowed, does that path work?
   ↓
Only then consider deeper infrastructure changes

Use the DNS guide when the origin address is uncertain, the 502/504 guide when an upstream application is failing, and the hosting architecture guide only when repeated evidence shows the current platform cannot support the workload.

---

Summary: Cloudflare Error 521 Checklist

• 521 means the origin refused Cloudflare's connection.
• Record the failing URL, timestamp/timezone and Cloudflare Ray ID before changing the system.
• Confirm the origin web server application is running.
• Confirm the origin is listening on the port required by the configured SSL/TLS mode.
• Check whether Cloudflare IP ranges are blocked or rate-limited.
• Inspect UFW, nftables/iptables, CSF, Fail2ban, security groups and hosting firewalls.
• Test the virtual host locally on the origin first, then use external direct-origin testing only when the firewall policy permits it.
• Review web-server and system logs for crashes, refusals and restarts.
• Check CPU, memory, disk, OOM events and service stability when 521 recurs.
• Verify A and AAAA origin records in Cloudflare's dashboard; public proxied DNS answers normally show Cloudflare edge IPs instead.
• Use 522/523 diagnostics for timeout or origin-unreachable problems.
• Use the 502/504 guide when the web server is reachable but an upstream application fails.
• Use 525/526 diagnostics when the problem is the Cloudflare-to-origin TLS path.

Frequently Asked Questions

What causes Cloudflare Error 521?

Error 521 means Cloudflare's connection to the origin was refused. Cloudflare identifies an offline origin web server application and blocked Cloudflare requests as the two most common causes. Also confirm the origin is listening on the port required by the configured SSL/TLS mode.

What is the difference between Cloudflare 521 and 522?

Error 521 is a connection refusal. Error 522 means Cloudflare could not establish the TCP connection within the expected time, so the diagnostic emphasis shifts toward timeout, reachability, routing, firewall and origin load.

Should I disable my firewall to test Error 521?

No. Inspect the firewall and security rules and allow Cloudflare's current published IP ranges as appropriate. Disabling the firewall entirely can expose the origin and is not a good first diagnostic step.

What causes Cloudflare Error 525?

Error 525 indicates that the TLS handshake between Cloudflare and the origin failed while the zone uses Full or Full (Strict) SSL/TLS. Check HTTPS availability, the secure origin port, certificate/key configuration, TLS compatibility, SNI and origin web-server logs.

What causes Cloudflare Error 526?

Error 526 occurs when Cloudflare cannot validate the origin certificate while Full (Strict) SSL is being used. Check expiration, revocation, hostname coverage, certificate chain completeness, issuer/trust and HTTPS availability on the origin.

Should I switch from Full (Strict) to Full to fix Error 526?

Switching from Full (Strict) to Full can be used as a temporary diagnostic or workaround because Full does not validate the origin certificate in the same way. The stronger long-term solution is to repair the certificate configuration so Full (Strict) works correctly.

Can a wrong origin IP be confused with Error 521?

Yes during troubleshooting, but Cloudflare documents origin-unreachable routing problems separately, including Error 523. For a true 521, prioritize connection refusal: server status, listening port and security rules blocking Cloudflare.

Are Cloudflare 521 and Nginx 502 the same?

No. A 521 usually means Cloudflare cannot establish the required origin connection. A 502 often means the web server itself is reachable but cannot obtain a valid response from an upstream application such as PHP-FPM.

Can I test the origin with curl --resolve?

Yes, but interpret the result correctly. A local-on-origin --resolve test can verify the listener and virtual host without the external firewall path. An external direct-origin test may be rejected intentionally when the origin only allows Cloudflare source IP ranges.

Why does public DNS show a different IP from my origin?

For a proxied Cloudflare record, public DNS normally returns Cloudflare edge addresses. Verify the configured origin A/AAAA record in the Cloudflare dashboard rather than treating the public proxied answer as the origin address.

What Cloudflare details should I save during a 521 incident?

Save the exact URL, timestamp and timezone, HTTP status, Ray ID and any Cloudflare diagnostic headers. Correlate those details with origin web-server, firewall and system logs before making broad configuration changes.

Does Retry-After: 120 mean Cloudflare will fix the 521 after two minutes?

No. Cloudflare currently marks 521 as retryable with a 120-second client backoff value, but the underlying origin refusal still has to be corrected by the site operator or hosting provider.

Should I remove my AAAA record to fix 521?

Only if the configured IPv6 origin is actually wrong or unsupported. First verify whether the server listens and routes correctly over IPv6. Removing a valid AAAA record without evidence can hide rather than diagnose the real problem.