when shell env includes https_proxy, wp core check-update fails without php-curl installed

Bug Report

[✅] Yes, I reviewed the contribution guidelines.
[✅] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

wp-cli seems to honor http_proxy and/or https_proxy shell environment variables properly only when php-curl is installed, but when using the fallback fsockopen transport of Requests, wp core check-update and wp core download --force fail in misleading fashion, leading to the possible mistaken conclusion that the current install is up to date.

Here is a shell session on a host that must use a proxy to reach the public internet and that does not have php-curl installed:

$ curl -s https://api.wordpress.org/core/version-check/1.7/?locale=en_US | jq . |head -n 20
{
  "offers": [
    {
      "response": "upgrade",
      "download": "https://downloads.wordpress.org/release/wordpress-6.8.3.zip",
      "locale": "en_US",
      "packages": {
        "full": "https://downloads.wordpress.org/release/wordpress-6.8.3.zip",
        "no_content": "https://downloads.wordpress.org/release/wordpress-6.8.3-no-content.zip",
        "new_bundled": "https://downloads.wordpress.org/release/wordpress-6.8.3-new-bundled.zip",
        "partial": false,
        "rollback": false
      },
      "current": "6.8.3",
      "version": "6.8.3",
      "php_version": "7.2.24",
      "mysql_version": "5.5.5",
      "new_bundled": "6.7",
      "partial_version": false
    },
$ wp core version
6.8.2
$ wp core check-update
Success: WordPress is at the latest version.
$ wp core download --force
Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/version-check/1.7/?locale=en_US': stream_socket_client(): Unable to connect to ssl://api.wordpress.org:443 (Connection timed out).

Now let's try again after installing php-curl:

$ dpkg -l |grep "php.*curl"
ii  php8.2-curl                                8.2.29-1~deb12u1                        amd64        CURL module for PHP
$ wp core check-update
+---------+-------------+-----------------------------------------------------------------------+
| version | update_type | package_url                                                           |
+---------+-------------+-----------------------------------------------------------------------+
| 6.8.3   | minor       | https://downloads.wordpress.org/release/wordpress-6.8.3-partial-2.zip |
+---------+-------------+-----------------------------------------------------------------------+

Steps to replicate

Create a container or VM (let's call it internal.example.org) that must use a proxy of the form http://proxy.example.org:3128 to reach the public Internet.
Confirm access to public resources, specifically the URL https://api.wordpress.org/core/version-check/1.7/?locale=en_US with a tool such as curl.
install the most recent vulnerable version of wordpress on internal.example.org
confirm WP install is reachable locally
attempt both wp core check-update and wp core download --force on internal.example.org

Describe what you would expect as the correct outcome

I would expect both check-update and download --force to correctly identify the existence of a new minor or major version. Failing that, I would expect both to give a cogent error.

Multiple possible approaches could be pursued, including tests both for the availability of curl and the presence of proxy environment variables, but the present defaults present an ugly tripping hazard.

Environment where this error occurs

$ wp --info
OS:     Linux 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 (2025-09-20) x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php8.2
PHP version:    8.2.29
php.ini used:   /etc/php/8.2/cli/php.ini
MySQL binary:   /usr/bin/mariadb
MySQL version:  mariadb  Ver 15.1 Distrib 10.11.14-MariaDB, for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:
WP-CLI root dir:        phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:      phar://wp-cli.phar/vendor
WP_CLI phar path:       phar:///usr/local/bin/wp
WP-CLI packages dir:
WP-CLI cache dir:       /localhome/phptest/.wp-cli/cache
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.12.0

Additional context

Similar error to wp-cli/checksum-command#93

This seems like a duplicate of wp-cli/wp-cli#3019.

The tl;dr of that conversation:

php-curl happens to honor the http_proxy env var
Requests defers honoring that env var to the library user (e.g., WordPress core or WP-CLI) (see also Auto use Proxy if HTTP_PROXY & HTTPS_PROXY Environment variable is set WordPress/Requests#218)
WP-CLI doesn't want to blindly trust that env var
One can manually configure proxy support via wp-cli.yml and the extra-php config

We might want to document this in our handbook.

EDIT: this is still a tripping hazard. Not a dupe because the bug is that check-update wrongly reports the install is up-to-date!

It does not make sense to merge this into a closed issue. Is there an existing ticket to improve documentation on wp-cli.yml? I spent time looking for where/how proxy config is set, and multiple sources just pointed back to wp-config.php as being the place to handle that, which seems wrong/bad.

Further, if the will of the maintainers is to move in the direction of documentation, there also needs to be a fix that prevents check-update from wrongly reporting that an install is up to date. I seem to have failed to convey myself clearly: this command behaves inconsistently, and can lead a user to a mistaken conclusion about the status of an install. That, the confusion, is the core thing I would like to see fixed.

Now, would I like to see http_proxy and https_proxy honored regardless of the presence of php-curl? Yes! I understand if the maintainers do not want to go down that path, and I am not going to push for that outcome. I would like to make sure folks always get either a correct response or a hard and clear error when wp core check-update is called, however.

So again, regardless of the outcome of this ticket, for anybody else reading this in the future: if you're seeing the output of wp core check-update report that you're up to date, but that does not seem right: check to confirm that php-curl is installed. Likewise, if you're getting Error: RuntimeException that includes the string stream_socket_client(): Unable to connect you probably have Requests falling back to the fsockopen Transport instead of the more feature-complete php-curl, so confirm that you have php-curl.

Right, so this is two-fold:

The command's output is misleading it fails to make an external request due to the proxy configuration.

WP-CLI simply uses wp_version_check() to check for updates. If that function fails to trigger an error due to network configuration right now, then that would need fixing in core.
On the WP-CLI side, if the update_core transient is empty (for example if wp_version_check failed, we could potentially display a warning. That would help distinguish between actual up-to-date sites and missing updates due to network issues. Happy to accept a PR with some tests here if this route proves viable.

It's unclear how to configure WP-CLI to honor the http_proxy env var, for example through wp-cli.yml.

wp-cli.yml is documented in our handbook already. My suggestion was specifically to document how to do this configuration. You might be able to do something like this:

# In wp-cli.yml
require:
  - path-to/proxy.php

// proxy.php

$proxy_host = getenv( 'HTTP_PROXY' );

if ( ! $proxy_host ) {
	return;
}

$proxy_url = parse_url( $proxy_host );

if ( $proxy_url['host'] ) {
	define( 'WP_PROXY_HOST', $proxy_url['host'] );
}

if ( $proxy_url['port'] ) {
	define( 'WP_PROXY_PORT', $proxy_url['port'] );
}

This would configure the proxy for HTTP requests in core when using WP-CLI, similar to when you define this in wp-config.php. The setup would be slightly more complex for modifying HTTP requests from WP-CLI itself.

I seem to have a bit of a Catch-22, since as I set up a dev environment (necessarily in a space that will require http_proxy to reach the public internet), I get errors like the following when running composer behat:

--- Failed steps:

001 Scenario: Check for update via Version Check API      # features/core-check-update.feature:5
      When I run `wp core download --version=5.8 --force` # features/core-check-update.feature:9
        $ wp core download --version=5.8 --force
        Downloading WordPress 5.8 (en_US)...

        Error: Failed to get url 'https://wordpress.org/wordpress-5.8.tar.gz': cURL error 28: Failed to con$
ect to wordpress.org port 443 after 10000 ms: Timeout was reached.
        cwd: /tmp/wp-cli-test-run--69091bf8ad9938.13355165/
        run time: 10.085129022598
        exit status: 1 (RuntimeException)

On the theory that something is better than nothing, and that perhaps I can be pointed in the direction of a good-enough setup to make a useful test, I'm commenting here, but I cannot currently commit to a timeline for submitting a PR, and would welcome somebody else making such a commitment.

No worries, thanks for looking into it. Let's see if we can use some HTTP mocks for these tests.

It doesn't help that wp_trigger_error, which is called by wp_version_check only prints a warning if WP_DEBUG is true (--debug flag). So you might actually get a warning today when enabling debug mode.

@swissspidy

I independently reproduced and confirmed this issue, and tested PR #303.

Reproduction

Using a Lima VM (Ubuntu 24.04, PHP 8.3.6 with php-curl), I:

Installed WordPress 6.4
Verified wp core check-update correctly detected updates (6.4.7 minor, 6.9 major)
Blocked api.wordpress.org via iptables
Cleared the update_core transient
Ran wp core check-update

Result (main branch):

Success: WordPress is at the latest version.

As @swissspidy noted, using --debug reveals the underlying error from wp-includes/update.php, but users without --debug get no indication the check failed.

PR #303 Testing

I tested PR #303 with the same network-blocked scenario:

Result (PR #303):

Warning: Failed to check for updates: cURL error 7: Failed to connect to api.wordpress.org port 80 after 1 ms: Couldn't connect to server

The fix correctly surfaces the error without requiring --debug. Normal operation (network available) continues to work as expected.

I used Claude to assist with setting up the test environment.

@ekamran

For enabling the HTTP proxy configuration support in WP-CLI, @ekamran has kindly built and shared https://github.com/ekamran/wp-cli-http-proxy-command today. If you're interested, I recommend giving it a try and providing feedback.

Navigation Menu

Repository navigation

when shell env includes https_proxy, wp core check-update fails without php-curl installed #292

Bug Report

Reproduction

PR #303 Testing

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

when shell env includes https_proxy, wp core check-update fails without php-curl installed #292

Description

Bug Report

Activity

swissspidy commented on Oct 29, 2025

tarheelcoxn commented on Oct 29, 2025

tarheelcoxn commented on Oct 29, 2025

swissspidy commented on Oct 29, 2025

tarheelcoxn commented on Nov 6, 2025

swissspidy commented on Dec 3, 2025

swissspidy commented on Dec 3, 2025

tarheelcoxn commented on Feb 2, 2026

Reproduction

PR #303 Testing

swissspidy commented on May 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions