Петля входу WordPress: повертає на сторінку входу — як виправити

Швидкий план діагностики (перевірте спочатку це)

Якщо у вас є лише п’ять хвилин до того, як хтось важливий запитає, чому не можна опублікувати допис гендиректора, робіть це в порядку. Ця послідовність швидко знаходить вузьке місце, бо слідує шляху автентифікації: браузер → edge-кеш → зворотний проксі → PHP → база даних.

1) Підтвердіть, чи встановлюються cookie і повертаються

• Перевірте: Чи отримує браузер Set-Cookie після POST з обліковими даними?
• Потім: Чи включає наступний запит до /wp-admin/ ті ж cookie?
• Чому: «Петля входу» часто означає, що WordPress каже «я не отримав дійсну auth cookie», тому повертає вас назад.

2) Переконайтеся, що канонічний URL і схема узгоджені

• Перевірте: Чи перескакуєте ви між http та https або між www та кореневим доменом?
• Чому: Cookie мають область дії, прив’язану до домену й схеми. Якщо POST для входу відбувається на одному хості/схемі, а адміністрування завантажується на іншому — cookie може не працювати.

3) Обійдіть кеші та рівні безпеки

• Перевірте: Чи кешує edge, WAF, «плагін продуктивності» або зворотний проксі wp-login.php або чи не змінюють вони заголовки?
• Чому: Ендпоїнти автентифікації динамічні. Кешувати їх — те саме, що написати на дверях «іноді відчинено».

4) Безпечно відключіть плагіни, потім — тему

• Перевірте: Чи зникає проблема після відключення плагінів?
• Чому: Один «захисний» або «cookie consent» плагін може поламати автентифікацію винахідливими способами.

5) Перевірте серверні сесії, PHP та запис у БД

• Перевірте: Чи PHP записує сесії? Чи БД доступна для запису? Є фатальні помилки?
• Чому: Якщо WordPress не може встановити стан, пов’язаний з автентифікацією (або є дивності з object cache), він не зможе утримувати вас у системі.

Як насправді працює потік входу WordPress (щоб не боротися із привидами)

Вхід у WordPress базується на cookie. Коли ви відправляєте облікові дані на wp-login.php, WordPress:

1. Перевіряє ім’я користувача/пароль (або SSO) та статус/права користувача.
2. Видає автентифікаційні cookie: зазвичай wordpress_logged_in_* та wordpress_sec_* (імена залежать від хешів/солей і налаштувань).
3. Перенаправляє вас (302) до /wp-admin/ або в цільову адресу.
4. У наступному запиті WordPress читає cookie, перевіряє їх щодо солей і запису користувача і або дозволяє доступ, або знову перенаправляє на вхід.

«Петля входу» означає одну з трьох речей:

• Cookie ніколи не були встановлені (блоковані, видалені, кешована відповідь, невірні заголовки).
• Cookie були встановлені, але не надсилаються назад (помилкова область домену, невідповідність secure-флагу, шлях, проблеми SameSite у певних потоках).
• Cookie надіслано, але відхилено (зламані солі після міграції, невідповідність DB/object cache, різниця часу, дивності в user meta, кастомний плагін автентифікації).

Практичне правило: ставтесь до цього як до налагодження розподілених систем. Є кілька шарів, і будь-який з них може «дружньо» переписати ваш запит у відмову.

Парафраз від авторитету надійності: надія — це не стратегія. — у дусі Gene Kranz (мислення місійних операцій).

Жарт №1: Петля входу WordPress — це єдиний кардіотренажер, який деякі з нас отримують за робочий день. Це не чудова програма добробуту.

Цікаві факти та історичний контекст (коротко, корисно)

