Wordfence relies on the visitor IP for blocking, rate limiting, login security, live traffic, and audit evidence. Behind CloudFront, a bad detection setting can make every visitor appear to use the proxy address, or it can trust a client-supplied header that an attacker can spoof. Wordfence provides an Amazon CloudFront trusted proxy preset, while CloudFront documents how it appends the actual TCP viewer address to `X-Forwarded-For`.
Use this for WordPress sites behind Amazon CloudFront, an Application Load Balancer, reverse proxy, host cache, or multiple proxy layers, especially before changing Wordfence rate limits or investigating widespread lockouts.
Quick answer
Draw the exact proxy chain, use the Wordfence CloudFront preset or an equally explicit trusted-proxy configuration, and test from controlled IPv4 plus IPv6 clients. Compare CloudFront `c-ip`, the header received at the origin, web server remote address, WordPress-observed value, and Wordfence live traffic. Reject any setup where a direct or client-added `X-Forwarded-For` value becomes the trusted visitor without passing through the known proxy chain.
What to check first
- Record DNS, CloudFront distribution, origin type, load balancer, host proxy, web server, container, WordPress, and Wordfence path, including whether the origin is reachable directly from the internet.
- Export the current Wordfence IP detection and trusted proxy settings before changing them, then preserve recent lockout, rate-limit, login, and live-traffic evidence.
- Send labeled requests from controlled IPv4, IPv6, mobile, corporate VPN, and residential clients and correlate CloudFront request ID, `c-ip`, `X-Forwarded-For`, origin remote address, and Wordfence visitor address.
- Repeat with a deliberately supplied fake `X-Forwarded-For` value, a comma-separated chain, duplicate header where the client permits it, and a direct-origin request that should be denied.
- Test login failures, password reset, XML-RPC if enabled, REST, admin AJAX, checkout, form submission, crawler access, rate limits, temporary blocks, unblock procedure, and emergency rollback.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Map and restrict the proxy chain | Record DNS, CloudFront distribution, origin type, load balancer, host proxy, web server, container, WordPress, and Wordfence path, including whether the origin is reachable directly from the internet. | CloudFront, origin, WordPress, and Wordfence evidence map every labeled request to the expected viewer without exposing secret headers. |
| Export current firewall settings | Export the current Wordfence IP detection and trusted proxy settings before changing them, then preserve recent lockout, rate-limit, login, and live-traffic evidence. | Spoof attempts preserve the untrusted value only as earlier chain data and never use it as the authoritative visitor address. |
| Run controlled IP canaries | Send labeled requests from controlled IPv4, IPv6, mobile, corporate VPN, and residential clients and correlate CloudFront request ID, `c-ip`, `X-Forwarded-For`, origin remote address, and Wordfence visitor address. | Two independent visitors no longer collapse into one proxy address, and one visitor remains consistent across login, REST, form, and checkout requests. |
| Test spoofed and direct-origin paths | Repeat with a deliberately supplied fake `X-Forwarded-For` value, a comma-separated chain, duplicate header where the client permits it, and a direct-origin request that should be denied. | A tested rollback restores the prior Wordfence setting, and the on-call owner can unblock a false positive without disabling the firewall globally. |
Why this usually happens
- CloudFront appends the TCP viewer address to an existing `X-Forwarded-For` chain, so the first or last value is not automatically trustworthy in every architecture.
- An origin that accepts public traffic lets an attacker bypass CloudFront and present headers that were supposed to come from a trusted proxy.
- Another load balancer or host proxy can append a second address and change which chain position represents the actual visitor.
- IPv6 formatting, shared corporate egress, VPN services, health checks, and bots can make a visually plausible sample misleading.
Field notes
- Use correlation IDs and timestamps rather than copying full cookies, authorization headers, or personal request payloads into the audit record.
- Do not tighten rate limits until IP identity is correct. A shared proxy address can turn a normal threshold into a site-wide block.
- Restrict direct origin access with an origin secret, network control, or equivalent architecture so header trust depends on an enforced path.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -D - -o /dev/null \
-H 'X-Forwarded-For: 203.0.113.77' \
https://example.com/ip-audit-canary
# Correlate: CloudFront c-ip, x-forwarded-for,
# origin remote address, WordPress value, Wordfence value.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Map and restrict the proxy chain
- Export current firewall settings
- Run controlled IP canaries
- Test spoofed and direct-origin paths
- Tune limits only after identity passes
Decision rule
Pass when each canary resolves to its real viewer address, a client-supplied fake value cannot replace it, direct origin requests are blocked or clearly untrusted, IPv4 and IPv6 work, and critical user journeys survive rate-limit plus unblock testing.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- CloudFront, origin, WordPress, and Wordfence evidence map every labeled request to the expected viewer without exposing secret headers.
- Spoof attempts preserve the untrusted value only as earlier chain data and never use it as the authoritative visitor address.
- Two independent visitors no longer collapse into one proxy address, and one visitor remains consistent across login, REST, form, and checkout requests.
- A tested rollback restores the prior Wordfence setting, and the on-call owner can unblock a false positive without disabling the firewall globally.
Mistakes to avoid
- Do not change several plugins, cache rules, firewall settings, or integrations before preserving a baseline.
- Do not treat one successful browser test as proof for APIs, background jobs, alternate roles, webhooks, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer records into tickets, screenshots, or long-lived logs.
- Do not close the test until the user-visible result and server-side evidence agree.
Questions teams ask during testing
Should I always select X-Forwarded-For?
No. Wordfence warns that the header should be trusted only behind a known proxy because clients can otherwise spoof it.
Why does CloudFront keep an address I supplied?
CloudFront appends the actual TCP viewer address to an existing chain. Earlier values can remain visible but should not become trusted automatically.
Can I fix widespread lockouts by raising the limit?
First prove visitor identity. Raising a limit can hide a proxy error and weaken protection without correcting the evidence.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, firewall, search visibility, or attribution workflow is at risk. We can preserve evidence, isolate the failing layer, make a narrow corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, audit Wordfence behind CloudFront.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references