WordPress Site Health "REST API error" and "Loopback request failed

Tools, Site Health, Status in WordPress can show two related critical issues: "The REST API encountered an error" and "Your site could not complete a loopback request." Both mean that WordPress, running on your server, tried to make an HTTP request to its own public URL and failed. That matters because WordPress relies on such requests for scheduled tasks, plugin and theme file editor checks, automatic update tests, and parts of the block editor.

The warning always includes details. Expand the issue and read the error text, since it names the failure: a cURL error number, an HTTP status, or a message about the response.

What a loopback request is

Your server acts as its own client. PHP calls something like https://example.com/wp-json/ or https://example.com/wp-cron.php. For that to work from the server itself, it must be able to resolve the domain, connect on port 443 or 80, validate the certificate and receive a normal response. Anything that works for visitors but not from inside the server causes this warning: split DNS, a firewall allowing only external IPs, basic auth, an IP allowlist or a bad certificate chain.

Decision order

1. Read the exact error text in Site Health.
2. Reproduce the request from the server shell, which isolates server-side network issues from WordPress.
3. Fix the layer the error points to.
4. Disable plugins last, when the error is an HTTP status from WordPress itself.

Run this on the server, as the same user that runs PHP if you can:

curl -sS -o /dev/null -w "%{http_code} %{remote_ip}\n" https://example.com/wp-json/

Match the error to a fix

cURL error 6: could not resolve host

The server cannot resolve its own domain. Check /etc/resolv.conf, the resolver, and whether DNS for the domain exists. Verify with the DNS चेकर. On a staging machine, a domain only listed in your laptop's hosts file will not resolve here. You can add the domain to the server's /etc/hosts pointing at 127.0.0.1 or its private IP.

cURL error 7: failed to connect

The name resolves, but the port is closed from the inside. Common reasons: the domain resolves to a public IP that your cloud firewall or NAT does not route back to the same machine ("hairpin NAT"), a firewall blocks outbound 443, or the web server listens only on certain interfaces. Test with the पोर्ट चेकर from outside, and curl -v from inside. Pointing the domain at the local address in /etc/hosts fixes hairpin problems.

cURL error 28: operation timed out

The request was accepted but not answered in time. Look for rate limits, a slow PHP-FPM pool (PHP-FPM reached pm.max_children is a frequent culprit, because the loopback needs a free PHP worker while the current request holds one), or a security tool dropping server-originated requests.

cURL error 60 or 35: SSL problems

The server does not trust the certificate or cannot negotiate TLS with itself. Typical causes are a missing intermediate certificate, an expired certificate, or an outdated CA bundle. Check the chain with the SSL Checker and read cURL error 60: SSL certificate problem. Self-signed certificates on staging sites produce the same warning.

HTTP 401 or 403

A request from the server is being blocked. Look for HTTP basic authentication (common on staging), an IP allowlist that excludes the server's own IP, ModSecurity, a security plugin, or a CDN firewall challenging server traffic. If you password protect the site, loopbacks fail unless you exempt them. See 403 Forbidden on wp-admin.

HTTP 404 on /wp-json/

Permalinks or rewrite rules are broken. Resave Settings, Permalinks. See 404 on posts after changing permalinks.

HTTP 301 or 302, or 200 with a login page

The site URL differs from the URL being requested, causing a redirect. Check Settings, General for https, www and path consistency, and trace with the HTTP स्टेटस चेकर. See WordPress too many redirects.

"The REST API did not process the 'context' query parameter correctly"

Some plugin, filter or proxy alters or strips the query string. Check security plugins, caching rules that ignore query strings and any code on the rest_ filters.

HTTP 500 or a PHP error

Read the PHP log. A fatal error in a plugin that hooks REST requests breaks it. See critical error on this website.

Test the REST API from outside

curl -i https://example.com/wp-json/
curl -i "https://example.com/?rest_route=/"

If the second form works but the first does not, rewrites are the problem. If both fail for you but loopback is blamed, compare headers with the HTTP Header Checker.

Why it affects scheduled posts

When WP-Cron cannot loop back, scheduled posts miss their times. If you see "missed schedule", read WP-Cron explained and fixed. Setting DISABLE_WP_CRON and running cron from a system job avoids loopbacks, but you still need working REST for the editor.

How to verify

Return to Site Health, Status and re-run the test (reload the page). The issue should disappear. Then run wp cron event run --due-now and confirm no errors. Use the वेबसाइट हेल्थ चेक for an external comparison.

अगले कदम

• Read Updating failed: not a valid JSON response.
• Fix certificates with renewing SSL certificates.
• Review WordPress plugin conflict troubleshooting.

सामान्य प्रश्न

Can I ignore the warning?

Not for long. Features that depend on loopbacks, such as scheduled posts and editor checks, may silently fail.

The site works for visitors. Why does it fail internally?

The server's own network path differs: DNS, NAT, firewall rules or trust stores can behave differently for requests from the machine itself.

Does it affect SEO?

Not directly, but missed scheduled posts and broken editing can affect publishing.

Is it caused by Cloudflare?

Sometimes, when a challenge or firewall rule blocks the server's IP. Allow your server's IP in the CDN's rules.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.