Меньше, чем ответ, но просто список вещей прямо из моего опыта с ним - возможно, вы что-то упустили.
Отладка запроса и его результатов
Без diggin 'слишком глубоко в процессе обновления, но WP HTTP API использует WP_HTTPкласс. Это также предлагает хорошую вещь: крюк отладки.
do_action( 'http_api_debug', $response, 'response', $class, $args, $url );
Где $responseтакже может быть WP_Errorобъект, который, возможно, говорит вам больше.
Примечание. Из краткого теста кажется, что этот фильтр работает (по какой-то причине) только в том случае, если вы поместите его как можно ближе к месту выполнения запроса. Поэтому, возможно, вам нужно вызвать его из-за обратного вызова на одном из приведенных ниже фильтров.
WP_HTTP Классовые аргументы
Аргументы Classes сами по себе фильтруемы, но некоторые из них возвращаются внутренними методами обратно к тому, что WP считает необходимым.
apply_filters( 'http_request_args', $r, $url );
Одним из аргументов является то ssl_verify, что по умолчанию верно (но для меня это вызывает серьезные проблемы при обновлении, например, с GitHub). Редактировать: после отладки тестового запроса я нашел другой аргумент, который проверяет, установлен ли SSL true. Это называется sslverify(без разделения подчеркивания). Не знаю, где это появилось в игре, если оно действительно используется или заброшено, и если у вас есть шанс повлиять на его ценность. Я нашел это с помощью 'http_api_debug'фильтра.
Полностью на заказ
Вы также можете «просто» переопределить все внутренние компоненты и перейти к пользовательской настройке. Для этого есть фильтр.
apply_filters( 'pre_http_request', false, $r, $url );
Первый аргумент должен быть установлен в true. Чем вы можете взаимодействовать с аргументами внутри $rи результатом parse_url( $url );.
полномочие
Еще одна вещь, которая может сработать, это запускать все через собственный прокси. Это требует некоторых настроек в вашем wp-config.php. Я никогда не пробовал этого раньше, но некоторое время назад я просмотрел константы и суммировал некоторые примеры, которые должны работать, и включил некоторые комментарии на случай, если мне это понадобится однажды. Вы должны определить WP_PROXY_HOSTи WP_PROXY_PORTкак мин. установка. В противном случае ничего не будет работать, и это просто обойдет ваш прокси.
# HTTP Proxies
# Used for e.g. in Intranets
# Fixes Feeds as well
# Defines the proxy adresse.
define( 'WP_PROXY_HOST', '127.0.84.1' );
# Defines the proxy port.
define( 'WP_PROXY_PORT', '8080' );
# Defines the proxy username.
define( 'WP_PROXY_USERNAME', 'my_user_name' );
# Defines the proxy password.
define( 'WP_PROXY_PASSWORD', 'my_password' );
# Allows you to define some adresses which
# shouldn't be passed through a proxy.
define( 'WP_PROXY_BYPASS_HOSTS', 'localhost, www.example.com' );
РЕДАКТИРОВАТЬ
WP_HTTPКласс обычно выступает в качестве базового класса (будет расширен для различных сценариев). Выступающие WP_HTTP_*классы Fsockopen, Streams, Curl, Proxy, Cookie, Encoding. Если вы подключите обратный вызов к 'http_api_debug'-action, то третий аргумент сообщит вам, какой класс использовался для вашего запроса.
Внутри WP_HTTP_curlкласса вы найдете request()метод. Этот метод предлагает два фильтра для перехвата поведения SSL: один для локальных запросов 'https_local_ssl_verify'и один для удаленных запросов 'https_ssl_verify'. WP, скорее всего, определит localкак localhostи что вы получите взамен get_option( 'siteurl' );.
Поэтому я бы попробовал выполнить следующее прямо перед тем, как выполнить этот запрос (или из обратного вызова, который подключен к ближайшему запросу:
add_filter( 'https_ssl_verify', '__return_true' );
# Local requests should be checked with something like
# 'localhost' === $_SERVER['HTTP_HOST'] or similar
# add_filter( 'https_local_ssl_verify', '__return_true' );
Sidenote: в большинстве случаев WP_HTTP_curlбудет использоваться для работы с прокси.
