Простой пример
https://www.example.ru → https://example.ru → https://www.example.ru
Конечного URL с кодом 200 нет, поэтому браузер прекращает переход и показывает ошибку слишком большого числа редиректов.
Частые причины
- две системы одновременно управляют www;
- HTTPS включен и на платформе, и на внешнем прокси с противоположными правилами;
- старый 301 ведет на URL, который редиректит обратно;
- Cloudflare или другой прокси настроен поверх серверных правил;
- страница T223 используется вместе с серверным редиректом.
Как диагностировать
Не проверяйте только браузером. Используйте инструмент, который показывает каждый HTTP-ответ по порядку. Найдите два адреса, между которыми начинается повторение.
Как исправить
Выберите один конечный URL с кодом 200. Затем перепишите правила так, чтобы все альтернативные версии вели только к нему. Уберите дублирующее управление редиректами в разных системах.
Что учитывать на Tilda
В Tilda есть отдельные настройки WWW/HTTPS и 301 внутри сайта. Блок T223 является JavaScript-переадресацией и не заменяет серверный 301. Перед сложной миграцией составьте карту правил.
Проверка после исправления
- главная по HTTP;
- главная по HTTPS;
- www и без www;
- несколько внутренних страниц;
- старые URL после миграции.
Проверка после изменений
- снять всю последовательность 3xx без автоматического скрытия;
- проверить правила www и HTTPS;
- проверить 301 внутри системы управления сайтом;
- временно отключить внешний прокси или CDN, если он управляет редиректами;
- найти первый повторяющийся URL;
После исправления выберите четыре теста: HTTP, HTTPS, www и без www плюс один старый внутренний URL. Все они должны завершаться на единственной конечной странице с кодом 200.
Что проверить в первую очередь
Очистка cookie и кеша иногда помогает при клиентских проблемах, но серверный цикл она не исправляет. Если один и тот же набор URL повторяется в HTTP-ответах, нужно менять правила.
Как появляется цикл, если каждое правило выглядит логичным
Типичный сценарий: сервер перенаправляет без www на www, а платформа делает обратное. Или правило страницы отправляет /old на /new, а глобальная настройка возвращает /new на старую версию хоста. По отдельности каждое правило кажется понятным, вместе они создают бесконечный круг.
Диагностика начинается с отключения предположений. Смотрите фактическую цепочку HTTP-ответов и фиксируйте каждый Location. По последнему успешному шагу обычно видно, какой слой вернул адрес назад.
Как исправлять безопасно
Определите единственную конечную версию URL и уберите конфликтующие правила. После исправления проверьте несколько типов страниц, а не только адрес, на котором обнаружили ошибку. Если цикл возник из-за протокола или зеркала, дополнительно проверьте HTTP/HTTPS и www/без www. Для общей карты используйте разбор цепочек редиректов.
Проверьте все слои, которые могут управлять редиректами
Цикл часто создается сочетанием платформы, прокси, CDN и старых ручных настроек. Диагностика должна перечислить каждый слой и его условие. После этого выбирается единый конечный URL и устраняется правило, которое возвращает запрос назад.
Проверка ответа сервера полезнее очистки браузерного кэша. Для Яндекса можно использовать инструмент проверки ответа сервера, а для локальной диагностики - curl или краулер с отображением всей цепочки.
Меняйте правила по одному и сохраняйте возможность отката
При сложной схеме сначала зафиксируйте текущие правила, затем отключайте или меняйте один слой за раз. После каждой правки повторяйте проверку четырех вариантов домена и проблемного внутреннего URL. Такой подход снижает риск заменить один цикл другим.
Как убедиться, что цикл устранен
Redirect loop лечится не очисткой кеша, если причина на сервере. Найдите повторяющуюся последовательность и оставьте одну понятную схему: альтернативные адреса → конечный URL 200.
