wp-admin WordPress не відкривається: справжні причини та виправлення

Швидкий план діагностики

Якщо ви на чергуванні — не філософствуйте. Тріаж. Ваша мета — швидко відповісти на три питання:

1. Чи доходить запит до сервера? (DNS, CDN/WAF, TLS, віртуальний хост, маршрутизація)
2. Чи віддає вебсервер запит у PHP коректно? (Nginx/Apache конфігурація, стан PHP‑FPM, таймаути)
3. Чи «задихається» сам WordPress? (фатали плагінів/теми, підключення/латентність БД, кеш об’єктів, дозволи файлової системи)

Перевірити перше (30–90 секунд): edge та HTTP‑статус

• З вашого ноутбука: curl -I https://example.com/wp-admin/ та curl -I https://example.com/wp-login.php.
• Дивіться коди статусу: 200/302/401/403/404/500/502/503/504. Це не декорація; це карта.
• Якщо бачите 301/302 цикли, зосередьтеся на нормалізації схеми/хоста та домені cookie.
• Якщо бачите 502/504, перевіряйте PHP‑FPM або таймаути апстріму (або додаток виконується занадто довго).
• Якщо бачите 403, дивіться правила WAF, basic auth, дозволи файлів або плагіни безпеки.

Перевірити друге (2–5 хвилин): логи з наміром

• Помилки Nginx/Apache для точного таймстемпу вашого запиту.
• Логи PHP‑FPM та slowlog (якщо увімкнено) для застряглих воркерів.
• Лог відлагодження WordPress (лише якщо можете безпечно увімкнути) для фаталів плагінів/тем.

Перевірити третє (5–15 хвилин): вузькі місця ресурсів

• Навантаження CPU, тиск пам’яті, OOM killer, I/O wait диска, заповнений файловий простір.
• Підключення до бази даних і латентність запитів.
• Доступність кешу об’єктів (Redis/Memcached) і таймаути.

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

Що насправді робить wp-admin (і чому він падає)

/wp-admin — це не одна сторінка. Це набір PHP‑точок входу (зокрема wp-admin/admin.php), які швидко розгалужуються у:

• Перевірки автентифікації (cookie, nonce, ролі користувачів)
• Читання з бази даних (user meta, опції, стан плагінів)
• Читання з файлової системи (плагіни, теми, переклади)
• HTTP‑виклики (деякі плагіни викликають зовнішні API на адмін‑сторінках — так, це трапляється)
• AJAX‑ендпоїнти (admin-ajax.php), які можуть зависати незалежно

Отже, коли «wp-admin не відкривається», ви зазвичай маєте справу з однією з цих категорій:

• Блокування на мережі/edge: неправильний DNS, CDN/WAF блокує, невідповідність TLS, невірний origin.
• HTTP маршрутизація/конфігураційна помилка: правила перезапису, невірний віртуальний хост, неправильний обробник PHP, зламані fastcgi_param.
• Фатал додатка: синтаксична помилка плагіна/теми, відсутній файл, несумісна версія PHP.
• Відмова залежностей: БД повільна/падає, Redis недоступний, NFS/EFS фрізить, диск повний, вичерпано іноди.
• Виснаження ресурсів: пул PHP‑FPM насичений, ліміт пам’яті, максимальний час виконання, заблоковані сесії.
• Цикл редиректів/автентифікації: невідповідність site URL, некоректне налаштування HTTPS offload, проблеми з доменом cookie.

Одна цитата, яку варто приклеїти над монітором:

«Надія — це не стратегія.» — Gene Kranz

Відмови wp-admin винагороджують метод, а не оптимізм.

Цікаві факти та історія (що допомагає у відлагодженні)

• Факт 1: WordPress походить від форку b2/cafelog у 2003 році, і його система плагінів розрослася в поле сумісності — потужна, але легко ламана одним невдалим оновленням.
• Факт 2: wp-login.php і /wp-admin/ — це окремі точки входу; збій в одній не завжди означає збій в іншій. Перевіряйте обидві.
• Факт 3: Історично WordPress припускав розгортання в стилі LAMP; сучасні стеки (Nginx + PHP‑FPM, реверс‑проксі, контейнери) вимагають додаткових заголовків і розуміння схеми, щоб уникнути циклів редиректів.
• Факт 4: «Біла сторінка смерті» стала відомою тому, що фатали PHP раніше не виводили нічого у браузер у production-конфігураціях — логи були єдиною правдою.
• Факт 5: Багато адмін‑запитів ефективно некешовані й специфічні для користувача, тому вони першими виявляють проблеми з базою даних і PHP — ваша кешована головна може продовжувати посміхатися, поки панель керування недоступна.
• Факт 6: Таблиця опцій (wp_options) — гаряча точка: автозавантажені опції читаються постійно. Надмірний autoload‑навантаження уповільнює кожну адмін‑сторінку.
• Факт 7: З WordPress 5.2 «захист від фатальних помилок» може надсилати листи адміністраторам і відновлювати деякі випадки — але це не врятує від проблем інфраструктури і не виправить пошкоджений opcode cache.
• Факт 8: REST API і admin‑ajax ендпоїнти часто страждають від правил безпеки; WAF, що «допомагає», може мовчки вбити дії інтерфейсу wp-admin.

