Cloudflare 521, 525 & 526 Errors on cPanel: Fix Guide

A Cloudflare 521, 525 or 526 error usually means something has gone wrong between Cloudflare and the website's origin server. The common mistake is changing Cloudflare's SSL/TLS mode before checking what the origin actually returns. That can hide one problem while creating another, especially when switching to Flexible mode.

Quick answer: Error 521 means the origin refused Cloudflare's connection. Error 525 means the TLS handshake between Cloudflare and the origin failed. Error 526 means Cloudflare couldn't validate the origin's certificate in Full (strict) mode. Test the origin directly with curl --resolve, identify whether the failure involves connectivity or TLS, and fix the underlying problem before changing encryption settings.

For most cPanel websites with a valid public SSL certificate, Full (strict) is the appropriate Cloudflare encryption mode.

What Cloudflare 521, 525 and 526 errors actually mean

When a visitor opens a website protected by Cloudflare, two separate connections are involved.

The first connection goes from the visitor's browser to Cloudflare.

The second connection goes from Cloudflare to the origin server hosting the website.

That second connection is where these errors occur.

The distinction matters because each error requires a different investigation.

Error 521 happens before normal HTTP processing

Cloudflare attempts to establish a connection to the origin, but the origin refuses it.

Common causes include:

• Apache or LiteSpeed isn't running.
• A server-level firewall blocks Cloudflare IP addresses.
• The server isn't listening on the port Cloudflare needs.
• Cloudflare points to an old or incorrect origin IP.

A firewall can cause this even when the website appears to work during a direct test from your computer.

That's because your computer and Cloudflare connect from different IP addresses.

Error 525 means TLS negotiation failed

With SSL/TLS mode set to Full or Full (strict), Cloudflare expects to establish an encrypted connection to the origin.

If the TLS handshake fails, Cloudflare may return 525.

Possible causes include an incorrectly configured HTTPS virtual host, unsupported TLS settings, SNI problems or certificate-related handshake failures.

Important distinction: A connection refused on port 443 does not automatically mean error 525. Depending on how the connection fails, Cloudflare may return 521 or 522 instead.

Also, an expired certificate doesn't necessarily cause 525. The TLS handshake may complete successfully, after which Full (strict) rejects the certificate with error 526.

Error 526 means the certificate failed validation

In Full (strict), Cloudflare checks the origin certificate rather than simply accepting any certificate presented by the server.

A usable origin certificate must be:

• Within its validity dates.
• Issued by a trusted public certificate authority or Cloudflare Origin CA.
• Valid for the requested or configured origin hostname.
• Supported by the necessary certificate chain.

A valid certificate installed for example.com doesn't automatically cover shop.example.com.

The domain must appear in the certificate's Subject Alternative Name list, or match an appropriate wildcard.

Cloudflare documents the requirements in its Full (strict) SSL/TLS guide.

Test the origin directly without Cloudflare

Before changing certificates, firewall rules or SSL settings, determine whether the origin itself works.

The easiest starting point is curl --resolve.

This option connects to a chosen IP address while keeping the original website hostname in the HTTP request and TLS Server Name Indication (SNI).

That means you can test the correct HTTPS website without following its normal Cloudflare-proxied DNS record.

Step 1: Find the correct origin IP

Open cPanel and look for the account's Shared IP Address or Dedicated IP Address.

Then open:

Cloudflare → DNS → Records

Check the relevant A record.

When a DNS record is proxied, Cloudflare's public DNS normally returns Cloudflare IP addresses. The Cloudflare dashboard shows the configured origin address.

The configured origin IP may match the IP shown in cPanel, but don't assume it always will.

Some websites use:

• A separate reverse proxy.
• A hosting load balancer.
• An external CNAME target.
• Multiple origin servers.
• Cloudflare origin routing rules.
• Cloudflare Tunnel.

If your website uses one of these configurations, identify the actual destination before performing a direct-origin test.

Also check IPv6 AAAA records. An outdated IPv6 destination can cause failures that don't appear when testing only the IPv4 address.

Step 2: Test HTTPS directly

On Windows 10 or Windows 11, open PowerShell and run:

