#Суть неисправности и признаки
На странице «Инструменты» → «Здоровье сайта» WordPress сообщает, что не удалось выполнить петлевой запрос (loopback request). Это попытка WordPress обратиться по HTTP(S) к собственному адресу. Проблема иногда мешает WP-Cron и проверкам встроенных редакторов, но она не обязательно означает, что публичный сайт недоступен. Задача — определить, где прерывается внутренний запрос: разрешение имени, сетевое соединение, проверка сертификата, требование авторизации, защитное правило или обработка PHP. Не отключайте TLS-проверку и межсетевой экран для сокрытия ошибки.
#Почему возникает проблема
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Сервер не может разрешить собственное доменное имяDNS на сервере отдаёт ошибку или адрес, по которому сам сервер не может подключиться. | Из серверного терминала запрос имени не находит IP или подключается к чужому адресу. | Проверить DNS и локальные маршруты, не подменяя сразу hosts. |
| Неверный HTTPS/TLSСертификат недействителен для домена либо сервер не передаёт промежуточную цепочку. | Сообщение cURL: certificate verify failed либо TLS handshake. | Исправить сертификат и цепочку на сервере по требованиям удостоверяющего центра. |
| Авторизация или защита блокирует обращение изнутриБазовая HTTP-авторизация, WAF или ограничения по IP возвращают 401/403. | Публичный посетитель видит сайт, а служба WordPress получает 401/403. | Найти конкретное правило по журналам; не создавать глобальное исключение. |
| Мало процессов PHP или тайм-аутСобственный запрос занимает дополнительный обработчик, а пул занят длинными задачами. | Тайм-аут и пустые ответы при высокой нагрузке, очередь PHP-FPM. | Проверить занятость и ограничения пула, не увеличивать параметры наугад. |
| Конфликт плагина/темыСторонний код перехватывает или замедляет HTTP-запрос. | На изолированной копии без конкретного расширения ошибка исчезает. | Проверить расширения по одному и обновить несовместимое. |
#Пошаговая диагностика и устранение
- Откройте исходное сообщение, а не только общую оценкуВ панели WordPress перейдите «Инструменты» → «Здоровье сайта» → «Состояние». Разверните пункт о петлевых запросах и запишите дословный ответ и время проверки: код 401, 403, 500, timeout или ошибка cURL подсказывают разные маршруты. Если есть только общая оценка, откройте раздел «Информация» и сохраните обезличенный технический отчёт для поддержки, не публикуя конфиденциальные данные.
- Проверьте адрес сайта и обычное открытиеВ «Настройки» → «Общие» посмотрите «Адрес WordPress (URL)» и «Адрес сайта (URL)». В отдельной вкладке браузера откройте главную и /wp-json/ под тем же именем и HTTPS. Если доступность зависит от www, проверьте редирект и сертификат. При некорректном адресе сначала исправьте причину несоответствия домена, не меняйте оба URL вслепую.
- Сравните доступность из браузера и с самого сервераЕсли есть SSH, откройте терминал под обычным пользователем. Выполните
curl -I --max-time 10 https://example.com/с заменой домена на свой. Это запрос только заголовков: HTTP 200/301/401/403 и задержка помогают локализовать причину, но не воспроизводят полностью внутренний запрос WordPress. Не добавляйте --insecure, поскольку отключение проверки сертификата скрывает реальную ошибку. - Проверьте DNS, IPv4 и IPv6 отдельноВ терминале сервера выполните
getent ahosts example.com, указав свой домен. Сравните возвращаемые адреса с действительными IPv4/IPv6 сайта. Если домен возвращает устаревший адрес или IPv6 ведёт на другой сервер, исправление нужно в соответствующей зоне DNS и конфигурации, а не в WP-Cron. При отсутствии команды getent на конкретной системе используйте штатную утилиту DNS, принятую у хостинга. - Проверьте журналы на 401, 403 и 5xxВ панели хостинга откройте журналы доступа и ошибок для домена, затем повторите тест в «Здоровье сайта». Найдите запрос по времени: статус 401 может указывать на HTTP-авторизацию, 403 — на политику доступа, 5xx — на сервер или PHP. При внешнем WAF изучите его журнал с идентификатором заблокированного запроса. Не разрешайте все внутренние адреса и не отключайте защиту сервера; корректируйте только подтверждённое правило.
- Проверьте ошибки сертификата на сервереОткройте правильный https:// адрес в браузере и проверьте срок действия и доменное имя сертификата. Если серверный curl сообщает certificate verify failed, попросите администратора проверить цепочку сертификата и системное хранилище доверенных центров для того PHP/системного окружения, которое делает запрос. Не используйте verify=false в коде и не отключайте проверку TLS в плагинах.
- Исключите конфликт дополнения на тестовой копииПосле резервной копии воспроизведите сайт на тестовом окружении с теми же версиями. По одному деактивируйте недавно обновлённые плагины через «Плагины» → «Установленные», повторяя тест «Здоровье сайта». Если ошибка исчезла только после конкретного плагина, восстановите его на копии и обратитесь к разработчику. Изменение темы используйте как отдельный диагностический тест, а не как обязательный шаг на рабочем сайте.
- Повторите тест и проверьте связанные функцииПосле исправления причины обновите «Здоровье сайта» и убедитесь, что сообщение об ошибке исчезло. Затем проверьте публикацию тестовой записи по расписанию, если эта функция ранее страдала. Если сообщение осталось, сохраните ошибки PHP, HTTP-код, точный адрес и время запросов; верните временные изменения и попросите хостинг проверить доступ сервера к самому себе и занятость процессов PHP-FPM.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат и что делать, если не помогло
Результат успешен, когда «Здоровье сайта» больше не сообщает об ошибке loopback и запланированные действия выполняются. Если предупреждение сохраняется при доступном публичном сайте, это не повод выключать брандмауэр: важно определить, какой именно процесс и протокол не проходят. При обращении к провайдеру предоставьте ответ cURL без секретов, журналы, действующий DNS и настройки прокси.