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:
- Go to DNS → Records
- Add an A record:
@(root domain) pointing to your cPanel server IP - Add a second A record:
wwwpointing to the same IP - Set both to Proxied (orange cloud)
- 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):
- Go to SSL/TLS Status
- Check the box next to your domain
- Click Run AutoSSL
Wait a minute, then refresh. The certificate should show as valid.
Step 2: Adjust Cloudflare SSL/TLS mode
In Cloudflare dashboard:
- Navigate to SSL/TLS → Overview
- If your origin has a valid certificate (AutoSSL, Let's Encrypt, commercial), choose Full (Strict)
- 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:
- Cloudflare connects to your origin over HTTP
- Your origin redirects to HTTPS
- Cloudflare repeats the request over HTTP
- 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.orftp.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:
- Go to Caching → Configuration
- 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.