curl.exe -v -o NUL --resolve example.com:443:203.0.113.10 https://example.com/

On Linux or macOS, run:

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

Replace:

• example.com with your website hostname.
• 203.0.113.10 with your origin IPv4 address.

The IP address shown above is reserved for documentation. It isn't a real hosting server to test.

The command sends a normal HTTPS GET request to the origin. It discards the response body while displaying connection, TLS and HTTP details.

This is better than using curl -I as the only diagnostic test because some applications handle HEAD requests differently from GET requests.

Step 3: Understand the curl result

A successful HTTP response after valid TLS verification is good evidence that the origin works from your current network.

However, it doesn't prove Cloudflare can reach the same origin.

A firewall could allow your IP while blocking Cloudflare.

Also, HTTP 200 isn't the only valid result. A protected page may return 401, and a missing page may return 404 while the web server and TLS connection are functioning correctly.

Step 4: Check HTTP on port 80

If HTTPS fails, test HTTP separately.

Windows:

curl.exe -v -o NUL --resolve example.com:80:203.0.113.10 http://example.com/

Linux/macOS:

curl -v -o /dev/null --resolve example.com:80:203.0.113.10 http://example.com/

If port 80 works but port 443 fails, investigate the HTTPS listener, certificate installation and server firewall.

If both fail, start with general origin availability and network connectivity.

This test does not modify DNS or website configuration.

For additional examples, see the curl DNS and connection troubleshooting guide.

Step 5: Inspect the certificate with OpenSSL

If OpenSSL is installed, run this command from a Linux or macOS terminal:

openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts </dev/null

It attempts a TLS connection using your hostname as SNI and displays certificate-chain and handshake details.

To print the leaf certificate's identifying information:

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

Inspect:

• subject: information identifying the certificate.
• issuer: certificate authority that issued it.
• notBefore: when the certificate becomes valid.
• notAfter: when it expires.
• subjectAltName: hostnames covered by the certificate.

The second command prints the first certificate received. It doesn't independently prove that the entire chain is trusted.

If OpenSSL cannot read a certificate, investigate the handshake output from the first command instead.

The -servername argument is especially important on shared hosting.

Without SNI, the server may return its default certificate rather than the certificate configured for your website.

The Cloudflare Origin CA exception

Here's a case that catches people out.

Suppose your origin uses a Cloudflare Origin CA certificate.

A direct curl request may report:

SSL certificate problem: self-signed certificate in certificate chain

Or another certificate trust error.

That does not automatically mean Cloudflare Full (strict) will fail.

Cloudflare trusts certificates issued by its own Origin CA for proxied origin connections. Ordinary curl installations typically don't trust that CA by default.

For troubleshooting only, you can repeat the test with -k to see whether the origin can serve an HTTPS response without curl enforcing certificate validation:

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

Never use a successful -k test as proof that the certificate is valid.

The -k option disables certificate verification. It is useful for isolating connection problems, not for confirming security.

Fix Cloudflare error 521 on cPanel

A 521 usually points to origin availability or connection rejection.

Work through the checks in order.

1. Confirm the origin is running

Start with the direct curl test.

If the connection is refused, check:

• Whether the hosting account is active.
• Whether Apache or LiteSpeed is running.
• Whether the correct port is listening.
• Whether the server has reached resource limits.
• Whether a network firewall is rejecting connections.

On shared hosting, you usually cannot restart Apache or inspect system-level firewall rules.

Open:

cPanel → Metrics → Errors

Look for relevant web server errors.

Be aware that this interface doesn't necessarily display every server-level network or TLS failure.

If the origin is unavailable, send your hosting provider the exact error time and hostname.

2. Check Cloudflare DNS

A common problem after migrating hosting is leaving an old origin IP in Cloudflare DNS.

Compare the Cloudflare DNS configuration with the actual origin destination.

Check both A and AAAA records, if present.

If the website uses a CNAME or load balancer, inspect that target instead.

Don't replace DNS records simply because the value differs from cPanel's Shared IP Address. First confirm the server architecture.

Incorrect DNS can produce several connection errors, not just 521.

3. Ask your host to check Cloudflare IP blocking

Cloudflare sends origin requests from its own IP ranges.

