Introduction

Once a site sits behind Cloudflare, the origin server no longer sees visitors connecting directly. If the web server is not configured to trust Cloudflare’s forwarded IP headers, logs and security rules will show Cloudflare edge addresses instead of the real client IP. That breaks rate limiting, audit trails, geolocation, and abuse analysis. The fix is to trust the correct proxy layer and make sure only legitimate Cloudflare headers can define the client address.

Symptoms

  • Access logs show Cloudflare IP ranges instead of visitor IP addresses
  • Rate limits or security rules affect many users as if they share one IP
  • Admin audit logs and fraud tools record the wrong remote address
  • Geo-based logic behaves strangely after enabling Cloudflare proxying
  • The issue appeared after moving the site behind Cloudflare or changing origin server config

Common Causes

  • The web server is not configured to trust Cloudflare proxy headers
  • Real IP modules or middleware are enabled but pointed at the wrong header
  • Trusted proxy ranges are missing, outdated, or too broad
  • Multiple reverse proxies rewrite client IP information in unexpected order
  • The application reads the wrong header instead of the normalized client address

Step-by-Step Fix

  1. Confirm the origin logs currently show Cloudflare edge IPs rather than end-user addresses.
  2. Review the web server or proxy configuration for real IP handling and verify it expects the correct forwarded header from Cloudflare.
  3. Limit trusted proxy configuration to Cloudflare’s published proxy ranges rather than trusting arbitrary upstream headers.
  4. If another load balancer or proxy sits in front of the app, map the full proxy chain so client IP restoration happens in the right order.
  5. Check whether the application, framework, or security plugin reads the normalized remote IP or a raw header value directly.
  6. Re-test with a known client request and confirm the access log, application log, and security rules all report the same real address.
  7. Make sure spoofed headers from direct-origin traffic cannot override client IP data if the origin is reachable outside Cloudflare.
  8. Revisit any rate limiting, firewall, or country-based logic that was tuned while the wrong IP data was in use.
  9. Keep trusted proxy settings documented and current so future infrastructure changes do not silently corrupt your logs again.