• Факт 1: WordPress використовує автентифікацію на основі cookie з ранніх релізів; імена cookie включають хеші, що походять із налаштувань сайту та солей, тому після міграцій логіни можуть «випадково» зламатися.
• Факт 2: Ендпоїнт wp-login.php — один із найчастіше атакованих публічних URL в інтернеті; багато хостинг-стеків додають правила WAF або обмеження швидкості, які можуть тонко заважати легітимним входам.
• Факт 3: Адмін-панель сильно покладається на перенаправлення (канонічний хост, примусове SSL, місцезнаходження адмінки). Неправильна конфігурація перенаправлень породжує петлі швидше, ніж майже будь-який інший баг сайту.
• Факт 4: Браузери посилили політику обробки cookie з часом (зокрема щодо SameSite), що може зломити потоки входу, які включають крос-сайтові POST або зовнішні IdP, якщо cookie встановлені неправильно.
• Факт 5: Багато CDN з «кешуйте все» колись постачалися з наївними налаштуваннями; сучасні конфігурації зазвичай виключають wp-admin і wp-login.php, але це все одно постійно конфігурують неправильно.
• Факт 6: WordPress зберігає канонічні URL (home і siteurl) у базі, але дозволяє перекривати їх через wp-config.php. Конфлікти між цими значеннями — класичний генератор петлі.
• Факт 7: Зворотний проксі (балансувальник навантаження, CDN, ingress) змінює значення «чи це HTTPS?» якщо форвард-заголовки некоректні; WordPress використовує це, щоб вирішити secure-флаги cookie і цілі перенаправлення.
• Факт 8: Object cache (Redis/Memcached) може робити автентифікацію «моторошною», коли застарілі значення залишаються після розгортань або коли кілька серверів мають різні солі/конфігурації.

Реальні причини петлі входу (відсортовано за частотою)

1) Невідповідність URL, хоста або HTTPS (канонічна тредміл-перенаправлення)

WordPress прагне одного істинного URL для сайту. Якщо ваш стек обслуговує кілька варіантів — http, https, з/без www, можливо альтернативний домен — POST для входу може бути на одному варіанті, а перенаправлення до /wp-admin/ потрапляти на інший. Cookie не пересуваються так, як ви б цього хотіли.

Типові тригери:

• home та siteurl налаштовані по-різному (один http, інший https).
• Примусове HTTPS на балансувальнику, але WordPress вважає, що це plain HTTP.
• Правила перенаправлення в Nginx/Apache конкурують з канонічними перенаправленнями WordPress.

2) Cookie заблоковані, видалені або неправильно обмежені

Якщо cookie не встановлюються або не повертаються, WordPress не може утримати вас у системі. Причини включають:

• Проксі/CDN видаляє заголовки Set-Cookie для «кешованості».
• Несумісність домену/шляху cookie після зміни домену.
• Secure-cookie для HTTPS не працює, бо WordPress не виявляє HTTPS (тоді він встановлює не-secure cookie, а ви потім переходите на HTTPS і їх не приймають).
• Плагіни з управлінням cookie або безпеки, що неправильно переписують заголовки.

3) Кеш (edge, плагін, сервер) кешує неправильні речі

Вражає, скільки конфігурацій продуктивності намагаються кешувати сторінки входу. Якщо відповідь входу або перенаправлення кешується, різні користувачі починають ділитися тим самим некоректним станом. Також, якщо кеш видаляє cookie, автентифікація ламається непомітно.

4) Конфлікти плагінів/тем, особливо безпеки та SSO

Плагіни безпеки, містки SSO, плагіни 2FA та пакети «відключити XML-RPC» часто підписуються на фільтри аутентифікації. Одне погане оновлення може ввести перенаправлення, яке ніколи не завершується.

5) Зламані солі/ключі після міграції або дріфт конфігурації між серверами

WordPress підписує auth-cookie солями й ключами в wp-config.php. Якщо ви їх зміните, існуючі cookie стануть недійсними (це нормально), але якщо у вас декілька апп-серверів із різними солями — користувачі втрачатимуть сесії або потраплятимуть у петлі залежно від того, до якого бекенду їх спрямовано.

6) Розбіжності часу або дивності TLS-термінації

Auth-cookie містять час життя. Якщо системний час неправильний (дрейф VM, проблеми в контейнері, NTP не працює), cookie можуть виглядати миттєво простроченими. Менш поширено, але вражає, коли відбувається.

7) Збої запису в БД або файловій системі та тонкі фатали

Автентифікація WordPress покладається на читання/запис у БД і на коректне виконання PHP. Якщо PHP завершується фатально після встановлення перенаправлення або БД тільки для читання, ви можете опинитися в петлі без очевидної помилки. Перевіряйте логи ретельно.

Практичні завдання: команди, вивід і рішення (12+)

Ось практичні завдання, які можна виконати на типовому Linux-хості. Налаштуйте шляхи, якщо у вас інша дистрибуція чи структура. Кожне завдання містить: команду, що означає вивід, і рішення для наступного кроку.

Завдання 1: Відтворіть ланцюжок перенаправлень з боку сервера

