WordPress loopback requests can fail when the server prefers an unreachable IPv6 address, uses split DNS, follows a stale record, reaches a proxy origin, or sees a TLS certificate that does not match the hostname.
Use this when Site Health reports loopback errors that do not reproduce from a normal browser, especially after DNS, CDN, IPv6, proxy, or migration changes.
Quick answer
WordPress Loopback IPv6 and DNS Mismatch Debug should be handled with a narrow evidence-first workflow: capture loopback error, compare dns, force both ip families, then verify the result before making broader changes.
What to check first
- Record the canonical site URL, Site Health error, response code, timeout, and requested host.
- Resolve A and AAAA records from the server and from an external resolver.
- Use curl with forced IPv4 and IPv6 to compare route, TLS, headers, and response.
- Check hosts files, private DNS zones, proxy origin rules, and certificate names.
- Correct the route, then run WordPress cron and loopback tests again.
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 |
|---|
| Capture loopback error | Record the canonical site URL, Site Health error, response code, timeout, and requested host. | The server resolves the canonical host to a reachable intended origin. |
| Compare DNS | Resolve A and AAAA records from the server and from an external resolver. | Supported IP families return valid TLS and HTTP responses. |
| Force both IP families | Use curl with forced IPv4 and IPv6 to compare route, TLS, headers, and response. | Site Health loopback checks pass. |
| Fix route or TLS | Check hosts files, private DNS zones, proxy origin rules, and certificate names. | Due cron events and background jobs run normally. |
Why this usually happens
- The server may prefer AAAA while public traffic uses IPv4.
- Private DNS can point the hostname at an old or inaccessible origin.
- A migration can leave stale hosts-file or load-balancer records.
- TLS verification can fail only on the internal route.
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 -sSI https://example.com/wp-cron.php?doing_wp_cron
curl -6 -sSI https://example.com/wp-cron.php?doing_wp_cron
wp cron test
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.
- Capture loopback error
- Compare DNS
- Force both IP families
- Fix route or TLS
- Retest cron
What to tell the client or owner
Document the resolver outputs, selected route, certificate, proxy or DNS change, and post-fix cron proof.
Production verification checklist
- The server resolves the canonical host to a reachable intended origin.
- Supported IP families return valid TLS and HTTP responses.
- Site Health loopback checks pass.
- Due cron events and background jobs run normally.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, 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, diagnose WordPress Site Health and cron failures.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references