Restoring the real visitor IP from CF-Connecting-IP, only for requests that came through Cloudflare
Why it matters
With Cloudflare proxying the storefront, every request reaches Magento from a Cloudflare address. Without help, Magento records a Cloudflare IP on every order, fraud and velocity checks see one visitor, geo-IP features point at a data centre, and admin IP allowlists cannot be used.
Cloudflare adds the real address in the CF-Connecting-IP header. With Trust CF-Connecting-IP on (the default), the module plugs into Magento’s remote address resolver and returns that header’s value instead of REMOTE_ADDR.
Why the header is only trusted from Cloudflare
Anyone who can reach your origin directly can send a CF-Connecting-IP header with whatever they like. So the module only honours it when the TCP peer, the raw REMOTE_ADDR, is inside Cloudflare’s published IP ranges. A request from any other address keeps REMOTE_ADDR, header or not. IPv4-mapped IPv6 peers are recognised.
The ranges are refreshed daily from Cloudflare (cron at 04:30) and stored in the module’s cache type. A copy ships with the module as a fallback, so the check works before the first cron run and if the fetch ever fails.
Behind a load balancer or proxy
If something sits between Cloudflare and your web server and does not rewrite REMOTE_ADDR, for example an AWS Application Load Balancer or an nginx reverse proxy, the peer Magento sees is that proxy, not Cloudflare, and the header is ignored. Restore the address in the web server first. For nginx:
set_real_ip_from 10.0.0.0/16; # your load balancer or proxy rangereal_ip_header X-Forwarded-For;For Apache, mod_remoteip with RemoteIPInternalProxy does the same. Once REMOTE_ADDR is Cloudflare’s address again, the module takes over and reads CF-Connecting-IP.
Doing this at the web server is worth it anyway: your access logs and anything else on the host get the right IP too.
Checking it
The “Real visitor IP” health check reports which case you are in: the peer was Cloudflare and the header was honoured, the peer was not Cloudflare so the header was ignored, or the header was missing. It only means something when it runs from an admin request that came through Cloudflare; from the CLI it is skipped.
Turning it off
Set Trust CF-Connecting-IP to No if your web server already restores the real IP from CF-Connecting-IP (for example with set_real_ip_from listing Cloudflare’s ranges and real_ip_header CF-Connecting-IP). The two approaches are equivalent; doing it twice is harmless but pointless.