Most people meet cURL for the first time inside Tools → Site Health. There is an orange or red item, you expand it, and buried in the text is something like “Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received”. Or a plugin’s settings page refuses to connect to its service and shows “cURL error 60: SSL certificate problem: unable to get local issuer certificate”.
The front of the site may look perfectly normal while this is going on, which makes it easy to ignore. But a cURL error means your server is failing to talk to another server, and a lot of WordPress depends on those conversations: updates, licence checks, payment confirmations, shipping rates, email sending services, and WordPress checking on itself. Here is what the common codes mean and how to work through them.
What cURL is and why WordPress uses it
cURL is a widely used library for making web requests from a server. When WordPress needs to fetch something from elsewhere, for example checking WordPress.org for updates or asking a payment gateway whether an order was paid, PHP usually hands the request to cURL. If cURL cannot complete it, it returns a numbered error, and WordPress or the plugin passes that number and message along to you.
The number is the useful part. Each code points to a different stage where the request broke: finding the other server, connecting to it, agreeing on a secure connection, or waiting for an answer.
There are two kinds of request to keep apart. Outbound requests go from your site to someone else: WordPress.org, Stripe, PayPal, Razorpay, a licence server. Loopback requests go from your site back to itself, which WordPress uses for scheduled tasks, for checking that code edits did not break anything, and for Site Health’s own tests. Site Health often reports a cURL error under items such as “Your site could not complete a loopback request” or a REST API test, and in that case the problem is your server reaching itself.
The cURL error codes you are most likely to see
| Code | Typical message | What it usually means |
|---|---|---|
| 6 | Could not resolve host | The server could not look up the domain name. A DNS problem on the server, or a typo in a URL a plugin is using. |
| 7 | Failed to connect | The domain resolved, but nothing answered on that port, or a firewall refused the connection. |
| 28 | Operation timed out | A connection started but no answer came back in time. The most common one by far. |
| 35 | SSL connect error | The two servers could not agree on a secure connection, often because one side uses old encryption settings. |
| 60 | SSL certificate problem | The certificate on the other side could not be verified, or the list of trusted certificates on your side is out of date. |
| 77 | Problem with the SSL CA cert | The file of trusted certificates that cURL is told to use is missing or unreadable. |
cURL error 28: operation timed out
When it appears in Site Health loopback or REST API tests
This is where most owners see it. Your site tried to load a page from itself and gave up after a few seconds. The likely causes, most common first:
- The site is slow to generate pages. A heavy plugin, a page builder doing a lot of work, or an overloaded shared server can make a single uncached request take longer than the test allows. Site Health tests are not cached the way visitor pages often are.
- A security plugin or firewall is blocking the server’s own requests. Some rules treat repeated requests from the server’s IP address as suspicious. Our explainer on how a website firewall works covers why this happens.
- The host blocks loopback connections, sometimes by accident after a server change, or because the site’s domain resolves to a different address from inside the server.
- A session started by a plugin is holding things up. Site Health sometimes reports a separate warning about an active PHP session, and the two often turn up together.
When it appears for outbound requests
If updates fail with error 28, or a payment or shipping plugin times out, the remote service may be slow, but more often your server’s outbound connections are being limited or filtered. Shared hosting accounts sometimes have outgoing connections restricted to certain ports or destinations.
cURL error 60 and other SSL errors
Error 60 means your server did not trust the certificate the other side presented. Three things cause it:
- The remote site’s certificate really is broken, expired or incomplete. If it is your own domain in a loopback test, check your certificate; our article on an expired SSL certificate explains what to look for.
- Your server’s list of trusted certificate authorities is out of date. Old server software does not recognise newer root certificates. WordPress ships its own certificate bundle inside
wp-includes/certificates/, but some plugins and server configurations use the system’s list instead. - The server’s cURL or OpenSSL is old. A server that has not been updated in a long time may not support the encryption that modern APIs require, which can show up as error 35 as well.
One fix you will find online is to switch off certificate checking in the plugin or in code. Do not. That removes the protection that stops someone in the middle from reading or changing the data, and for payment or login traffic that is a serious risk. The right fix is to update the certificate store or the server software, which is usually the host’s job.
Working through it, safest steps first
- Write down the exact message and where it appeared. Site Health, a plugin page, the update screen or an email. The code number and the URL in the message tell you which server was being contacted.
- Run Site Health again a few minutes later. Timeouts are sometimes one-off. If it clears, note the time and watch whether it returns.
- Check whether the remote service is down. If only one plugin’s service fails and everything else works, the problem may well be at their end. Most large services publish a status page.
- Take a backup before changing plugins or settings. A quick full backup from your host is enough.
- Temporarily disable your security or firewall plugin and re-run the test. If the error disappears, look in that plugin for a setting about blocking the server’s own IP, REST requests or loopback requests, then switch it back on.
- Disable other plugins one at a time if the loopback test still times out. A slow or misbehaving plugin often shows up this way. On a live shop, do this on a copy rather than the real site.
- Check your CDN or proxy. Services in front of the site can challenge or block requests from your own server. Their dashboards usually log blocked requests.
- Ask your host specific questions. “Can my server make outbound HTTPS connections to api.example.com?”, “Is loopback to my own domain allowed?”, “Which versions of cURL and OpenSSL does this server run, and is the CA certificate store current?” Precise questions get precise answers. Our hosting and domain support exists for exactly this kind of back-and-forth if you would rather not handle it yourself.
Why it matters even when the site looks fine
A cURL error rarely takes a site offline, so it tends to sit in Site Health for months. The cost shows up elsewhere:
- Updates fail quietly. If WordPress cannot reach WordPress.org, security fixes do not arrive.
- Payments go unconfirmed. Gateways often confirm payment by calling your site back, and your site may also need to call theirs. When those calls fail, orders sit in “pending payment” even though the customer paid. Our page on fixing payment gateway problems covers that side.
- Scheduled tasks stall. Loopback failures can stop WordPress’s task runner from firing, so scheduled posts, backups and emails slip.
- The block editor can misbehave. Problems reaching your own site often show up next to REST API errors in Site Health.
For a wider view of what the other Site Health warnings mean and which ones to leave alone, see our walk-through of the Site Health screen.
Preventing repeat cURL errors
- Stay on a hosting plan where the server software is kept current. Very old servers are behind most SSL errors.
- Keep PHP on a supported version, which usually brings a newer cURL with it.
- Do not stack several security, firewall and CDN layers that each block traffic on their own rules. One well-configured layer is easier to reason about.
- Check Site Health after any hosting move, DNS change or new security plugin, while you still remember what changed.
cURL errors are one entry among many in our overview of WordPress errors and fixes, which is useful if you are seeing several problems at once and are not sure which to start with.
Need it looked at?
These errors sit between WordPress and the server, which is why they can bounce between your developer and your host with nobody owning them. If that is where you are, send us the exact error text and a screenshot of Site Health. We will tell you honestly whether it is a plugin, a setting or something only the host can change, and fix what is ours to fix. Our WordPress fixing work covers it.
Next in this series: The REST API Encountered an Error: WordPress Fix
