How to Put Cloudflare in Front of Shared cPanel Hosting Without Breaking SSL
Putting Cloudflare in front of a shared cPanel website means pointing the domain’s nameservers at Cloudflare, letting Cloudflare proxy traffic to the cPanel server, and setting the correct Cloudflare SSL mode so HTTPS keeps working on both ends of that connection. Get the SSL mode wrong and the most common result is an endless redirect loop or a browser warning the moment Cloudflare goes live. Get it right and the site keeps its existing cPanel certificate while gaining Cloudflare’s caching, DNS, and security layer on top.
Why Put Cloudflare in Front of a Shared cPanel Website?
Cloudflare sits between a visitor’s browser and the cPanel server, caching static content, filtering malicious traffic, and serving DNS from a global network instead of the hosting provider’s own nameservers alone. On shared cPanel hosting specifically, this matters because the underlying server is handling many accounts at once, and offloading traffic to Cloudflare’s edge reduces the load that reaches the origin server for every cached request.
How Cloudflare sits between visitors and the cPanel server
Once a domain’s traffic is proxied through Cloudflare, a visitor’s browser connects to a Cloudflare edge server first, not directly to the cPanel hosting account. Cloudflare then either serves a cached copy of the page or forwards the request to the origin cPanel server and returns the response. This extra hop is invisible to a normal visitor, but it changes almost everything about how DNS, SSL, and even the visitor’s IP address appear from the server’s side.
This is the part that trips people up the first time. The cPanel access log starts showing Cloudflare’s own IP ranges as the source of every request instead of the visitor’s real address, unless the server is configured to restore the original visitor IP from Cloudflare’s forwarded headers. Anyone reviewing traffic logs or an IP based ban list right after turning on Cloudflare needs to account for this shift, or every visitor ends up looking like it came from the same handful of Cloudflare addresses.
What Cloudflare can provide for a shared hosting website
Beyond the well known CDN caching, Cloudflare provides authoritative DNS hosting, a web application firewall, DDoS mitigation, and free SSL certificates for the connection between the visitor and Cloudflare’s edge. For a shared cPanel account, this can noticeably cut bandwidth usage on the hosting plan, since Cloudflare serves cached images, CSS, and JavaScript directly from its own network instead of hitting the origin server every time.
We have watched shared hosting accounts running WordPress sites cut their origin bandwidth by more than half after properly configuring Cloudflare caching rules. That single change also tends to shave real time off page load, since a visitor in another country is often served from a nearby Cloudflare edge location rather than crossing the ocean to reach the actual server.
How Cloudflare proxying changes the normal traffic path
Without Cloudflare, a domain’s DNS points directly at the cPanel server’s IP address, and every visitor connects to that IP. With Cloudflare’s proxy enabled, the domain’s public DNS record points at a Cloudflare IP instead, and the real server IP is hidden from public DNS lookups entirely. Any tool that expects to see the origin server’s IP directly, like some older security scanners or IP based whitelisting on third party services, needs to be updated to account for this.
Hiding the origin IP is actually one of Cloudflare’s more useful side effects for a shared hosting account. A server running dozens of separate cPanel accounts becomes a much less attractive direct target once its IP is no longer sitting in public DNS for every domain on it, since an attacker scanning for a specific site can no longer find the underlying server address through a simple lookup.
What remains managed by the cPanel hosting provider
Cloudflare changes how traffic reaches the server. It does not take over hosting the actual website files, email, databases, or the cPanel account itself. Email delivery in particular usually stays completely separate from Cloudflare’s proxy, since MX records are typically left unproxied and continue routing directly to whatever mail service the domain uses, whether that is standard cPanel email or a filtered service like MailChannels. The cPanel server still needs its own valid SSL certificate, still runs the actual site code, and is still where AutoSSL, backups, and file management happen exactly as before.
Nothing about adding Cloudflare changes who the hosting provider is either. Support tickets about disk space, database errors, or a plugin conflict still go to the same place they always did. Cloudflare only ever touches the path traffic takes to reach the server, not what happens once it gets there.
What Should You Check Before Connecting Cloudflare to cPanel?
Before touching DNS or nameservers, confirm the site already works correctly on the cPanel server, verify the origin SSL certificate is valid, and export a copy of the current DNS records. Skipping this step is the single biggest reason Cloudflare migrations go wrong, since it becomes far harder to tell whether a problem came from Cloudflare or was already present on the server.
Confirming the domain works correctly on the cPanel server
Load the site directly using the server’s IP address or a temporary hosts file entry, bypassing DNS entirely, and confirm it loads correctly over both HTTP and HTTPS. If the site is already broken at the origin, adding Cloudflare on top will not fix it and will only make the actual problem harder to diagnose later.
We have taken support calls for a “Cloudflare broke my site” issue where the site had actually been throwing a database connection error at the origin for two days before Cloudflare was ever added. Testing the origin directly first would have caught that in under a minute instead of an hour spent troubleshooting the wrong layer entirely.
Checking that the origin server has a valid SSL certificate
Most cPanel hosting includes AutoSSL, which issues a free Let’s Encrypt certificate automatically for each domain on the account. Confirm this certificate is active and not expired before adding Cloudflare, since several Cloudflare SSL modes depend entirely on the origin having a working certificate of its own. A missing or expired origin certificate is one of the most common causes of the 525 and 526 errors covered further down.
The SSL/TLS Status page inside cPanel shows the current certificate, its issuer, and its expiry date in one place, and it takes about ten seconds to check. Doing that check now, before anything else changes, means any certificate problem found later can be pinned on Cloudflare’s connection to the origin rather than a pre existing gap that was never Cloudflare’s fault to begin with.
Reviewing existing DNS records before changing nameservers
Log into cPanel’s DNS zone editor or the current DNS provider and record every existing record: the A record for the main domain, any subdomains, MX records for email, and TXT records used for SPF, DKIM, or domain verification. Moving nameservers to Cloudflare without capturing this first risks silently breaking email delivery or a subdomain that nobody remembered was in use.
TXT records are the ones people forget most often, since they rarely get touched after the initial setup and often exist for a third party service like a domain verification for Google Workspace or an SPF record that keeps outbound email from landing in spam. Losing one of those quietly during a nameserver switch does not break the website at all, which is exactly why it tends to go unnoticed until email starts bouncing days later.
Identifying records that should not be proxied
Not every DNS record belongs behind Cloudflare’s proxy. MX records cannot be proxied at all, and certain subdomains, like ones used for direct mail server access, FTP, or cPanel’s own control panel port, generally need to stay in DNS only mode so they connect straight to the origin server without passing through Cloudflare’s edge.
A mail. subdomain and a cpanel. or webmail. subdomain are the two most common ones that need to stay grey clouded. Proxying either of those through Cloudflare tends to break the specific ports those services rely on, since Cloudflare’s proxy only forwards standard web traffic on the ports it is built to handle.
Backing up the existing DNS configuration
Export the full DNS zone file from the current nameserver provider before making any changes. Cloudflare’s own import tool usually captures most existing records automatically, but a manual export provides a fallback to check against if anything looks different after the import, and it is the fastest way to recover quickly if something gets missed.
Keep this export somewhere outside the account being changed, like a local text file or a shared drive, rather than only inside the same cPanel account. If the zone file lived only on the server and something goes wrong with the account itself during the switch, that backup disappears right when it would be needed most.
How Do You Connect Cloudflare to Shared cPanel Hosting?
Connecting Cloudflare to a shared cPanel domain means adding the site to a Cloudflare account, letting Cloudflare scan and import the existing DNS records, updating the domain’s nameservers at the registrar, and then turning on proxying for the records that should go through Cloudflare. The whole process typically takes effect within a few hours once the nameserver change propagates.
Adding the domain to Cloudflare
From the Cloudflare dashboard, adding a site starts with entering the domain name and selecting a plan, with the free plan covering everything a shared cPanel hosting account typically needs. Cloudflare then scans the domain’s current DNS automatically as the very next step.
There is rarely a reason to pick a paid Cloudflare tier for a single shared cPanel site early on. The free plan already includes proxying, the shared SSL certificate, basic DDoS protection, and DNS hosting, and the paid tiers mostly add features aimed at much higher traffic volumes than a typical shared hosting account handles.
Importing and reviewing existing DNS records
Cloudflare’s scan pulls in existing records from the current nameservers, but this scan is not always perfect. Go through the imported list against the manual export from earlier and add anything Cloudflare’s scanner missed, particularly less common record types or subdomains that were only lightly used.
CAA records, if the domain has one specifying which certificate authorities are allowed to issue certificates for it, are a common miss during automatic scans. Missing a CAA record does not usually break the site immediately, but it can cause a confusing certificate issuance failure later when AutoSSL tries to renew and the CAA record no longer permits it.
Updating the domain’s nameservers
Cloudflare provides two nameserver addresses to enter at the domain registrar, replacing whatever nameservers the domain was using before, which is often the cPanel host’s own nameservers. This change has to happen at the registrar, not inside cPanel itself, since nameservers control which DNS provider is authoritative for the domain.
A domain registered somewhere different from where it is hosted, which is common, means logging into a separate registrar account entirely for this step. Confirming which company actually controls the nameservers before starting saves a fair amount of confused searching through the wrong dashboard.
Enabling Cloudflare proxying for web traffic
Once nameservers have propagated, the A record for the main domain and any subdomains that serve web traffic get their proxy status turned on, shown as an orange cloud icon in the Cloudflare dashboard rather than a grey one. MX records and any record meant to bypass Cloudflare stay on the grey, DNS only setting.
It helps to enable proxying one record at a time on a first setup rather than flipping every cloud icon at once. Testing the main domain first, confirming it loads correctly, and only then proxying each subdomain in turn makes it far easier to spot exactly which record caused a problem if one shows up.
Verifying that the website still resolves correctly
After nameserver propagation, which can take anywhere from a few minutes to about 24 hours depending on the registrar and previous DNS record TTLs, confirm the site loads correctly, email is still arriving, and any subdomains still resolve as expected. A quick DNS lookup tool showing a Cloudflare IP address for the proxied records confirms the switch actually took effect.
Send a real test email to and from the domain during this window rather than assuming MX records carried over correctly just because the website loads fine. Email and web traffic resolve through completely separate DNS records, so a website loading perfectly says nothing about whether mail is still routing correctly.
Which Cloudflare SSL Mode Should You Use With cPanel Hosting?
Full (strict) is the SSL mode almost every shared cPanel hosting setup should use, since it encrypts the connection all the way from the visitor’s browser to the origin server and validates that the origin’s certificate is genuine. Flexible SSL, while it might look like the simplest option, causes more redirect loop problems on cPanel hosting than any other single misconfiguration covered in this guide.
How Flexible SSL works and why it can cause problems
Flexible SSL encrypts the connection between the visitor and Cloudflare, but the connection from Cloudflare to the origin cPanel server runs over plain HTTP with no encryption at all. This becomes a serious problem the moment the cPanel server itself is set to force HTTPS, which is common, since the server keeps redirecting Cloudflare’s unencrypted request back to HTTPS, and Cloudflare keeps forwarding it as HTTP again. The result is an infinite redirect loop that shows up in a browser as ERR_TOO_MANY_REDIRECTS.
When Full SSL is appropriate
Full SSL encrypts the entire path, visitor to Cloudflare and Cloudflare to origin, but does not verify that the origin’s certificate is trusted or even matches the domain. This mode works as a step up from Flexible when the origin has some certificate installed but it might be self signed or otherwise not fully valid, though it leaves a gap that Full (strict) closes completely.
On shared cPanel hosting with AutoSSL running, this middle mode rarely needs to exist for more than a few minutes during initial setup, since a genuinely valid certificate is usually already in place. Full mode is more useful as a diagnostic step, confirming the connection works at all, before tightening straight to Full (strict) once that is confirmed.
Why Full (Strict) is generally the preferred setup
Full (strict) requires the origin server to present a valid, trusted certificate that matches the domain, and Cloudflare will refuse the connection if it does not. Since cPanel’s AutoSSL already issues a free, valid Let’s Encrypt certificate for the domain automatically, there is almost never a reason on shared cPanel hosting to use anything less secure than Full (strict).
The one honest exception is a domain still in the process of getting its first AutoSSL certificate issued, which can take a short while after DNS first points at the correct server. Trying to force Full (strict) before that certificate exists just produces a 526 error, so a brief window on Full mode while AutoSSL catches up is a reasonable, temporary step rather than a permanent setting.
How the connection between Cloudflare and the origin is encrypted
With Full or Full (strict) enabled, the request Cloudflare forwards to the cPanel server travels over HTTPS on port 443, using whatever certificate is installed on that cPanel account. This is a completely separate encrypted connection from the one between the visitor and Cloudflare, which is why both ends need their own valid certificate for the whole chain to actually be secure end to end.
It is worth picturing this as two separate locks rather than one long tunnel. A visitor’s browser only ever verifies Cloudflare’s certificate directly, and Cloudflare in turn verifies the cPanel server’s certificate on the visitor’s behalf, which means a browser never actually sees the origin’s certificate at all under Full (strict).
Why the cPanel server still needs a valid SSL certificate
A common misunderstanding is that Cloudflare’s free SSL replaces the need for any certificate on the origin server. It does not. Cloudflare’s certificate only covers the visitor facing connection. Without AutoSSL active and issuing a valid Let’s Encrypt certificate on the cPanel side, Full (strict) mode simply will not connect, and the site will show a 526 error to every visitor instead.
This is the single most common support question we get right after someone enables Cloudflare on a shared cPanel account for the first time. Nine times out of ten the answer is the same. AutoSSL had not finished issuing yet, or the domain’s DNS had not fully propagated when AutoSSL tried to validate it, and running the AutoSSL check again a few minutes later clears it.
How Do You Prevent Cloudflare SSL Redirect Loops and Errors?
Preventing redirect loops means making sure Cloudflare’s SSL mode and cPanel’s own HTTPS redirect rules agree with each other, since a mismatch between the two is the root cause behind almost every redirect loop this setup produces. Full (strict) mode paired with a working origin certificate resolves the vast majority of these cases outright.
Avoiding conflicts between Cloudflare and cPanel HTTPS redirects
cPanel, WordPress plugins, and .htaccess rules can all force HTTP to HTTPS redirects independently of Cloudflare. When Cloudflare is set to Flexible while the origin also forces HTTPS, those two redirect rules fight each other endlessly. Switching Cloudflare to Full or Full (strict) removes this conflict entirely, since the origin then genuinely receives an HTTPS request instead of an HTTP one it immediately tries to redirect.
Leaving a duplicate forced HTTPS rule at both the origin and inside Cloudflare’s own settings is harmless once Full (strict) is active, since the origin request is already HTTPS by the time it arrives. The conflict only exists specifically under Flexible mode, which is one more reason that mode causes more support tickets than any of the others.
Fixing ERR_TOO_MANY_REDIRECTS
This specific browser error almost always traces back to Flexible SSL mode combined with a server side forced HTTPS redirect. The fix is switching the Cloudflare SSL mode to Full (strict), confirming the origin certificate is valid through AutoSSL, and clearing the browser cache before testing again, since browsers sometimes cache the redirect loop itself for a short period.
If the error persists after switching to Full (strict), the next place to check is a caching plugin or a page cache that saved a copy of the broken redirect from before the fix. Purging both the Cloudflare cache and any server side cache clears out a stale redirect that would otherwise keep serving the old broken behavior for a while longer.
Troubleshooting 525 and 526 SSL errors
A 525 error means Cloudflare could not complete an SSL handshake with the origin server at all, usually because no certificate is installed or the server is not listening on port 443 for that domain. A 526 error means a certificate exists but Cloudflare does not trust it, most often because AutoSSL has not run yet, the certificate expired, or the domain on the certificate does not match. Running AutoSSL manually from cPanel and waiting a few minutes resolves the majority of both error types.
A 526 error that persists after a fresh AutoSSL run is worth checking against the CAA record mentioned earlier, since a CAA record that no longer permits Let’s Encrypt will silently block renewal without an obvious error message pointing at the actual cause.
Checking WordPress HTTPS and site URL settings
WordPress stores its site URL and home URL directly in the database, and if either one is still set to the plain HTTP version after Cloudflare is enabled, WordPress itself can generate redirect behavior that looks identical to a Cloudflare SSL issue but has nothing to do with Cloudflare at all. Checking the Settings menu inside WordPress, or the wp_options table directly for a site that will not load its admin area, rules this out quickly.
A WordPress site stuck in a redirect loop even after the Cloudflare SSL mode is correctly set to Full (strict) is almost always this exact issue rather than anything related to Cloudflare. Updating both the siteurl and home values to the HTTPS version, either through the admin dashboard or directly in the database when the admin area itself will not load, clears it.
Identifying mixed content problems after enabling HTTPS
Mixed content happens when a page loads correctly over HTTPS but still calls some images, scripts, or stylesheets over plain HTTP, which most modern browsers block or flag with a warning icon. This is not a Cloudflare specific problem, but it becomes visible for the first time once a site starts enforcing HTTPS through Cloudflare, and the fix is updating any hardcoded HTTP links in the site’s content or theme files to HTTPS instead.
Cloudflare’s own Automatic HTTPS Rewrites setting catches a good share of these automatically by rewriting known HTTP resource links to HTTPS on the fly. It does not catch everything, particularly links buried inside older blog post content added by hand years earlier, so a manual scan through the browser’s developer console is still worth doing on any site with a long publishing history.
How Can You Verify That Cloudflare and cPanel SSL Are Working Correctly?
Verifying the setup means testing the site over HTTPS from a real browser, checking exactly which certificate is being presented, confirming Cloudflare can reach the origin without errors, and then continuing to watch the site for a few days after the change. A setup that works once during testing can still surface an issue days later if DNS caching or a forgotten subdomain was missed earlier.
Testing the website over HTTPS
Load the site directly using its HTTPS address in several different browsers, and also test any subdomains that were proxied. A clean load with the padlock icon showing and no browser warning confirms the basic chain is working end to end.
Testing from a phone on mobile data, not just a desktop browser on the same office network, catches DNS caching issues that a single local test would miss entirely, since a mobile carrier’s DNS resolver often refreshes on a completely different schedule than a home or office connection.
Checking the certificate presented to visitors
Clicking the padlock icon in most browsers shows which certificate is actually being presented. With Cloudflare’s proxy active, visitors see a Cloudflare issued certificate covering the domain, not the origin cPanel certificate directly, since Cloudflare terminates the visitor facing connection at its own edge before forwarding the request onward.
Seeing a certificate issued by anything other than Cloudflare after proxying is enabled is a sign the proxy is not actually active for that record, even if the dashboard appears to show the orange cloud icon turned on. A DNS lookup confirming the record resolves to a Cloudflare IP address is the quickest way to settle that question either way.
Confirming Cloudflare can connect securely to the origin
The SSL/TLS overview screen inside the Cloudflare dashboard reports the current encryption mode and generally flags an obvious origin connection problem if one exists. Beyond that dashboard view, watching for 525 or 526 errors over the following day or two is the most reliable practical confirmation that the Cloudflare to origin leg is actually working under real traffic, not just a single test load.
Cloudflare’s analytics tab also breaks down response status codes over time, and a sudden cluster of 5xx responses right after the switch, even if a manual test looked fine, is worth investigating immediately rather than waiting for a client to report it first.
Testing redirects and canonical HTTPS URLs
Load the plain HTTP version of the domain and confirm it redirects cleanly to HTTPS exactly once, rather than looping or redirecting multiple times before landing on the final URL. Checking that both the www and non www versions of the domain resolve to the same final HTTPS URL is worth doing here too, since a mismatched canonical setup causes duplicate content problems independent of anything Cloudflare related.
A browser’s network inspector tab, available in the developer tools of any modern browser, shows every redirect hop involved in loading a single page. Counting exactly one redirect from HTTP to HTTPS, and nothing beyond that, confirms the setup is clean rather than technically working while quietly wasting an extra round trip on every page load.
Monitoring the website after DNS and SSL changes
DNS and SSL changes do not always show every problem immediately, since caching at the browser, ISP, or Cloudflare level can mask an issue for a day or two before it becomes visible. Keeping an eye on the site’s uptime, checking email delivery specifically, and reviewing Cloudflare’s analytics for a spike in error responses over the following week catches anything that a same day test missed.
Shared cPanel hosting is exactly the kind of environment where Cloudflare’s free plan earns its keep, since it offloads bandwidth and adds a real security layer without requiring anything beyond what AutoSSL already provides on the origin. Every cPanel hosting account we run comes with AutoSSL active by default specifically so a setup like this works cleanly the first time, and CloudFlare CDN is bundled in free with hosting rather than being a paid add on bolted on afterward. We field support tickets about ERR_TOO_MANY_REDIRECTS often enough that walking a client straight to Full (strict) mode has become close to a reflex response for our support team.
Agencies and freelancers managing more than a handful of client sites tend to run into this exact setup repeatedly, and running those sites through reseller hosting or, at real scale, master reseller hosting means every new client account inherits the same AutoSSL and Cloudflare friendly configuration without having to rebuild it by hand each time. It is worth being honest that Cloudflare’s free plan will not add meaningful value to a site that is already extremely low traffic, since there is not much to cache or protect at that scale. Once a client site does outgrow shared hosting entirely, moving it to VPS hosting keeps the same Cloudflare setup intact, since none of this DNS or SSL configuration is tied to the shared plan specifically.
For businesses running an application installed through Softaculous, like WordPress or WooCommerce, the same site URL and mixed content checks covered above apply just as directly, since these platforms are the most common source of hardcoded HTTP links that trip up an otherwise correct Cloudflare setup. If SSL for client domains needs to be managed and resold as its own service rather than relying on AutoSSL alone, our SSL Reseller Program is built for exactly that. And for any agency structuring this as a paid maintenance offering for clients, our reseller features comparison and end user support options are worth a look, since both are designed to sit underneath exactly this kind of managed hosting and security setup.
