You open Tools > Site Health in wp-admin and see a red flag: "The loopback request to your site failed." Plugin updates hang, scheduled posts don't publish on time, and the theme/plugin editor throws a vague error when you try to save changes. Nothing looks broken on the front end, so it's easy to ignore — until a client cron job or an automatic update quietly stops working and nobody notices for weeks.
A loopback request is just your server calling itself: https://yourdomain.com/wp-cron.php or a similar internal URL, fired from the same box that's hosting the site. When that call fails, WordPress can't verify plugin/theme edits before saving them, can't reliably fire wp-cron, and some page builders and REST-API-dependent plugins start behaving oddly. Here's how to actually find why it's failing, not just how to silence the warning.
Symptom
- Site Health shows "The loopback request to your site failed" under Status > Critical/Recommended issues
- Plugin/theme file editor in wp-admin gives a generic save error
- Scheduled (future-dated) posts stay stuck in "Scheduled" past their publish time
- Auto-updates for plugins/themes/core silently don't run
- Some builders (Elementor, Divi) show "unable to connect" warnings during specific actions
Run this to see the raw error WordPress is choking on:
wp site-health --format=table --url=https://yourdomain.comOr without WP-CLI, temporarily add this to wp-config.php to log the actual HTTP response:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Then check wp-content/debug.log after reloading Site Health. You'll usually see something like cURL error 28: Connection timed out, cURL error 60: SSL certificate problem, or a plain 403/406 response — each one points somewhere different.
Cause
Loopback failures come down to one of five things, roughly in order of how often we see them:
| Cause | Typical signal |
|---|---|
| Server can't resolve its own domain (DNS/hosts mismatch, especially behind Cloudflare) | cURL error 6 or 7, or the request hangs until timeout |
| Security plugin or ModSecurity/CSF is blocking the server's own IP | 403 or 406 in the response, nothing in PHP error log |
| SSL certificate issue on the loopback URL itself | cURL error 60, "SSL certificate problem: unable to get local issuer certificate" |
| WP_HOME / WP_SITEURL point somewhere the server can't reach (staging URL left in prod, http vs https mismatch) | Loopback succeeds manually via curl but fails from inside WP |
| Outbound firewall rule blocking port 443 to localhost or the server's own public IP | Connection timed out, works fine from an external machine |
The Cloudflare case deserves its own callout because it's the one we see most on VPS setups: if your DNS is proxied (orange cloud) and the server's own /etc/hosts or resolver sends its self-request out through Cloudflare's edge, and your SSL mode or firewall rejects that round-trip, the loopback dies even though the public site loads fine for everyone else.
Fix
Step 1 — test the loopback manually from the server, exactly the way WordPress does it:
curl -Ik https://yourdomain.com/wp-cron.php?doing_wp_cronIf this hangs or errors, you've reproduced the problem outside of WordPress, which rules out plugin conflicts entirely and confirms it's server/network/SSL.
Step 2 — check DNS resolution on the server itself:
dig +short yourdomain.comCompare that IP to your actual server IP (curl -s ifconfig.me). If it returns a Cloudflare IP instead of your origin, and your firewall (CSF, iptables, ufw) doesn't allow outbound HTTPS back to that Cloudflare range, either add a local /etc/hosts entry pointing the domain straight at 127.0.0.1 / the server's own IP, or open outbound 443.
A safe hosts-file override on a single-site VPS:
echo "127.0.0.1 yourdomain.com www.yourdomain.com" | sudo tee -a /etc/hostsOn shared cPanel hosting you can't edit /etc/hosts, so this fix doesn't apply — skip to Step 3 or 4.
Step 3 — rule out a security plugin or WAF blocking the server's own IP. Temporarily deactivate Wordfence, Sucuri, or any "block bad bots"-style plugin and re-check Site Health. If it passes, whitelist your server's own outbound IP inside that plugin's firewall rules instead of leaving it disabled. On a cPanel VPS with ModSecurity, check for a rule ID in the error log:
grep -i "modsecurity" /usr/local/apache/logs/error_log | tail -20and whitelist the specific rule for your own domain rather than turning ModSecurity off site-wide.
Step 4 — fix a broken SSL chain on the loopback URL. If curl -Ik from Step 1 returned a certificate error, the site's SSL cert is incomplete or expired — even if browsers show a padlock, because browsers often cache OCSP/chain info that curl won't. Re-issue AutoSSL in cPanel (WHM > SSL/TLS Status > select domain > Run AutoSSL) or renew with certbot on a plain VPS:
certbot renew --cert-name yourdomain.com --force-renewalStep 5 — check WP_HOME and WP_SITEURL in wp-config.php. If either was hardcoded to a staging domain, an http:// URL on an https:// site, or a domain that no longer resolves, loopback requests will target the wrong place:
define('WP_HOME','https://yourdomain.com');
define('WP_SITEURL','https://yourdomain.com');Or check/fix via WP-CLI without editing files directly:
wp option get siteurl
wp option get home
wp option update siteurl https://yourdomain.com
wp option update home https://yourdomain.comPrevention
- If you're behind Cloudflare, keep an eye on which SSL/TLS mode you're running (Full Strict is the safest) so origin-to-edge round trips don't randomly fail after a certificate renewal.
- When you whitelist your own server IP in a security plugin or ModSecurity, document it somewhere — it's the first thing that gets undone by a plugin reset or a WAF rule sync.
- Set a calendar reminder or monitoring check for SSL expiry independent of AutoSSL/certbot's own renewal, so a silent renewal failure doesn't quietly break loopback requests for weeks before anyone notices scheduled posts stopped firing.
- After any staging-to-production migration, always verify
wp option get siteurlandhomematch the live domain before calling the migration done.
Frequently Asked Questions
Does a failed loopback request take my site down?
No. Your front end keeps serving normally to visitors. What breaks are the background/internal functions: wp-cron-based scheduling, the theme/plugin file editor's save-time check, and some plugin update flows that rely on WordPress calling itself.
Why does Site Health say it's failing when my site clearly loads in the browser?
Because your browser is requesting the page from the outside, over whatever DNS and network path your ISP uses. A loopback request originates from the server itself, which can hit a completely different DNS answer, firewall rule, or SSL validation path — especially with Cloudflare proxying or strict outbound firewall rules in play.
Can I just ignore the Site Health warning?
You can, but scheduled posts and silent auto-update failures tend to be the first casualties, and they're easy to miss until a client asks why last week's scheduled post never went live. It's worth the 15 minutes to fix properly.
I'm on shared cPanel hosting and can't edit /etc/hosts — what do I do?
Focus on Steps 3, 4, and 5: rule out a security plugin/ModSecurity block, confirm the SSL certificate is valid via curl -Ik, and double-check WP_HOME/WP_SITEURL. Most shared-hosting loopback failures trace back to one of those three, not DNS routing.
Will disabling wp-cron entirely fix this?
It removes the symptom you'll notice most (missed scheduled posts) if you replace it with a real system cron hitting wp-cron.php, but it doesn't fix the underlying loopback problem — the file editor and update checks still rely on the same self-request working correctly.
