I've been running into trouble with all my localhost install of Wordpress reporting cURL error 28 (timeout) since (I believe!)I've switched my PHP version from 7.0 to 7.2 with brew on my local Mac OS machine. Viewing any of my local site’s admin areas or using the WP CLI the WP update checks and other cURL calls result in failing cURL requests:

Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /Users/…/wp-includes/update.php on line xxx

(xxx line varies on which install, local https site or not, etc, but always boils down to a line catching a curl error)

From what I can tell PHP is using the brew installed cURL and cURL works both in CLI and in PHP, e.g. running this explicitly in a theme functions.php works and returns the expected result (a JSON of updates):

$ch = curl_init("http://api.wordpress.org/core/version-check/1.7/");
curl_setopt($ch, CURLOPT_HEADER, 0);
var_dump("exec", curl_exec($ch));
var_dump("error", curl_error($ch));

Equally, just getting a cURL request on the terminal works as well:

curl -v http://api.wordpress.org/core/version-check/1.7/

Both return the same JSON.

I've tried to edit my WP’s /wp-includes/ various http, request and cURL related classes to debug what is going on. Since the functios.php’s cURL works, but WP’s internal do not, I assume my PHP cURL is working per se.

In /wp-includes/Requests/Transports/cURL.php I've tried to comment out as many curl_setopt calls as possible to approximate the same minimal cURL call that works in my functions.php but with no luck — also I don't know of a way to see the exact cURL settings the request goes out with. curl_getinfo reveals mostly empty or defaulted values, like what I'd expect with a request that never succeeded.

Other things I've tried and checked:

  • Installed Health Check plugin to confirm: Yes, REST API fails, Connection to Wordpress.org fails, Loopback request fails
  • Various combinations of: Disabled plugins & themes, no plugins, fresh WP install
  • phpinfo() tells me cURL is enabled (v7.64.0)
  • I reinstalled curl, openssh, [email protected] via brew several times
  • Restarted computer, restarted apache server
  • Posted on wp.org
  • Checked php error log, checked WP debug.log, set error_reporting to (E_ALL): Nothing suspicious in regards to cURL calls shows up
  • Firewall is disabled (also the other cURL calls work, so…)

I'm absolutely baffled about what is going on here and why WP’s cURL requests are failing and essentially rendering my entire development environment useless.

Any help or suggestions to get to the bottom of this is very, very much appreciated.

Edit: FYI, same issue on stackoverflow as well: https://stackoverflow.com/questions/54906545/how-to-set-or-circumvent-curlopt-connecttimeout-in-php-globally

  • Have you seen this? samuelaguilera.com/post/curl-error-28-wordpress Commented Feb 26, 2019 at 15:14
  • @MikeNGarrett Had seen it, yes, but that didn't apply to a case where a cURL would normally work, but not from within WP’s internals.
    – kontur
    Commented Feb 26, 2019 at 15:17
  • 1
    You don't happen to have WP_HTTP_BLOCK_EXTERNAL set, do you? Since it's an issue with resolving, could you try curling the IP for api.wordpress.org instead of the domain name. Also, try setting CURLOPT_CONNECTTIMEOUT to 30 seconds or longer. Commented Feb 26, 2019 at 15:37
  • I don't have WP_HTTP_BLOCK_EXTERNAL set and am also trying this form different local installations. Curl’ing the IP I get a 302 because it seems to fetch from wordpress.org not api.wordpress.org, but I think this can be expected. Increasing the timeout, via filter, constants or directly in WP core classes does not have any other effect except it taking longer to timeout; it’s not an issue with an actual timeout, I reckon, just that the timeout is the final trigger for aborting the cURL that is set to fail from the beginning.
    – kontur
    Commented Feb 27, 2019 at 7:09
  • @MikeNGarrett You were spot on about CURLOPT_CONNECTTIMEOUT, actually! I've looked at the CURLOPT_TIMEOUT option all the time, changing it’s values, but bumping CURLOPT_CONNECTTIMEOUT actually resolves the issue, partially. The problem is a) I don't know what changed in my PHP upgrade that the behavior in this regard is different now, and b) I don't know how to set this aside from the http_api_curl — for example my WP CLI calls still fail, because they use the 10s default defined in /wp-includes/class-request.php.
    – kontur
    Commented Feb 27, 2019 at 13:16

1 Answer 1


Try This First: Your Problem Might Be DNS

In my testing this is a problem with DNS resolving. In my case it's because the DNS filter/cache I run on my local network wasn't responding to requests. After restarting the service on the DNS server my requests got through quickly & easily. I would suggest checking any local DNS servers on your network.

OP also resolved the problem by specifically changing DNS settings to Google's DNS provider, but I saw elsewhere that for some problem the problem was Google's DNS, so switching away from Google fixed the problem.

Back to your regularly scheduled answer:

If it's a CURL_CONNECTTIMEOUT problem, then you I think you can do this:

function filter_request_timeout($timeout) {
    return 100; // desired time in seconds
add_filter('http_request_timeout', 'filter_request_timeout' );

Both CURLOPT_CONNECTTIMEOUT and CURLOPT_TIMEOUT use the same value when the timeout is set: https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-http-curl.php#L127

However, if this just happened since installing PHP 7.2 maybe there's another reason. Did you update the cURL extension as well? I'm having the same issue on PHP 7.3 via Homebrew, so I'm going to see what I can do without resorting to adding a filter to the dev version of all my sites.

Update: the http_request_timeout filter is for the default timeout. If the timeout has been set between getting the default and sending the request, it needs to happen in the http_request_args filter:

function johnbeales_filter_request_args( $args, $url ) {

    if(strpos($url, 'wordpress.org') !== false ) {
        $args['timeout'] = 100; // Timeout in seconds

    return $args;
add_filter('http_request_args', 'johnbeales_filter_request_args', 10, 2);

Since we're having trouble connecting to wordpress.org, I only adjusted the timeout on requests to wordpress.org.

  • Hey @"John B", thanks for your answer! I've managed to use a filter to overwrite the WP curl request settings, but the problem is that a) I'd need to do this for every localhost install I have (10~20 active at any point) and b) the filters only affect parts that load the theme functions — e.g. the WP CLI calls will still fail.
    – kontur
    Commented Mar 3, 2019 at 20:02
  • Yeah, it's not ideal, and weird. With me, when I set a 100-second timeout, sometimes my whole browser request timed out and I just got a 503, (IIRC). Once I fixed the DNS it was super-fast. I saw somewhere that there might be a problem with Google DNS and those WordPress.org URLs, so if you're using Google DNS maybe try Cloudflare and see if that fixes it.
    – John B
    Commented Mar 4, 2019 at 14:52
  • Well, this is astonishing. Explicitly added e.g. Google’s DNS servers ( and and the cURL connection requests no longer time out. I think you ought to highlight that in your answer, since that is essentially what solved the problem; not using my default DNS servers in my MacOS network settings. Probably I thought the PHP update introduced the issue, but I remember I updated PHP because I had updated MacOS — so maybe that update changed or reset some network settings.
    – kontur
    Commented Mar 5, 2019 at 9:25
  • @kontur Done! Hopefully anyone else can fix this more easily than we did ;)
    – John B
    Commented Mar 5, 2019 at 21:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.