Loopback WordPress: Site Health, WP-Cron и ошибки 403

В WordPress может быть полностью доступен фронтенд, открываться админка и даже нормально работать REST API, но в Инструменты → Здоровье сайта при этом появляется предупреждение: сайт не может выполнить loopback-запрос. Такая ошибка выглядит второстепенной, однако она указывает на конкретный класс проблем — WordPress не может корректно обратиться к самому себе по HTTP.

Loopback нужен не для «проверки ради проверки». WordPress использует самозапросы для запуска части запланированных событий и проверки стабильности изменений в редакторах тем и плагинов. Поэтому ошибка может проявляться как зависшие cron-события, несвоевременные фоновые операции или предупреждения Site Health.

Ниже — практическая схема диагностики: как отличить ошибку приложения от DNS, SSL, reverse proxy, Basic Auth, WAF или security-плагина и что проверять, прежде чем отключать защиту или менять системный cron.

Что такое loopback-запрос в WordPress

Официальная документация WordPress определяет loopback как ситуацию, когда собственный сервер или сайт пытается подключиться к самому себе. В Site Health Core выполняет такой тест отдельно и сообщает, может ли сайт завершить self-request.

Это важно отличать от обычного запроса посетителя. Браузер приходит на сайт извне, а loopback начинается на сервере, где уже работает WordPress, и возвращается к публичному адресу этого же сайта. На пути могут участвовать DNS, TLS, CDN, reverse proxy, firewall, HTTP Basic Auth и правила безопасности.

В Core loopback используется, в частности, для запуска WP-Cron и для проверки, что изменения в редакторе темы или плагина не сделали сайт недоступным. Поэтому успешная загрузка главной страницы ещё не доказывает, что loopback работает.

Какие симптомы указывают на проблему

Симптом	Что он может означать	Что проверить первым
Site Health: loopback request failed	WordPress не получил ожидаемый ответ от собственного URL	HTTP-код, timeout, DNS и SSL
Запланированные записи выходят с задержкой	WP-Cron не запускается или self-request не доходит до wp-cron.php	WP-Cron, системный cron и loopback
Фоновые задачи периодически зависают	Проблема может быть на уровне cron, очереди или HTTP self-request	События cron и логи приложения
Ошибка появляется только на staging	Часто мешает Basic Auth, maintenance mode или ограничение по IP	Защиту staging и заголовки Authorization
После включения WAF появилась 403	Сервер блокирует собственный запрос через внешний контур	Firewall/WAF events и IP источника
cURL timeout	Запрос не успевает пройти DNS, connect, TLS или upstream	curl с сервера и сетевой маршрут

Как WordPress проверяет loopback

В Core есть отдельный Site Health test для loopback requests. WordPress отправляет HTTP-запрос к своему site_url() и ожидает корректный ответ. Для теста используется ограниченный timeout; Core также умеет передавать Basic Auth, если текущая среда уже работает под HTTP Basic Authentication.

Отдельно WP-Cron использует spawn_cron(), который инициирует HTTP-запрос к wp-cron.php. Этот запрос делается неблокирующим способом, чтобы запуск фонового события не держал пользовательскую страницу дольше необходимого.

То есть Site Health и WP-Cron — связанные, но не одинаковые вещи. Site Health проверяет саму способность сайта выполнить loopback, а cron — отдельный механизм планировщика, который может использовать self-request для запуска событий.

Шаг 1. Сначала повторите запрос с самого сервера

Проверка из браузера недостаточна. Нужно выполнить запрос именно с VPS/хостинга, где работает WordPress. Начните с простого HEAD-запроса:

curl -I https://example.com/

Затем измерьте HTTP-код и общее время:

curl -sS -o /dev/null \
  -w 'HTTP %{http_code} total=%{time_total}s\n' \
  https://example.com/

Если браузер получает 200, а сервер — 403, 401 или timeout, проблема почти наверняка находится не в шаблоне страницы. Сравнивайте именно маршрут «сервер → публичный домен → сервер».

Шаг 2. Проверьте DNS именно внутри сервера

Публичный домен может резолвиться на CDN, старый IP, IPv6-адрес или другой reverse proxy. Поэтому полезно увидеть, куда домен разрешается с самого сервера:

getent hosts example.com

Если доступен dig:

dig +short example.com
dig +short AAAA example.com

Сравните результат с текущей архитектурой. Если сайт находится за Cloudflare или другим CDN, публичный DNS закономерно может указывать не на origin. Это не ошибка само по себе. Ошибка возникает, когда сервер не способен пройти этот маршрут обратно или попадает на неверный origin/виртуальный хост.

