Недоступен раздел обновлений в WordPress: причины и пошаговое исправление

Короткий ответ: Раздел «Обновления» в админ-панели WordPress перестаёт работать, когда веб-сервер не может связаться с api.wordpress.org. Чаще всего проблема вызвана отключённым wp-cron, заблокированным fsockopen в PHP или firewall/CloudFlare, который режет исходящие HTTPS-запросы. Ниже — три проверенных сценария диагностики и исправления.

Дата публикации: 5 июня 2026
Автор: Команда GuruPractice
Последнее обновление: 5 июня 2026

Почему раздел обновлений может быть недоступен

WordPress обновляет ядро, плагины и темы через внешнее API по адресу https://api.wordpress.org. Если этот HTTPS-запрос не доходит — страница «Обновления» в админ-панели показывает ошибку: «Не удалось проверить наличие обновлений» или просто пустой экран с предупреждением.

Основные причины:

1. WP-Cron не отрабатывает — WordPress полагается на собственный механизм cron для фоновых проверок обновлений
2. Функция PHP fsockopen() отключена хостингом — без неё WP не может открыть сокет к внешнему серверу
3. Firewall или CloudFlare блокирует исходящие запросы — часто встречается на дешёвых shared-хостингах
4. Неверный WP_HTTP_BLOCK_EXTERNAL — константа в wp-config.php, запрещающая любые внешние HTTP-запросы
5. Проблемы с SSL-сертификатами (cURL) — устаревший CA-бандл или неверная цепочка сертификатов

Шаг 1. Проверка wp-cron (самая частая причина)

WordPress запускает запланированные задачи не через системный cron, а через WP-Cron — имитацию, которая срабатывает при каждом посещении сайта посетителем. Если на сайте мало трафика, WP-Cron может просто не запускаться.

Как проверить:

1. Установите плагин WP Crontrol (бесплатный, в репозитории)
2. Перейдите в Инструменты → События Cron
3. Посмотрите, есть ли событие wp_version_check и wp_update_plugins со статусом «Следующий запуск»

Если событий нет или они просрочены — проблема в wp-cron.

Исправление:

Добавьте в wp-config.php:

define('DISABLE_WP_CRON', false);

А лучше — настройте настоящий системный cron. Отключите WP-Cron и создайте задачу в cPanel или через SSH:

# Отключить встроенный wp-cron — добавить в wp-config.php
define('DISABLE_WP_CRON', true);

# Добавить в системный crontab (выполняется каждые 15 минут)
*/15 * * * * /usr/bin/php /путь/к/wp-cron.php >/dev/null 2>&1

Это самое эффективное решение — системный cron работает независимо от посещаемости.

Шаг 2. Проверка fsockopen и allow_url_fopen

WordPress использует несколько транспортов для HTTP-запросов: cURL, fsockopen, streams. Если fsockopen отключён на хостинге — WP теряет один из каналов связи.

Как проверить:

Создайте php-файл в корне сайта (например /info.php) с содержимым:

<?php
phpinfo();

Откройте его в браузере, найдите секцию Core → allow_url_fopen — должно быть On.
Найдите секцию sockets — модуль должен быть включён (или SimpleXML).

Исправление:

• На shared-хостинге — откройте PHP Selector или настройки PHP в панели хостинга и включите allow_url_fopen + модуль sockets
• На VPS/Dedicated — проверьте, что PHP собран с поддержкой сокетов:

php -m | grep sockets
php -i | grep allow_url_fopen

Если allow_url_fopen = Off, отредактируйте php.ini:

allow_url_fopen = On

И перезапустите веб-сервер:

sudo systemctl restart php8.3-fpm   # или php8.1-fpm
sudo systemctl restart nginx

Шаг 3. Проверка firewall и CloudFlare

Некоторые хостинг-провайдеры блокируют исходящие соединения на уровне iptables или firewalld. CloudFlare под опцией «Under Attack Mode» тоже режет запросы к api.wordpress.org.

Как проверить:

Войдите по SSH и выполните тест соединения:

# Проверка DNS
nslookup api.wordpress.org

# Проверка HTTPS-соединения
curl -v --connect-timeout 5 https://api.wordpress.org

# Проверка через PHP
php -r "echo file_get_contents('https://api.wordpress.org/');" 2>&1

Если curl отвечает, а php нет — проблема в PHP-окружении (см. Шаг 2).
Если оба не отвечают — блокировка на уровне сети.

Исправление:

1. CloudFlare: снимите «Under Attack Mode» или отключите CloudFlare для api.wordpress.org
2. Хостинг: откройте тикет в поддержку — «разблокируйте исходящие соединения к api.wordpress.org»
3. Свой сервер: проверьте iptables:

sudo iptables -L -n | grep DROP
# Если есть блокировка — добавьте разрешение:
sudo iptables -A OUTPUT -d api.wordpress.org -j ACCEPT

Сохраните правила: sudo netfilter-persistent save

Шаг 4. Проверка WP_HTTP_BLOCK_EXTERNAL (самый быстрый тест)

Откройте wp-config.php и найдите строки:

define('WP_HTTP_BLOCK_EXTERNAL', true);

Если эта константа установлена в true, WordPress блокирует все внешние HTTP-запросы, включая проверку обновлений. Либо закомментируйте строку, либо добавьте разрешённые хосты:

define('WP_HTTP_BLOCK_EXTERNAL', true);
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org');

Когда проблема остаётся — переустановка WordPress вручную

Если раздел обновлений не работает, но все проверки выше пройдены — скачайте свежую версию WordPress вручную и распакуйте поверх (Файлы → FTP → загрузить новые файлы):

cd /var/www/your-site
wget https://wordpress.org/latest.zip
unzip latest.zip
cp -r wordpress/wp-admin wp-content .
cp -r wordpress/wp-includes .
rm -rf wordpress latest.zip

Важно: не удаляйте wp-content и wp-config.php — обновляются только wp-admin и wp-includes.

Профилактика

1. Настройте системный cron вместо WP-Cron
2. Используйте хостинг с поддержкой allow_url_fopen и sockets
3. Не отключайте CloudFlare Proxy (оранжевое облачко) без проверки совместимости
4. Раз в месяц проверяйте раздел обновлений вручную
5. Держите PHP и MySQL/MariaDB на актуальных версиях

Заключение

Недоступный раздел обновлений — в 90% случаев одна из трёх причин: сломанный wp-cron, отключённый fsockopen или блокировка firewall. Пройдите по шагам сверху вниз — каждого шага достаточно, чтобы либо найти проблему, либо исключить целый класс причин. После исправления обновления WordPress начнут работать снова.