Как исправить циклический редирект при входе в WordPress после настройки SSL и кеша

Циклический редирект при входе в WordPress обычно проявляется одинаково: вы вводите логин и пароль, после чего снова попадаете на страницу входа или видите бесконечную переадресацию между wp-login.php, /my-account/ и главной страницей. На практике это часто связано не с самим паролем, а с конфликтом между SSL, настройками URL сайта, кешем, прокси или cookie авторизации.

Ниже разберём рабочий порядок диагностики и исправления без лишних предположений. Если у вас WooCommerce, отдельное внимание стоит уделить странице My Account, потому что именно там чаще всего всплывают конфликты cookie и редиректов.

Как понять, где ломается вход

Сначала важно не лечить «вслепую». Один и тот же симптом может иметь разные причины: неверный siteurl, смешанный HTTP/HTTPS, кеширующий плагин, редирект на уровне Nginx/Apache или конфликт с плагином безопасности.

Что проверить в первую очередь

• Открывается ли сайт только по https:// или часть страниц всё ещё уходит на http://.
• Совпадают ли адреса в Настройки → Общие: Адрес WordPress (URL) и Адрес сайта (URL).
• Есть ли редирект на уровне хостинга, CDN или reverse proxy.
• Не кешируется ли страница входа или страница аккаунта WooCommerce.
• Не меняет ли логин-страницу плагин безопасности или плагин скрытия wp-login.php.

Быстрая диагностика через браузер и заголовки

Откройте DevTools → Network и посмотрите цепочку ответов после отправки формы входа. Если видите повторяющиеся 302 или 301 между двумя адресами, проблема почти всегда в редиректе или cookie, а не в авторизации как таковой.

Полезно проверить заголовки и конечный URL через curl:

curl -I https://example.com/wp-login.php
curl -I -L https://example.com/wp-login.php

Если в цепочке есть переходы между http и https, сначала исправляйте схему URL. Если редирект идёт на страницу входа после успешной отправки формы, ищите конфликт cookie или кеша.

Пошаговое решение: от URL до кеша

1. Приведите URL сайта к одному варианту

В Настройки → Общие оба адреса должны быть одинаковыми по схеме и домену. Для сайта с SSL это обычно означает, что и WordPress URL, и адрес сайта начинаются с https://.

Если в админку попасть нельзя, проверьте значения через wp-config.php или WP-CLI. Это безопаснее, чем править базу вручную, если вы не уверены в текущем состоянии сайта.

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

После изменения очистите кеш браузера и попробуйте вход в приватном окне. Старые cookie могут маскировать результат.

2. Убедитесь, что WordPress видит HTTPS

Если сайт стоит за Cloudflare, nginx reverse proxy или балансировщиком, WordPress может считать соединение обычным HTTP, даже если пользователь открывает HTTPS. Тогда cookie авторизации выставляются не так, как ожидается, и вход зацикливается.

В таком случае в wp-config.php часто добавляют проверку заголовка X-Forwarded-Proto:

if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Этот фрагмент нужен только если у вас действительно есть прокси, который передаёт протокол через заголовок. На обычном shared-хостинге он не обязателен.

3. Отключите кеширование для страниц входа и аккаунта

Страницы wp-login.php, wp-admin и, если используется WooCommerce, /my-account/ не должны попадать в публичный кеш. Иначе сервер может отдавать уже закешированную форму или ответ с устаревшими cookie.

Для проверки временно отключите кеширующий плагин и повторите вход. Если проблема исчезла, настройте исключения. Для большинства плагинов логика одна: исключить URL входа, админку и страницу аккаунта из кеша, а также не кешировать ответы с установленными auth-cookie.

4. Сбросьте cookie и проверьте домен cookie

Если сайт недавно переезжал с www на без www или наоборот, cookie могли быть выданы для другого домена. В результате браузер отправляет не те данные, и WordPress не завершает авторизацию.

Проверьте, не задан ли вручную COOKIE_DOMAIN в wp-config.php. Если вы не уверены, лучше не задавать его без необходимости. Неверное значение часто ломает вход сильнее, чем помогает.

