Cloudflare cPanel DNS Proxy: Real Visitor IPs

How to move a cPanel-hosted domain behind Cloudflare without breaking mail, SSL or your firewall — which records to proxy, which to leave alone, and how to make Apache, LiteSpeed and CSF see the real client IP instead of Cloudflare's.

Published 29 Sep 2026Updated 3 Oct 2026 5 min read By srvScripts team

Which records to proxy

When you add a domain to Cloudflare it imports the zone from cPanel and turns the orange cloud on for most A records. Go through them:

@ and www (A records to the server IP): proxied. This is the point of Cloudflare.
mail, smtp, imap, pop, webmail, cpanel, whm, ftp: DNS only (grey cloud). Cloudflare’s proxy only carries HTTP(S) on standard ports; a proxied mail record silently breaks IMAP and SMTP for every client, and a proxied cpanel record breaks port 2083 unless you pay for Spectrum.
MX: points to a hostname, usually mail.domain.com. It must resolve to the real IP, so that hostname must be DNS-only. Same for any autodiscover/autoconfig records.
TXT (SPF, DKIM, DMARC): copy across exactly. Check afterwards with dig TXT default._domainkey.domain.com +short.
The server hostname (server.hostingcompany.com) usually lives in a different zone; leave it.

Change the nameservers at the registrar only after the zone in Cloudflare matches dig ANY on the cPanel server. Keep the zone in cPanel as well — the cPanel DNS zone is still what AutoSSL and the local resolver read.

SSL mode: Full (strict), nothing else

Cloudflare → SSL/TLS → Full (strict). “Flexible” serves HTTPS to visitors while fetching your site over plain HTTP, which breaks WordPress redirects (infinite loop) and leaks everything between Cloudflare and your server. Full (strict) needs a valid certificate on the origin, which cPanel’s AutoSSL provides — but AutoSSL’s DCV check has to reach your server through Cloudflare. It does, over HTTP on /.well-known/, as long as you have no page rule forcing HTTPS on that path and no WAF rule blocking it.

If AutoSSL fails after the move, temporarily grey-cloud @, run AutoSSL, then re-enable the proxy; or install a Cloudflare Origin Certificate (SSL/TLS → Origin Server) in cPanel, which is valid for 15 years and never needs DCV.

Turn on Always Use HTTPS and Automatic HTTPS Rewrites in Cloudflare, and remove any .htaccess HTTP→HTTPS redirect that checks %{HTTPS} — behind the proxy that variable is always off and causes a loop. If you need a redirect in .htaccess, test %{HTTP:X-Forwarded-Proto} !https instead.

Real visitor IPs

Behind Cloudflare, Apache sees every request coming from a Cloudflare IP. Your logs are useless, CSF/LFD bans Cloudflare instead of the attacker, and WordPress security plugins block everyone. Fix it at the web server so every layer above gets the real address.

Apache (EasyApache 4): install mod_remoteip and trust Cloudflare’s ranges.

dnf -y install ea-apache24-mod_remoteip
cat > /etc/apache2/conf.d/includes/pre_main_global.conf <<'EOF'
RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxyList /etc/apache2/conf.d/cloudflare-ips.txt
EOF
(curl -s https://www.cloudflare.com/ips-v4; echo; curl -s https://www.cloudflare.com/ips-v6) > /etc/apache2/conf.d/cloudflare-ips.txt
/scripts/rebuildhttpdconf && systemctl restart httpd

Change the log format from %h to %a in WHM → Apache Configuration → Global Configuration → LogFormat if the domlogs still show Cloudflare IPs. Refresh the IP list monthly from cron; Cloudflare adds ranges.

LiteSpeed Enterprise: WHM → LiteSpeed → Configuration → Use Client IP in Header → Trusted IP Only, and add the Cloudflare ranges under Allowed Trusted IPs. No module needed; restart LiteSpeed.

CSF: add the Cloudflare ranges to /etc/csf/csf.ignore so LFD never bans them, and set CC_ALLOW_PORTS or use CSF’s built-in Cloudflare integration (CF_ENABLE = "1" in csf.conf with an API token) so bans are pushed to Cloudflare’s firewall where they actually stop the request.

WordPress: with mod_remoteip done nothing else is required. If you cannot change the server, the official Cloudflare plugin rewrites REMOTE_ADDR from CF-Connecting-IP in PHP only — good enough for comment IPs and Wordfence, not for Apache logs or CSF.

Lock the origin

Once the proxy works, nobody should be able to bypass it by hitting the server IP directly (it is still in old DNS caches, mail headers and Shodan). Allow ports 80/443 only from Cloudflare’s ranges in CSF:

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do csf -a "$ip" "Cloudflare"; done

then remove 80 and 443 from TCP_IN. Keep 2083/2087/993/995/465/587 open — those are the services you left DNS-only on purpose.

Verify

curl -sI https://domain.com | grep -i cf-ray shows the request went through Cloudflare. tail -f /etc/apache2/logs/domlogs/domain.com while you browse should show your own IP, not 172.68.x.x. dig mail.domain.com +short must return the server IP, not a Cloudflare one. And send yourself an email from the domain — if DKIM and SPF still pass in the headers, the zone copy was complete.

Diagram: Behind the Cloudflare proxy the origin sees Cloudflare IPs; mod_remoteip restores the visitor IP from CF-Connecting-IP.

Cloudflare cPanel DNS proxy at a glance

Cloudflare cPanel DNS Proxy summary card: When you add a domain to Cloudflare it imports the zone from cPanel and turns the orange cloud on for most A records. — In short: When you add a domain to Cloudflare it imports the zone from cPanel and turns the orange cloud on for most A records.

Official documentation: Cloudflare developer docs, cPanel & WHM documentation, Linux man pages.