Сайт WordPress ушёл в цикл переадресации: как найти и убрать причину
Если браузер сообщает, что сайт слишком много раз перенаправлял запрос, или после входа в админку снова открывается страница авторизации, причина обычно не в одном «сломавшемся WordPress», а в конфликте двух правил переадресации. Например, сервер переводит HTTPS обратно на HTTP, а WordPress снова требует HTTPS. Чтобы исправить цикл, сначала нужно увидеть, между какими адресами ходит запрос, а затем отключить именно конфликтующее правило.
Сначала определите, где возникает цикл
Проверьте главную страницу, проблемную страницу и адрес админки отдельно. Откройте сайт в приватном окне или другом браузере: браузер мог сохранить постоянный редирект, и тогда старый результат мешает проверке. Если ошибка остаётся, посмотрите цепочку перенаправлений. При наличии доступа к терминалу можно выполнить команду, подставив адрес своего сайта:
curl -sSIL --max-redirs 10 https://example.com/В ответе обращайте внимание на строки HTTP/ и Location:: они показывают статус ответа и следующий адрес. Повторяющиеся переходы между HTTP и HTTPS, между вариантами с www и без него или между двумя URL с разными путями обычно указывают на конфликт правил. Если команда недоступна, воспользуйтесь инструментом проверки редиректов в браузере или попросите хостинг посмотреть цепочку запросов.
Сразу уточните, одинаково ли ведут себя адреса с http:// и https://, с www и без него, а также открывается ли страница входа. Это помогает сузить поиск: например, цикл только на HTTPS чаще связан с SSL или прокси, а редирект только на отдельных страницах может задаваться плагином или правилом для конкретного URL.
Проверьте SSL и передачу HTTPS на сервер
Убедитесь, что сертификат установлен и действует для нужного домена, включая вариант с www, если он используется. Проверить это можно в панели хостинга или открыв сайт по HTTPS и посмотрев сведения о сертификате в браузере. Если сертификат отсутствует или настроен не на тот домен, сначала исправьте SSL на стороне хостинга: переключение редиректов само по себе проблему сертификата не решит.
Отдельный сценарий — сайт работает за прокси или CDN, который принимает HTTPS от посетителя, а до сервера обращается по HTTP. WordPress может видеть внутренний HTTP-запрос и перенаправлять его на HTTPS, хотя посетитель уже пришёл по защищённому адресу. Прокси снова передаёт запрос серверу по HTTP — и цикл повторяется. В этом случае проверьте настройки SSL у прокси и способ, которым хостинг передаёт исходный протокол WordPress. Настройка зависит от провайдера и веб-сервера; не добавляйте наугад в wp-config.php универсальный код, объявляющий все запросы HTTPS. Неверная проверка заголовка прокси может создать уязвимость или нарушить работу сайта.
Если используется Cloudflare, проверьте режим SSL/TLS. Режим Flexible при HTTP-соединении между Cloudflare и сервером может конфликтовать с принудительным HTTPS на сервере. Для режима Full (strict) на исходном сервере должен быть действующий сертификат. Менять режим следует с учётом реального состояния SSL у хостинга, а не только ради исчезновения сообщения браузера.
Сверьте адреса WordPress
В админке откройте «Настройки → Общие» и сравните поля «Адрес WordPress (URL)» и «Адрес сайта (URL)». В них должны быть указаны корректные адреса с нужной схемой — обычно https:// — и одинаковым вариантом домена. Если WordPress установлен в отдельной папке, адрес WordPress и адрес сайта могут различаться по пути: не заменяйте их одной строкой, не проверив структуру установки.
Если админка недоступна, сначала проверьте, не заданы ли значения WP_HOME или WP_SITEURL в файле wp-config.php. Такие константы переопределяют адреса из настроек базы данных. Перед изменением файла скачайте его копию. Если констант нет, значения можно проверить через WP-CLI, запущенный в каталоге WordPress:
wp option get home
wp option get siteurlПри наличии доступа к WP-CLI исправляйте только подтверждённо неверный адрес. Например, если оба значения должны вести на HTTPS и домен без www:
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'Не копируйте пример буквально: используйте адрес и путь вашей установки. Если WP-CLI недоступен, значения можно проверить в таблице wp_options через phpMyAdmin, но префикс таблиц у сайта может отличаться от wp_. Перед изменением базы сделайте резервную копию. В сети WordPress Multisite адреса могут задаваться на уровне сети, поэтому обычная правка этих двух параметров не всегда является правильным решением.
Исключите конфликт плагина или кэша
Редиректы могут настраивать плагины безопасности, SEO, SSL, кэширования и отдельные плагины переадресаций. Если проблема началась сразу после установки или изменения конкретного плагина, начните с него: отключите правило принудительного HTTPS или редирект для проблемного URL, затем проверьте сайт. Если доступа в админку нет, через FTP/SFTP или файловый менеджер хостинга временно переименуйте папку подозреваемого плагина внутри wp-content/plugins. Это обратимая проверка: верните прежнее имя, если цикл не изменился.
Не отключайте все плагины первым действием на рабочем сайте: это может нарушить формы, оплату и другие функции. Если подозреваемый компонент неизвестен, безопаснее повторить проверку на копии сайта. В крайнем случае можно временно переименовать всю папку plugins, но это отключит сразу все обычные плагины и повлияет на работу сайта. После проверки верните папке исходное имя и включайте компоненты последовательно, проверяя редирект после каждого изменения.
После отключения плагина очистите кэш самого плагина, серверный кэш и кэш CDN, если они используются. Кэш браузера проверяйте отдельно. Очистка кэша полезна после изменения правила, но не исправит продолжающийся цикл, если конфликтующее правило всё ещё включено.
Проверьте правила веб-сервера и дополнительные редиректы
Если адреса WordPress корректны, а плагины не объясняют цепочку, проверьте правила веб-сервера. На Apache редиректы могут находиться в .htaccess в корне сайта или в конфигурации хостинга; на Nginx используются правила конфигурации сервера, и файл .htaccess на них не влияет. Посмотрите, нет ли одновременно нескольких правил, которые переключают HTTP/HTTPS или добавляют и убирают www.
Перед редактированием сохраните копию конфигурационного файла. Не заменяйте весь .htaccess стандартным шаблоном WordPress без проверки: в нём могут быть нужные правила хостинга, безопасности или других приложений. Если правка правила на Apache не помогла, восстановите копию. Конфигурацию Nginx обычно меняет поддержка хостинга или администратор сервера — на обычном тарифе владелец сайта может не иметь к ней доступа.
Проверьте также настройки панели хостинга: принудительный HTTPS и перенаправление на основной домен иногда включены одновременно с аналогичными правилами в WordPress или плагине. Для каждого типа адреса должен оставаться один согласованный переход к выбранной версии сайта, а не два правила, отправляющих запросы в противоположные стороны.
Проверьте результат и соберите данные, если цикл остался
После каждого изменения повторно проверьте ту же цепочку адресов, которая раньше зацикливалась. Затем откройте главную страницу, несколько внутренних страниц и /wp-admin/ в приватном окне. Убедитесь, что используется выбранный основной адрес, а вход в админку не возвращает пользователя на прежний URL. Если кэш очищен, а цепочка не изменилась, вернитесь к конфигурации сервера, прокси и адресам WordPress — вероятно, проверялось не то правило.
Если самостоятельно найти источник не удалось, передайте хостингу точный адрес, время проверки, цепочку переходов и информацию о том, меняется ли результат для HTTP/HTTPS и домена с www. Не отправляйте пароли, ключи доступа и содержимое конфигурационных файлов целиком. Поддержка сможет проверить серверные правила и заголовки прокси, которые не видны из админки WordPress.