Skip to content
Back to Blog
Hosting Support10 min read

Cloudflare cPanel Hosting Setup: Troubleshooting Common Errors

Step-by-step diagnosis and fixes for the most common Cloudflare-cPanel integration errors, from DNS misconfigurations and SSL handshake failures to origin server connection issues.

Written by Abdul AbrorTechnical Hosting Support Engineer
Cloudflare cPanel Hosting Setup: Troubleshooting Common Errors
On this page

Integrating Cloudflare with cPanel hosting offers significant benefits—DDoS protection, CDN performance, and flexible SSL options—but the setup process frequently trips up even experienced administrators. When the integration breaks, symptoms range from complete site outages to subtle SSL warnings that erode visitor trust. This guide walks through the most common real-world errors you'll encounter, explains their root causes, and provides the exact steps to resolve them.

Error 1: DNS_PROBE_FINISHED_NXDOMAIN or Site Not Resolving

Symptoms

Visitors see a browser error stating the site can't be found. dig or nslookup queries return NXDOMAIN or no A/AAAA records. The site worked before adding Cloudflare.

Root Cause

Cloudflare's nameservers are active for your domain, but the DNS records in your Cloudflare dashboard don't match your actual hosting environment. This typically happens when:

  • You changed nameservers to Cloudflare but didn't import or manually create DNS records
  • The A or AAAA record points to the wrong IP address
  • You deleted critical DNS records during cleanup

The Fix

Step 1: Verify nameserver delegation

dig NS yourdomain.com +short

You should see Cloudflare nameservers like ava.ns.cloudflare.com and dex.ns.cloudflare.com. If you still see your registrar's or host's nameservers, the delegation hasn't propagated or wasn't completed.

Step 2: Check your origin server IP

Log into cPanel and navigate to the sidebar or dashboard where your primary IP is displayed, or run this from SSH:

curl -4 ifconfig.me

Note this IPv4 address—this is your origin.

Step 3: Add the A record in Cloudflare

In your Cloudflare dashboard:

  1. Go to DNS → Records
  2. Add an A record: @ (root domain) pointing to your cPanel server IP
  3. Add a second A record: www pointing to the same IP
  4. Set both to Proxied (orange cloud)
  5. Click Save

DNS propagation through Cloudflare is near-instant, but browser caches may hold stale records. Test in an incognito window or run:

dig yourdomain.com @1.1.1.1

You should see Cloudflare IPs in the answer section, confirming the proxy is active.

Error 2: Error 521 – Web Server Is Down

Symptoms

Cloudflare displays a branded error page: "Error 521: Web server is down." The origin server may be online and serving content if accessed directly by IP.

Root Cause

Cloudflare successfully resolved DNS and attempted to connect to your origin server, but the connection failed or timed out. Common causes:

  • Firewall rules blocking Cloudflare IP ranges
  • The origin IP in Cloudflare DNS points to a wrong or inactive address
  • Apache or LiteSpeed stopped or crashed on the cPanel server
  • The hosting provider blocks inbound connections on port 80/443 from non-whitelisted sources

The Fix

Step 1: Verify the web server is running

SSH into your cPanel server and check Apache or LiteSpeed status:

systemctl status httpd        # CentOS/RHEL/AlmaLinux
systemctl status apache2      # Ubuntu/Debian
systemctl status lsws          # LiteSpeed

If the service is stopped, start it:

systemctl start httpd

Step 2: Whitelist Cloudflare IPs in your firewall

If you use CSF (ConfigServer Security & Firewall), edit /etc/csf/csf.allow and add:

tcp|in|d=80|s=173.245.48.0/20
tcp|in|d=80|s=103.21.244.0/22
tcp|in|d=80|s=103.22.200.0/22
tcp|in|d=80|s=103.31.4.0/22
tcp|in|d=80|s=141.101.64.0/18
tcp|in|d=80|s=108.162.192.0/18
tcp|in|d=80|s=190.93.240.0/20
tcp|in|d=80|s=188.114.96.0/20
tcp|in|d=80|s=197.234.240.0/22
tcp|in|d=80|s=198.41.128.0/17
tcp|in|d=443|s=173.245.48.0/20
tcp|in|d=443|s=103.21.244.0/22
tcp|in|d=443|s=103.22.200.0/22
tcp|in|d=443|s=103.31.4.0/22
tcp|in|d=443|s=141.101.64.0/18
tcp|in|d=443|s=108.162.192.0/18
tcp|in|d=443|s=190.93.240.0/20
tcp|in|d=443|s=188.114.96.0/20
tcp|in|d=443|s=197.234.240.0/22
tcp|in|d=443|s=198.41.128.0/17

