Too many redirects WordPress после SSL — как исправить
Почему возникает бесконечный редирект после SSL
Самая частая причина — siteurl и home в таблице wp_options остались на http://, а хостинг или плагин уже редиректит на https://. Сервер гонит трафик на https://, а WordPress обратно на http://. Возникает замкнутый цикл, который браузер обрывает ошибкой ERR_TOO_MANY_REDIRECTS.
Вторая причина — .htaccess. Плагины кэширования (LiteSpeed Cache, WP Rocket) и безопасности (Wordfence, Sucuri) часто дописывают свои редиректы в .htaccess. Если там встречаются правила http → https и https → http одновременно — петля гарантирована.
Третья — плагин Really Simple SSL. Он перехватывает редиректы на уровне PHP. Если на сервере уже настроен редирект через Nginx или .htaccess, плагин создаёт второй уровень редиректа. Вместе они дают цикл.
Четвёртая — Cloudflare в режиме Flexible SSL. Cloudflare отдаёт клиенту HTTPS, а до сервера трафик идёт по HTTP. WordPress видит HTTP и пытается перебросить на HTTPS. Cloudflare снова принимает как HTTPS и передаёт по HTTP серверу. Сервер опять редиректит. Цикл. Подробнее этот случай разобран в статье Cloudflare ломает админку WordPress.
Шаг 1. Проверить siteurl и home через wp-admin
Если wp-admin открывается — зайти в Настройки → Общие. Поля «Адрес WordPress (URL)» и «Адрес сайта (URL)» должны начинаться с https:// и совпадать. Если одно поле на http, а второе на https — редирект возникает уже при входе в админку.
Если wp-admin тоже выдаёт ERR_TOO_MANY_REDIRECTS — исправлять через БД или wp-config.php.
Шаг 2. Исправить через БД
Подключиться к БД через phpMyAdmin, WP-CLI или консоль (на сервере).
Через WP-CLI:
wp option update siteurl 'https://your-site.ru'
wp option update home 'https://your-site.ru'Через SQL (если WP-CLI нет):
UPDATE wp_options SET option_value = 'https://your-site.ru'
WHERE option_name IN ('siteurl', 'home');На Beget phpMyAdmin доступен в разделе «Базы данных» панели управления. На Timeweb — в разделе «MySQL» → «phpMyAdmin». На Reg.ru — через ISPmanager, раздел «Базы данных» → «phpMyAdmin». Префикс таблиц может отличаться от wp_ — посмотреть его можно в wp-config.php (строка $table_prefix).
Шаг 3. Исправить через wp-config.php
Если доступ к БД временно недоступен, добавить константы в wp-config.php перед строкой /* That's all, stop editing! */:
define('WP_HOME', 'https://your-site.ru');
define('WP_SITEURL', 'https://your-site.ru');Этот способ работает на любом хостинге. На Reg.ru бывают проблемы с записью в wp-config.php из-за прав доступа — тогда просить поддержку хостинга поправить файл. На Beget и Timeweb таких ограничений нет.
Шаг 4. Очистить .htaccess от дублирующих редиректов
Открыть .htaccess через FTP или файловый менеджер хостинга. Удалить все редиректы на https://, оставив только стандартный блок 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Если нужен редирект с HTTP на HTTPS — добавить его строго после блока WordPress и с проверкой HTTP_X_FORWARDED_PROTO (для Cloudflare):
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Шаг 5. Сбросить кэши
После всех исправлений сбросить кэш:
- Браузера: очистить историю за последний час в режиме инкогнито.
- Плагинов кэширования: в админке WordPress → Настройки плагина → Purge Cache.
- Cloudflare: в панели Cloudflare → Caching → Purge Everything (если сайт за CDN).
- PHP-кэш: на VPS перезапустить PHP-FPM: sudo systemctl reload php8.1-fpm. На Beget и Timeweb — в панели хостинга, раздел «PHP» → «Сбросить OPcache».
Проверка результата
Открыть сайт в режиме инкогнито. Ошибка ERR_TOO_MANY_REDIRECTS должна исчезнуть. Проверить цепочку редиректов:
curl -sI -L https://your-site.ru | grep -i locationВ выводе должен быть только один финальный URL без многократных переходов туда-сюда. Если видно несколько location с чередованием http/https — в .htaccess или конфиге сервера остался конфликт.
Когда способ не сработает
Cloudflare Flexible SSL. Если хостинг не поддерживает HTTPS напрямую, а Cloudflare работает в Flexible-режиме. Серверу приходит HTTP-запрос, .htaccess редиректит на HTTPS, Cloudflare снова конвертирует в HTTP. Решение: переключить Cloudflare в Full (Strict) и установить сертификат Let's Encrypt на сервер.
Nginx без .htaccess. На VPS (Beget VPS, Timeweb VPS, Reg.ru VPS) редиректы пишутся в конфиге /etc/nginx/sites-enabled/site.conf. Там может быть двойной редирект или return 301 без проверки схемы. Проверить конфиг: grep -r 'return 301' /etc/nginx/. На shared-хостинге такое редко, но на VPS — типичная причина.
Плагин безопасности. iThemes Security, Sucuri Security, All In One WP Security принудительно форсируют HTTPS на уровне кода. Если плагин не даёт отключить редирект — временно деактивировать через БД (UPDATE wp_options SET option_value = '' WHERE option_name = 'active_plugins') и настроить SSL заново.
Закэшированный редирект в браузере. Если сайт открывался до включения SSL, браузер мог закэшировать 301 редирект. Помогает очистка истории браузера за всё время или открытие в режиме инкогнито.
Частые вопросы
Сайт упал после SSL — помогу за 15 минут
Сталкиваюсь с циклическими редиректами с 2014 года. Знаю все нюансы Beget, Timeweb и Reg.ru. Напишите — покажу, где проблема.