Когда проблема в WooCommerce

Если редирект возникает не на /wp-admin/, а при входе через /my-account/, смотрите на связку WooCommerce + кеш + редиректы после логина. У WooCommerce есть собственная логика работы с сессией и страницей аккаунта, и она конфликтует с агрессивным кешированием.

Что проверить в WooCommerce

• Назначена ли страница My Account в настройках WooCommerce.
• Не кешируется ли эта страница через CDN или плагин оптимизации.
• Не включён ли редирект после входа на страницу, которая сама требует авторизацию и снова отправляет на логин.
• Нет ли плагина, который меняет поведение woocommerce_login_redirect или login_redirect.

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

add_filter('login_redirect', function ($redirect_to, $requested, $user) {
    if (is_wp_error($user) || empty($user->roles)) {
        return $redirect_to;
    }

    if (in_array('administrator', $user->roles, true)) {
        return admin_url();
    }

    return function_exists('wc_get_page_permalink') ? wc_get_page_permalink('myaccount') : home_url('/my-account/');
}, 10, 3);

Этот код не лечит сам loop, но помогает убрать лишние редиректы, если проблема была в конфликте нескольких правил перехода после входа.

Проверка результата после внедрения

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

Минимальный чек-лист проверки

• Откройте сайт в приватном окне.
• Войдите через wp-login.php и, если есть WooCommerce, через /my-account/.
• Проверьте, что после входа нет повторного возврата на форму логина.
• Перейдите в /wp-admin/ и убедитесь, что сессия сохраняется.
• Очистите кеш плагина, CDN и браузера, затем повторите тест.
• Проверьте вход с другого устройства или сети, чтобы исключить локальный кеш.

Если используете curl, смотрите на отсутствие бесконечной цепочки 301/302 и на корректный конечный URL после авторизации. Для WooCommerce полезно проверить, что страница my-account отдаёт не закешированную версию для гостя после логина.

Частые ошибки и как их исправить

Смешали HTTP и HTTPS

Одна из самых частых причин. Сайт открывается по HTTPS, но в базе или конфиге остался HTTP. Исправление: привести WP_HOME и WP_SITEURL к одному HTTPS-адресу, затем обновить ссылки в базе, если это был старый переезд.

Кешируют страницу входа

Если кеш отдаёт старую форму или старые cookie, вход может зацикливаться даже при правильном пароле. Исправление: исключить wp-login.php, wp-admin и /my-account/ из кеша, а затем сбросить весь кеш.

Неверный домен cookie после переезда

После смены www / без www браузер может хранить cookie для старого домена. Исправление: очистить cookie, проверить редирект на канонический домен и не задавать лишний раз COOKIE_DOMAIN.

Плагин безопасности меняет логику входа

Некоторые плагины защиты добавляют свои редиректы, ограничения по сессии или скрывают страницу входа. Если после их обновления начался loop, временно отключите плагин и проверьте вход. Если проблема исчезла, ищите конфликт в его настройках, а не в WordPress core.

Редирект задан в нескольких местах

Когда редирект после входа прописан в теме, в плагине и на уровне сервера, итоговая цепочка становится непредсказуемой. Исправление: оставить одно правило, остальные убрать или отключить на время диагностики.

Практические советы по безопасности и производительности

Когда вход уже стабилен, не возвращайтесь к агрессивным редиректам и кешу для логин-страниц. Это не ускоряет сайт, а только усложняет поддержку.

• Не кешируйте авторизованные страницы и страницы с персональными данными.
• Не храните в wp-config.php лишние жёсткие редиректы, если сайт работает за прокси или CDN.
• После правок в wp-config.php проверяйте вход в инкогнито и с мобильной сети.
• Если используете плагины безопасности, оставляйте только одну логику ограничения входа, а не несколько одновременно.

Если вам нужен более системный контроль над безопасностью входа, имеет смысл использовать один инструмент для очистки дублей, кеша и технических конфликтов, а не набор разрозненных плагинов. Но даже в этом случае сначала стоит устранить базовую причину редиректа, а потом уже усиливать защиту.