Then restart CSF:

csf -r

Alternatively, many cPanel servers include the cPHulk brute-force protection. Cloudflare's connection attempts can trigger blocks. Whitelist Cloudflare IPs in WHM → cPHulk Brute Force Protection → White List Management.

Step 3: Test direct origin connectivity

Temporarily add a hosts file entry on your local machine to bypass Cloudflare and test the origin directly:

# /etc/hosts or C:\Windows\System32\drivers\etc\hosts
198.51.100.50   yourdomain.com

Replace 198.51.100.50 with your actual origin IP. Visit http://yourdomain.com in a browser. If the site loads, the origin is healthy and the issue is firewall-related.

Error 3: Error 525 – SSL Handshake Failed

Symptoms

Cloudflare returns "Error 525: SSL handshake failed." Visitors cannot load the HTTPS version of your site, even though HTTP may work.

Root Cause

Cloudflare is set to use Full or Full (Strict) SSL mode, which requires an SSL certificate on your origin server. The handshake fails when:

  • No SSL certificate is installed in cPanel for the domain
  • The certificate is expired, self-signed, or has a hostname mismatch
  • Port 443 is blocked by a firewall or not listening
  • The origin server SSL is configured incorrectly

The Fix

Step 1: Verify SSL certificate in cPanel

Log into cPanel → SSL/TLS Status. Look for your domain. If it shows "No certificate detected" or an expired date, you need to install one.

