WordPress: бесконечный редирект при входе в админку

#Как проявляется

После ввода логина и пароля страница /wp-login.php загружается снова, без сообщения об ошибке, или браузер сообщает «Слишком много перенаправлений». Данные верны, но сессия не устанавливается. Причины: неверные значения Адрес WordPress и Адрес сайта (с www или без, http или https), повреждённые cookies, плагин безопасности или кэширования, неверный .htaccess, смещение времени сервера, ошибка в wp-config.php или за прокси (Cloudflare) не передаётся протокол HTTPS. Эта ошибка отличается от общей петли HTTPS: здесь проблема именно в аутентификации и cookies.

#Причины

#Порядок

1. Очистите cookies для вашего сайта и попробуйте в режиме инкогнитоОткройте страницу входа сайта в приватном окне браузера; если там вход работает, вероятна проблема с сохранёнными cookies. В Chrome откройте страницу сайта → значок настройки сайта слева от адреса → «Файлы cookie и данные сайта»/«Данные сайта» (название зависит от версии) и удалите данные только этого домена. Это завершит сеансы на нём. Затем заново откройте /wp-login.php и повторите вход; если проблема остаётся в приватном окне, переходите к настройке сайта.
2. Сравните адреса сайта и WordPress с адресом в браузереВ кабинете WordPress, если доступен, перейдите «Настройки → Общие» и сравните поля «Адрес WordPress (URL)» и «Адрес сайта (URL)» с адресом в браузере: особенно схему https и вариант с www. Если в панель не войти, администратор может прочитать настройки из базы через WP-CLI wp option get home и wp option get siteurl в корне сайта. Не меняйте адреса, пока не проверены DNS, TLS и правила перенаправления.
3. Задайте адреса в wp-config.php для принудительной проверкиСохраните копию wp-config.php в корневой папке WordPress и откройте редактор файлов панели хостинга. Если значения в базе неверны и доступ в админку закрыт, временно добавьте корректные WP_HOME и WP_SITEURL с реальным доменом до строки «That’s all, stop editing!». В кодовом блоке ниже — образец, example.ru надо заменить. Проверьте вход; при ошибке верните резервную копию файла.
4. Отключите все плагины, переименовав папку wp-content/pluginsЕсли подозрение на конфликт плагина остаётся, откройте файловый менеджер хостинга → wp-content, переименуйте plugins в plugins.off и попробуйте открыть /wp-login.php в приватном окне. Эта операция временно отключает все плагины и может нарушить формы, оплату и защиту сайта. Если вход появился, верните имя папки и деактивируйте плагины по одному из административного интерфейса; при неуспехе просто верните исходное имя.
5. Верните стандартный .htaccessПроверьте в корне сайта .htaccess только если запросы обслуживаются Apache. Скопируйте текущий файл, затем сравните блок между # BEGIN WordPress и # END WordPress со штатной конфигурацией для вашего режима размещения. Не стирайте чужие правила безопасности и перенаправлений. После согласованного изменения откройте /wp-login.php; на Nginx .htaccess не применяется — исправления нужны в конфигурации Nginx.
6. Проверьте, что кэширование не применяется к wp-login.php и wp-adminОткройте настройки кэша в используемом плагине WordPress, панели хостинга и внешней сети доставки содержимого. Убедитесь, что /wp-admin/, /wp-login.php и страницы авторизации не отдаются из общего кэша и что cookies не удаляются правилами прокси. Сохраните нынешние исключения, добавьте точечные правила по документации конкретного продукта, очистите только кэш сайта и повторите вход.
7. Проверьте дату и время на сервереВ терминале сервера выполните timedatectl status (Linux с systemd): проверьте текущие дату, время и синхронизацию. На устройстве пользователя тоже проверьте часы и часовой пояс. Если системное время расходится, администратор должен исправить настройку NTP на своём сервере; ручную установку времени на продуктивной машине без оценки последствий не применяйте. После исправления перезапустите браузер.
8. Если сайт за Cloudflare или прокси, добавьте определение HTTPSЕсли HTTPS завершается на обратном прокси, проверьте по журналу, что до PHP корректно доходит информация о схеме запроса. Для доверенного прокси можно настроить обработку HTTP_X_FORWARDED_PROTO в wp-config.php по приведённому примеру, но нельзя безусловно доверять заголовку, присланному напрямую из интернета. Прежде сравните правила прокси и is_ssl(); сделайте копию файла, измените, проверьте вход и при новой петле отмените правку.
9. Проверьте права на файлы и свободное местоЧерез панель хостинга проверьте, не заполнен ли диск: метрики «Диск» и «inode». Затем откройте свойства wp-config.php и каталога wp-content, убедитесь, что веб-сервер может читать конфигурацию и записывать файлы сеансов/кэша в разрешённые каталоги. Не ставьте 777 и не меняйте владельца всех файлов рекурсивно; точные права зависят от пользователя PHP-FPM. После исправления проверьте журнал PHP.
10. Обновите постоянные ссылкиЕсли уже удалось войти, откройте «Настройки → Постоянные ссылки», ничего не меняйте и нажмите «Сохранить изменения» для обновления правил WordPress, если это действительно нужно. Затем проверьте главную, /wp-admin/ и /wp-login.php. Этот шаг редко исправляет петлю входа; если редирект сохраняется, смотрите последовательность заголовков Location в инструментах разработчика браузера или с помощью curl -IL и ищите конфликтующие правила.
11. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения

    Вариант 1Переименовать папку плагинов (SSH) и вернуть обратно после проверки

    Linux · Терминал (Bash)КомандаКопировать всёВыделить

    Переименовать папку плагинов (SSH) и вернуть обратно после проверки

    cd /var/www/site/wp-content

    mv plugins plugins.off

    # проверьте вход; затем:

    mv plugins.off plugins

    Вариант 2Принудительно задать адреса (перед строкой «That's all, stop editing!»)

    PHPКомандаКопировать всёВыделить

    Принудительно задать адреса (перед строкой «That's all, stop editing!»)

    define('WP_HOME', 'https://example.ru');

    define('WP_SITEURL', 'https://example.ru');

    Вариант 3За обратным прокси или Cloudflare: передать признак HTTPS

    PHPКомандаКопировать всёВыделить

    За обратным прокси или Cloudflare: передать признак HTTPS

    if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {

    $_SERVER['HTTPS'] = 'on';

    }

    Вариант 4Стандартный .htaccess WordPress

    ТекстКомандаКопировать всёВыделить

    Стандартный .htaccess WordPress

    # BEGIN WordPress

    RewriteEngine On

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    RewriteBase /

    RewriteRule ^index\.php$ - [L]

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    # END WordPress

    Вариант 5Проверить время сервера и ответ страницы входа

    Linux · Терминал (Bash)КомандаКопировать всёВыделить

    Проверить время сервера и ответ страницы входа

    date

    curl -sI https://example.ru/wp-login.php | head -10

    Вариант 6WP-CLI: проверить адреса и сбросить пароль админа при необходимости

    Linux · Терминал (Bash)КомандаКопировать всёВыделить

    WP-CLI: проверить адреса и сбросить пароль админа при необходимости

    wp option get home

    wp option get siteurl

    wp user list --role=administrator

#Если вы всё равно не можете войти

Войдите в phpMyAdmin и проверьте таблицу wp_options: значения siteurl и home должны совпадать с адресом, по которому вы открываете сайт. Исправьте их и очистите кэш. Сброс пароля выполняется командой wp user update 1 --user_pass=НовыйПароль или в phpMyAdmin заменой хеша в таблице wp_users (функция MD5 для совместимости).