WordPress cURL Error 28: How to Fix Connection Timeouts

cURL error 28 means a request took longer than its allowed time. It shows up during plugin updates, license checks, payment callbacks, remote image imports, REST API tests, and loopback requests.

The full error usually looks like this:

cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received
cURL error 28: Resolving timed out after 5001 milliseconds
cURL error 28: Connection timed out after 30000 milliseconds

Raising the timeout hides the symptom. It doesn't fix the network problem.

First Five Minutes: Triage cURL Error 28

1. Copy the full error. Note the destination URL and the timeout value.
2. Open Tools → Site Health. Check which test fails: REST API, loopback, or WordPress.org connectivity.
3. Ask the host to test DNS and an outbound HTTPS request to the exact destination from the server.
4. If it's a loopback request, check whether the server can reach its own domain.
5. If one plugin triggers it and others don't, the problem is that integration — not the server.

Find the Exact Destination

The URL in the error matters. A request from your server to api.wordpress.org is different from a loopback request to your own domain or a call to Stripe.

Look at the full error string. Note whether it says Resolving timed out (DNS problem) or Connection timed out (network or firewall problem). They point to different fixes.

Check Tools → Site Health and the plugin log that generated the message. If a specific plugin shows the error, note its version and the exact request it makes.

Test From Outside WordPress

A browser on your laptop working doesn't prove the server can make outbound requests. Test from the web server itself.

Ask the host to run:

dig api.wordpress.org
curl -vI https://api.wordpress.org --max-time 10
curl -vI https://your-own-domain.com --max-time 10

Look at where it hangs. DNS resolution, TCP handshake, TLS negotiation, or the first byte from the remote server.

The host should also check:

• Outbound firewall rules
• DNS resolvers
• IPv4 and IPv6 routing
• Proxy settings
• Whether the remote service blocks the server IP

Shared hosts sometimes block outbound requests on non-standard ports. That breaks payment gateways and license servers that don't use 443.

Check Loopback Requests

If WordPress can't call its own domain, the problem is usually one of these:

• DNS points to a CDN or proxy the server can't reach
• Firewall blocks the server from reaching its own origin IP
• Staging site protected by HTTP basic auth
• Old origin IP still cached in DNS
• Security plugin blocking requests without a user agent

Test with curl from the server to the site's own URL. If it hangs, the loopback path is broken.

Test Plugins and Security Layers

Disable the plugin making the call on staging. If the error disappears, the plugin or the remote service is the problem — not WordPress.

Check WAF logs for blocked REST or admin-ajax.php requests. A security rule that blocks outbound requests without a WordPress user agent causes this often.

If one integration times out while every other connection works, contact that provider. Send timestamps, request IDs, and the exact cURL error. "It's slow" gets nowhere. "cURL error 28 to api.example.com at 14:32 UTC, 30s timeout, request ID abc123" gets a real answer.

Check SSL and Server Software

Confirm that PHP cURL, OpenSSL, and the CA certificate bundle are current. Expired CA bundles break HTTPS requests even when the network path is fine.

Certificate problems usually produce a different cURL error (60 or 77). But a misconfigured TLS inspection layer, an old PHP version, or an outdated cURL build can delay negotiation enough to trigger error 28.

Ask the host for the current PHP version, cURL version, and OpenSSL version. Compare them against the plugin's requirements.

Don't Just Raise the Timeout

Raising a timeout is only safe when the remote task legitimately needs longer and the connection is otherwise healthy. For example, a large file import from a slow remote server.

It's not safe for:

• Checkout requests (visitors won't wait 60 seconds)
• Webhooks (retries are cheaper than blocking)
• Scheduled jobs (queue them and log failures)

For anything user-facing, build retries, timeouts, and logging instead. A request that hangs for 30 seconds and then fails is worse than one that fails fast and retries.

Verify the Fix

Run the exact Site Health test or plugin function that produced the error. Confirm scheduled events complete. Watch the server logs for a day to make sure the timeout doesn't return under load.

If the error comes back during traffic spikes, the problem isn't the timeout value. It's capacity, DNS instability, or a remote service that can't keep up.

Bottom Line

cURL error 28 is almost always one of these: DNS resolution failed, an outbound firewall blocked the request, the loopback path is broken, or a remote service is slow or unreachable. Read the full error, test from the server, and fix the network path. Don't just bump the timeout.