Диагностика loopback-запросов WordPress: как найти причину ошибки

Что такое loopback-запрос и почему он важен

Во время loopback-запроса сервер, на котором работает WordPress, обращается к URL собственного сайта — обычно к HTTPS-домену и служебной конечной точке, например wp-cron.php. Запрос проходит через DNS, сетевой стек, балансировщик или CDN, веб-сервер, правила безопасности и PHP так же, как обычное внешнее обращение.

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

Ошибка loopback не всегда означает неисправность самого WordPress. Часто причина связана с DNS, TLS-сертификатом, Basic Auth, правилами WAF, запретом исходящих соединений или неправильной конфигурацией прокси.

• Типичные симптомы: ошибка loopback в Site Health, пропущенные запланированные события и длительные задержки во время административных операций.
• Запрос может возвращать ошибку даже в том случае, если тот же URL нормально открывается на компьютере администратора.
• Внутренний запрос нужно проверять именно с сервера или контейнера, где работает WordPress.

Быстрая проверка через WP-CLI и curl

Начните с WP-CLI. Команда wp cron test проверяет, может ли WordPress выполнить тестовый loopback-запрос для Cron. Запускайте ее от того же пользователя и в той же среде, где работает сайт: при использовании Docker, Kubernetes или отдельного PHP-контейнера это может быть не хостовая система.

Дополнительно проверьте URL с помощью curl. Запрос HEAD удобен для быстрой проверки, но некоторые серверы или WAF обрабатывают HEAD и GET по-разному. Поэтому при необходимости повторите проверку обычным GET-запросом без загрузки тела ответа.

• Зафиксируйте HTTP-код, время ответа и текст ошибки, а не только факт успешного или неудачного выполнения.
• Код 2xx или 3xx обычно означает, что сетевой путь работает, однако редирект или авторизация все равно могут мешать работе конкретной конечной точки.
• Коды 401 и 403 часто указывают на Basic Auth, WAF или правило доступа; 404 — на неправильный URL или конфигурацию сайта; 5xx — на проблему обработки PHP или веб-сервера.

wp cron test
curl -I https://example.com/wp-cron.php
curl -sS -D - -o /dev/null -w '\nHTTP %{http_code}\nВремя: %{time_total}s\n' https://example.com/wp-cron.php

Проверка DNS и маршрута с сервера

Сервер должен разрешать домен сайта в соответствии с вашей инфраструктурой. Если домен указывает на внешний CDN или балансировщик, loopback-запрос может выйти в Интернет и вернуться через дополнительные уровни фильтрации. В некоторых сетях исходящий доступ к собственному публичному IP-адресу запрещен.

Проверяйте DNS непосредственно с сервера WordPress. Сравните полученные записи A и AAAA с фактической схемой развертывания. Распространенная причина — корректный IPv4, но недоступный IPv6: curl может сначала выбрать запись AAAA и завершиться по тайм-ауту.

• Убедитесь, что hostname из URL WordPress разрешается из PHP-среды, а не только с рабочего компьютера.
• Проверьте доступность порта 443 или 80 и маршрут до адреса, который возвращает DNS.
• Если используется split-horizon DNS, внутренний сервер должен получать правильный внутренний адрес.
• Не подменяйте домен записью в hosts без понимания последствий: это может скрыть ошибку DNS и привести к разному поведению на разных серверах.

getent hosts example.com
nslookup example.com
curl -4 -I https://example.com/wp-cron.php
curl -6 -I https://example.com/wp-cron.php

TLS, прокси и веб-сервер: где чаще всего возникает блокировка

Для HTTPS loopback-запрос должен успешно пройти проверку сертификата, имени домена и цепочки доверия. Самоподписанный или просроченный сертификат, неполная цепочка или неправильная дата на сервере могут привести к ошибке SSL. Не пытайтесь исправить это отключением проверки сертификата: такое решение снижает безопасность и лишь скрывает причину проблемы.

Если перед WordPress установлены Nginx, Apache, CDN, reverse proxy или балансировщик, проверьте передачу заголовков Host и X-Forwarded-Proto. Неправильное определение HTTPS может вызвать бесконечные редиректы между HTTP и HTTPS или привести к генерации неправильного URL.

Отдельно проверьте правила доступа. Basic Auth на staging-сайте, геоблокировка, ограничение частоты запросов, блокировка запросов с IP-адреса сервера и правила для wp-cron.php часто прерывают loopback-запрос.

• Проверьте, отличается ли ответ на запрос с сервера от ответа, который вы получаете на своем компьютере.
• Проверьте конфигурацию редиректов и убедитесь, что конечный URL не требует авторизации.
• Для WAF создайте узкое исключение для внутренних запросов к нужному домену или конечной точке, а не отключайте всю защиту.
• После изменения конфигурации очистите кэш прокси и повторите тест с сервера.

curl -v https://example.com/wp-cron.php

Логи помогают определить реальную причину

Запустите тест и одновременно просматривайте access- и error-логи Nginx или Apache. Если записи о запросе нет, проблема, вероятно, возникает до веб-сервера: на уровне DNS, firewall, маршрутизации или TLS. Если запись есть, анализируйте HTTP-код, время выполнения, ошибки upstream и IP-адрес клиента.

В логах PHP ищите тайм-ауты, ошибки подключения, исчерпание памяти и фатальные ошибки плагинов. На уровне WordPress полезно временно включить журналирование ошибок контролируемым способом, не показывая технические сообщения посетителям.

• Код 502 или 504 от прокси часто означает проблему связи с PHP-FPM или upstream, а не саму проблему loopback.
• Задержка без HTTP-ответа может указывать на firewall, DNS, IPv6 или зависший процесс PHP.
• Повторяющиеся ответы 403, вызванные одним и тем же правилом WAF, нужно исправлять на уровне этого правила, а не скрывать ошибку.
• После диагностики удалите избыточное debug-журналирование или ограничьте доступ к логам.

tail -f /var/log/nginx/access.log /var/log/nginx/error.log
# Для Apache пути к логам могут отличаться:
tail -f /var/log/apache2/access.log /var/log/apache2/error.log

Как исправить проблему без опасных обходных решений

Правильное исправление зависит от найденной причины: восстановите разрешение DNS, исправьте IPv6 или маршрутизацию, установите корректный сертификат, настройте reverse proxy и разрешите серверу исходящие HTTPS-соединения к собственному домену. Если запрос блокирует WAF, добавьте минимально необходимое исключение и проверьте его по логам.

Если сайт защищен с помощью Basic Auth, предусмотрите контролируемый доступ для служебных запросов или другой способ тестирования, не оставляя сайт без защиты. Для production-среды лучше согласовать это с администратором инфраструктуры и зафиксировать изменения в конфигурации.

Не отключайте loopback с помощью DISABLE_WP_CRON или других параметров только для того, чтобы убрать сообщение в Site Health. DISABLE_WP_CRON отключает запуск WP-Cron во время загрузки страниц и не устраняет сетевую проблему. Если нужна более надежная модель запуска, WP-Cron можно заменить системным планировщиком, но события все равно должны корректно выполняться в окружении WordPress.

• После исправления повторите wp cron test и curl с того же сервера или контейнера.
• Проверьте Site Health и фактическое выполнение тестового запланированного события.
• Убедитесь, что изменения не открыли административные конечные точки для внешних запросов.
• Если проблема появилась после переноса сайта, сравните DNS, прокси, сертификаты и правила firewall со старой средой.