Если Chrome показывает сообщение «Страница недоступна, на сайте обнаружено циклическое перенаправление» и код ERR_TOO_MANY_REDIRECTS, значит, правила перенаправления сайта противоречат друг другу. Например, одно правило отправляет браузер с HTTP на HTTPS, а другое возвращает его обратно на HTTP, и этот круг не заканчивается. Сделав несколько десятков попыток, браузер останавливается и показывает ошибку. Firefox называет ту же ситуацию «некорректным перенаправлением на странице». Хорошая новость в том, что причина почти всегда в настройках и её можно увидеть своими глазами.
Посмотрите на цепочку перенаправлений
Прежде чем гадать, выясните, куда именно перенаправляет сервер. Удобнее всего сделать это командой curl: она выводит заголовки каждого ответа и следующий адрес. Запустите на своём компьютере или на сервере:
curl -sIL --max-redirs 10 http://example.uz | grep -iE "^HTTP|^location"Вы увидите ответы 301 или 302 и заголовки Location. Если в списке по очереди повторяются два одинаковых адреса, например https://example.uz/ и http://example.uz/, значит, круг образуют именно эти два правила. Если чередуются www.example.uz и example.uz, проблема в правилах для www. Часто одна эта команда сразу показывает причину.
Перенаправление на HTTPS и конфликт с прокси
Самый частый случай возникает, когда сайт работает через прокси-сервис вроде Cloudflare. Если там выбран режим SSL «Flexible», посетитель подключается к прокси по HTTPS, а прокси обращается к серверу по обычному HTTP. Сервер видит HTTP-запрос и отвечает «перейдите на HTTPS». Прокси передаёт этот ответ браузеру, браузер снова приходит по HTTPS — и круг замыкается. Решение — переключить режим в прокси на «Full» или «Full (strict)», для чего на сервере должен быть настоящий SSL-сертификат. Если на хостинге установлен бесплатный сертификат Let's Encrypt, правильный выбор — «Full (strict)».
Если отключить прокси нельзя, серверное правило может определять, что запрос на самом деле пришёл по HTTPS, по заголовку X-Forwarded-Proto. Но такой подход безопасен только за доверенным прокси.
Дублирующиеся и противоречивые правила в .htaccess
Бывает, что владелец сайта добавляет правило HTTPS в .htaccess, затем ставит плагин, который делает то же самое, а потом ещё включает перенаправление в панели. Если правила не согласованы — например, одно ведёт на www, а другое на адрес без www, — возникает бесконечный круг. Надёжнее всего задать HTTPS и основной домен в одном месте одним правилом. Пример ниже перенаправляет все запросы на https://example.uz, то есть на HTTPS-адрес без www:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.uz%{REQUEST_URI} [L,R=301]В настройках сайта в панели ISPmanager тоже может быть флажок перенаправления с HTTP на HTTPS. Если он включён, строку HTTPS в .htaccess можно убрать и оставить только правило для www: выполнять одну и ту же задачу в двух местах — прямой путь к ошибке.
Поставьте это правило в начало файла, перед всеми остальными, и удалите другие строки с той же задачей. Если сайт должен работать с www, инвертируйте условие, но не оставляйте оба варианта одновременно.
Настройки адресов в WordPress
В базе данных WordPress хранятся два важных значения: siteurl и home. Если там указано http://www.example.uz, а сервер перенаправляет всё на https://example.uz, WordPress в ответ возвращает браузер на «свой» адрес. Получается тот же бесконечный круг. Если в админку не попасть, значения можно принудительно задать в wp-config.php:
define('WP_HOME', 'https://example.uz');
define('WP_SITEURL', 'https://example.uz');При наличии SSH и WP-CLI значения в базе можно проверить и изменить напрямую:
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.uz'
wp option update home 'https://example.uz'Проверьте также плагины, которые принудительно включают HTTPS или управляют перенаправлениями. Временное переименование папки плагина помогает быстро понять, участвует ли он в проблеме.
Пример из практики
После переезда сайта частной школы в Ташкенте на новый домен главная страница перестала открываться. Команда curl показала, что сервер отправляет http-запрос на https, затем WordPress перенаправляет его на старый домен, а старый домен — снова на новый. Причиной оказалось оставшееся в базе старое значение home. Как только его заменили на новый HTTPS-адрес и очистили кэш, сайт сразу открылся. Этот пример показывает, что большая часть проблем с редиректами после переезда связана со старыми адресами в базе.
Очистите кэш и cookie
Браузер надолго запоминает 301-перенаправления. Поэтому даже после исправления настроек на сервере ошибка может сохраняться у вас, хотя у других сайт уже работает. Проверяйте в режиме инкогнито или через curl, при необходимости удалите кэш браузера и cookie сайта. Плагины кэширования страниц тоже могут хранить старое перенаправление — не забудьте их очистить.
Если все настройки выглядят правильно, а круг не исчезает, обратитесь в поддержку через кабинет sayt.uz и приложите вывод curl: видимая цепочка заметно ускоряет решение.