Не стоит сразу добавлять домен в /etc/hosts на 127.0.0.1. При HTTPS это может обойти часть реальной цепочки и скрыть проблему с TLS, Host/SNI или reverse proxy. Такой override оправдан только тогда, когда он соответствует вашей архитектуре.

Шаг 3. Разберите HTTP-код, а не «лечите loopback» вслепую

Результат	Частая причина	Направление проверки
401 Unauthorized	Basic Auth или дополнительная авторизация staging	Проверить, получает ли self-request нужный Authorization
403 Forbidden	WAF, firewall, security-плагин, запрет по IP	Посмотреть события блокировки и правило, которое сработало
404 Not Found	Неверный host/path, прокси-маршрут или нестандартный site URL	Проверить home/siteurl, redirects и virtual host
5xx	Ошибка PHP, upstream, proxy loop или перегрузка	PHP/nginx/apache logs и трассировку upstream
cURL 28 / timeout	DNS, connect, TLS, firewall или зависший upstream	curl -Iv, DNS и сетевой маршрут
SSL certificate problem	Цепочка сертификата, SNI или локальное trust store	Проверить сертификат и TLS с сервера

Шаг 4. Проверьте TLS и редиректы

Для детальной сетевой диагностики полезен verbose-режим:

curl -Iv https://example.com/

Он показывает DNS-resolve, подключение, TLS handshake, сертификат и redirect headers. Если есть цепочка http → https → www → без www или обратно, убедитесь, что она конечная и одинаково работает с сервера.

Глобально отключать проверку SSL через фильтры WordPress — плохой способ «исправить» loopback. Так можно скрыть реальную ошибку сертификата и одновременно ослабить проверку локальных HTTPS-запросов. Исправлять нужно причину: сертификат, цепочку, SNI или конфигурацию proxy.

Шаг 5. Проверьте Cloudflare, WAF и security-плагины

Если сайт находится за CDN/WAF, собственный сервер может выглядеть для внешнего контура как обычный клиент. Правило, которое блокирует подозрительные IP, User-Agent, частые запросы или определённые URL, способно задеть и loopback.

При 403 не отключайте весь WAF. Найдите конкретное событие блокировки и условие правила. Безопасный подход — минимально разрешить легитимный self-request или скорректировать ошибочное правило, сохранив остальную защиту.

То же относится к WordPress security-плагинам. Если проблема исчезает в troubleshooting mode после отключения конкретного плагина, нужно искать его правило блокировки HTTP API или локального запроса, а не оставлять защиту полностью выключенной.

Basic Auth на staging: частая причина 401

Staging часто закрывают паролем на уровне nginx, Apache, панели хостинга или Cloudflare Access. В результате обычный посетитель после авторизации видит сайт, а внутренний self-request получает 401.

WordPress Core учитывает стандартный PHP Basic Auth в loopback test, но нестандартная авторизация на уровне внешнего proxy или отдельной access-системы может требовать своей настройки. Проверка простая: выполните curl -I с сервера и посмотрите, действительно ли ответ равен 401 и какой слой добавляет WWW-Authenticate.

Плагины, тема и mu-plugins тоже могут ломать loopback

Официальная документация WordPress называет конфликт плагина или темы наиболее частой причиной loopback-проблем. Для диагностики рекомендуются стандартные troubleshooting steps: временно отключить плагины, включая mu-plugins, и проверить на стандартной теме.

На production делать это «в лоб» опасно. Используйте staging или Health Check troubleshooting mode, который позволяет провести тест для вашей админ-сессии, не отключая плагины для обычных посетителей.

Если после отключения расширений loopback начинает работать, возвращайте их по одному и фиксируйте момент, когда ошибка появляется снова. Так вы получите конкретный конфликт вместо списка подозрений.

WP-Cron и loopback: где проходит граница

WP-Cron — это планировщик событий WordPress. Loopback — один из механизмов, которым Core может инициировать выполнение cron-процесса через запрос к wp-cron.php. Поэтому ошибка loopback способна влиять на расписание, но «loopback failed» не означает автоматически, что все cron-задачи сломаны.

На нагруженных сайтах часто отключают запуск WP-Cron на пользовательских запросах и вызывают его системным cron. Это нормальная архитектура, если системный cron действительно настроен. Опасный вариант — поставить DISABLE_WP_CRON и забыть создать внешний запуск: тогда фоновые события перестанут выполняться независимо от состояния Site Health.