Почніть з перших принципів: класифікуйте збій

1) Чи доступний взагалі origin?

Якщо ваш браузер не може дістатися сайту, wp-admin не має значення. Спочатку перевірте DNS, CDN і TLS. Багато «проблем WordPress» — це насправді «балансувальник навантаження говорить з неправильним пулом».

2) Який HTTP‑код ви отримуєте стабільно?

• 301/302 цикл: невідповідність URL/схеми, заголовки реверс‑проксі, проблеми з cookie, війни канонізації.
• 403: WAF, IP‑білійт, basic auth, дозволи файлів, плагін безпеки, ModSecurity‑правила.
• 404: невідповідний віртуальний хост, правила перезапису, неправильний docroot, відсутні файли WordPress, плутанина в multisite шляхах.
• 500: PHP‑фатал, неправильна конфігурація, ліміт пам’яті, зламаний плагін/тема, поганий opcode cache, помилки прав файлів.
• 502/504: Nginx не може поговорити з PHP‑FPM, PHP‑FPM перевантажений/завис, таймаут апстріма або додаток чекає на БД/диск.
• 503: режим обслуговування, перевантажений origin, деплой у процесі або апстрім спеціально скиджає навантаження.

3) Тільки wp-admin чи всі динамічні сторінки?

Порівняйте:

• / (часто кешовано)
• /wp-login.php (менше коду плагінів, ніж повний адмін)
• /wp-admin/ (більше перевірок, більше хуків плагінів)
• /wp-admin/admin-ajax.php (гарячий шлях для панелей керування)

Жарт №1: Кеш‑шар — це як гарна скатертина: вона може приховати безлад, але не помиє посуд.

4) Вирішіть: конфіг, потужності чи код?

Усе, що ви робите, має на меті віднести інцидент до однієї категорії:

• Конфіг: заголовки проксі, SSL‑термінація, правила перезапису, обробник PHP, власник файлів, SELinux/AppArmor.
• Потужності: пул PHP‑FPM, підключення до БД, IOPS, пам’ять, CPU, Redis.
• Код: оновлення плагіна/теми, зміна версії PHP, пошкоджений ядро WordPress, власний mu‑plugin.

Практичні завдання: команди, висновки та рішення

Нижче перелік перевірених у полі завдань, які можна виконати на типовому Linux‑хості. Вони написані реалістично: ви запускаєте команду, читаєте вивід і приймаєте рішення. Якщо ви в контейнерах, виконуйте еквівалент у потрібному pod/контейнері.

Завдання 1: Відтворіть збій з сервера і захопіть статус/редиректи

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-admin/ | head -n 20
HTTP/2 302
date: Sat, 27 Dec 2025 10:12:41 GMT
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly
server: nginx

Що це означає: Ви отримуєте нормальний редирект на сторінку логіна. Якщо користувачі скаржаться «wp-admin не відкривається», перевірте, чи сам логін працює і чи cookie встановлюються/повертаються.

Рішення: Якщо бачите цикл редиректів, де location: відскакує між HTTP і HTTPS або між доменами, переходьте до діагностики циклу редиректів (Завдання 4–6).

Завдання 2: Перевірте, чи завантажується wp-login.php, але wp-admin ні

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/wp-login.php | head -n 15
HTTP/2 200
date: Sat, 27 Dec 2025 10:12:55 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: Сторінка входу доступна. Якщо wp-admin таймаутить або повертає 500, але wp-login працює, підозрюйте хуки плагінів при bootstrap адмінки, повільну БД після автентифікації або потужність PHP‑FPM.

Рішення: Зосередьтесь на PHP‑FPM, БД та фаталах WordPress, а не на DNS/CDN.

Завдання 3: Визначте точну помилку upstream (приклад Nginx)

