WordPress loopback tests call the site from the server itself. The request can fail at DNS, IPv6, CDN, WAF, cloud firewall, basic authentication, TLS, redirect, origin routing, or PHP. A generic Site Health error does not identify which boundary rejected the request.
Use this when Site Health reports a loopback failure, scheduled events stall, background updates fail, or a form and ecommerce queue depends on WP-Cron.
Quick answer
Create a unique request ID, reproduce the loopback from WordPress and the host, then find that ID in DNS, CDN, WAF, load balancer, web server, and PHP logs. Fix the first boundary that fails and rerun the same trace before changing another layer.
What to check first
- Record the exact loopback URL, method, redirects, host, resolved addresses, and TLS name.
- Add a safe correlation header or query marker to one controlled request.
- Compare server-side curl over IPv4 and IPv6 with the WordPress HTTP API result.
- Search CDN, WAF, firewall, load balancer, web server, and PHP logs for the marker.
- Confirm basic auth, bot protection, and maintenance rules exempt only the required internal path.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Correct public and internal DNS or remove an unsupported address family. | Record the exact loopback URL, method, redirects, host, resolved addresses, and TLS name. | The correlated request appears in each expected layer from edge to PHP. |
| Fix the first WAF, firewall, authentication, TLS, or redirect rule that rejects the trace. | Add a safe correlation header or query marker to one controlled request. | WordPress Site Health no longer reports the loopback error. |
| Scope any exception to the required host, path, method, and trusted source behavior. | Compare server-side curl over IPv4 and IPv6 with the WordPress HTTP API result. | A due scheduled event executes and records its expected side effect. |
| Retest the WordPress HTTP API and scheduled-event workflow with the same marker. | Search CDN, WAF, firewall, load balancer, web server, and PHP logs for the marker. | The exception does not expose wp-cron.php or administrative routes broadly. |
Why this usually happens
- The origin resolves its own hostname differently from public visitors.
- A WAF or bot rule challenges server-originated requests that have no browser cookies.
- Basic auth, TLS, or redirects create a loop that public monitoring does not expose.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
id='loopback-20260808-001'
curl -4 -sS -D- -o /dev/null -H "X-Debug-ID: $id" 'https://example.com/wp-cron.php?doing_wp_cron=1'
curl -6 -sS -D- -o /dev/null -H "X-Debug-ID: $id" 'https://example.com/wp-cron.php?doing_wp_cron=1'
# Search edge, WAF, load balancer, access, and PHP logs for the same ID.
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 |
|---|
| Public external request | Clean browser or remote curl | Expected 2xx response through CDN |
| Origin server request | Server curl to public hostname | Same route and valid TLS response |
| IPv4 and IPv6 | Force each address family | Both succeed or DNS publishes only the supported family |
| WordPress HTTP API | wp_remote_get with correlation marker | Response reaches intended callback without 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.
- Correct public and internal DNS or remove an unsupported address family.
- Fix the first WAF, firewall, authentication, TLS, or redirect rule that rejects the trace.
- Scope any exception to the required host, path, method, and trusted source behavior.
- Retest the WordPress HTTP API and scheduled-event workflow with the same marker.
- Remove temporary diagnostics and document the permanent rule owner.
Decision rule
The first system that lacks or rejects the correlated request owns the next investigation. If the web server returns 2xx but WordPress still reports failure, inspect response timing, redirects, body expectations, and PHP callback behavior.
Production verification checklist
- The correlated request appears in each expected layer from edge to PHP.
- WordPress Site Health no longer reports the loopback error.
- A due scheduled event executes and records its expected side effect.
- The exception does not expose wp-cron.php or administrative routes broadly.
Field notes
- Do not allowlist the entire server IP until the failed path and rule are known.
- A 200 homepage response does not prove the specific cron or loopback callback works.
- Keep the correlation marker free of secrets because it may appear in several logging systems.
Questions teams ask during testing
Can Cloudflare or CloudFront cause a loopback error?
Yes. Any CDN or WAF layer can block, challenge, redirect, or time out the server-originated request.
Should wp-cron.php be public?
It normally needs controlled reachability, but the safest architecture depends on whether the site uses request-triggered WP-Cron or a system scheduler.
Why use a request ID?
It joins one attempt across multiple systems and prevents unrelated traffic from confusing the diagnosis.
Mistakes to avoid
- Do not disable the WAF globally to prove one path.
- Do not test only the homepage.
- Do not ignore IPv6 when the hostname publishes an AAAA record.
- Do not declare success until a real scheduled event completes.
What to tell the client or owner
Share the URL path, correlation ID, UTC time, resolved addresses, response chain, first rejecting layer, matched rule, and the successful scheduled-event verification.
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, trace a WordPress loopback failure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references