The simplest fix: use AutoSSL (Let's Encrypt or Sectigo):

  1. Go to SSL/TLS Status
  2. Check the box next to your domain
  3. Click Run AutoSSL

Wait a minute, then refresh. The certificate should show as valid.

Step 2: Adjust Cloudflare SSL/TLS mode

In Cloudflare dashboard:

  1. Navigate to SSL/TLS → Overview
  2. If your origin has a valid certificate (AutoSSL, Let's Encrypt, commercial), choose Full (Strict)
  3. If your origin has a self-signed certificate or none, choose Full or Flexible

Full (Strict) is the most secure option and should be your goal. Flexible encrypts traffic between visitors and Cloudflare but leaves the origin connection unencrypted—acceptable as a temporary workaround but not recommended long-term.

Step 3: Confirm port 443 is open

ss -tuln | grep :443

You should see Apache or LiteSpeed listening on port 443. If not, check your virtual host configuration in /etc/apache2/ or /usr/local/apache/conf/ for SSL directives, or consult your LiteSpeed admin panel.

Restart the web server after changes:

systemctl restart httpd

Error 4: Redirect Loop (ERR_TOO_MANY_REDIRECTS)

Symptoms

Browsers display "This page isn't working" or "ERR_TOO_MANY_REDIRECTS." The site worked before enabling Cloudflare or changing SSL settings.

Root Cause

Your origin server is configured to redirect HTTP to HTTPS, but Cloudflare's SSL mode is set to Flexible. The loop occurs because:

  1. Cloudflare connects to your origin over HTTP
  2. Your origin redirects to HTTPS
  3. Cloudflare repeats the request over HTTP
  4. Infinite loop

Alternatively, a misconfigured .htaccess rule or WordPress plugin forces HTTPS in a way that conflicts with Cloudflare's forwarding headers.

The Fix

Step 1: Change Cloudflare SSL mode to Full

In Cloudflare → SSL/TLS → Overview, select Full or Full (Strict). This tells Cloudflare to connect to your origin over HTTPS, matching your origin's redirect behavior.

Step 2: Check .htaccess for redirect rules

In cPanel File Manager, navigate to public_html and edit .htaccess. Look for these common patterns:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This is fine if Cloudflare is set to Full or Full (Strict). If you must use Flexible mode temporarily, modify the condition to respect Cloudflare's X-Forwarded-Proto header:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Step 3: Disable problematic WordPress plugins

If you run WordPress, plugins like Really Simple SSL or Force HTTPS can cause loops. Temporarily rename the plugin folder via FTP or File Manager:

mv wp-content/plugins/really-simple-ssl wp-content/plugins/really-simple-ssl.bak

Test the site. If the loop disappears, reconfigure or replace the plugin.

Error 5: Origin IP Leaked or Direct Access Bypasses Cloudflare

Symptoms

Attackers or bots connect directly to your cPanel server IP, bypassing Cloudflare's DDoS protection and WAF. You notice unusual traffic patterns or attacks hitting the origin.

Root Cause

Your origin IP is publicly discoverable through:

  • Historical DNS records cached or archived before Cloudflare was enabled
  • DNS records for subdomains not proxied (gray cloud)
  • Email headers revealing the server IP
  • Misconfigured DNS records like mail. or ftp. pointing directly

The Fix

Step 1: Restrict origin to accept traffic only from Cloudflare

In CSF firewall, replace your existing rules with an allow-only approach for ports 80 and 443. Edit /etc/csf/csf.conf and set:

TCP_IN = "22,587,465,993,995"
TCP_OUT = "1:65535"

Then create /etc/csf/csf.cloudflare with Cloudflare's IP ranges (update periodically):

173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17

Add a script in /etc/csf/csfpost.sh to apply these rules on firewall start:

#!/bin/bash
for ip in $(cat /etc/csf/csf.cloudflare); do
    iptables -I INPUT -p tcp --dport 80 -s $ip -j ACCEPT
    iptables -I INPUT -p tcp --dport 443 -s $ip -j ACCEPT
done
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

Make it executable and restart CSF:

chmod +x /etc/csf/csfpost.sh
csf -r

Step 2: Proxy all public DNS records

In Cloudflare DNS, review every A and AAAA record. Click the cloud icon to enable proxying (orange cloud) for any record that serves web traffic. Leave mail, FTP, and SSH subdomains unproxied (gray cloud) since they require direct access, but ensure they point to different IPs or accept this risk.

Step 3: Rotate your origin IP if already leaked

If your IP is widely known, contact your hosting provider to request a new dedicated IP. Update the A records in Cloudflare DNS to the new IP, then apply the firewall rules above.

Error 6: Cloudflare Caching Stale or Wrong Content

Symptoms

Visitors see outdated pages, old CSS/JS files, or content meant for a different visitor. Purging cache in cPanel doesn't help.

Root Cause

Cloudflare's edge cache is serving content based on its own cache rules, independent of your origin server's cache. Common triggers:

  • Cloudflare cached a page before you made updates
  • Cache Everything page rule is active without proper exclusions
  • Cookies or query strings aren't properly configured for dynamic content

The Fix

Step 1: Purge Cloudflare cache

In Cloudflare dashboard:

  1. Go to Caching → Configuration
  2. Click Purge Everything

For granular control, use Custom Purge and specify URLs or tags.

Step 2: Configure cache exclusions

Navigate to Rules → Page Rules (or Configuration Rules in newer interfaces). Create a rule:

  • If: URL matches yourdomain.com/wp-admin/*
  • Then: Cache Level = Bypass

Repeat for other dynamic paths like /cart/*, /checkout/*, or /my-account/* on eCommerce sites.

Step 3: Review Cache-Control headers on origin

In your cPanel site's .htaccess or application config, set appropriate headers:

<FilesMatch "\.(jpg|jpeg|png|gif|css|js|woff2)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

<FilesMatch "\.(html|php)$">
  Header set Cache-Control "no-cache, no-store, must-revalidate"
</FilesMatch>

Cloudflare respects these headers unless overridden by page rules.

Conclusion

Cloudflare and cPanel integration is powerful but unforgiving of small configuration mistakes. Most errors stem from DNS mismatches, SSL mode conflicts, or firewall blocks preventing Cloudflare's edge servers from reaching your origin. By systematically diagnosing symptoms—checking DNS resolution, verifying SSL handshakes, reviewing firewall rules, and confirming Cloudflare's cache behavior—you can resolve issues quickly and restore full protection and performance. Regular audits of your DNS records, SSL certificates, and firewall rules will prevent these errors from recurring as your infrastructure evolves.

FAQ

Why does my site still show the old IP after changing nameservers?

DNS propagation can take up to 48 hours, though Cloudflare updates are usually instant. Your local ISP or device may cache the old record. Flush your DNS cache or test from a different network.

Can I use Cloudflare with cPanel AutoSSL?

Yes. AutoSSL validates domain control via HTTP-01 challenge. Ensure the .well-known/acme-challenge/ path is not blocked by Cloudflare page rules or firewall rules.

What happens if I enable Cloudflare's "Always Use HTTPS" with Flexible SSL?

You'll create a redirect loop. Always pair "Always Use HTTPS" with Full or Full (Strict) SSL mode.

How do I restore the real visitor IP in cPanel logs?

Install mod_cloudflare for Apache or configure LiteSpeed to read the CF-Connecting-IP header. In WHM, enable "Trust IP Headers" under Server Configuration → Tweak Settings, though this is typically automatic with cPanel's Cloudflare integration.

Should I keep Rate Limiting enabled in cPanel if I use Cloudflare?

Cloudflare's rate limiting is more effective at the edge. You can disable cPanel's rate limiting (like mod_evasive or cPHulk for web traffic) to reduce resource usage, but keep SSH brute-force protection active.