Visitor IP detection is misconfigured

What Wordfence found

Behind a proxy or CDN, the real visitor address arrives in a forwarded header rather than the connection itself. This finding means the configured method does not match the site's real setup.

Why it matters

Get this wrong in one direction and every visitor appears to share the proxy's address, so blocking one attacker blocks everyone and rate limits never trigger correctly. Get it wrong in the other and the address becomes attacker-controlled, letting anyone spoof a header to evade a block or frame another address. Both undermine every IP-based control on the site.

How to fix it

1. 1Establish how the site is actually served: direct, behind Cloudflare, behind a load balancer, or behind a host's own proxy.
2. 2Set Wordfence's IP detection to match, using the option it recommends for that setup.
3. 3Verify by comparing a known visit against the logged address.
4. 4Re-check after any hosting or CDN change — this silently breaks during migrations.

How WPSecureOps treats it

The connector reports this as checkHowGetIPs. WPSecureOps files it under Firewall and bands it by the numeric severity Wordfence assigns, so findings of this kind from every site you manage arrive in one queue rather than one email per site. Titles and descriptions are stripped of HTML and the site's absolute path is replaced before anything leaves the server.