Wordfence sees the same IP for everyone: fix detection behind a proxy

Understand the risk of mistaking a relay address for a visitor

Wordfence displays the same IP address for visitors supposedly coming from different networks. It may be showing a proxy or server address instead of the one forwarded for the client. A block triggered by one request can then affect several people, and logs become difficult to interpret.

A proxy is an intermediary that receives a connection and forwards it to the WordPress server. From the server’s perspective, this intermediary is sometimes the direct peer. The original address may be forwarded in a header, but that header becomes trustworthy only when the chain producing it is controlled.

The desired result is attribution consistent with the networks actually observed, without allowing a visitor to freely choose the address used by security. Adding the proxy address to a list that bypasses every rule does not solve this problem. It may instead give many requests the same privileged access. We will check detection before changing blocking rules.

Compare two genuinely distinct networks

Two browser windows on the same network may share a public address. This is normal behind a home router or corporate gateway. Merely seeing two users under the same IP therefore does not demonstrate misconfiguration.

Prepare two connections with known, different public egress addresses, such as a fixed network and an authorized mobile connection. Compare the same address family where relevant: a device may use IPv6 while an egress record shows only its IPv4. Keep these addresses in a private record.

1. Record each connection’s egress address using the network’s usual trusted method.
2. Open a simple public page on the site from each connection, without submitting a form or payment.
3. Record the time and a recognizable path so you can locate the visits.
4. Then compare the addresses recorded by Wordfence for these two requests.
5. If they are correct or the networks actually share their egress, do not change detection. Instead, look for the reason behind the grouping you interpreted as a fault.

Back up settings and identify the chain

This intervention assumes Wordfence configuration permissions and knowledge of the hosting intermediaries. Record the current method, trusted proxies, and any exceptions. Prepare maintenance access that lets you roll back if incorrect detection blocks the account making the change.

Have the route confirmed: any content delivery service, hosting proxy, web server, and PHP. The product may receive an address already restored by the server or need to use a header itself. Configuring the two layers differently without understanding their roles can create a new error.

Prefer a copy reproducing this chain, but do not conclude from a copy without a proxy that production uses the same method. A backup of settings and, for a server change, the configuration fragment is necessary. Do not copy a complete diagnostics report into a forum: it may reveal paths, internal addresses, and other information unrelated to detection. Recording a few relevant fields is enough to prepare the choice.

Read the addresses detected in Wordfence

In Wordfence > All Options > General Wordfence Options, open How does Wordfence get IPs. Compare Detected IP(s) and Your IP with this setting with the expected address for the current connection. In Wordfence > Tools > Diagnostics, the IP Detection section supplements this record.

The verified plugin is Wordfence Security 9.0.2 by Mark Maunder, requiring at least WordPress 4.7 and PHP 7.0, with testing declared up to WordPress 7.1.4. Labels may be translated, and the environment may enforce a setting. Use the module already present; installing another firewall will not automatically repair address forwarding.

1. Keep the current values before selecting another method.
2. Record the direct PHP address and available headers without inventing missing ones.
3. Compare the address reported for your connection with the expected one.
4. Ask the owner which relays and header are actually trustworthy.
5. If no source contains the correct address, move to server forwarding: randomly choosing another row cannot recreate data that never arrives.

Choose a source matching the architecture

When the server receives visitors directly, or already restores their addresses reliably, the PHP REMOTE_ADDR value may be the correct source. Behind a proxy that leaves its address in this field, this value alone may represent the relay instead of the visitor.

Wordfence also offers methods based on X-Forwarded-For or X-Real-IP. Use them only when the intended intermediary forwards this information correctly. A header freely supplied by the client must not become proof of identity. Automatic mode remains the usual starting point; replace it only when comparison and architecture justify another choice.

Select the confirmed method under How does Wordfence get IPs, then use the screen’s save button, generally Save Changes. Repeat the same short read and record. The expected result is a consistent address for this visitor, then for the second network. A good value in your own session does not yet validate every possible chain. If the change produces an empty, internal, or shared address for the two connections, restore the initial method and continue with trusted relays.

