Діагностика loopback-запитів WordPress: як знайти причину помилки

Що таке loopback-запит і чому він важливий

Під час loopback-запиту сервер, на якому працює WordPress, звертається до URL цього самого сайту — зазвичай до HTTPS-домену та службового endpoint, зокрема 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 зазвичай означає, що мережевий шлях працює, але редирект чи авторизація все одно можуть заважати конкретному endpoint.
• Коди 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-запит повинен успішно пройти перевірку сертифіката, імені домену та ланцюжка довіри. Самопідписаний або прострочений сертифікат, неповний chain чи неправильна дата на сервері можуть призвести до помилки SSL. Не варто виправляти це вимкненням перевірки сертифіката: таке рішення послаблює безпеку і лише приховує причину.

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

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

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

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 та фактичне виконання тестової запланованої події.
• Переконайтеся, що зміни не відкрили адміністративні endpoint для сторонніх запитів.
• Якщо проблема з’явилася після перенесення сайту, порівняйте DNS, проксі, сертифікати й правила firewall зі старим середовищем.