cr0x@server:~$ sudo tail -n 40 /var/log/nginx/error.log
2025/12/27 10:13:10 [error] 1842#1842: *991 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 203.0.113.10, server: example.com, request: "GET /wp-admin/ HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:", host: "example.com"

Що це означає: Nginx поговорив з PHP‑FPM, але не отримав заголовок відповіді до таймауту. Це майже ніколи не «помилка Nginx». PHP застряг, перевантажений або чекає на БД/диск/мережу.

Рішення: Перевірте стан пулу PHP‑FPM і повільні запити (Завдання 7–9), потім БД (Завдання 12).

Завдання 4: Виявити цикли редиректів і де вони починаються

cr0x@server:~$ curl -sS -o /dev/null -D - -L --max-redirs 10 https://example.com/wp-admin/ | egrep -i 'HTTP/|location:'
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/
HTTP/2 301
location: http://example.com/wp-admin/
HTTP/1.1 301 Moved Permanently
location: https://example.com/wp-admin/

Що це означає: Ви перекидаєтесь між HTTP і HTTPS. Це проблеми виявлення схеми на реверс‑проксі/SSL‑термінації або невідповідність siteurl/home WordPress з реальністю.

Рішення: Виправте визначення схеми: забезпечте передачу X-Forwarded-Proto проксі та його врахування WordPress (Завдання 6), і перевірте налаштування URL у БД (Завдання 11).

Завдання 5: Підтвердити, що сервер вважає канонічний хост/схему

cr0x@server:~$ php -r 'echo "HTTPS=" . ($_SERVER["HTTPS"] ?? "");'
HTTPS=

Що це означає: У CLI це порожньо, але це нагадує про реальну проблему: WordPress вирішує «чи я HTTPS?» на основі серверних змінних. За проксі вони часто неправильні, якщо не налаштовано.

Рішення: Переконайтеся, що вебсервер передає коректні fastcgi‑параметри і проксі інжектує forward‑заголовки.

Завдання 6: Перевірити, чи доходять заголовки реверс‑проксі до PHP (Nginx + PHP‑FPM)

cr0x@server:~$ sudo grep -R "X-Forwarded-Proto" -n /etc/nginx/sites-enabled | head
/etc/nginx/sites-enabled/example.conf:42:proxy_set_header X-Forwarded-Proto $scheme;

Що це означає: Заголовок встановлено для проксійованих локацій, але wp‑admin може обслуговуватися через fastcgi, а не proxy. Різні блоки — різна поведінка.

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

Завдання 7: Перевірка стану PHP‑FPM: воркери насичені?

cr0x@server:~$ sudo systemctl status php8.2-fpm --no-pager
● php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled)
     Active: active (running) since Sat 2025-12-27 09:41:03 UTC; 33min ago
   Main PID: 912 (php-fpm8.2)
     Status: "Processes active: 28, idle: 0, Requests: 18452, slow: 37, Traffic: 2.1req/sec"

Що це означає: Idle = 0. Це явний сигнал: пул повністю зайнятий. Запити очікують у черзі, Nginx таймаутить, wp-admin «не відкривається».

Рішення: Додайте потужності (обережно збільшіть pm.max_children, масштабування) або зменшіть вартість на запит (усуньте повільні запити до БД, відключіть погані плагіни, усуньте дискові фризи).

Завдання 8: Подивіться конфіг пулу PHP‑FPM на ліміти, що відповідають симптомам

cr0x@server:~$ sudo egrep -n 'pm\.max_children|pm\.max_requests|request_terminate_timeout' /etc/php/8.2/fpm/pool.d/www.conf | sed -n '1,120p'
56:pm.max_children = 20
62:pm.max_requests = 500
115:request_terminate_timeout = 60s

Що це означає: З max_children = 20 сплески wp-admin швидко насичують пул. Таймаут завершення 60s може вбити довгі законні операції (наприклад, оновлення плагінів), але також запобігає повному зависанню.

Рішення: Якщо бачите таймаути біля ~60s, це може бути самостворена проблема. Налаштовуйте відповідно до CPU/пам’яті та реального профілю запитів, а не на відчуттях.

Завдання 9: Визначте, чи PHP помирає від нестачі пам’яті

cr0x@server:~$ sudo tail -n 30 /var/log/php8.2-fpm.log
[27-Dec-2025 10:14:02] WARNING: [pool www] child 2143 said into stderr: "PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes) in /var/www/html/wp-includes/class-wpdb.php on line 2345"

Що це означає: Класика: досягнуто ліміт пам’яті. wp-admin зазвичай підвантажує більше кодових шляхів і великі масиви.

