WPLocation reads the address the origin server presents as the client IP. On a site behind a CDN or reverse proxy, that may be the proxy address rather than the visitor address. Free does not automatically trust arbitrary forwarded headers because a direct client can forge them when the origin is reachable.
Confirm the problem first
- Check the database in WPLocation → Diagnostics with a known public IP address. This isolates the local country file from request routing.
- Compare the country result of a real public request with the country expected for the visitor’s network.
- Review the CDN or reverse proxy’s documented origin headers and verify that direct access to the origin is restricted or handled separately.
Use the integration point only with a verified source
The PHP filter wplocation_verified_client_ip receives the default client address and may return a replacement. A site-specific integration should use the proxy provider’s documented and authenticated forwarding mechanism, validate the result as an IP address, and return the original address if verification fails. Never blindly return the first value in X-Forwarded-For.
Deploy and test such code on staging with both direct-origin and proxied requests. Your hosting team may already set a trustworthy REMOTE_ADDR from the edge, in which case no filter is needed. This is a developer/hosting configuration, not a WPLocation Settings toggle.
Retest cache behavior
Correct IP detection alone does not fix a shared cache. A CDN can still reuse saved country-specific HTML. Follow Page cache and CDN safety and test allowed, denied and unknown results at the public URL.
Contact WPLocation with your software versions and the result you expected. Keep keys and customer data private.