You open Tools > Site Health and there it is in red: the loopback request to your site failed. The front end looks fine, yet scheduled posts slip and the theme editor won't save. It's almost always a blocked conversation between your site and itself, and the cURL error underneath tells you where to look.
Quick Answer: WordPress tests loopbacks by sending a POST request to its own wp-cron.php with a 10-second timeout. A "failed" result means no HTTP response came back at all, so the block usually sits below WordPress: a firewall dropping your server's own IP, DNS pointing your domain at the wrong place, a TLS handshake error, or a plugin holding the request open. Read the cURL number, then fix that layer.
Last verified: September 2026, against WordPress 7.1 core code and the official loopback handbook (PHP 8.3+ recommended).
Our engineers resolve 20-30 client site issues a day, and this warning turns up often enough that we've written the fix the way we'd explain it to a colleague.
What "The Loopback Request to Your Site Failed" Actually Means
A loopback is your WordPress install calling its own URL over HTTP. Core uses it to start WP-Cron, and the plugin and theme editors use it to confirm a code change didn't break the site. The WordPress loopback troubleshooting handbook covers the basics, but not how the check works.
As of WordPress 7.1 (released August 2026), the Site Health loopback check sends a POST request to your site's own wp-cron.php, forwards your login cookies, and waits a maximum of 10 seconds. If the connection errors out or nothing answers in that window, WordPress reports a critical failure and prints the underlying cURL error. You can read the Site Health loopback test source yourself.
Failed vs. "unexpected HTTP status code": why the wording matters
Under the heading "Your site could not complete a loopback request", Site Health shows one of two warnings:
- "Failed" plus a cURL error (critical): no response at all. Think network, DNS, TLS or a hung PHP process.
- "Returned an unexpected http status code" such as 401, 403 or 503 (recommended): something answered but refused, usually a WAF rule, a Cloudflare challenge or password protection.
Most guides lump these together. Knowing which one you have halves the search.
Is this error actually hurting my site?
Usually, yes, just quietly. Posts miss their publish time, WooCommerce background jobs back up, and backup plugins skip runs. Visitors see nothing wrong, so the warning often sits unread for weeks.
Read the cURL Error First: The 3-Layer Loopback Triage
The number after "cURL error" is the fastest diagnostic you have. We sort every site health loopback error into three layers (network, encryption and application) because each layer has its own short list of suspects. Here's the lookup table for the WordPress loopback request failed cURL error codes we see most often:
| cURL error in Site Health | Layer | What it usually means | Where to fix it | |---|---|---|---| | 6: Could not resolve host | Network | The server can't resolve its own domain | DNS and hosts file | | 7: Failed to connect | Network | Firewall rejecting the server's own IP | Firewall | | 28: Operation timed out | Network or application | Dropped packets, or PHP never answered | Firewall, then PHP | | 35: SSL connect error | Encryption | TLS handshake failed | SSL and TLS | | 60: SSL certificate problem | Encryption | Code switched certificate checks back on | SSL and TLS |
If your code isn't listed, the official libcurl error code reference explains every number.
cURL error 28 is the most ambiguous code in a failed WordPress loopback. It means nothing answered within 10 seconds, which can be a firewall silently dropping packets or PHP being too busy or locked to respond. Test from the server shell first: if curl answers instantly there, the problem lives inside WordPress rather than the network.
bashcurl -sS -o /dev/null -w "%{http_code} in %{time_total}s\n" -X POST https://example.com/wp-cron.php
A 200 in under 2 seconds means the network path is healthy. A hang or error means it isn't.
From the Ticket Queue: According to Hostaccent's support-queue data (2026), WordPress problems make up about 30% of monthly tickets and brute-force and malware work another 25%. They overlap here: the firewall rules that stop attacks are the ones most likely to block a site's own loopback.
Server-Side Fixes: Firewall, DNS and SSL
Start below WordPress, because no plugin toggle clears a network or TLS block.
1. A loopback request blocked by firewall rules
The most common server-side cause of a failed loopback is a firewall treating the server's own public IP as a stranger. CSF/LFD, Fail2ban and cloud firewalls can all block it, and a silent DROP rule produces cURL error 28 after the full 10-second wait instead of a clean refusal.
We tune CSF/LFD rules in production, and in our experience the trigger is often LFD itself: a burst of wp-cron hits looks like a flood, so the server blocks itself. Check for your server IP and allow it:
bashcsf -g 203.0.113.10 csf -a 203.0.113.10 "server self loopback" fail2ban-client status
For Fail2ban, add the IP to ignoreip in jail.local.
Behind Cloudflare, the loopback travels to the edge and back, where Under Attack mode or Bot Fight Mode can challenge it (usually a 403 or 503 warning). Add a WAF custom rule that skips your origin IP (ip.src eq 203.0.113.10), as Cloudflare's developer documentation describes.
Pro Tip: ModSecurity blocks return a 403, so they trigger the status-code warning, not "failed". Search the audit log (cPanel:
/etc/apache2/logs/modsec_audit.log; Plesk:/var/log/modsecurity/modsec_audit.log) forwp-cron.php, then disable that rule ID for that path only.
2. DNS and hosts-file mistakes
cURL error 6 or 7 usually means the server can't find itself. Compare what the server resolves with its real address:
bashgetent hosts example.com hostname -I
If they don't match, check /etc/hosts. Across the 4,000+ site migrations Hostaccent has handled since 2016, a leftover hosts entry pointing at the old server is one of the loopback failures our team spots fastest. Remove it or update the IP.
Check the hostname too. If it matches the site's domain, local lookups can land in the wrong place; fix it with hostnamectl set-hostname server1.example.com. Pinning your domain to the origin IP in /etc/hosts has a bonus: loopbacks never touch Cloudflare at all.
3. SSL and TLS handshake errors
A detail most guides miss: the loopback test switches certificate verification off by default through the https_local_ssl_verify filter, so cURL error 60 means a plugin or mu-plugin turned it back on. Search your code for that filter.
cURL error 35 usually means port 443 answered with plain HTTP or the wrong virtual host. Test the origin directly:
bashcurl -Iv --resolve example.com:443:203.0.113.10 https://example.com/
If Cloudflare runs in Flexible SSL mode, the origin may have no working HTTPS listener. Install a certificate there (Let's Encrypt is fine) and switch to Full (strict).
Live site and no time to experiment? If you'd rather not edit firewall rules on a site that's earning right now, our engineers fix this exact error for a small one-time fee, and you'll see the exact quote before anyone touches your server. Hosted with Hostaccent? Then it's simply covered by support, free. Have an engineer fix it
Still blocked at Cloudflare?
Send the error code, affected hostname, and recent DNS or SSL changes. We will separate edge, origin, firewall, and certificate causes before proposing work.
Site-Side Fixes: Plugins, Sessions, Auth and PHP Workers
Shell test returns a fast 200, but Site Health still complains? The block is inside WordPress or PHP.
4. Plugin or theme conflicts
The official handbook names plugin and theme conflicts as the most common cause overall. Save your active list, deactivate everything, test, then bring plugins back one at a time (use a staging copy if the site is busy):
bashwp plugin list --status=active --field=name > active-plugins.txt wp plugin deactivate --all wp cron test wp plugin activate plugin-slug
Rename wp-content/mu-plugins briefly to rule it out too. The Health Check & Troubleshooting plugin disables plugins for your session only, so visitors aren't affected. Our team runs this WP-CLI routine in mass plugin audits, and security and caching plugins are the usual suspects.
5. PHP sessions that never close
A plugin that calls session_start() without closing the session makes every loopback hang for the full 10 seconds. WordPress forwards your browser cookies with the test request, so PHP makes the second request wait for the session lock held by the first. Site Health flags this separately as an active PHP session. Update or replace the plugin.
6. Basic auth and exhausted PHP workers
Password-protected staging sites often return a 401, because under PHP-FPM WordPress frequently can't read the basic-auth credentials to forward them. Exempt the cron file in .htaccess:
apache<Files "wp-cron.php"> Require all granted </Files>
On Nginx, add auth_basic off; inside the location block that serves wp-cron.php.
Worker exhaustion is sneakier. The loopback needs a second PHP worker while your admin page holds the first, so a pool with pm.max_children at 2 or 3 runs out. Look for "server reached pm.max_children setting" in the PHP-FPM log. That shortage often sits behind high TTFB in WordPress and the odd 500 internal server error in WordPress. Raise the pool within your RAM, or size a server properly with our guide to the best VPS for WordPress in 2026.
Pro Tip: Two or three workers is fine for a brochure site. A WooCommerce store needs more headroom, because Action Scheduler starts its own background runners through loopback requests.
How to Confirm the Fix and Stop It Coming Back
A loopback fix is confirmed when three checks pass together: Tools > Site Health shows "Your site can perform loopback requests", wp cron test reports success, and overdue events in wp cron event list clear after a few page loads. If only the first passes, keep digging.
To keep it fixed:
- Make the whitelist permanent. Put your server IP in
csf.allowand Fail2ban'signoreip, so a restart or rule update doesn't re-block it. - Audit after every migration or IP change. Check
/etc/hosts, the hostname and Cloudflare rules. - Use a real cron job on busy sites. Add
define( 'DISABLE_WP_CRON', true );towp-config.php, then schedule WP-CLI every 5 minutes:
bash*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1
That last step makes scheduled tasks reliable, but it doesn't repair the loopback, which the editors still need. Fix the cause first. If the site also feels sluggish, work through our WordPress site slow diagnosis guide, and if traffic is climbing, read up on hosting for high traffic WordPress sites.
Fixed It, or Still Stuck? Your Next Step
Now you know the cause usually hides below WordPress, in a firewall rule, a hosts file or a PHP pool.
Fixed it? Whitelist your server's own IP permanently. On a well-managed host, though, this class of problem is support's job, not yours. That's how Hostaccent runs WordPress Hosting: the Basic plan at $22.99/yr (renews at $22.99/yr) includes NVMe storage, a 30-day money-back guarantee and 24/7 help from our own engineers, from a UK-registered host (hosting since 2016, UK-incorporated 2018). It's sized for one site, so a busy store should start on Medium.
Still seeing "the loopback request to your site failed"? Open a ticket with our engineers. Small one-time fee, exact quote before any work starts.
Frequently Asked Questions
Is it safe to ignore the loopback request to your site failed warning?
Not for long. Your site keeps loading for visitors, but anything that depends on WP-Cron becomes unreliable: scheduled posts can miss their time, backup and security-scan plugins may skip runs, and WooCommerce background jobs pile up. The plugin and theme file editors also lose their safety check. If you use none of those features the risk is lower, but most sites rely on at least one of them every day.
Does disabling WP-Cron fix a site health loopback error?
No. Setting DISABLE_WP_CRON to true and adding a system cron job makes scheduled tasks run reliably, but the Site Health test still posts to wp-cron.php and keeps failing while the underlying block remains. The plugin and theme editors also still need loopbacks to verify changes. Treat a real cron job as a performance upgrade, not a repair for the firewall, DNS or plugin problem behind it.
Why does the loopback fail only when Cloudflare is enabled?
With Cloudflare proxying your domain, the server's request to itself travels out to the Cloudflare edge and back, so it's handled like any other visitor. Under Attack mode, Bot Fight Mode or a strict WAF rule can challenge it, which usually shows up as a 403 or 503. Add a custom rule that skips your origin IP, or pin the domain to the origin in /etc/hosts so loopbacks never leave the server.
Can a security plugin cause a loopback failure?
Yes, and it's one of the more common culprits. Security plugins with rate limiting, country blocking or bot filtering sometimes block requests from the server's own IP, or requests that lack a normal browser signature. Deactivate the plugin briefly, clear any caches, and rerun the Site Health check. If the check passes, whitelist your server's IP in the plugin's settings rather than leaving the site unprotected with it switched off.
Why does the error appear on my staging site but not on live?
Staging sites are usually password-protected with HTTP basic auth, and the loopback request can't always pass those credentials along, especially under PHP-FPM, so it receives a 401 response instead. Staging copies also inherit hosts entries, hardcoded URLs or firewall rules that don't match their new domain. Exempt wp-cron.php from the password protection, confirm the staging domain resolves to the right server, and then run Site Health again.
Discussion
Have a question or tip about this topic? Share it below — your comment will appear after review.