Рішення: Обережно підвищте ліміт PHP і знайдіть основну причину (зазвичай плагін, що виконує важкі запити адміністрування). Не підвищуйте пам’ять до моменту, поки хост не почне свопитися.

Завдання 10: Підтвердити наявність і читабельність файлів ядра WordPress

cr0x@server:~$ ls -la /var/www/html/wp-admin | head
total 172
drwxr-xr-x  9 www-data www-data  4096 Dec 26 22:01 .
drwxr-xr-x  5 www-data www-data  4096 Dec 27 09:55 ..
-rw-r--r--  1 www-data www-data  7339 Dec 26 22:01 admin.php
-rw-r--r--  1 www-data www-data  1058 Dec 26 22:01 index.php

Що це означає: Файли присутні і належать користувачу виконання. Якщо бачите дивних власників (наприклад, CI‑користувач) або відсутні файли — ядро може бути частково задеплояне або перезаписане.

Рішення: Виправте власність файлів і відновіть відомо‑робоче ядро WordPress за потреби. Часткові оновлення викликають дивні збої тільки в адмінці.

Завдання 11: Перевірити URL сайту, збережені в базі даних

cr0x@server:~$ mysql -N -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
siteurl https://example.com
home https://example.com

Що це означає: Якщо вони неправильні (http vs https, невірний домен, застарілий staging URL), редиректи wp-admin можуть зациклитись або перекидати на неправильний хост.

Рішення: Виправте їх у БД (або тимчасово перевизначте в wp-config.php під час реагування). Потім усуньте процес, що дозволив дрейф.

Завдання 12: Перевірити стан MySQL/MariaDB і повільні запити прямо зараз

cr0x@server:~$ mysql -e "SHOW PROCESSLIST;" | head -n 15
Id	User	Host	db	Command	Time	State	Info
214	app	10.0.2.15:51122	wp	Query	28	Sending data	SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'
221	app	10.0.2.15:51148	wp	Query	31	Locked	UPDATE wp_options SET option_value = '...' WHERE option_name = 'rewrite_rules'

Що це означає: Читання автозавантажених опцій займають десятки секунд і UPDATE заблокований: це реальна причина зависання wp-admin. Адмін‑сторінки постійно читають опції; блокування там отруйне.

Рішення: Визначте утримувача блокування, зменшіть контенцію блокувань і дослідіть роздуті опції/autoload. За потреби вбивайте зле що працює під час інциденту і потім розбирайтеся в корені.

Завдання 13: Знайти утримувача блокування (InnoDB) і вирішити, чи вбивати його

cr0x@server:~$ mysql -e "SHOW ENGINE INNODB STATUS\G" | egrep -n "LATEST DETECTED DEADLOCK|TRANSACTION|WAITING" | head -n 30
103:TRANSACTION 4211892, ACTIVE 62 sec starting index read
110:LOCK WAIT 12 lock struct(s), heap size 1136, 6 row lock(s)
121:MySQL thread id 221, OS thread handle 140520112060160, query id 981231 10.0.2.15 app updating

Що це означає: Маєте очікування блокування приблизно 60 секунд. Адмін‑запити можуть накопичуватися за цим і насичувати PHP‑FPM.

Рішення: Під час реагування розгляньте можливість вбити блокуючу сесію, якщо це безпечно (KILL 221;) і ви розумієте побічні ефекти (часткові оновлення, інсталяції плагінів). Потім усуньте корінь проблеми.

Завдання 14: Перевірити вільне місце на диску та виснаження інодів (тихі вбивці)

cr0x@server:~$ df -h /var/www/html /var/lib/mysql
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        80G   79G  650M  99% /
/dev/vdb1       200G  120G   81G  60% /var/lib/mysql

cr0x@server:~$ df -i /var/www/html
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      5242880 5239011   3869  100% /

Що це означає: У вас закінчилися іноди. Це може ламати сесії, завантаження, оновлення плагінів, запис кешу і логів. Проявляється як «wp-admin зламаний» у творчих і неінформативних способах.

Рішення: Звільніть іноди (очистіть tmp/cache, старі релізи, налаштуйте ротацію логів) і додайте моніторинг. Диск, що заповнився — передбачувана проблема; ставтеся до неї як до відмови процесу, а не як до форс‑мажору.