If CSF, Imunify360, a hosting firewall or another network security service blocks those IPs, visitors may see 521.

This can happen after a traffic spike or an overly aggressive security rule.

Ask your hosting provider to:

• Check whether Cloudflare source IPs were rejected during the error.
• Verify that the current Cloudflare IP ranges are permitted through the relevant firewall.
• Inspect connection limits and rate-limiting rules.
• Confirm Apache or LiteSpeed is listening on the required port.

Cloudflare maintains the current network ranges at:

https://www.cloudflare.com/ips/

Use the official current list, not an old IP list copied from a forum.

One distinction matters here.

An Apache .htaccess rule that denies an HTTP request normally produces a response such as 403. It isn't the same as a firewall rejecting a TCP connection.

So if the browser shows 521, start with server-level connection handling rather than randomly deleting .htaccess rules.

For related Apache configuration, see the security headers and .htaccess guide.

4. Check the required origin port

With Full or Full (strict), the normal origin HTTPS port is 443.

With Flexible, Cloudflare normally connects to the origin over HTTP.

If Apache is only accepting HTTP connections but Cloudflare requires HTTPS, the origin connection can fail.

On shared hosting, ask your provider to confirm port availability and listener configuration rather than trying to change system firewall settings yourself.

Verification: The origin should respond consistently when tested directly, and requests coming through Cloudflare should no longer produce 521.

If direct access works but Cloudflare still fails, provide your host with the Cloudflare error timestamp and Ray ID so they can investigate the Cloudflare-to-origin connection.

Fix Cloudflare error 525 on cPanel

Error 525 means Cloudflare couldn't complete a TLS handshake with the origin.

Changing the certificate alone won't fix every 525.

The problem may involve the HTTPS listener, SNI or TLS negotiation settings.

1. Check whether the origin has an SSL certificate

Open cPanel.

Depending on the cPanel version and hosting configuration, the interface may be:

Security → SSL/TLS Status

Or the newer unified interface:

Security → SSL/TLS Certificates → Status

The unified interface is used in newer cPanel releases and combines certificate status, installation and other SSL management features.

Find your domain and check:

• Whether a certificate is installed.
• Whether it is active.
• Whether the certificate covers the hostname.
• Whether it is expired or approaching expiration.
• Whether AutoSSL reports a problem.

Do the same for www.example.com if the website uses that hostname.

2. Run AutoSSL when available

If your provider supports AutoSSL and the domain is eligible, use the available AutoSSL control to request or renew a certificate.

Depending on your provider's configuration, the control may appear in the standalone SSL/TLS Status interface or another part of the unified certificate workflow.

Some hosts hide manual AutoSSL actions.

If you don't see a Run AutoSSL button, that doesn't necessarily mean AutoSSL is broken.

Ask the provider whether AutoSSL is enabled for your domain.

After issuance, rerun the direct HTTPS test.

If issuance fails, inspect the domain validation error.

Common problems include:

• Incorrect DNS records.
• Domain validation requests blocked by security rules.
• Redirects interfering with HTTP validation.
• Restrictions on certificate issuance.
• Incorrect or restrictive CAA records.
• Domains excluded from AutoSSL.

The cPanel AutoSSL DCV troubleshooting guide explains these cases in more detail.

3. Confirm the HTTPS listener works

A certificate stored in cPanel doesn't prove that Apache is serving it correctly.

The HTTPS virtual host must be configured and available.

Use the direct curl test to confirm that the server presents a certificate and completes TLS negotiation.

If HTTP works but HTTPS doesn't, send your hosting provider the exact results.

On shared hosting, an HTTPS listener problem may require an administrator to repair the virtual host configuration.

4. Check SNI and TLS compatibility

If a certificate is installed and the port is open, the next suspects are:

• Incorrect SNI handling.
• Unsupported TLS protocol versions.
• No compatible cipher suite.
• Server-side TLS errors.
• Security software interrupting handshakes.

Use the OpenSSL test from the earlier section to inspect what the server presents for the requested hostname.

If a valid certificate is returned in your tests but 525 continues, ask the host to compare TLS-related errors in the server logs with the times Cloudflare reported failures.

