What breaks when IP detection is wrong?

Everything IP-based: rate limiting, brute-force lockouts, country blocking, and manual bans all act on the wrong address. Behind a CDN with wrong detection, every visitor appears to come from the CDN's IPs — so a lockout triggered by one attacker can block the CDN edge, meaning everyone, while the attacker rotates freely.

Which setting is right for my site?

Match it to your topology: behind Cloudflare, use the CF-Connecting-IP header; behind another proxy or load balancer, X-Forwarded-For with the proxy's addresses trusted; no proxy at all, the default REMOTE_ADDR. Wordfence's diagnostic on that settings page shows which header carries your real client address.

Is trusting X-Forwarded-For dangerous?

Only if you trust it from anyone: the header is client-suppliable, so honouring it from arbitrary sources lets an attacker choose their logged IP and dodge bans. It must be honoured only when the request comes from your own proxy's address range — which is exactly what the misconfiguration finding is checking.

Glossary · Firewall

Visitor IP detection is misconfigured

Wordfence type: checkHowGetIPs
Category: Firewall
Severity: Medium

Wordfence is reading visitor IP addresses in a way that does not match how the site is actually served.

Written by G. Schad, Cybersecurity Specialist Published 2026-07-31 · Updated 2026-08-22

The alert usually reads

Your 'How does Wordfence get IPs' setting 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

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

Common questions

What breaks when IP detection is wrong?: Everything IP-based: rate limiting, brute-force lockouts, country blocking, and manual bans all act on the wrong address. Behind a CDN with wrong detection, every visitor appears to come from the CDN's IPs — so a lockout triggered by one attacker can block the CDN edge, meaning everyone, while the attacker rotates freely.
Which setting is right for my site?: Match it to your topology: behind Cloudflare, use the CF-Connecting-IP header; behind another proxy or load balancer, X-Forwarded-For with the proxy's addresses trusted; no proxy at all, the default REMOTE_ADDR. Wordfence's diagnostic on that settings page shows which header carries your real client address.
Is trusting X-Forwarded-For dangerous?: Only if you trust it from anyone: the header is client-suppliable, so honouring it from arbitrary sources lets an attacker choose their logged IP and dodge bans. It must be honoured only when the request comes from your own proxy's address range — which is exactly what the misconfiguration finding is checking.

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.

Primary references

Product behaviour and remediation guidance were checked against these primary sources.