A WordPress administrator can load the site successfully while Site Health reports a loopback 401, 403, 405, redirect loop, timeout, TLS error, or unexpected response. The browser carries cookies, Basic Auth credentials, challenge clearance, DNS resolution, and cached state that the server-side WordPress HTTP request may not have.
Use this when scheduled posts, WP-Cron, page-cache detection, plugin or theme editor checks, background jobs, or Site Health fail even though normal browser pages appear healthy.
Quick answer
Capture the exact Site Health response, then compare four paths: browser, external curl, origin-side curl, and a WordPress `wp_remote_get` request. Record destination IP, TLS result, Host header, redirect chain, cookies, authorization, user agent, WAF rule, status, timing, and body signature. Fix the first layer where the paths diverge and rerun the actual scheduled workflow.
What to check first
- Copy the complete Site Health loopback error, response code, elapsed time, target URL, and timestamp before changing plugins or firewall rules.
- Resolve the hostname from the application host and compare IPv4, IPv6, CDN address, origin address, TLS name, certificate chain, and proxy route.
- Replay the target externally, from the origin shell, and through WordPress HTTP API while recording redirects, Host, Authorization, Cookie, nonce, user agent, status, timing, and response hash.
- Review Basic Auth, maintenance mode, WAF challenge, bot protection, trusted proxy headers, security plugins, active PHP sessions, and allowlists for browser-only assumptions.
- After the narrow correction, rerun Site Health, a scheduled post, one due cron event, page-cache detection, and the affected background task.
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 the exact failure | Copy the complete Site Health loopback error, response code, elapsed time, target URL, and timestamp before changing plugins or firewall rules. | Browser, external, origin, and WordPress HTTP paths reach the intended host and return an approved status without an unexpected challenge or redirect loop. |
| Diff four request paths | Resolve the hostname from the application host and compare IPv4, IPv6, CDN address, origin address, TLS name, certificate chain, and proxy route. | Site Health passes the loopback test and no active PHP session warning remains. |
| Identify the first divergent layer | Replay the target externally, from the origin shell, and through WordPress HTTP API while recording redirects, Host, Authorization, Cookie, nonce, user agent, status, timing, and response hash. | A scheduled post and one due cron or background event complete at the expected time without a manual trigger. |
| Apply the narrow auth or routing fix | Review Basic Auth, maintenance mode, WAF challenge, bot protection, trusted proxy headers, security plugins, active PHP sessions, and allowlists for browser-only assumptions. | WAF and proxy logs show the server-self request was allowed by a narrow, documented rule rather than a global bypass. |
Why this usually happens
- A staging password exists at the proxy, but the WordPress loopback request has no Authorization header.
- A WAF trusts the browser after a challenge cookie while the server-self request is challenged or blocked.
- Internal DNS resolves the hostname to a different origin or stale address than public DNS.
- An active PHP session holds a lock while WordPress waits for a request that needs the same session.
Field notes
- Do not publish Authorization headers, cookies, nonces, internal addresses, or complete response bodies in a support ticket.
- Use response hashes and a short sanitized body signature to compare paths without copying private content.
- A manual cron command can restore service temporarily, but it does not prove the web-triggered loopback path is fixed.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
curl -sS -o /dev/null -w '%{http_code} %{remote_ip} %{time_total} %{redirect_url}\n' https://example.com/wp-cron.php
wp eval '$r=wp_remote_get(home_url('/wp-cron.php')); print_r(array('code'=>wp_remote_retrieve_response_code($r),'error'=>is_wp_error($r)?$r->get_error_message():''));'
wp cron event run --due-now
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 the exact failure
- Diff four request paths
- Identify the first divergent layer
- Apply the narrow auth or routing fix
- Verify real scheduled work
Decision rule
Fix the earliest proven difference. A 401 points first to authentication, a 403 to firewall or policy evidence, a 405 to method handling, a timeout to DNS, network, origin, or application timing, and a redirect loop to host or scheme normalization. Confirm with logs before changing multiple layers.
What to tell the client or owner
Share the sanitized Site Health error, URL, status, timestamp, destination IP class, TLS result, redirect chain, response hash, WAF event ID, WordPress HTTP error, and affected scheduled workflow.
Production verification checklist
- Browser, external, origin, and WordPress HTTP paths reach the intended host and return an approved status without an unexpected challenge or redirect loop.
- Site Health passes the loopback test and no active PHP session warning remains.
- A scheduled post and one due cron or background event complete at the expected time without a manual trigger.
- WAF and proxy logs show the server-self request was allowed by a narrow, documented rule rather than a global bypass.
Mistakes to avoid
- Do not add permanent broad WAF or authentication bypasses for all WordPress requests.
- Do not assume localhost is the same path WordPress uses for the site's public URL.
- Do not disable every plugin on production when a Health Check troubleshooting session can isolate the conflict for your account.
- Do not close the issue after Site Health passes without testing the scheduled business workflow.
Questions teams ask during testing
Why does the site work in my browser?
Your browser may carry cookies, credentials, cached DNS, or a WAF clearance that the server-side request does not have.
What can loopback failures break?
WordPress documents scheduled events and code stability checks. Plugins also use loopbacks for background work and cache detection.
Should the server call 127.0.0.1?
Not necessarily. Test the URL WordPress actually requests and the route its hostname resolves to in that environment.
When HandL WP should help
HandL WP can compare browser, CDN, WAF, origin, DNS, TLS, and WordPress HTTP evidence, then correct a loopback failure without opening a broad security exception.
If this is active on a production site, fix a WordPress loopback request.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references