cr0x@server:~$ curl -I -L https://example.com/wp-admin/ | sed -n '1,40p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wp-wpml_current_language=en; path=/
server: nginx

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-store, no-cache, must-revalidate, max-age=0

Що це означає: Один 302 на логін — нормальна поведінка, якщо ви не авторизовані. Якщо ви бачите повторювані 302, що відскакують між wp-login.php і wp-admin, у вас є петля.

Рішення: Якщо петля з’являється тут без браузера — це серверна логіка перенаправлень або проблема канонічного URL, а не «мій браузер божевільний».

Завдання 2: Перевірте, чи кешує проксі/CDN сторінку входу

cr0x@server:~$ curl -I https://example.com/wp-login.php | egrep -i 'cache|age|cf-cache-status|x-cache|via|set-cookie'
cache-control: no-store, no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: Ви хочете бачити no-store або подібні обмежувальні директиви. Якщо бачите заголовки на кшталт x-cache: HIT або статус кешування CDN, це підозріло.

Рішення: Якщо кешується — налаштуйте CDN/зворотний проксі, щоб обходити кеш для /wp-login.php і /wp-admin/*, і ніколи не видаляти Set-Cookie.

Завдання 3: Підтвердіть канонічні URL WordPress (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp option get home
https://example.com
cr0x@server:/var/www/html$ wp option get siteurl
http://example.com

Що це означає: Ця невідповідність (https vs http) — класичний тригер петлі.

Рішення: Встановіть їх однаково (схема та хост). Виберіть один канонічний URL і дотримуйтесь його.

Завдання 4: Безпечно виправте home та siteurl

cr0x@server:/var/www/html$ wp option update home 'https://example.com'
Success: Updated 'home' option.
cr0x@server:/var/www/html$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.

Що це означає: WordPress генеруватиме cookie/перенаправлення на основі цих значень.

Рішення: Повторіть спробу входу. Якщо петля лишається — переходьте до виявлення HTTPS і заголовків проксі.

Завдання 5: Перевірте, чи WordPress вважає запит HTTPS (за проксі)

cr0x@server:~$ grep -R "HTTPS" -n /var/www/html/wp-config.php | head
# (no output)

Що це означає: Немає явного примусу HTTPS на рівні програми. Це нормально, якщо форвард-заголовки коректні, але ризиковано, коли вони не вірні.

Рішення: Якщо TLS завершується на балансувальнику й трафік до PHP іде по HTTP, переконайтеся, що X-Forwarded-Proto встановлений і враховується, або додайте умовно $_SERVER['HTTPS']='on' у wp-config.php.

Завдання 6: Перевірте форвард-заголовки в Nginx (поширена причина)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "X-Forwarded-Proto|X-Forwarded-For|fastcgi_param"
112:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
113:    proxy_set_header X-Forwarded-Proto $scheme;
210:    fastcgi_param HTTPS $https if_not_empty;

Що це означає: Якщо ви за проксі, $scheme може бути http між проксі та origin навіть коли клієнт використовував HTTPS. Це змушує WordPress думати, що він на HTTP.

Рішення: Налаштуйте форвард-прото від edge (LB → origin). Часто потрібно, щоб Nginx довіряв X-Forwarded-Proto від LB і передавав його в PHP.

Завдання 7: Перевірте заголовки відповіді на предмет відсутніх/переписаних cookie

cr0x@server:~$ curl -s -D - https://example.com/wp-login.php -o /dev/null | sed -n '1,40p'
HTTP/2 200
date: Fri, 27 Dec 2025 11:20:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: Ви отримуєте Set-Cookie хоча б для тестового cookie. Після POST з обліковими даними ви повинні бачити й автентифікаційні cookie.

Рішення: Якщо Set-Cookie зникає тільки на POST — підозрюйте правила WAF, кешування або плагін, що помирає під час відповіді.

Завдання 8: Зробіть POST на wp-login.php і перевірте auth-cookie (імітація з сервера)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://example.com/wp-login.php \
  -d "log=admin&pwd=wrongpassword&wp-submit=Log+In&redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&testcookie=1" | egrep -i 'HTTP/|set-cookie:|location:'
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: З неправильними обліковими даними ви не отримаєте auth-cookie; ви маєте бачити 200 із сторінкою помилки.

Рішення: Якщо навіть правильні облікові дані не породжують auth-cookie (ви б побачили додаткові рядки set-cookie), переходьте до логів PHP і ізоляції плагінів.

Завдання 9: Перевірте PHP-FPM і веб-логи на предмет фаталів, пов’язаних з автентифікацією

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:18:32] WARNING: [pool www] child 2147 said into stderr: "PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/foo/foo.php:12) in /var/www/html/wp-includes/pluggable.php on line 1428"

Що це означає: «Headers already sent» може перешкоджати встановленню cookie. Без cookie — немає входу. Якийсь плагін вивів щось (навіть пробіли) до того, як WordPress міг встановити заголовки.

Рішення: Вимкніть проблемний плагін. Потім виправте його (або замініть), бо проблема повертатиметься.

Завдання 10: Вимкніть плагіни, не заходячи в wp-admin

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 14 of 14 plugins.

Що це означає: Ви прибрали вплив плагінів із рівня проблеми.

Рішення: Спробуйте знову увійти. Якщо виправилося — вмикайте плагіни по одному, щоб знайти винного.

Завдання 11: Переключіться на стандартну тему, щоб виключити тему як джерело проблем

cr0x@server:/var/www/html$ wp theme list
+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| corp-theme     | active   | none   | 4.8.1   |
+----------------+----------+--------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Що це означає: Якщо тема має кастомні редиректи для входу, SSO-хуки або проблеми з буферизацією виводу, це ізолює тему.

Рішення: Якщо це вирішує петлю, ваша «гарна корпоративна тема» — тепер інцидент у продакшені. Поводьтеся відповідно.

Завдання 12: Перевірте дріфт солей/ключів у конфігурації між серверами (швидкий diff)

cr0x@server:~$ sudo egrep "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" -n /var/www/html/wp-config.php
54:define('AUTH_KEY',         '...a...');
55:define('SECURE_AUTH_KEY',  '...b...');
56:define('LOGGED_IN_KEY',    '...c...');
57:define('NONCE_KEY',        '...d...');

Що це означає: Ці значення мають бути ідентичні на всіх апп-серверах за лоад-балансером.

Рішення: Якщо у вас кілька origin-ів, перевірте відповідність у всіх місцях. Якщо не збігаються — виправте деплой, щоби конфігурація була консистентною.

Завдання 13: Перевірте системний час і синхронізацію NTP (перевірка строків cookie)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-27 11:20:44 UTC
           Universal time: Fri 2025-12-27 11:20:44 UTC
                 RTC time: Fri 2025-12-27 11:20:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Якщо годинники відстають або NTP неактивний — cookie можуть виглядати простроченими миттєво.

Рішення: Якщо синхронізація відсутня — виправте час спочатку. Не діагностуйте автентифікацію на сервері, який не погоджується щодо «тепер».

Завдання 14: Перевірте стан Redis object cache (якщо використовується)

cr0x@server:~$ redis-cli ping
PONG
cr0x@server:~$ redis-cli info | egrep "used_memory_human|maxmemory_human|evicted_keys"
used_memory_human:312.45M
maxmemory_human:512.00M
evicted_keys:18422

Що це означає: Велика кількість евікшенів може спричиняти дивну поведінку. Не завжди петля входу, але може дестабілізувати кешовані значення, пов’язані з автентифікацією.

Рішення: Якщо евікшенів багато — збільште пам’ять кешу або зменшіть використання кешу. Переконайтеся, що плагін object cache підходить і налаштований коректно.

Завдання 15: Переконайтеся, що БД доступна для запису і не повертає помилок

cr0x@server:~$ mysql -N -e "SHOW GLOBAL VARIABLES LIKE 'read_only';"
read_only	OFF

Що це означає: Якщо БД у режимі read-only (або вона падає), WordPress може поводитися непередбачувано, особливо коли плагіни записують user meta чи сесії.

Рішення: Якщо read-only увімкнено несподівано — виправте стан реплікації/фейловеру або вкажіть WordPress на правильний primary.

Завдання 16: Перевірте, що wp-content не тільки для читання (оновлення й деякі автентифікаційні потоки)

cr0x@server:~$ sudo -u www-data test -w /var/www/html/wp-content && echo "wp-content writable" || echo "wp-content NOT writable"
wp-content writable

Що це означає: Не кожна петля входу пов’язана з записом у файли, але проблеми з правами часто супроводжують пошкоджені розгортання та «headers already sent» проблеми.

Рішення: Якщо не доступно для запису і ваш стек очікує можливість запису — виправте власника/права; якщо стек забороняє записи, переконайтеся, що плагіни/теми не намагаються робити запис під час виконання, що ламає відповіді.

Типові помилки: симптом → корінь → виправлення

Симптом: Правильний пароль, миттєве перенаправлення назад на wp-login.php, без повідомлень

Корінь проблеми: Cookie не зберігаються або не повертаються (несумісність домену, невідповідність secure-флагу, «headers already sent», проксі видаляє Set-Cookie).

Виправлення: Перевірте узгодженість home/siteurl, перевірте заголовки відповіді на Set-Cookie, усуньте попередження PHP «headers already sent», і відключіть кешування на сторінках входу/адміністрування.

Симптом: Працює в одному браузері/пристрої, не працює в іншому

Корінь проблеми: Різниця політик cookie (поведінка SameSite, блокування сторонніх cookie), застарілі cookie, або розширення браузера, що змінює запити.

Виправлення: Тестуйте у чистому профілі/інкогніто, очистіть cookie для сайту, забезпечте, щоб потік входу був first-party (без крос-сайтових POST), і підтвердіть HTTPS та канонічний хост.

Симптом: Працює через origin напряму, не працює через CDN/WAF

Корінь проблеми: Edge кешує login/admin, сторінки виклику WAF, видалення заголовків або захист від ботів помилково визначає людей як ботів.

Виправлення: Обходьте кеш для ендпоїнтів автентифікації, додайте allowlist для IP адмінів за потреби, і переконайтеся, що challenge-сторінки не застосовуються до POST на wp-login.php.

Симптом: Помилка лише при увімкненні «Примусового HTTPS» або HSTS

Корінь проблеми: WordPress не виявляє HTTPS за проксі; він встановлює cookie або робить перенаправлення неконсистентно.

Виправлення: Виправте форвард-заголовки і/або реалізуйте виявлення HTTPS у wp-config.php. Забезпечте, щоб лише один шар відповідав за канонічні перенаправлення.

Симптом: Випадкові виходи/петлі в середовищі з балансуванням навантаження

Корінь проблеми: Різні солі/ключі на апп-серверах, неконсистентний wp-config.php, або відсутні sticky sessions, якщо їх вимагає плагін.

Виправлення: Зробіть конфігурацію незмінною та ідентичною на всіх вузлах. Уникайте залежності від sticky sessions; якщо не можна — налаштуйте їх явно й задокументуйте причину.

Симптом: Вхід працює, але wp-admin відразу виводить після кількох кліків

Корінь проблеми: Плагін кешу кешує admin-ajax, агресивний плагін безпеки інвалідовує сесії, або зсув часу.

Виправлення: Виключіть admin-шляхи з кешу, налаштуйте правила безпеки і перевірте синхронізацію часу.

Симптом: Лише адміністратори не можуть увійти; редактори можуть

Корінь проблеми: Політики перенаправлення для адміністраторів, неправильне налаштування 2FA, перевірки прав або кастомний mu-плагін.

Виправлення: Перевірте must-use плагіни та налаштування безпеки; тестуйте з усіма плагінами відключеними; перегляньте серверні логи на предмет перенаправлень за ролями.

Чеклісти / покроковий план

Чекліст A: Однопрохідне «поверніть мене в wp-admin» відновлення

1. Очистіть cookie браузера для сайту (або використайте приватне вікно). Якщо й там не вдається увійти — це не «застарілі cookie».
2. Підтвердіть канонічний URL:
   • Зробіть home і siteurl ідентичними (схема + хост).
   • Виберіть або www, або кореневий домен і дотримуйтеся цього.
3. Тимчасово обійдіть CDN/WAF (файл hosts / прямий доступ до origin), щоб перевірити, чи edge — проблема.
4. Вимкніть усі плагіни через WP-CLI або перейменування wp-content/plugins.
5. Переключіться на стандартну тему, щоб виключити тему як джерело проблем.
6. Перевірте логи на предмет «headers already sent» та фаталів.
7. Виправте виявлення HTTPS за проксі (форвард-заголовки або умовне встановлення HTTPS у wp-config.php).
8. Повторно вмикайте плагіни по одному. Зупиніться, коли петля повернеться. Цей плагін — ваш винуватець, а не жертва.

Чекліст B: Загартування, щоб це не повернулося наступного вівторка

1. Виключіть ендпоїнти автентифікації з кешу: /wp-login.php, /wp-admin/*, та за потреби /wp-json/ для адмінських потків.
2. Стандартизувати деплой конфігурації: одне джерело істини для wp-config.php і солей, доставлене ідентично на всі вузли.
3. Моніторинг перенаправлень: відстежуйте рівень 302 для wp-login.php і wp-admin. Сплеск часто — ранній сигнал.
4. Логування на edge і origin: включайте ідентифікатори запитів, щоб відслідковувати одну спробу входу через стек.
5. Документуйте політику канонічного URL (хост, схема, HSTS). Недописана політика стає фольклором; фольклор — інцидентами.
6. Тестуйте після змін: коли змінюєте правила CDN, термінацію HTTPS або плагіни кешу — явно тестуйте потік входу.

Жарт №2: Найшвидший спосіб створити петлю входу WordPress — сказати: «Це лише невелика зміна редиректу». Петля це почує.

Три корпоративні історії з практики

Інцидент №1: Неправильне припущення (HTTPS — це HTTPS, так?)

Середня компанія запускала WordPress за балансувальником, який термінував TLS. Origin-сервери спілкувалися внутрішньо по plain HTTP. Команда вважала, що раз у браузері є замочок — додаток «знає», що це HTTPS.

Одного дня редактори почали скаржитися на петлю входу. Не всі — але достатньо, щоб викликати паніку й шквал повідомлень у Slack. Балансувальник було замінено в рамках оновлення мережі, і поведінка заголовків за замовчуванням змінилася.

На origin WordPress почав бачити запити як HTTP. Він відповідав перенаправленнями на HTTPS (бо home був https), але також встановлював cookie так, що це не відповідало очікуванням браузера. Історія auth-cookie стала неконсистентною між запитами. Користувачі входили, їх перенаправляло, а потім до них ставилися як до незнайомців і повертали назад.

Вирішення було банальним: забезпечити коректну установку X-Forwarded-Proto: https на edge і впевнитися, що origin йому довіряє. Коли WordPress отримав стабільне уявлення про схему, петля зникла.

Урок: у проксованому середовищі «HTTPS» — не факт, а твердження, передане заголовками. Якщо ви явно не керуєте цим твердженням, додаток вигадає свою реальність.

Інцидент №2: Оптимізація, що обернулася проти (кешувати все)

Інша організація мала ініціативу продуктивності. Хтось увімкнув агресивне правило CDN для кешування більшої кількості HTML, включно з «низькоризиковими» сторінками. wp-login.php виглядав як «ще одна сторінка» у наборі правил. Це була перша помилка.

За кілька годин коефіцієнт успішних логінів упав. Не до нуля — але достатньо, щоб заплутати. CDN видавав кешовані сторінки входу із застарілими nonce і невідповідними цільовими редиректами. Ще гірше — деякі кешовані відповіді не включали Set-Cookie коректно, залежно від того, як edge трактував «некешовані» заголовки.

Інцидент став питанням політики, бо зміни позиціонувалися як «робота над продуктивністю», а продуктивність має вигляд героя. Натомість вона перетворила автентифікацію на імовірнісний театр.

Вирішення полягало у створенні явних правил обходу для всіх ендпоїнтів автентифікації та всього, що встановлює чутливі cookie. Потім додали synthetic-монітор, який виконував повний потік входу і сповіщав про несподівані ланцюжки перенаправлень.

Урок: кеш — не хаммер, а скальпель. Якщо ви махаєте ним як молотом, ви рано чи пізно влучите у власну систему входу.

Інцидент №3: Нудна, але правильна практика, що врятувала день (імутований конфіг)

Компанія запускала WordPress на кількох апп-серверах. Вони мали сувору практику: конфігурація, включно з солями й ключами, керувалася централізовано й деплоїлась однаково з кожним релізом. Ніяких ручних правок. Ніяких «швидких фіксів» на окремих вузлах.

Вони все одно мали інцидент — інженер додав новий вузол у стані стресу. Вузол прийшов зі старішого образу і спочатку мав неузгоджений wp-config.php. У багатьох середовищах це спричинило б випадкові петлі входу залежно від того, до якого бекенду потрапляє користувач.

Ось що їх врятувало: пайплайн деплойменту виявив дріфт. Новий вузол не пройшов перевірку контрольної суми конфігурації і ніколи не потрапив до пулу балансувальника. Петля входу ніколи не дійшла до клієнтів; вона залишилася проблемою стейджингу, де їй і місце.

Вони виправили образ, пере-розгорнули і продовжили роботу. Жодної нічної «чому це лише у деяких користувачів» детективної сесії.

Урок: найнадійніше виправлення автентифікації — запобігти невідповідності. Друге за надійністю — не дозволяти невідповідним вузлам обслуговувати трафік.

Питання та відповіді

Чому WordPress продовжує перенаправляти мене на сторінку входу після входу?

Бо WordPress не отримує або не приймає дійсну auth-cookie у наступному запиті. Зазвичай це спричинено невідповідністю URL/схеми, проблемами з областю cookie, кешуванням, заголовками проксі або плагіном, що втручається в заголовки.

Чи очищення cookie — це справжнє вирішення?

Очищення cookie — це діагностичний крок. Якщо воно раз вирішило проблему, ймовірно ви нещодавно змінили солі/ключі або була тимчасова невідповідність cookie. Якщо не допомагає — проблема в стеку, а не в браузері.

Чи може CDN або WAF спричинити петлю входу?

Абсолютно. Якщо CDN кешує wp-login.php, видаляє Set-Cookie або виконує challenge на POST-запити — ви застрягнете в петлі. Обійдіть edge, щоб підтвердити, потім додайте явні правила обходу.

У чому різниця між home і siteurl, і чому це важливо?

siteurl — це місце, де живуть ядрові файли WordPress; home — це те, що сайт вважає своїм публічним URL. Якщо вони не узгоджуються (особливо схема/хост), перенаправлення і область cookie можуть зламати автентифікацію.

Я за балансувальником. Який заголовок має найбільше значення?

X-Forwarded-Proto. Якщо він неправильний або йому не довіряють, WordPress може вважати, що він працює по HTTP, навіть коли клієнт використовує HTTPS, що призведе до зламаних перенаправлень і флагів cookie.

Чи може це бути плагін, навіть якщо сайт працює для відвідувачів?

Так. Публічні сторінки можуть працювати, а адмін/автентифікація — ламаються, бо плагіни підписуються на логіку входу, редиректи, перевірки безпеки та заголовки. Вимкніть плагіни, щоб переконатися.

Чому це відбувається лише у деяких користувачів у балансованому середовищі?

Зазвичай через дріфт конфігурації (різні солі/ключі) або припущення про стейтфул-стан. Якщо один бекенд відкидає cookie, створені іншим, ви отримаєте «працює іноді» поведінку. Зробіть конфіг ідентичною і уникайте стейтфул-хитрощів.

Чи допоможе скидання солей WordPress виправити петлю входу?

Скидання солей анулює всі сесії, що може «вирішити» петлі, спричинені неконсистентними або скомпрометованими cookie. Але якщо корінь проблеми — заголовки проксі, кеш або невідповідність URL — це не допоможе — користувачі просто будуть викинуті і все одно лишаться в петлі.

Що робити, якщо я не можу отримати доступ до wp-admin або WP-CLI взагалі?

Перейменуйте директорію плагінів через SSH, щоб відключити їх усіх: wp-content/plugins → plugins.disabled. Якщо це вирішує вхід — повертайте плагіни поступово. Якщо ні — зосередьтеся на home/siteurl та виявленні HTTPS за проксі.

Висновок: наступні кроки, щоб уникнути повторення

Виправлення петлі входу WordPress — це не геройство, а відмова дозволяти своєму стеку вас обманювати. Слідкуйте за cookie. Слідкуйте за перенаправленнями. Підтвердіть, що WordPress знає, який у нього канонічний URL, і перевірте, що браузер робить насправді.

Практичні наступні кроки:

1. Зробіть home і siteurl ідентичними (схема + хост).
2. Переконайтеся, що ваш проксі/CDN не кешує і не змінює wp-login.php і /wp-admin/, і ніколи не видаляє Set-Cookie.
3. Перевірте виявлення HTTPS за проксі через форвард-заголовки.
4. Вимкніть плагіни/теми, щоб ізолювати вивід заголовків і хуки автентифікації; вмикайте по одному.
5. Уніфікуйте wp-config.php (особливо солі/ключі) на всіх вузлах і тримайте час синхронізованим.

Якщо ви зробите ці п’ять речей, петля входу повернеться до того, чим вона має бути: історією, яку ви розповідаєте іншим інженерам, а не місцем вашого постійного життя.