2026年11月12日
2026年11月12日
WordPress “cURL error 28” Timeout: Causes and Fixes
This article is a localized edition of the Japanese original. Read the Japanese original
"cURL error 28" means that when WordPress made an HTTP request to an external server (or to itself), it did not get a response within the allotted time and the request was cut off. It is not a bug in WordPress core: something is making it wait, somewhere in the network path, DNS, the remote server or a plugin on your own site. This article sorts out what the error means depending on where it appears, then walks through reproducing the request on the server to narrow down the cause and fixing it properly.
What the Error Message Means
The message you see is usually one of these:
cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes receivedcURL error 28: Connection timed out after 5001 millisecondscURL error 28: Resolving timed out after 5000 milliseconds
cURL is the library PHP uses for HTTP requests, and error 28 means "timeout." The end of the message tells you at which stage it stopped.
- Resolving timed out: It stopped while looking up the IP address for the domain name (DNS resolution)
- Connection timed out: The connection to the remote server could not be established at all
- Operation timed out ... 0 bytes received: The connection was made, but no response came back
The number of milliseconds is the timeout that was set for that request. WordPress functions such as wp_remote_get() give up after 5 seconds unless told otherwise. Some processes, such as the Site Health loopback check, use their own longer values.
Where the Error Appears Points to the Cause
Even with the same "cURL error 28," what you should suspect depends on where it appeared.
- It appears under "Tools" → "Site Health" as a REST API or loopback request failure: WordPress failed to connect to its own URL. Suspect your own site (plugins, PHP sessions, Basic authentication, the server firewall).
- Plugin or theme updates or new installs fail: Requests to external servers such as WordPress.org are not getting through. Suspect the server's outbound connections, DNS or IPv6 handling.
- It appears in a specific plugin's external API integration (payments, email delivery, social media integration, etc.): Either that remote service is slow, or there is a problem on the route from your server to it.
Step 1: Reproduce the Request on the Server
A URL that opens in your browser may still be unreachable from the server. The basic rule is to judge from the server side.
Try it the same way WordPress does with WP-CLI
If WP-CLI is available, test the same request using the WordPress HTTP API.
wp eval '$r = wp_remote_get( "https://api.wordpress.org/", array( "timeout" => 15 ) ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r ); echo PHP_EOL;'
If you get a status code (such as 200), the request at least completes within 15 seconds. If it fails at 5 seconds but succeeds at 15, "the remote side is slow"; if it still errors at 15 seconds, "the route is blocked." To test the loopback to your own site, replace the URL with your site's address.
Use the curl command over SSH
If you have SSH access, curl's verbose output shows which stage is taking time.
curl -v -m 20 -o /dev/null https://api.wordpress.org/
curl -4 -v -m 20 -o /dev/null https://api.wordpress.org/
If the first line stops at name resolution or connection while the second line with -4 (IPv4 only) goes through immediately, the server's IPv6 connectivity is very likely not working properly. If it stops at name resolution, the problem is the server's DNS settings (resolver).
Step 2: Isolate Causes on Your Own Site
Plugin and theme conflicts
Loopback failures are often caused by plugins. The troubleshooting mode of the "Health Check & Troubleshooting" plugin lets you recheck Site Health with all plugins disabled and the default theme active, for your logged-in session only. If the error disappears, re-enable the plugins one at a time to find the culprit.
Waiting caused by PHP sessions
If a plugin opens a PHP session with session_start() and never closes it, a loopback request using the same session keeps waiting for the earlier request to finish and times out. Site Health may show a warning at the same time saying that a PHP session was created. In that case, check for an update to the plugin in question; if that does not help, report it to the author or consider an alternative plugin.
Basic authentication and IP restrictions
If you protect the whole site with Basic authentication or IP restrictions, as on a staging environment, requests from WordPress to itself are blocked too. Either allow access from the server's IP address or, for a test environment, treat the loopback warning as a known issue.
Constants that block external requests
If WP_HTTP_BLOCK_EXTERNAL is defined as true in wp-config.php, WordPress blocks requests to any host not listed in WP_ACCESSIBLE_HOSTS. In this case you get a different error message rather than a timeout, but checking it while you review the settings keeps you from confusing it with other causes.
Step 3: Fix It According to the Cause
Before you start, back up wp-config.php, functions.php and your own plugin files before editing them.
If the remote side is just slow, extend the wait for that request only
If you know an external API responds slowly, extend the timeout only for requests to that service. Extending the wait for every request on the site makes the whole admin area sluggish when the remote service goes down, so narrowing the target is the safe approach.
add_filter( 'http_request_args', function ( $args, $url ) {
if ( 'api.example.com' === wp_parse_url( $url, PHP_URL_HOST ) ) {
$args['timeout'] = 20;
}
return $args;
}, 10, 2 );
Replace api.example.com with the actual remote domain. Add this to your own plugin or your theme's functions.php. If the plugin has its own "timeout" setting, use that first.
If IPv6 is the bottleneck, the proper fix is on the server side
If the cause is a broken IPv6 route, the proper fix is to have the server administrator or hosting company check the state of outbound IPv6 connectivity. As a stopgap when you cannot act right away, you can restrict WordPress's cURL requests to IPv4.
add_action( 'http_api_curl', function ( $handle ) {
curl_setopt( $handle, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4 );
}, 10, 1 );
This only hides the server-side problem, so remove it once the cause is fixed.
If outbound connections are blocked, check the firewall
If you manage your own server on a VPS or in the cloud, check that outbound ports 80 and 443 are allowed in the firewall (iptables, ufw, cloud security groups, etc.). If only updates fail on a shared hosting server, check the hosting company's outage information and whether there is a setting that restricts connections to overseas servers.
Fixes you should not use
Searching online may turn up the advice to "set sslverify to false," but that only turns off certificate verification and does not solve the timeout. It lowers the security of your connections, so do not use it. Likewise, extending the timeout to several minutes only makes the admin area slow while hiding the root cause.
Checking Whether It Is Fixed
Reopen "Tools" → "Site Health" and check that the items about the REST API and loopback no longer show problems. Site Health results may be cached for a while, so if the change does not show up, wait a bit and reload. If updates were failing, recheck under "Dashboard" → "Updates" and see whether plugin updates go through. Site Health item names and display may change between WordPress versions (as of October 2026).
Summary
- "cURL error 28" is an HTTP request timeout. Resolving / Connection / Operation at the end of the message tells you the stage where it stopped
- If it appears in the Site Health loopback check, suspect your own site (plugins, PHP sessions, Basic authentication); if it appears during updates, suspect the server's outbound connections, DNS or IPv6
- Reproduce the request from the server with
wp_remote_get()via WP-CLI orcurl -vover SSH to isolate the cause - Extend the timeout only for slow remote services with
http_request_args, and avoid disablingsslverifyor extending timeouts globally
- How to Send External Requests with the WordPress HTTP API
- How to Resolve WordPress Site Health Warnings
Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)