If the route actually passes through Cloudflare, Wordfence also offers CF-Connecting-IP. Choose this source only after confirming that relay and reliable handling of the header through to PHP. If the server has already restored the real address in REMOTE_ADDR, that method may remain correct: layering two corrections without observing their values does not make detection more reliable.

Define trusted proxies without trusting the entire network

An X-Forwarded-For chain may contain several addresses. Processing must distinguish authorized relays from the address selected for the visitor. Do not systematically choose the first or last value merely because it resembles a public address.

On the same screen, the + Edit trusted proxies link allows entry of confirmed addresses or CIDR ranges. A CIDR range describes a set of network addresses. Use current values supplied by the service owner, not documentation examples or a very broad private range chosen for convenience.

1. Obtain the list of only those relays authorized to provide replacement addresses.
2. Keep the previous list, then open + Edit trusted proxies.
3. Enter the confirmed values in Trusted Proxies, or use the preset for the service actually used when available and appropriate.
4. Save and check Your IP with this setting.
5. Compare both networks again. If a relay is missing or the list seems too broad, have the chain corrected before continuing; do not classify all visitors as trusted proxies.

Have the header corrected when missing or rewritten

If the expected address appears in no source received by PHP, the correction must happen before Wordfence. The proxy may not forward the header, overwrite it with its own peer, or pass through a visitor-supplied value. A header’s name does not demonstrate its trusted origin.

Send the owner the known route, time window of both requests, and observed values. They must compare the address received at the first intermediary with the one forwarded to the application server. A controlled chain must define who replaces the information and which peers are authorized to supply it.

Do not add a public PHP file displaying every header. Private tools and targeted service logs are more suitable for this comparison. Do not change DNS to avoid the proxy during diagnosis either: that would change the route and could expose a normally protected origin. After forwarding is corrected, repeat the Wordfence check before changing its settings a second time. The expected result is usable information, not more headers carrying conflicting values.

Restore a trusted address in an identified Nginx server

This advanced procedure concerns the owner of the actual Nginx server, with the realip module available. It does not apply to a mere WordPress account. In the configuration for only the affected domain, the fragment illustrates restoration from X-Forwarded-For; you must replace CIDR_PROXY_VERIFIE with the confirmed authorized source. Repeat the directive only for necessary relays.

With recursive searching, if the initial peer is a declared trusted proxy, Nginx selects the last non-trusted address in the header chain. This does not make an arbitrary address list trustworthy. The configuration producing the header and the origin’s access scope must also be controlled.

1. Back up the active fragment and verify the module and configuration context.
2. Adapt only the domain block with the confirmed addresses and correct header.
3. Check with nginx -t, retaining the service’s usual parameters.
4. Only after success, apply the planned reload, for example nginx -s reload for that management method.
5. Check the resulting PHP value, then Wordfence detection. If the test fails, restore the fragment and its active state using the same check.

set_real_ip_from CIDR_PROXY_VERIFIE;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Correct consequences without bypassing every rule

Once detection is repaired, an earlier block may still target the shared address previously used in error. Examine the relevant events and rules before removing that consequence. Correcting the source does not automatically erase all saved blocks.

Do not put the proxy address in Allowlisted IP addresses that bypass all rules to restore general access. If Wordfence considers visitors to come from that address, this exception may apply to a very large set of requests. A proxy trusted for reading a header and an address allowed to bypass security are two different concepts.

The owner may remove only a bypass exception added for this troubleshooting or lift a block confirmed as a consequence of incorrect attribution. Keep its initial state and the reason for correction. If a legitimate rule continues blocking a visitor at their correct address, handle that rule according to its precise event. Do not relax every threshold or protection to compensate for an attribution issue that must now be verified separately.

Verify detection on actual journeys

