11 сентября 2026 года в админке WordPress на двух разных хостингах одно и то же: Site Health не достучался до WordPress.org. Ошибка cURL 28, десять секунд, адрес 66.6.42.251. Через два часа ping до wordpress.org на соседнем 66.6.42.252 шёл за 129–130 мс. Сайт у посетителя при этом может открываться как ни в чём не бывало.
13 сентября, воскресенье, 256-й день года: официальный День программиста. К празднику это выглядит как «заблокировали wordpress.org». По двум хостингам и одному ping так говорить рано. Ниже: что именно проверяет админка, почему ping не опровергает таймаут PHP и как обновляться, если кнопка в «Обновлениях» молчит.
Что увидели 11 сентября
Сообщение из Site Health, как его прислали с двух площадок в 11:12:
«Подключение к серверам WordPress.org используется для проверки новых версий, установки и обновлений WordPress, плагинов и тем. Ошибка: Ваш сайт не смог подключиться к WordPress.org по 66.6.42.251, и вернул ошибку: cURL error 28: Connection timed out after 10001 milliseconds».
В 13:28 с другой машины ушёл ping на wordpress.org [66.6.42.252], 32 байта данных. Три ответа: 130 мс, 129 мс, 129 мс, TTL 51. Потери не было.
Это не противоречие и не доказательство, что «всё уже ожило». Это два разных протокола и два разных IP.
Что на самом деле дёргает Site Health
Тест «связь с WordPress.org» живёт в WP_Site_Health::get_test_dotorg_communication(). Он не пингует wordpress.org. Он делает wp_remote_get( 'https://api.wordpress.org' ) с таймаутом 10 секунд. 10001 миллисекунда в ошибке: PHP ждал чуть больше этих десяти секунд и сдался. Байтов в ответ не пришло.
IP в тексте ошибки берётся из gethostbyname( 'api.wordpress.org' ), не из A-записи wordpress.org. На 11 сентября 2026 года DNS выглядел так:
- wordpress.org → 66.6.42.252
- api.wordpress.org → 66.6.42.251
- downloads.wordpress.org → 66.6.42.250
Елена упёрлась в .251, Maxim пинговал .252. ICMP до витрины и HTTPS из PHP до API: разные двери. Фильтр на 443 может резать API, а ping при этом зелёный. Обратное тоже бывает: ICMP закрыт, обновления ставятся.
Это ещё не запись в реестре
Официального сообщения Роскомнадзора о блокировке wordpress.org на момент подготовки материала нет. Форма проверки в едином реестре и на blocklist.rkn.gov.ru требует капчу, живую выгрузку «wordpress.org есть / нет» отсюда не снять. Третьи стороны тоже не показали готовой карточки блокировки. Писать «внесли в реестр» по таймауту PHP нельзя.
Картина 11 сентября другая. С отдельного VPS в 15:00 MSK HTTPS до wordpress.org отдавал 200 примерно за 1,2 с, до api.wordpress.org: 302 за 0,56 с, до downloads.wordpress.org: 302 за 0,56 с. Ping до .251 и .252 шёл около 179 мс, потерь не было. Запрос version-check 1.7 ответил оффером WordPress 7.1. Сами серверы проекта в этот час не лежали.
Два хостинга с одним и тем же cURL 28: это уже не «сломан PHP на одном тарифе». Это исходящий HTTPS с площадки, где крутится сайт. ТСПУ на пути провайдера, фильтр исходящих у хостера, IPv4-only у PHP при кривом AAAA, таймаут на середине пути. Без traceroute и без curl с самого хостинга гадать, какой из вариантов, бессмысленно.
Что ломается на рабочем сайте
Витрина от этого теста не падает. Падает канал, которым ядро ставит и обновляет само себя, плагины и темы: api.wordpress.org и downloads.wordpress.org. «Плагины → добавить новый», «Обновления», фоновые мелкие патчи, проверка версии, иногда перевод пакетов. Сайт при этом может открываться с телефона, из офиса и из дома.
Актуальное ядро на 11 сентября 2026: WordPress 7.1, релиз 19 августа, страница архива релизов. Точечный 7.1.1 по расписанию Make WordPress Core намечен на 17 сентября. Если к четвергу кнопка в админке так и не достучится до API, патч сам не приедет.
Сначала диагностика с хостинга, не ping с ноутбука
Проверять нужно там, где крутится PHP: SSH, терминал панели, WP-CLI. Ping с домашнего Windows до wordpress.org отвечает на другой вопрос.
getent hosts api.wordpress.org wordpress.org downloads.wordpress.org curl -4 -Iv --max-time 15 https://api.wordpress.org/ curl -4 -Iv --max-time 15 https://downloads.wordpress.org/ curl -4 -sS --max-time 15 "https://api.wordpress.org/core/version-check/1.7/" | head
Если DNS резолвится, а HTTPS висит до таймаута: фильтр или обрыв на 443. Если HTTPS с SSH проходит, а Site Health в админке нет: смотреть PHP, исходящие у FastCGI/FPM, security-плагин, не IPv6 ли тянет PHP в чёрную дыру. Если с SSH тоже 28, писать хостеру: исходящий HTTPS на api.wordpress.org и downloads.wordpress.org, не «почините ping».
WP-CLI, если бинарь есть:
wp core version wp core check-update wp plugin list --update=available
Те же таймауты, что у админки, означают: CLI ходит в ту же API и тоже не пролезет. Отключать проверку TLS «чтобы заработало» не стоит. Это не лечение фильтра, а дырка в канал обновлений.
Если кнопки в админке нет, а браузер wordpress.org открывает
Исходящий с хостинга и входящий в браузер: разные пути. Zip ядра по-прежнему лежит на wordpress.org/download. Ручное обновление: бэкап файлов и базы, затем шаги из официальной инструкции Updating WordPress. Коротко: не трогать wp-config.php и содержимое wp-content, кроме файлов, которые ядро само перезаписывает; wp-admin и wp-includes менять целиком; после заливки зайти в /wp-admin/ и при необходимости пройти upgrade.php.
Плагин и тему в таком режиме ставят zip-ом из каталога, если страница плагина в браузере открывается, или с зеркала, которому вы доверяете. Случайный zip с форума: это уже не «обошли таймаут», а неизвестный код на проде.
Перед любой ручной заливкой: копия, не пятничный деплой «на глаз» и не отключение файрвола «на всякий случай».
13 сентября: праздник, не отгул у хостера
День программиста в России: 256-й день года. В обычный год это 13 сентября, в високосный 12-е. 2026-й обычный. Это закрепил указ Президента РФ от 11.09.2009 № 1034. Профессиональный праздник, не нерабочий день из Трудового кодекса. Касса и хостинг в воскресенье работают. Site Health с cURL 28 сам не починится, потому что «256».
Имеет смысл в пятницу-субботу: бэкап, посмотреть, ставится ли обновление, если нет: zip на диске и письмо хостеру, а не сюрприз в понедельник, когда 7.1.1 уже в расписании. Баги, которые не жрут заказы, могут подождать. Канал обновлений ядра лучше не оставлять на «разберёмся после праздника».
Коротко
- 11.09.2026, два хостинга: Site Health → api.wordpress.org 66.6.42.251, cURL 28 после 10 с.
- Ping до wordpress.org 66.6.42.252 в тот же день отвечал. Это не проверка API.
- С отдельного VPS около 15:00 MSK HTTPS до org/api/downloads открывался, version-check отдавал WordPress 7.1.
- Записи wordpress.org в реестре запрещённых сайтов на этот час нет в виде проверяемого факта. «Заблокировали» из таймаута не следует.
- Сайт может жить, кнопка обновлений: нет. Диагностика: curl с хостинга, не ping с ноутбука. Дальше: хостер или ручной zip по официальной инструкции.
