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.

Start with evidence and the smallest reversible change; work on staging when possible, preserve the logs and rollback material if production is already down, and keep the objective specific: trace self-requests through DNS, HTTPS, authentication, firewalls, PHP sessions, and timeouts so scheduled events and editor safety checks can run.

What the symptom narrows down

  • 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.

Evidence to collect before the fix

  1. Read the exact Site Health loopback error and target URL.
  2. From the server, resolve the hostname and request the URL with curl -I using normal TLS verification.
  3. Check firewall, CDN, basic-auth, and security logs for the self-request.
  4. 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

Begin with the first plausible cause: the server resolves the public hostname incorrectly or cannot connect back through the firewall/CDN. Before changing state, write down what would confirm it and run the first read-only check: read the exact Site Health loopback error and target URL.

If the result supports that cause, try one bounded repair on staging: correct internal DNS/routing or allow the narrowly defined self-request path. If evidence from “Read the exact Site Health loopback error and target URL” points elsewhere, keep this layer unchanged and move to the next check. That small decision log is far easier to audit than several simultaneous edits.

Apply fixes in the safest order

  1. Correct internal DNS/routing or allow the narrowly defined self-request path.
  2. Supply approved authentication for staging or exempt only the required loopback request.
  3. 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.

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=1

Interpretation 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.

Prove recovery

  • 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.

Shortcuts that create a second incident

  • Do not disable certificate verification to make the test green.
  • Do not allowlist an entire network when one host/path is sufficient.

Change record

ScopeFix the WordPress Site Health Loopback Request Failure · URL · role · first/last occurrence
EvidenceStatus · request ID · first relevant log entry
ChangeOne action · backup/rollback point · operator
ProofOriginal reproduction · adjacent paths · monitoring window

Primary references

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.