Для WooCommerce есть отдельный уровень фоновых задач — Action Scheduler. Его диагностика разобрана в статье про WP-Cron и Action Scheduler в WooCommerce. Не смешивайте эти уровни: сначала подтвердите работу базового WordPress cron/loopback, затем исследуйте очередь конкретного плагина.

Как проверить cron после исправления loopback

Если на сервере есть WP-CLI, начните со списка событий:

wp cron event list

Для контролируемой проверки можно запустить просроченные события:

wp cron event run --due-now

Это не замена исправлению loopback, а способ понять, выполняются ли callbacks вообще. Если команда работает, а автоматический запуск нет, исследуйте механизм запуска cron. Если падает сама callback-функция, проблема уже не в self-request.

Loopback в Docker, контейнерах и reverse proxy

В контейнерной архитектуре публичный домен может идти через внешний nginx/Traefik/Cloudflare, а WordPress/PHP работает во внутренней сети. Самозапрос из контейнера может резолвиться иначе, чем запрос с рабочей станции.

Проверьте три вещи: куда внутри контейнера резолвится домен, доступен ли оттуда публичный 443 и правильно ли proxy возвращает запрос на нужный backend с корректным Host. Если проблема появляется только внутри контейнера, обычная проверка с хоста может быть недостаточной.

Не добавляйте случайные network aliases ради того, чтобы Site Health стал зелёным. Маршрут должен соответствовать реальной схеме сайта и не обходить обязательную авторизацию, TLS или защиту.

Почему увеличение timeout редко является решением

Если loopback падает по timeout, увеличение лимита иногда лишь делает ошибку более долгой. Сначала нужно понять, где именно тратится время: DNS, TCP connect, TLS handshake, proxy, PHP startup или обработка WordPress.

Для общей серверной диагностики полезно сопоставить self-request с PHP slow log, nginx/apache access log и временем ответа. Если сама WordPress-страница работает медленно, отдельно проверьте запросы и hooks. Для этого есть разбор медленных запросов WordPress через Query Monitor.

Если задержку создаёт уже не self-request, а сторонний сервис, смотрите отдельную статью про медленные внешние API в WordPress.

Что не нужно делать

Не отключайте SSL verification глобально. Исправьте сертификат или TLS-маршрут.
Не выключайте весь WAF. Найдите конкретное правило и конкретный self-request.
Не добавляйте свой сервер в безусловный allowlist для всех URL. Разрешение должно быть минимальным.
Не увеличивайте timeout до десятков секунд как основное лечение. Это маскирует причину.
Не отключайте WP-Cron без системной замены. Иначе запланированные события останутся без запуска.
Не считайте 200 из браузера доказательством. Проверяйте запрос с того же сервера/контейнера, где работает WordPress.
Не меняйте DNS или hosts вслепую. Сначала зафиксируйте текущий маршрут и поймите, какой слой блокирует запрос.

Короткий порядок диагностики

Site HealthЗафиксировать текст ошибки, HTTP-код или cURL error.
Server curlПовторить запрос к публичному домену непосредственно с сервера.
DNS и TLSПроверить resolve, сертификат, redirects и virtual host.
WAF/AuthИсключить 401/403 от proxy, firewall и security-плагина.
WordPress layerПроверить конфликт плагинов, темы и mu-plugins.
CronПосле исправления убедиться, что запланированные события выполняются.

Что проверить после исправления

Site Health больше не показывает ошибку loopback requests;
публичный URL с сервера отвечает ожидаемым HTTP-кодом без лишних циклических redirect;
scheduled posts и cron events выполняются по расписанию;
в логах нет новых 401/403/timeout для self-request;
WAF и security-плагины остаются включены и не блокируют легитимный маршрут;
REST API, формы, авторизация, корзина и checkout не пострадали от исправления;
если используется системный cron, он действительно запускается и контролируется.

Когда нужна точечная диагностика

Loopback-ошибка редко лечится одной универсальной настройкой: на одном сервере виноват Basic Auth, на другом — Cloudflare/WAF, на третьем — неверный DNS внутри контейнера, а на четвёртом запрос ломает конкретный WordPress-плагин.

В A.S Groups можно заказать диагностику и доработку WordPress: проверить цепочку DNS → TLS → reverse proxy → PHP → WordPress, логи, Site Health и cron, а затем исправить конкретную причину без отключения нужной защиты и фоновых функций.

Следующий шаг

Нужно решить похожую задачу?

Предложить диагностику WordPress по цепочке DNS, SSL, reverse proxy, WAF, PHP и cron без отключения нужной защиты.

Обсудить задачу