Завдання 15: Виявити I/O wait, що робить усе «повільним»

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server)  12/27/2025  _x86_64_ (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    4.22   62.35    0.00   21.33

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  %util
vda              4.20   85.30   92.1   941.4    8.12  91.3  98.7

Що це означає: 62% iowait і майже 100% завантаження диска. Ваша «проблема WordPress» насправді — затримка сховища. wp-admin виконує багато дрібних читань (PHP‑файли, сесії, опції), тому він страждає першим.

Рішення: Зменшіть I/O (відключіть шумний логінг, виправте резервні завдання, перемістіть сесії/об’єктний кеш у пам’ять, покращіть рівень зберігання) або масштабуйтесь до більшої кількості IOPS. Не налаштовуйте таймаути PHP, щоб «виправити» крах сховища.

Завдання 16: Підтвердити стан Redis об’єктного кешу (якщо використовується)

cr0x@server:~$ redis-cli -h 127.0.0.1 ping
PONG

cr0x@server:~$ redis-cli -h 127.0.0.1 info stats | egrep 'instantaneous_ops_per_sec|rejected_connections'
instantaneous_ops_per_sec:1874
rejected_connections:0

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

Рішення: Якщо Redis працює неналежно, відновіть його або тимчасово відключіть object cache drop‑in (wp-content/object-cache.php), щоб відновити доступ до адмінки.

Завдання 17: Відключити плагіни без доступу до wp-admin (доволі безпечний спосіб)

cr0x@server:~$ cd /var/www/html/wp-content
cr0x@server:~$ mv plugins plugins.disabled
cr0x@server:~$ mkdir plugins
cr0x@server:~$ chown -R www-data:www-data plugins

Що це означає: WordPress не завантажить плагіни, якщо каталог порожній. Це найшвидший спосіб підтвердити «плагін убив адмінку».

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

Завдання 18: Переключитися на стандартну тему, якщо адмінка зламана через тему

cr0x@server:~$ mysql -N -e "UPDATE wp_options SET option_value='twentytwentyfour' WHERE option_name IN ('template','stylesheet'); SELECT option_name, option_value FROM wp_options WHERE option_name IN ('template','stylesheet');"
template	twentytwentyfour
stylesheet	twentytwentyfour

Що це означає: Це примусово перемикає тему на стандартну. Деякі теми або фреймворки тем можуть прив’язуватися до адмінки і ламати її.

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

Завдання 19: Перевірити, чи не застряг режим «maintenance»

cr0x@server:~$ test -f /var/www/html/.maintenance && echo "maintenance file present" || echo "no maintenance file"
maintenance file present

Що це означає: Невдале оновлення могло залишити WordPress у режимі обслуговування, повертаючи 503‑подібну поведінку або сторінку «Briefly unavailable».

Рішення: Видаліть .maintenance лише якщо впевнені, що зараз жодне оновлення не виконується. Потім коректно повторіть оновлення.

Завдання 20: Тимчасово увімкнути логування WordPress (контрольована зона впливу)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/html/wp-config.php | head"
90:define('WP_DEBUG', false);
91:define('WP_DEBUG_LOG', false);
92:define('WP_DEBUG_DISPLAY', false);

Що це означає: Debug вимкнено (добре). Коли wp-admin впав через фатали, можливо, потрібні логи. Але не виводьте помилки в HTML у production.

Рішення: Увімкніть WP_DEBUG_LOG = true і тримайте WP_DEBUG_DISPLAY вимкненим, відтворіть один раз, потім вимкніть і перегляньте wp-content/debug.log.

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

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

«Too many redirects» на /wp-admin

Симптом: Помилка в браузері або curl показує чергування 301/302 між http/https або між доменами.

Причина: Невідповідність siteurl/home, проксі не ставить X-Forwarded-Proto, WordPress думає, що він на HTTP, хоча клієнт на HTTPS, або плагін канонічних редиректів бореться з балансувальником.

Виправлення: Забезпечте коректні форвард‑заголовки; виправте siteurl/home; додайте явне визначення HTTPS у wp-config.php за наявності TLS‑термінації; приберіть дублюючу логіку редиректів.

Порожній білий екран (без HTML, без помилок)

Симптом: wp-admin повертає порожню сторінку, іноді 200.

Причина: PHP‑фатал з display_errors вимкненим; плутанина з opcode cache після деплоя; зламаний плагін/тема; вичерпання пам’яті.

Виправлення: Перевірте логи PHP‑FPM і вебсерверу; коротко увімкніть WP debug log; відкотіть оновлення плагіна/теми; скиньте opcache через перезапуск сервісу, якщо доречно.

502 Bad Gateway від Nginx (або 504 Gateway Timeout)

Симптом: Nginx повертає 502/504; у логу помилка upstream timed out або connect() failed до php‑fpm сокета.

Причина: PHP‑FPM впав, шлях до сокета неправильний, пул насичений або PHP чекає на БД/диск/мережу.

Виправлення: Перезапустіть PHP‑FPM, якщо він завис; виправте права/шлях до сокета; збільшіть потужності; знайдіть і усуньте повільний шлях (плагін, блокування БД, затримка сховища).

403 Forbidden тільки на wp-admin

Симптом: Головна сторінка завантажується; wp-admin — 403.

Причина: Правило WAF спрацювало на admin cookie або query string; basic auth застосований помилково; плагін безпеки блокує IP; дозволи файлової системи на wp-admin.

Виправлення: Перегляньте логи WAF; додайте в білий список admin‑шляхи обережно; підтвердьте блоки локацій Nginx/Apache; виправте власність/дозволи; перевірте відсутність випадкових deny‑правил.

«Error establishing a database connection» при зверненні до адмінки

Симптом: Сторінка помилки БД, часто переривчасто в навантаженні.

Причина: БД впала, досягнуто max connections, мережеві проблеми, DNS для хоста БД зламаний, або повільні запити створюють нагромадження підключень.

Виправлення: Перевірте стан БД, processlist і ліміти підключень; масштабуйтесь; оптимізуйте запити; використовуйте персистентні підключення тільки якщо розумієте наслідки.

Логін працює, але wp-admin завантажується вічно

Симптом: Облікові дані прийняті; панель ніколи не закінчує завантаження.

Причина: admin-ajax.php виклики зависають через плагін, REST API блокується або повільний зовнішній API викликається в адмінці.

Виправлення: Перегляньте вкладку network у DevTools браузера для застряглих запитів; слідкуйте за логами admin-ajax; відключіть плагіни; обмежте або додайте таймаути для зовнішніх викликів; пропустіть REST‑ендпоїнти через правила безпеки.

Доступ мають лише деякі користувачі

Симптом: Працює для вас, не працює для колег; або працює на мобільному, але не на корпоративному ноутбуку.

Причина: Неправильний домен/шлях cookie, проблеми SameSite при SSO, корпоративний проксі кешує або обрізає заголовки, IP‑білійт.

Виправлення: Нормалізуйте домен і схему; перевірте атрибути Set‑Cookie; уникайте IP‑білійтів, якщо не контролюєте мережу; перевірте поведінку проксі.

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

Інцидент №1: Хибне припущення (видання «це не може бути DNS»)

Середня компанія запускала WordPress для маркетингових сторінок і партнерського порталу, що жив у wp-admin. Головна сторінка була під агресивним кешуванням CDN. Зовні все виглядало добре: лендінги завантажувалися миттєво, перевірки аптайму пройшли, керівництво перестало питати. Саме тоді почалася реальна проблема.

Sales ops повідомили, що ніхто не може увійти. Інженери робили звичні речі: чистили кеш, пробували інкогніто, звинувачували cookie. Хтось впевнено сказав: «DNS в порядку, бо сайт завантажується». Це припущення тримало інцидент у полоні дві години.

Ловушка: CDN мав два origin’и. Статичні сторінки віддавалися з origin A (правильного). Шляхи адмінки були направлені на origin B (старе середовище) через застаріле правило базоване на шляхах, додане під час попередньої міграції. Origin B відповідав, але з іншим TLS сертифікатом і іншим siteurl WordPress, тож він зациклював користувачів у редиректах, поки браузери не здалися.

Виправлення було нудним: виправити правила маршрутизації CDN і очистити неправильну поведінку. Урок був гостріший: «сайт завантажується» не є перевіркою здоров’я. Потрібні перевірки, які б хітали /wp-login.php і реальний адмін‑ендпоїнт, а не лише кешовану головну.

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

Інша команда гналася за продуктивністю. Вони додали Redis object cache drop‑in, щоб зменшити навантаження на БД. У staging це виглядало чудово: менше запитів до БД, швидше генерація сторінок, задоволені графіки. Вони задеплояли це в прод під час вікна низького трафіку і пішли додому задоволені.

За три дні wp-admin почав періодично таймаутити. Головна сторінка все ще «кричала», бо була кешована на edge. Дашборд же став лотереєю. Воркери PHP‑FPM накопичувалися в «busy» стані. Логи Nginx заповнилися upstream таймаутами. БД виглядала тихішою, ніж зазвичай — що підозріло заспокоювало.

Справжня причина — мережевий шлях і таймаути. Redis був на окремому вузлі. За певних умов втрати пакетів клієнт Redis гальмував довше, ніж upstream‑таймаут веб‑рівня. Кожен адмін‑запит чекав на читання з кешу, утримуючи PHP‑воркерів у заручниках. Достатньо заручників — і пул насичується. Тоді все виглядає як «WordPress впав», хоча насправді кеш просто був не мертвий, а повільний.

Вирішення включало налаштування адекватних таймаутів клієнта, додавання моніторингу Redis і стратегії «fail open» для object cache, де це доречно. Оптимізація не провалилася тому, що кеш поганий; вона провалилася, бо команда поставила нову залежність рівною localhost.

Інцидент №3: Скучная, але правильна практика, що врятувала день (гігієна релізів)

Ще одна організація тримала кілька WordPress‑сайтів на спільній інфраструктурі. Не гламурно. Але у них була дисципліна релізів: іммутабельні директорії релізів, переключення через symlink і документований rollback, який будь‑хто на чергуванні міг виконати о 3 ранку без вигадування синтаксису.

Одного вечора оновлення плагіна внесло PHP‑фатал під час bootstrap адмінки для частини запитів — саме при завантаженні сторінки налаштувань, що викликала відсутню функцію в PHP 8.2. Фронтенд сторінки лишалися ок, бо кеш і фатальний шлях був лише для адмінки. Інцидент повідомили як «адміни не можуть публікувати». Це бізнес‑інцидент, навіть якщо дашборд‑моніторинг лишається зелений.

Інженер на чергуванні не SSH‑вся «покопатися». Він пройшов по runbook: переключив symlink назад на попередній реліз, перезапустив PHP‑FPM щоб очистити opcache, перевірив здоров’я wp-admin і лише потім почав розбиратися в корені. Бізнес‑операції відновилися за кілька хвилин.

Пізніше вони протестували плагін у staging, що відповідала production PHP, і задеплоїли виправлену версію. Ніхто не писав героїчного постмортему «ми не спали всю ніч». Вони написали тихий тикет: «Додати synthetic checks для admin‑шляхів і заборонити оновлення ризикових плагінів». Скучно, але врятувало день.

Контрольні списки / покроковий план

Крок за кроком: безпечно відновити доступ до wp-admin

1. Підтвердьте масштаб: проблема лише у вас, у деяких мережах чи у всіх? Тестуйте з двох точок (ваш ноутбук + сервер).
2. Зніміть HTTP‑поведінку: код статусу, ланцюг редиректів і заголовки відповіді для /wp-admin/ і /wp-login.php.
3. Подивіться логи вебсерверу: звіртеся за таймстемпом і request ID, якщо він є.
4. Перевірте стан PHP‑FPM: працює, насичений, логує фатали, є повільні запити.
5. Перевірте стан БД: підключення, блокування, повільні запити, max connections.
6. Перевірте диск: місце + іноди + I/O wait. Звідси походить «випадкова» поведінка.
7. Швидко виключіть плагіни: перейменуйте wp-content/plugins. Якщо адмінка повернеться — знайдіть винуватця.
8. Перевірте тему: переключіться на стандартну тему через оновлення БД, якщо потрібно.
9. Підтвердьте канонічні налаштування URL: siteurl і home. Виправте невідповідність, що викликає цикли.
10. Тільки потім налаштовуйте таймаути/потужності: таймаути — не виправлення для зламаних залежностей; це лише запобіжник.
11. Відкотіть, якщо було недавнє оновлення: Якщо wp-admin впав після зміни, не сперечайтесь — відкотіть і стабілізуйте, потім розбирайтесь.
12. Запишіть корінь проблеми, поки пам’ять свіжа: ваше майбутнє «я» — інша людина з меншим контекстом і більше оповіщень.

Контрольний список: перевірка реверс‑проксі та HTTPS offload

• Балансувальник надсилає X-Forwarded-Proto та X-Forwarded-For.
• Вебсервер передає релевантні заголовки/параметри в PHP.
• WordPress бачить HTTPS коректно (особливо для cookie адмінки, помічених як secure).
• siteurl і home співпадають з публічним URL, включно зі схемою.
• Немає дублюючої логіки редиректів (балансувальник + плагін + вебсервер), що б’ються між собою.

Контрольний список: потужності та здоров’я залежностей

• PHP‑FPM має idle‑воркерів за нормального навантаження.
• БД показує мало блокувань і розумні часи запитів для опцій/користувачів.
• Диск має запас по місцю та інодам; бекапи не перетинаються з піковим трафіком.
• Redis/Memcached або здорові, або налаштовані на швидкий фейл/відкритий фейл.
• Моніторинг включає synthetic‑чеки, що хітять /wp-login.php і не кешований динамічний ендпоїнт.

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

Чому головна працює, а wp-admin впав?

Бо ваша головна, ймовірно, кешована (CDN, плагін кешування сторінок, реверс‑проксі). wp-admin — специфічний для користувача і динамічний, отже він потрапляє у PHP і базу напрямую. Помилки в адмінці часто пов’язані з потужністю або залежностями, які кеш приховує.

Який найшвидший спосіб визначити, чи плагін винуватий?

Перейменуйте wp-content/plugins, щоб WordPress завантажив нуль плагінів, і спробуйте wp-admin знову. Якщо відновиться — доказ «плагін‑причина». Потім відновіть плагіни поступово.

Чи підвищення ліміту пам’яті PHP — реальне виправлення?

Іноді. Якщо логи показують виснаження пам’яті, підвищення ліміту може відновити доступ. Але розглядайте це як тимчасовий турнікет. Основна причина — часто важкі адміністративні запити або величезні опції.

Що саме викликає «too many redirects» на wp-admin?

Зазвичай плутанина схеми/хоста: TLS‑термінація на проксі без коректних заголовків, невідповідність home/siteurl, або плагін редиректів, що примушує https, а origin думає http.

Як відлагоджувати порожню білу сторінку, не показуючи помилок користувачам?

Спершу дивіться логи Nginx/Apache і PHP‑FPM. Якщо потрібно, увімкніть WP_DEBUG_LOG, залишаючи WP_DEBUG_DISPLAY вимкненим, відтворіть один раз, потім вимкніть. Читайте wp-content/debug.log.

Чи може Cloudflare/CDN/WAF блокувати wp-admin, навіть якщо сайт завантажується?

Так. Правила WAF часто націлені на /wp-admin, wp-login.php, REST API або патерни admin‑ajax. Також CDN може маршрутизувати admin‑шляхи інакше. Перевіряйте логи edge і правила маршрутизації за шляхами.

Як зрозуміти, чи це насичення PHP‑FPM чи один повільний зовнішній ресурс?

Насичення PHP‑FPM показується як «idle: 0» і черги запитів, часто з upstream таймаутами. Далі треба знайти, чому воркери зайняті: повільні запити до БД/блокування, I/O wait диска або зовнішні API‑виклики. Не зупиняйтесь на «пул заповнений».

Яка найпоширеніша проблема бази даних, що викликає зависання wp-admin?

Контенція блокувань і повільні запити по таблиці опцій. Адмінка постійно читає опції, а деякі плагіни оновлюють опції так, що утворюються довгі блокування.

Чи слід перезапускати сервіси під час інциденту?

Перезапуск PHP‑FPM може бути тактичним кроком, якщо він завис або opcache пошкоджено після деплоя. Бездумні й повторні перезапуски — шлях до загадкових інцидентів. Захопіть логи і симптоми перш ніж перезапускати з метою.

Як запобігти, щоб outages wp-admin лишалися непоміченими?

Додайте synthetic моніторинг, що хітує /wp-login.php і динамічний ендпоїнт (некешований). Налаштуйте оповіщення на зростання 5xx, цикли редиректів та upstream таймаути. «Homepage 200 OK» не є стратегією надійності.

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

Коли wp-admin не відкривається, припиніть ставити це як ребус WordPress і почніть розглядати як продакшн‑інцидент. Визначте клас відмови (редиректи, 5xx, таймаути, петлі авторизації), підтвердьте, де запит помирає (edge, вебсервер, PHP, БД, сховище) і зробіть найменший безпечний крок, що відновить доступ.

Зробіть наступне, в порядку пріоритету:

1. Додайте health‑чеки для адмін‑шляхів (сторінка входу плюс динамічний ендпоїнт), щоб кеш не вводив в оману.
2. Інструментуйте стек: часи upstream вебсерверу, насичення PHP‑FPM, очікування блокувань БД, I/O wait диска та заповненість файлової системи (місце й іноди).
3. Зробіть відкот легким: іммутабельні релізи, переключення symlink і команда rollback у один клік.
4. Контролюйте оновлення плагінів: staging, що відповідає production PHP, і ворота для ризикових плагінів, що сильно чіпають адмінку.
5. Визначте політику щодо залежностей: якщо додаєте Redis, NFS, WAF або новий проксі‑шар — ви додаєте ще один шлях для відмови wp-admin. Спроектуйте таймаути та режими відмов явно.

Панель керування не є особливою. Це просто ваш найщиріший ендпоїнт — некешований, stateful і безжальний. Ставтеся до нього відповідно.