When Cloudflare Hides the Real Visitor IP in WordPress
Problem: You enabled Cloudflare’s orange-cloud proxy, and now your server logs show Cloudflare IP addresses instead of real visitors. That’s expected behavior. It’s also a common source of broken controls.
When Cloudflare proxies traffic, your origin server sees the Cloudflare edge IP as the client by default. Unless you restore the original visitor IP at the server level, WordPress security logic, WooCommerce fraud checks, rate limiting, and any middleware relying on REMOTE_ADDR operate on the wrong address.
This is not a Cloudflare flaw. It’s an origin configuration issue.
What changes when you enable Cloudflare proxying
When a DNS record is orange-clouded, Cloudflare acts as a reverse proxy. Cloudflare’s documentation explains that the origin will see Cloudflare IP addresses unless you configure restoration of the original visitor IP (Cloudflare Docs – Restoring original visitor IPs).
Cloudflare forwards the real client IP in headers such as CF-Connecting-IP and X-Forwarded-For (Cloudflare Docs – HTTP headers reference). If your server does nothing with those headers, every request appears to originate from Cloudflare.
What that affects in practice:
- Login throttling and security plugins. IP-based limits may treat all traffic as one source or fail to distinguish attackers from legitimate users.
- WooCommerce fraud controls. IP reputation, country checks, and risk scoring can become unreliable.
- Server-level rate limiting and WAF rules. Limits applied to the Cloudflare IP instead of the visitor won’t behave as intended.
- Access logs and investigations. Logs reflect edge IPs, not actual clients, complicating audits and incident review.
- GA4 server-side tagging and Measurement Protocol workflows. Google Analytics processes IP addresses for geolocation but does not expose them in reports (Google Analytics Help – About IP addresses in Analytics). Restoring the real IP at the origin does not change GA4’s anonymization or reporting policies. It does, however, affect any upstream server logic or tagging pipeline that depends on
REMOTE_ADDRfor geo, validation, or routing.
The critical security point: you must not blindly trust X-Forwarded-For or similar headers from all sources. Both Apache and NGINX documentation make clear that real IP restoration must be restricted to explicitly trusted proxy IP ranges.
How to restore the real visitor IP safely
This is a server-level fix, not a WordPress plugin setting.
Apache (mod_remoteip)
Apache’s mod_remoteip module replaces the client IP with the value from a trusted header (Apache HTTP Server – mod_remoteip).
- Enable
mod_remoteip(often via EasyApache in cPanel environments). - Set
RemoteIPHeader CF-Connecting-IP. - Define trusted proxies using
RemoteIPTrustedProxy(orRemoteIPInternalProxy) limited to official Cloudflare IP ranges. - Update your log format to use
%a(the overridden client IP) instead of%h, which reflects the connection address.
If you configure the header but fail to restrict trusted proxies, you create an IP spoofing risk because any upstream source could inject a forged header.
NGINX (ngx_http_realip_module)
NGINX provides real_ip_header and set_real_ip_from directives to restore client IPs behind proxies (NGINX – ngx_http_realip_module).
- Set
real_ip_header CF-Connecting-IP; - Add
set_real_ip_fromentries for Cloudflare IP ranges only. - Enable
real_ip_recursive on;when evaluating forwarded chains through multiple proxies.
As with Apache, the trust boundary is everything. Only trust known Cloudflare IP ranges.
cPanel / WHM environments
cPanel documents specific guidance for restoring visitor IP addresses in reverse proxy setups, including Cloudflare (cPanel & WHM – Restore Visitor IP Addresses). Depending on your stack, this may involve enabling modules, rebuilding Apache, or adjusting NGINX reverse proxy configuration. Some managed hosts already handle this; many self-managed VPS or dedicated servers do not.
What to do next
- Inspect recent access logs. If you see repeated Cloudflare IP ranges instead of diverse client IPs, real IP restoration is likely missing.
- Compare server variables. Temporarily log
$_SERVER['REMOTE_ADDR']and$_SERVER['HTTP_CF_CONNECTING_IP']to confirm the mismatch. - Verify trusted proxy configuration. Confirm Apache or NGINX trusts only official Cloudflare IP ranges, not all upstream sources.
- Retest rate limiting and login controls. Trigger controlled login attempts from different networks and confirm limits apply per visitor.
- Test WooCommerce geo logic. Place test orders from known IP geographies and confirm country detection aligns.
- Review GA4 geo consistency. After remediation, compare server-side tagging outputs and GA4 geographic reporting for alignment, understanding that GA4 does not expose raw IP data.
If your origin sees the wrong IP, your logs, rate limits, and fraud signals are operating on distorted inputs. The fix is straightforward—but only if you treat proxy trust as a security boundary and verify behavior end to end after the change.
Sources
- Cloudflare Docs: Restoring original visitor IPs
- Cloudflare Docs: HTTP headers reference
- Apache HTTP Server Docs: mod_remoteip
- NGINX Docs: ngx_http_realip_module
- cPanel & WHM Docs: Restore Visitor IP Addresses
- Google Analytics Help: About IP addresses in Analytics
Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.
This article is for informational purposes only and reflects general marketing, technology, website, and small-business guidance. Platform features, policies, search behavior, pricing, and security conditions can change. Verify current requirements with the relevant platform, provider, or professional advisor before acting. Nothing in this article should be treated as legal, tax, financial, cybersecurity, or other professional advice.
Editorial note: Splinternet Marketing articles are researched from cited platform, documentation, regulatory, and industry sources. AI may assist with drafting and review; final content is checked for source support, practical usefulness, and platform/date accuracy before publication.