Jetpack cURL error 52 due to disabled XML-RPC — UX improvement suggestion

[jamesburgos]

This is duplicate issue. I'm posting it because I believe it would be useful for others who are self-hosting their sites to have a contained easy to scan solution.

Summary

Issue:
While setting up Jetpack on my WordPress site (hosted via Cloudways), I encountered this error:

Jetpack: [http_request_failed] cURL error 52: Empty reply from server

This prevented Jetpack from establishing a connection between WordPress.com and my site. Local server logs showed 200 OK responses for admin-side Jetpack requests, but the remote connection failed.

Root Cause:
The issue was traced to XML-RPC being disabled at the server level. Jetpack depends on XML-RPC for its initial handshake and certain features. Once XML-RPC was re-enabled, Jetpack connected successfully.

---

Troubleshooting Steps

1. Reviewed server logs:

   • All Jetpack-related requests from the admin UI returned 200 OK.
   • No errors appeared in the access logs for local API calls.

2. Verified server software:

   • Confirmed cURL and OpenSSL versions met Jetpack’s requirements.

3. Temporarily disabled caching/security layers:

   • Turned off Varnish and security plugins (e.g., Wordfence) to rule out interference.
   • No change.

4. Whitelisted Jetpack IPs (precautionary):

   • Added Jetpack’s IP ranges to the Cloudways firewall, though it was later confirmed this wasn’t the issue.
   • Helpful to note as best practice for others troubleshooting similar problems.

5. Contacted Cloudways support:

   • Discovered XML-RPC was disabled at the server level.

---

Additional Context

• Why XML-RPC was disabled:
  XML-RPC is often disabled by hosting providers as a precaution against brute force attacks. This makes sense from a security standpoint but can break functionality for plugins like Jetpack that rely on it.

• Suggestion for Conditional Enablement:
  Rather than fully disabling XML-RPC, consider conditionally enabling it only for trusted IP ranges (e.g., Jetpack’s IPs). This maintains security while allowing necessary services to function.

  Example .htaccess rule:

  <Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
  Allow from [Jetpack IP ranges]
  </Files>

• User Experience Concern:
  The cURL error 52 message that Jetpack throws in this scenario is gnarly and opaque to less technical users. Compare this to the clearer messaging WordLand displays when JSON API is disabled. Suggest improving Jetpack’s error messaging to:

  • Clearly identify that XML-RPC is likely disabled.
  • Suggest remedial actions or point users to documentation.

  This would ease scaring off potential users of WordLand who might otherwise be turned away by a cryptic cURL message. I've read commentary elsewhere from potential users grimacing over the requirement to authenticate via WordPress.com in order to use WordLand. And there are some among different WordPress dev circles who avoid installing Jetpack on their site like the plague. For the willing who are also self-hosting, the XML-RPC block could be a dead stop. It may be too early to glean insight from your logs but it might be worth monitoring abandonments at the point where I experienced this error.

---

Cloudways Support Transcript

Me:
I’m experiencing issues connecting Jetpack on my Cloudways-hosted WordPress site. The error I get is:
Jetpack: [http_request_failed] cURL error 52: Empty reply from server.
Can you check if any firewall or server-level configuration might be interfering?

Cloudways Support:
Upon review, we found that XML-RPC was disabled at the server level. This is likely causing the issue.

Me:
Please enable XML-RPC and I’ll test the connection again.

Cloudways Support:
XML-RPC has been re-enabled. Please verify.

Me:
Tested — Jetpack connected successfully. Issue resolved.

[jeherve]

User Experience Concern: The cURL error 52 message that Jetpack throws in this scenario is gnarly and opaque to less technical users. Compare this to the clearer messaging WordLand displays when JSON API is disabled. Suggest improving Jetpack’s error messaging to:

* Clearly identify that **XML-RPC is likely disabled**.

* Suggest remedial actions or point users to documentation.

👋 I'd like to chime in from the Jetpack side of things. That's definitely something we've tried to improve over the years. We've worked on multiple improvements to better surface broken connections, and how they could be fixed. We now surface such issues and links within the Jetpack dashboard, but also in WordPress' "Site Health" screen (under Tools > Site Health) and consequently in the Site Health displayed in your main WordPress dashboard. We've also worked on ways to make our connection more reliable, by relying on other tools when XML-RPC is not available for example.

That said, not everyone relies on the same methods to block or restrict access to XML-RPC. One can use the filters available in WordPress itself, but others may choose to remove the file entirely, block access to it, block some of the requests but not all, and more. That can make it more difficult to suggest a solution at times, since there isn't a single solution to solve all XML-RPC problems on a site.

If we didn't catch your scenario, that's something I'd like us to fix in Jetpack. I think it should be fixed there rather than in WordLand.

Do you happen to know more about how Cloudways had blocked access to the file? If so, could you send us an email via this form and mention this issue, so we can take a closer look?

Thank you!

[jamesburgos]

@jeherve I'm just reporting what I experienced and how I dealt with it. As a UX enthusiast, this issue has a good chance of being a recurring one (for all the reasons you suggest) as more self-hosted WordPress users signup to try WordLand. I'm not proposing how to fix it, but I am suggesting a more gentle way to notify the user who WILL encounter the error in the WordLand UI.

This is more polite

Than this, IMHO ;)

Ps. I submitted the info you requested to the jetpack form.
I'll leave it there. Cheers

[jeherve]

I submitted the info you requested to the jetpack form.

Thank you! I'll take a look at it when I get to it, and I'll see if we could improve how we detect your use-case, and thus display better error messages in our interfaces and APIs.