This is particularly useful when 525 appears only occasionally.

Intermittent TLS failures may involve specific backend servers or temporary server resource problems.

Don't assume a successful test from your laptop rules those possibilities out.

Should you switch to Flexible to remove 525?

Not as a normal fix.

Flexible causes Cloudflare to connect to the origin using unencrypted HTTP.

That may hide an HTTPS handshake problem, but it doesn't repair the origin's TLS configuration.

It can also create redirect loops when the origin forces HTTPS.

Keep the objective clear: repair origin HTTPS and use Full (strict) when certificate validation succeeds.

Fix Cloudflare error 526 in Full (strict)

Error 526 is narrower than 525.

Cloudflare can reach the HTTPS origin, but it doesn't accept the certificate presented by the server.

1. Identify why certificate validation fails

Use the curl and OpenSSL results to guide the investigation.

Don't rely only on the certificate's subject field to determine hostname coverage.

Modern certificates generally identify valid hostnames in the Subject Alternative Name extension.

Also, a matching issuer and subject can indicate a self-issued certificate, but those two fields alone aren't a complete trust-validation test.

2. Option A: Fix or renew AutoSSL

For a normal cPanel website, a valid publicly trusted AutoSSL certificate is usually the simplest option.

Check whether the hostname is included in AutoSSL coverage.

If renewal failed, fix the domain control validation problem first.

Then rerun AutoSSL or ask your hosting provider to do so.

Once issued, test the origin certificate again.

If you have a public certificate that is valid, trusted and correctly installed, Cloudflare doesn't require an additional Origin CA certificate.

3. Option B: Install a Cloudflare Origin CA certificate

Cloudflare Origin CA certificates are designed for encrypted connections between Cloudflare and the origin server.

They work with Full (strict), but ordinary browsers don't normally trust them.

Use one when the site is expected to receive traffic through Cloudflare and your hosting configuration permits the installation.

In Cloudflare:

SSL/TLS → Origin Server → Create Certificate

Choose the certificate's hostnames and validity period.

For a typical domain, the certificate may cover:

example.com
*.example.com

The wildcard covers first-level subdomains, but not every deeper subdomain.

For example, *.example.com doesn't automatically cover app.dev.example.com.

After generation, Cloudflare provides the signed certificate and private key.

Store the private key securely. Never place it in a publicly accessible website directory, commit it to a repository, or send it in an ordinary support email.

In cPanel, open the certificate installation interface.

Depending on your version, this may be:

Security → SSL/TLS → Manage SSL Sites

Or:

Security → SSL/TLS Certificates → Installation

Install the certificate and its matching private key.

Some server configurations also require the appropriate CA chain.

Cloudflare provides installation instructions at:

https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/

Important: Cloudflare Origin CA certificates should not be used for a hostname that visitors need to access directly through a DNS-only record.

If Cloudflare is paused or proxying is disabled, browsers connecting directly to the origin may report an untrusted certificate.

If the site must support direct public HTTPS access, use a publicly trusted certificate instead.

4. Can switching to Full temporarily remove error 526?

Yes, in some cases.

Cloudflare documents switching from Full (strict) to Full as a possible temporary workaround for certificate-validation failures.

In Full mode, the Cloudflare-to-origin connection remains encrypted, but Cloudflare doesn't validate the origin certificate in the same way.

That removes an important protection against origin impersonation.

If service restoration requires this temporary downgrade, document the change, repair the certificate promptly, and restore Full (strict) as soon as validation succeeds.

Don't leave Full enabled indefinitely because the certificate problem has disappeared from the browser.

And don't switch to Flexible simply to avoid certificate management.

Prevent redirect loops and verify the repair

After repairing 521, 525 or 526, check that the website is genuinely working through Cloudflare.

A successful direct-origin test is only part of the verification.

Why Flexible mode causes ERR_TOO_MANY_REDIRECTS

Suppose the visitor requests:

https://example.com

Cloudflare is set to Flexible.

It connects to the origin using:

http://example.com

The origin has an HTTPS redirect rule and responds:

301 Location: https://example.com

The browser follows the redirect.

Cloudflare again requests the origin over HTTP.

The origin redirects again.

The cycle repeats until the browser stops with:

ERR_TOO_MANY_REDIRECTS

The preferred fix is to configure a valid HTTPS origin and use Full (strict).

Don't remove HTTPS protection from your entire application just to accommodate Flexible mode.

If your site uses Laravel, WordPress or reverse-proxy-aware redirects, also verify that the application correctly interprets the original request scheme.

Incorrect trusted-proxy configuration can cause redirects even when the TLS mode itself is appropriate.

For Apache-based configurations, the HeadsNTail .htaccess generator can help create HTTPS redirect rules. Review the generated rules before installing them.

Verify the site from the origin and through Cloudflare

First, repeat your direct-origin HTTPS test.

Windows:

curl.exe -v -o NUL --resolve example.com:443:203.0.113.10 https://example.com/

Linux/macOS:

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

For a publicly trusted certificate, you want TLS validation to succeed and the origin to return the expected HTTP response.

If the origin uses Cloudflare Origin CA, remember that ordinary curl may not trust its certificate even when Cloudflare Full (strict) accepts it.

Next, test the public Cloudflare route.

Windows:

curl.exe -v -o NUL https://example.com/

Linux/macOS:

curl -v -o /dev/null https://example.com/

This second request follows normal DNS resolution and should reach Cloudflare when the domain is proxied.

Check that:

• The expected page or redirect is returned.
• No Cloudflare 521, 525 or 526 appears.
• HTTPS works for both the root domain and www if both are used.
• Login pages, forms and application routes still work.
• Redirects don't loop.
• Cloudflare's SSL/TLS configuration uses Full (strict) after certificate repair.

For intermittent problems, test more than once and compare timestamps.

If only some requests fail, investigate multiple origins, different backend certificates, IPv4 versus IPv6 routing and traffic-dependent server failures.

A single HTTP 200 response doesn't prove that every origin behind a load balancer is healthy.

Don't forget SSL renewal

Once the site works, inspect the certificate's expiration date.

For a public AutoSSL certificate, confirm that renewal is functioning and that the domain isn't excluded from AutoSSL coverage.

For Cloudflare Origin CA certificates, maintain your own expiration tracking. Cloudflare documentation notes that it doesn't currently send expiration notifications for these certificates.

An SSL problem discovered before expiry is easier to resolve than a production outage caused by a failed renewal.

For wider hosting checks, including backups, access controls and PHP configuration, use the cPanel website security checklist.

If you're seeing Cloudflare challenges interfere with a Laravel application rather than a connection-level error, see Cloudflare JS challenge breaking a Laravel SPA.

FAQ

What is the difference between Cloudflare error 521 and 522?

Error 521 generally means the origin refused Cloudflare's connection. Error 522 means Cloudflare timed out while attempting to establish a connection or while waiting for the origin's acknowledgment. Both involve origin connectivity, but they don't describe identical failures. Check the server's listener, firewall, network path and availability.

Why does Cloudflare show error 525 when my SSL certificate is valid?

A valid certificate doesn't guarantee a successful TLS handshake. The origin may have SNI, protocol, cipher or HTTPS virtual host configuration problems. Intermittent failures can also happen when only one backend server is misconfigured. Compare origin TLS logs with the exact times Cloudflare returned 525.

Can I fix Cloudflare error 526 without buying an SSL certificate?

Usually, yes. If your hosting provider supports AutoSSL, you can use an eligible publicly trusted certificate at no additional certificate cost. Cloudflare Origin CA certificates are another option when the origin only needs to serve proxied traffic. The certificate must still be installed correctly and match the requested hostname.

Should I use Flexible, Full or Full (strict) on cPanel?

Use Full (strict) when your origin supports HTTPS and presents a certificate that Cloudflare trusts. Full encrypts traffic but does not perform the same origin certificate validation. Flexible uses unencrypted HTTP between Cloudflare and the origin and can cause redirect loops. If Full (strict) fails, diagnose the origin rather than permanently weakening the encryption mode.

Next step: Before changing Cloudflare settings, run the direct-origin curl test and record the exact error. That result tells you whether to investigate the server connection, TLS handshake or certificate validation.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.