A loopback is the site requesting its own URL. External visitors can reach the site while the server itself cannot because internal DNS, firewall, basic authentication, or TLS trust differs.
Use the sequence below as a diagnostic method, not as a promise that one setting fits every host; verify its example paths, privileges, and backup assumptions while working to trace self-requests through DNS, HTTPS, authentication, firewalls, PHP sessions, and timeouts so scheduled events and editor safety checks can run.
Likely failure paths
- The server resolves the public hostname incorrectly or cannot connect back through the firewall/CDN.
- Basic authentication, maintenance rules, or security plugins block internal requests.
- An active PHP session or slow request prevents the loopback from completing.
The branches are ordered to protect the strongest evidence around this possibility: the server resolves the public hostname incorrectly or cannot connect back through the firewall/CDN. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Integration failures happen at custody boundaries; wordPress can format a request successfully while DNS, TLS, a proxy, remote service, authentication layer, or receiving provider rejects the next step; record what each boundary accepted—not just what the WordPress screen announced; in this guide, the practical goal is to trace self-requests through DNS, HTTPS, authentication, firewalls, PHP sessions, and timeouts so scheduled events and editor safety checks can run.
A controlled investigation
- Read the exact Site Health loopback error and target URL.
- From the server, resolve the hostname and request the URL with
curl -Iusing normal TLS verification. - Check firewall, CDN, basic-auth, and security logs for the self-request.
- Review Site Health for an active PHP session and inspect slow plugin hooks.
The sequence moves from observation toward intervention. Preserve the result of the final check—review Site Health for an active PHP session and inspect slow plugin hooks—because it provides a useful comparison after the repair.
Test one hypothesis without losing the baseline
The opening hypothesis is the server resolves the public hostname incorrectly or cannot connect back through the firewall/CDN. Test it with the least invasive observation available: read the exact Site Health loopback error and target URL. Do not change configuration until the observation has been saved with a timestamp.
When that evidence is consistent with the hypothesis, stage this repair: correct internal DNS/routing or allow the narrowly defined self-request path. Otherwise, preserve the current state and advance to the next branch. This keeps rollback simple and prevents a second change from masking the first.
Make the smallest durable change
- Correct internal DNS/routing or allow the narrowly defined self-request path.
- Supply approved authentication for staging or exempt only the required loopback request.
- Close PHP sessions before outbound HTTP and reduce work performed during the probe.
Before applying “Correct internal DNS/routing or allow the narrowly defined self-request path,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can rerun Site Health and a scheduled event; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Close the incident with evidence
- Rerun Site Health and a scheduled event.
- Confirm TLS verification remains enabled.
- Ensure the fix does not create a public bypass around authentication.
One successful refresh is not closure. Keep the incident open until you can also confirm TLS verification remains enabled, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
A useful escalation contains the UTC timestamp, destination host or route, sanitized request/response headers, status and application error code, correlation ID, retry behavior, and the source IP when relevant; never send live credentials in a ticket; include the result of this first observation: read the exact Site Health loopback error and target URL.
State what was tested, including the result of “Read the exact Site Health loopback error and target URL,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Test the site’s public hostname from the server itself
Run this on the WordPress host. It verifies DNS, TCP, TLS, and HTTP without disabling certificate checks.
getent hosts example.com || host example.com
curl -sS -o /dev/null -D - \
--connect-timeout 5 --max-time 15 \
https://example.com/wp-cron.php?doing_wp_cron=1Interpretation and safety: A 200 or empty response may be normal for wp-cron.php; the diagnostic value is reachability and timing. Do not add -k to bypass TLS verification.
Do not trade visibility for a green screen
- Do not disable certificate verification to make the test green.
- Do not allowlist an entire network when one host/path is sufficient.
Evidence log
Primary references
- WordPress loopbacks — official reference consulted for this guide.
- WordPress Site Health — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Correct internal DNS/routing or allow the narrowly defined self-request path”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.