WordPress Site Health and WP-Cron can fail when the server resolves its own hostname to an AAAA record that reaches a stale origin, a different virtual host, unsupported IPv6 listener, wrong TLS certificate, or separate WAF policy. A browser on IPv4 may look healthy while server-originated loopback requests prefer IPv6 and receive the wrong response.
Use this when Site Health reports a loopback or REST error, cron is unreliable, the site recently changed host or CDN, or IPv4 and IPv6 requests behave differently.
Quick answer
Resolve the hostname's A and AAAA records from the WordPress host, then force the same HTTPS request over IPv4 and IPv6. Compare destination, certificate, status, redirects, headers, body marker, WAF event, and origin log. Fix or remove the AAAA record only after confirming the intended IPv6 origin and retesting WordPress Site Health.
What to check first
- Capture A and AAAA answers from public DNS and from the resolver used by the WordPress server.
- Force homepage, REST, and wp-cron requests over IPv4 and IPv6 with the same Host and TLS name.
- Compare certificate SANs, redirect chains, cache headers, body markers, and final response code.
- Search CDN, WAF, load balancer, and origin logs for the exact test time and source behavior.
- Check whether recent DNS, migration, proxy, firewall, or IPv6-listener changes explain the split.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Confirm the intended IPv6 architecture and preserve DNS, TLS, WAF, and origin evidence. | Capture A and AAAA answers from public DNS and from the resolver used by the WordPress server. | A and AAAA requests reach the intended application with matching TLS identity and route behavior. |
| Correct the AAAA target or configure the intended IPv6 listener and virtual host. | Force homepage, REST, and wp-cron requests over IPv4 and IPv6 with the same Host and TLS name. | REST and cron paths return their expected content without WAF challenge or stale-host redirect. |
| Align TLS certificates, redirects, CDN behaviors, and WAF exceptions across both routes. | Compare certificate SANs, redirect chains, cache headers, body markers, and final response code. | WordPress Site Health passes the loopback test after DNS TTL and cache effects are accounted for. |
| Wait for the relevant DNS TTL and flush only local resolver caches used by the test. | Search CDN, WAF, load balancer, and origin logs for the exact test time and source behavior. | CDN, WAF, and origin logs show the successful IPv4 and IPv6 retest with UTC timestamps. |
Why this usually happens
- An old AAAA record survives a hosting migration while the A record is updated.
- The web server listens on IPv6 but the correct virtual host or certificate is not attached.
- CDN, firewall, or rate-limit rules differ between IPv4 and IPv6 paths.
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 -D /tmp/v4.headers https://example.com/wp-json/ -o /tmp/v4.body
curl -6 -sS -D /tmp/v6.headers https://example.com/wp-json/ -o /tmp/v6.body
diff -u /tmp/v4.headers /tmp/v6.headers
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 | Force hostname to current IPv4 origin | Expected WordPress response and Site Health callback |
| AAAA only | Force hostname to advertised IPv6 origin | Same TLS, virtual host, application, and policy as IPv4 |
| REST route | Request /wp-json/ over both families | Both return expected WordPress JSON without challenge |
| Cron route | POST or request wp-cron.php over both families | No stale redirect, basic-auth page, or WAF challenge |
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.
- Confirm the intended IPv6 architecture and preserve DNS, TLS, WAF, and origin evidence.
- Correct the AAAA target or configure the intended IPv6 listener and virtual host.
- Align TLS certificates, redirects, CDN behaviors, and WAF exceptions across both routes.
- Wait for the relevant DNS TTL and flush only local resolver caches used by the test.
- Repeat IPv4, IPv6, REST, cron, and Site Health tests from the WordPress server.
Decision rule
If forced IPv6 reaches a different certificate, application body, redirect, or policy than IPv4, treat the AAAA route as misconfigured. If both families match but WordPress still fails, move to authentication, timeout, plugin, or internal resolver evidence.
Production verification checklist
- A and AAAA requests reach the intended application with matching TLS identity and route behavior.
- REST and cron paths return their expected content without WAF challenge or stale-host redirect.
- WordPress Site Health passes the loopback test after DNS TTL and cache effects are accounted for.
- CDN, WAF, and origin logs show the successful IPv4 and IPv6 retest with UTC timestamps.
Field notes
- Record resolver and TTL because split DNS and cached answers can change the result.
- Do not publish real origin IPs in a public article, ticket, or screenshot.
- A response code alone is insufficient; verify the expected WordPress body or route contract.
Questions teams ask during testing
Why does the browser work while Site Health fails?
The browser and server may use different resolvers, address families, routes, authentication, or firewall policies.
Should I remove IPv6 permanently?
Only if the architecture does not support it. Otherwise fix the AAAA route so both families serve the same intended site.
What if curl -6 cannot connect?
Confirm the server has IPv6 connectivity and whether publishing an AAAA record is appropriate for that origin.
Mistakes to avoid
- Do not delete the AAAA record before confirming whether customers and other services depend on IPv6.
- Do not test only from a laptop whose network never uses IPv6.
- Do not treat an HTML login page returned with 200 as a successful REST response.
- Do not expose origin addresses while sharing diagnostic evidence.
What to tell the client or owner
Provide masked A and AAAA results, resolver, TTL, forced-route status and body type, certificate identity, WAF event, origin log, Site Health message, and the final DNS or server change.
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, fix a WordPress loopback error.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references