Revisit both networks and the same public reads. Compare new events with their expected addresses, then verify an authorized login. A page cache may prevent certain requests from reaching WordPress; a visit missing from the log is not automatically a new address error.

In Wordfence > Tools > Live Traffic, use the relevant filters and time window. If collection mode does not show the necessary public reads, temporarily adapt collection within the prepared scope, then restore the initial setting. Avoid leaving a frequently refreshed view open unnecessarily on limited hosting.

1. Confirm that the two different addresses are distinguished on the observed requests.
2. Check that no relay address has become a general bypass authorization.
3. Check the logged-in flow and public site without deliberately triggering a block.
4. Have the owner verify that an untrusted client cannot freely impose the selected source.
5. Archive redacted results and final settings. Displayed geographic location is insufficient evidence of correct attribution.

Distinguish a shared address from an individual identity

Even with correct configuration, an IP address does not uniquely identify a person. Several users may share the egress of a company, mobile carrier, or private network. Conversely, one device may change address or address family between connections.

If grouping concerns only these cases, do not change trusted proxies to artificially force a different address per user. Examine actual behavior and the limits of IP-based rules. A logged-in account, an event, and a network address provide complementary information without being interchangeable.

After infrastructure changes, check the different intended entry points: main domain, subdomains, or administration access according to the architecture. Network subsites may share server configuration while using different paths. Success on the homepage does not validate a second route through other relays. Keep these differences in the maintenance record to avoid reusing a trust list designed for another domain or a previous provider.

Return to the previous setting if the correction is not established

If a change produces inconsistent addresses, restore the saved initial method and list. If server configuration also changed, have the targeted fragment reverted and checked before reloading. Do not restore an entire old database to undo an address setting.

Then check that maintenance access and the public site remain available. An incorrect initial configuration may retain the symptom, but documenting it is better than accumulating attempts when nobody knows which is active. Prepare the next correction with the owner based on the values actually received.

The useful record contains the target, known intermediaries, expected test addresses, and values observed before and after. Mask unrelated items and keep originals private. Distinguish plugin settings from server settings: restoring one does not necessarily undo the other. Diagnosis must end with an identified, consistent, reproducible configuration, not merely temporary administration access.

Document trust for future changes

Keep the list of intermediaries, their official address source, and the person maintaining these values. A provider may change its network; a list copied once and forgotten can become incomplete. Prepare a check after every migration, proxy addition, or change in header handling.

Keep a simple scenario with two authorized networks and a few recognizable reads. It lets you verify the chain without generating load, scanning the site, or triggering a blocking rule. The check must confirm the address and its trusted source, not merely a visual difference in a table.

No additional plugin is needed for this troubleshooting: the product’s diagnostics and private server tools can locate the discrepancy. If the host manages relays, send it the precise comparison and expected setting without trying to bypass its configuration. A clearly identified trust policy allows useful protections to remain and future events to be understood without treating every visitor as one server.

Separate address evidence from trust evidence

Two criteria must appear in the acceptance test. The first is functional: two distinct egress networks are recorded with their expected addresses. The second concerns provenance: only the authorized proxy chain can supply the information used. Success on the first does not demonstrate the second.

In the private record, note each control’s expected egress address, time, requested path, and finally attributed address. Then ask the operator to confirm which intermediary overwrites the client-supplied header and which peers may transmit a replacement value. This confirmation concerns the effective configuration, not merely the name X-Forwarded-For.

For a Cloudflare site, also check alternative routes known to operations. Origin access bypassing the proxy must be handled according to the intended architecture; it must not be made public to perform the test. A copy without the same relays is insufficient to certify the production result.

If addresses become correct but trust remains undetermined, record “attribution observed, provenance to be confirmed” instead of declaring configuration complete. Keep the previous method and list so the plugin change can be undone if necessary; an Nginx change requires its own controlled rollback. Existing Wordfence tools suffice for the application portion, and no firewall-bypassing allowlist is necessary.