Wordfence documents that Cloudflare and other services can publish IPv6 for a hostname even when the origin host cannot make outbound IPv6 connections. Because scans progress through repeated self-requests, the scan may time out or fail intermittently while normal visitor traffic works. The diagnostic separates public DNS, origin networking, PHP cURL behavior, WordPress loopback, WP-Cron, Wordfence settings, and WAF responses.
Use this when a Wordfence scan starts but does not finish, diagnostics show an IPv6 callback failure, Cloudflare fronts the site, or enabling Use only IPv4 to start scans changes the result.
Quick answer
Record A and AAAA answers from outside and from the origin, then test the same HTTPS hostname over IPv4 and IPv6 from the server. Review Wordfence Diagnostics and the scan log for callback failures. If IPv6 is published but the host cannot route it outbound, enable Wordfence's Use only IPv4 to start scans and rerun the same canary. Keep the setting only when the evidence matches, and separately fix cron, TLS, WAF, or loopback problems if IPv4 also fails.
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 |
|---|
| IPv4 | Origin to public hostname | TLS and callback pass |
| IPv6 | Origin to public hostname | Route result recorded |
| Wordfence | Default then IPv4 mode | Stage delta explains failure |
| Cron | Next scheduled scan | Automatic run completes |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Map DNS and origin routes | Capture public and origin A and AAAA answers, CDN proxy state, origin addresses, TLS hostname, PHP, cURL, WordPress, and Wordfence versions. | The origin route difference is captured with A, AAAA, TLS, status, and timing evidence. |
| Compare IPv4 and IPv6 callbacks | Run read-only IPv4 and IPv6 HTTPS requests from the origin to the public hostname and record DNS, connect, TLS, status, redirect, and timing evidence. | The Wordfence canary completes or advances consistently under the chosen route. |
| Join Wordfence and hosting logs | Review Wordfence Diagnostics, scan log, WordPress Site Health loopback, WP-Cron, WAF, and hosting logs for the same UTC request window. | WP-Cron and the next scheduled scan complete without manual intervention. |
| Canary the IPv4-only scan option | Enable Use only IPv4 to start scans only for the controlled canary, repeat the scan, and compare stage progression and callbacks. | The workaround and long-term network owner are documented. |
What to check first
- Capture public and origin A and AAAA answers, CDN proxy state, origin addresses, TLS hostname, PHP, cURL, WordPress, and Wordfence versions.
- Run read-only IPv4 and IPv6 HTTPS requests from the origin to the public hostname and record DNS, connect, TLS, status, redirect, and timing evidence.
- Review Wordfence Diagnostics, scan log, WordPress Site Health loopback, WP-Cron, WAF, and hosting logs for the same UTC request window.
- Enable Use only IPv4 to start scans only for the controlled canary, repeat the scan, and compare stage progression and callbacks.
- Confirm scheduled scans, cron, retries, alerts, and public traffic remain healthy before documenting IPv4 mode as the chosen workaround.
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/
wp cron test
Why this usually happens
- A CDN publishes AAAA records while the origin host lacks outbound IPv6 routing.
- The public browser reaches the CDN normally, hiding the origin's self-request failure.
- A WAF or TLS redirect treats the origin callback differently from a visitor request.
- WP-Cron or scan retries fail independently and are incorrectly blamed on IPv6.
Decision rule
Keep IPv4-only scan startup only when the origin IPv6 callback fails and the same IPv4 path completes. If both fail, continue with TLS, WAF, DNS, loopback, cron, or hosting diagnosis.
Production verification checklist
- The origin route difference is captured with A, AAAA, TLS, status, and timing evidence.
- The Wordfence canary completes or advances consistently under the chosen route.
- WP-Cron and the next scheduled scan complete without manual intervention.
- The workaround and long-term network owner are documented.
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.
- Map DNS and origin routes
- Compare IPv4 and IPv6 callbacks
- Join Wordfence and hosting logs
- Canary the IPv4-only scan option
- Verify scheduled scans and cron
Mistakes to avoid
- Changing production configuration before recording the exact version, failing request, timestamp, and rollback point.
- Treating a clean dashboard or one successful request as proof while the public page, background job, log, stored record, and downstream system remain unchecked.
- Testing a different role, device, locale, order state, form, cache state, or integration path from the one that users actually reach.
- Leaving debug logging, temporary exclusions, duplicate hooks, helper code, test endpoints, or broad permissions active after the verification window.
Questions teams ask during testing
Can I make this change directly in production?
Start with read-only evidence and use staging for code, update, security, checkout, form, or queue changes. 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, role, URL, device, locale, cache state, and downstream integration. Compare stored evidence rather than relying on a visual impression.
What evidence should I retain?
Keep UTC time, exact versions, URL or record ID, expected and 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 diagnose the Wordfence scan path.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references