Wordfence scan troubleshooting can involve self-requests from the server back to the site. When DNS advertises IPv6 but the host, firewall, CDN, or origin route cannot complete that path, a scan may fail while browser traffic looks normal. Forcing IPv4 can restore the scan, but a permanent setting across every site hides the infrastructure problem and can become stale after a host or network change. A fleet review records where the exception exists, why it exists, what evidence supports it, and when to retest the normal route.
Use this for agencies and hosting teams when some Wordfence scans require IPv4-only mode, when migrated sites inherited old settings, or when IPv6, loopback, DNS, and Cloudflare behavior differs across a managed fleet.
Quick answer
Export the Wordfence scan connection settings for each site and identify every IPv4-only exception. From the origin, resolve A and AAAA records, test HTTPS over both address families, inspect TLS name and chain, compare edge and origin logs, and run a controlled scan stage. Keep IPv4-only only where the IPv6 path is proven broken and cannot be repaired immediately. Add an owner, reason, evidence link, review date, and rollback test so the exception does not silently become policy.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| A only | Valid IPv4 route | Normal scan passes |
| A plus AAAA | Both routes healthy | No exception needed |
| Broken AAAA | IPv6 timeout, IPv4 passes | Temporary IPv4 exception |
| CDN to origin mismatch | Edge works, origin loopback fails | Repair origin route |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Inventory every fleet exception | Inventory site, host, CDN, DNS A and AAAA records, Wordfence version, scan connection mode, last successful scan, failure stage, and exception owner. | Every IPv4-only site has current failure evidence, owner, and expiry date. |
| Prove the failing address family | Run origin-side DNS, IPv4, IPv6, TLS, SNI, redirect, authentication, loopback, and firewall checks against the canonical hostname. | Origin-side A, AAAA, TLS, loopback, and firewall checks are stored with UTC timestamps. |
| Repair DNS, route, TLS, or firewall ownership | Compare a failed normal scan with an IPv4-only canary using the same site, version, stage, time window, and resource limits. | The canary completes every Wordfence scan stage without a new resource failure. |
| Run one controlled scan canary | Repair stale AAAA records, firewall routes, proxy rules, TLS bindings, or host networking when they are owned and safely changeable. | Repaired sites pass a scheduled scan after the exception is removed. |
What to check first
- Inventory site, host, CDN, DNS A and AAAA records, Wordfence version, scan connection mode, last successful scan, failure stage, and exception owner.
- Run origin-side DNS, IPv4, IPv6, TLS, SNI, redirect, authentication, loopback, and firewall checks against the canonical hostname.
- Compare a failed normal scan with an IPv4-only canary using the same site, version, stage, time window, and resource limits.
- Repair stale AAAA records, firewall routes, proxy rules, TLS bindings, or host networking when they are owned and safely changeable.
- Retest the normal setting after infrastructure repair and remove the exception only after a full scheduled scan passes.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -I --max-time 15 https://example.com/
curl -6 -sS -I --max-time 15 https://example.com/
# Compare Wordfence diagnostics and scan logs for the same UTC test.
Why this usually happens
- DNS retains an AAAA record after a migration to a host without working IPv6.
- The server can resolve the site to IPv6 but its firewall or route cannot return to the public hostname.
- TLS or virtual-host configuration differs between address families.
- A copied fleet configuration preserves IPv4-only long after the original incident is gone.
Decision rule
Keep IPv4-only only when a same-fixture comparison proves IPv6 is the failing path and the exception has a named owner and review date.
Production verification checklist
- Every IPv4-only site has current failure evidence, owner, and expiry date.
- Origin-side A, AAAA, TLS, loopback, and firewall checks are stored with UTC timestamps.
- The canary completes every Wordfence scan stage without a new resource failure.
- Repaired sites pass a scheduled scan after the exception is removed.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Inventory every fleet exception
- Prove the failing address family
- Repair DNS, route, TLS, or firewall ownership
- Run one controlled scan canary
- Expire the exception after a normal scan
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP audit Wordfence scan exceptions across the fleet.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references