WordPress Site Health - cURL error 28 (REST API, loopback)

Updated: May 4, 2020

Recently, I discovered an interesting little problem. I run WordPress on my books-only website, and naturally, there's testing that needs to be done to make sure everything is hunky-dory ere any changes are introduced to the domain. One such change was the introduction of the Site Health check tool in WordPress 5.2, which tells you of any critical issues and recommended actions for your setup.

On its own, this is fine, but then I noticed a couple of supposedly critical errors showing up with update to 5.4, indicating a sudden new issue with the domain. The errors were: The REST API encountered an error and Your site could not complete a loopback request. The details for both these read: Error: cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received (http_request_failed). Weird. Let's debug.

Problem in more detail

Critical issues sound alarming. But then, you need to look at potential problems carefully, to understand what the actual impact is. Quite often, companies are over-stringent with how they treat bugs and problems, because no one wants to be accused of being too lax with issues that could lead to security complications. So let's have a look at the status report:

CURL error 28

The first issue reads as follows:

The REST API encountered an error

The REST API is one way WordPress, and other applications, communicate with the server. One example is the block editor screen, which relies on this to display, and save, your posts and pages.

The REST API request failed due to an error.
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

The second one has the following text:

Your site could not complete a loopback request

Loopback requests are used to run scheduled events, and are also used by the built-in editors for themes and plugins to verify code stability.

The loopback request to your site failed, this means features relying on them are not currently working as expected.
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

The first error tells us that this is one way WordPress uses to communicate with the server - this means there are other ways. The error isn't explicit in whether this will actually cause possible issues when performing various operations.

It does specifically mention the block editor - the whole new Gutenberg thingie introduced in WordPress 5.0, which I do not use, and instead rely on the awesome Classic Editor. So maybe this is a non-issue to begin with. Then, there's the question of actual functionality - none of the mentioned functions are affected. WordPress works and does everything as it should. Perhaps a false positive? We shall see soon.

The second error talks about scheduled events - like background updates, overnight tasks, etc. Again, if you have none configured, this is a non-issue. If you do, and they run correctly, then the problem does not affect you. The error does say "working as expected" - but this is not a very deterministic, precise statement. It makes troubleshooting more difficult.

Source of the problem

But let's assume for a moment that these are actually real problems. The question is, how do you troubleshoot where they stem from? Not an easy thing, and there's nothing in the actual error messages that can steer you in the right direction.

So what I had to do was manually turn off every single non-default component, one by one, and then re-run the health check, to see whether any one particular element was at fault. Luckily, I could test this at leisure, but imagine the impact in a production setup.

Now ... after a while, I had tried every single plugin and theme that I was using, and none of these seemed to affect the outcome. WordPress continued complaining. Then, I decided to expand my search. I happen to be using an .htaccess file, with basic authentication and a few other useful details, as a secondary layer of access control to the admin page. Lo and behold, removing the auth part fixed it. No more health check errors!

AuthType Basic
AuthName restricted
AuthUserFile /home/mastablasta/wp-admin/passwd
Require valid-user

So it would seem - WordPress Site Health does not like .htaccess files. I haven't explored exactly how this trips the checks, but then, I do not need to. One, I know what the source of the problem is. Two, the errors do not affect the functionality that I want and need, hence this is a non-issue.

Conclusion

It is obvious that the problems in Site Health are internal - after all, they only started cropping up with the move to WordPress 5.4. Of course, some piece of code somewhere has changed, but then, essentially, if a core product behavior is suddenly radically different than it was just before the update, and there are no huge problems in the other elements of the site's functionality, then it's quite likely the issue stems from said core product update.

I do like the idea of this site-issues-at-a-glance kind of thing, but I am not happy with the false positives, or the goose chase that the errors have created for me, even if only briefly. Errors need to be meaningful. If I have no insight what might be wrong from the way the error manifests, then there's really no point showing the technical details. The cURL error 28 and .htaccess seem so far apart. Anyway, here we are. If you're affected by a similar problem, have a look at your site configuration, see if you're using basic auth, and perhaps suffering from the same would-be bug. We're done here.

Cheers.

You may also like: