ERR_TOO_MANY_REDIRECTS: сайт отправляет по кругу

ERR_TOO_MANY_REDIRECTS значит, что сайт отправляет браузер по кругу: адрес отвечает переадресацией на другой адрес, тот — обратно или дальше по цепочке, и до страницы дело не доходит. Мы собрали стенд, на котором воспроизвели пять частых причин петли, замерили, после скольких переходов сдаются Chrome, Firefox и curl, и проверили, почему ошибка остаётся у посетителя даже после исправления сервера. А ещё обошли

2056 сайтов из нашего списка организаций и нашли среди них петлю.

Что означает ошибка: перевод и код

Дословно — «слишком много переадресаций». В исходниках Chromium у ошибки номер −310 и пояснение:

Attempting to load an URL resulted in too many redirects.

Текст на русском в Chromium 149, который мы сняли на стенде:

Страница недоступна. Сайт 127.0.0.1 выполнил переадресацию слишком много раз. Попробуйте удалить файлы cookie. ERR_TOO_MANY_REDIRECTS

В Firefox та же ситуация называется NS_ERROR_REDIRECT_LOOP — этот код вернул нам Firefox 151 на стенде.

Переадресация (редирект, перенаправление) — это ответ сервера с кодом 301, 302, 307 или 308 и заголовком Location, где указан новый адрес. Браузер выполняет переход сам, человек его не видит. Подробно о кодах и о том, какой выбирать, — в статье 301 или 302.

Проблема на стороне сайта или на вашей

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

Ещё один быстрый признак — сообщение о конкретном адресе. Chrome пишет имя домена, который выполнил переадресацию слишком много раз. Если это не тот сайт, который вы открывали, а, например, страница авторизации другого сервиса, петля возникает между двумя сайтами.

Сколько переадресаций выдерживает браузер

Мы подняли сервер, который отдаёт цепочку из заданного числа переадресаций, и открыли её в каждом клиенте по три раза.

В исходнике Chromium предел записан числом 20 со ссылкой на стандарт Fetch. На деле браузер делает не больше 20 запросов подряд: исходный и 19 переходов. Ошибка появляется за сотые доли секунды — на стенде 0,02–0,09 с, потому что каждый ответ пустой.

Отсюда практический вывод: петлю браузер не отличает от очень длинной цепочки. Для него важна только длина. Но на живых сайтах длинных цепочек почти нет — об этом ниже, в нашем обходе.

Пять причин петли: что мы воспроизвели на стенде

Каждый случай мы открыли в Chromium 149 три раза, петлю из двух страниц — по разу с каждым кодом. Все пять дают одну и ту же ошибку, поэтому по коду причину не узнать — только по цепочке адресов.

1. Конфликт правил на сервере

Самый простой случай — два правила, которые спорят друг с другом. Одно отправляет с www на адрес без www, другое — обратно. Или .htaccess переводит на https, а nginx перед ним — снова на http. Каждое правило по отдельности выглядит правильно, вместе они создают круг.

2. HTTPS за прокси или CDN

Причина, которую чаще всего разбирают в выдаче. Посетитель подключается к прокси по https, а прокси идёт к основному серверу по обычному http. Сервер видит http и, как ему велено, отправляет на https. Браузер снова приходит к прокси по https, прокси — снова к серверу по http. На стенде это ошибка 3 из 3. Стоило прокси добавить заголовок X-Forwarded-Proto: https, а серверу — проверять его, страница открылась с первого запроса.

У Cloudflare так работает режим SSL Flexible: до посетителя соединение шифруется, до сервера — нет. Если на сервере включён переход на https, возникает петля. Лечится режимом Full или Full (strict) с сертификатом на сервере.

3. Cookie, которую браузер не сохраняет

Личный кабинет без cookie отправляет на страницу входа, вход ставит cookie и возвращает в кабинет. Если браузер cookie не сохранил, круг замыкается. На стенде мы ставили cookie с флагом Secure на сайте по http — браузер такую cookie отклоняет, и вышла ошибка 3 из 3. Без флага — открылось.

Отсюда же совет «удалите cookie» на странице ошибки: испорченная cookie сессии иногда держит посетителя в такой петле, хотя у остальных сайт работает.

4. Настройки CMS

В WordPress адрес сайта записан в двух полях: «Адрес WordPress (URL)» и «Адрес сайта (URL)». Если там http, а сервер переводит на https, или наоборот, CMS и сервер отправляют посетителя друг к другу. Похожее делают плагины переадресаций, кэширования и SSL, если включить их поверх серверного правила.

5. Приложение не доверяет прокси

Фреймворки вроде Django, Laravel или Express сами переводят на https и сами решают, пришёл ли запрос по https. Если приложению не сказать, что перед ним прокси, оно смотрит на соединение от прокси, видит http и отправляет на https. Это та же петля, что во втором случае, только правило живёт не в nginx, а в коде.

Почему ошибка остаётся после исправления

Это самый неприятный случай: сервер уже починили, а у части посетителей ошибка не уходит. Мы проверили, как ведёт себя браузер. Сначала две страницы отправляли друг на друга, затем сервер исправили, и ту же страницу открыли снова — в том же профиле и в новом. По одному прогону на каждый код.

Постоянные переадресации 301 и 308 браузер запоминает и в следующий раз даже не спрашивает сервер — сразу идёт по сохранённому кругу. Временные 302 и 307 он не хранит. Поэтому петля на 301 после исправления продолжает жить у тех, кто успел на неё попасть, пока они не очистят кэш.

Вывод для владельца сайта: пока правило переадресации не проверено, его стоит включать кодом 302 и переводить на 301, только когда всё работает.

Наш замер: 2056 сайтов, петля у одного

Мы взяли все домены из нашего списка организаций — 2056 — и 17 октября 2026 года запросили у каждого главную страницу по http и по https. Шли за переадресациями так же, как браузер: с сохранением cookie и с пределом 20 переходов.

Хотя бы по одному протоколу ответили 1692 сайта.

Длинных цепочек нет вовсе: больше трёх переходов не было ни у кого. Значит, если браузер пишет ERR_TOO_MANY_REDIRECTS, это почти наверняка петля, а не «много редиректов».

Петля нашлась у одного сайта — cakeandpie.ru, кафе. Он стоит за Cloudflare, и главная по https отвечает переадресацией на свой же адрес https://cakeandpie.ru/. Мы повторили запрос по три раза из Германии и через прокси на российском сервере: петля каждый раз. Chromium 149 показал ERR_TOO_MANY_REDIRECTS три раза из трёх. Любопытная деталь: на запрос GET сайт отвечает кодом 301, на HEAD — 308. Ответ помечен cf-cache-status: DYNAMIC, то есть его отдаёт сам сервер, а не кэш Cloudflare. Это совпадает с картиной режима Flexible из второй причины, но настроек сайта мы не видим и утверждать этого не можем.

Как исправить ошибку пользователю

Если сайт чужой, исправить петлю на нём нельзя, но можно проверить, не держит ли её ваш браузер.

1. Откройте сайт в окне инкогнито. Там нет ваших cookie и сохранённых переадресаций. Открылось — причина в браузере, дальше шаги 2–3. Ошибка осталась — сломан сайт, ждать или написать владельцу.
2. Удалите cookie этого сайта. В Chrome: значок слева от адреса → «Файлы cookie и данные сайтов» → удалить. Удалять все cookie браузера не нужно.
3. Очистите кэш. Именно в кэше живёт запомненная переадресация 301. В Chrome: «Настройки» → «Конфиденциальность и безопасность» → «Удалить данные о работе в браузере» → «Изображения и другие файлы, сохранённые в кэше».
4. Отключите расширения, которые меняют адреса: принудительный https, блокировщики, VPN-расширения. Они тоже умеют замыкать круг.
5. Проверьте дату и время на компьютере. Неверное время ломает сертификаты и срок cookie — сессия сразу считается истёкшей.

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

Как найти петлю на своём сайте

Диагностику полезнее начинать не с правки настроек, а с того, чтобы увидеть полную последовательность переходов. Тогда понятно, какие два правила образуют круг.

Командой curl

curl -sIL --max-redirs 10 https://ваш-сайт.ru/

Вот реальный пример — та самая петля из нашего обхода:

HTTP/2 308
location: https://cakeandpie.ru/
HTTP/2 308
location: https://cakeandpie.ru/
HTTP/2 308
location: https://cakeandpie.ru/
curl: (47) Maximum (3) redirects followed

Команда печатает каждый ответ по очереди. Смотрите на строки HTTP/ и location:: если адрес в location повторяется, это и есть круг. Ключ --max-redirs 10 не даёт curl ходить по кругу до своего предела в 50.

Если петля появляется только у вошедших пользователей, добавьте сохранение cookie: -c cookies.txt -b cookies.txt.

В браузере

Откройте инструменты разработчика (F12), вкладку Network, поставьте галочку Preserve log и откройте адрес. В списке будут все запросы с кодами 301, 302 и колонкой с новым адресом. Цепочка обычно читается за секунду.

Без консоли цепочку пройдёт и наша проверка переадресации. Она открывает четыре адреса сайта — с www и без, по http и https — и от каждого идёт по переадресациям до конца, до 20 шагов. Если адрес встречается в цепочке второй раз, проверка пишет, что переадресация ходит по кругу и браузер покажет ERR_TOO_MANY_REDIRECTS, и называет адрес, с которого начинается петля. На cakeandpie.ru из нашего обхода она нашла петлю на всех четырёх адресах. Ответ сервера по каждому шагу она не печатает, поэтому заголовки, на которых петля замыкается, смотрят уже curl.

Как исправить на сервере

1. Найдите все места, где живут переадресации: конфигурация nginx или Apache, .htaccess, панель управления хостингом, настройки CDN и балансировщика, CMS и её плагины, код приложения. Петлю почти всегда создают два источника одновременно: например, хостинг включает https в своей панели, а плагин CMS делает то же самое.
2. Оставьте одно правило на каждое действие. Переход на https и выбор канонического домена — с www или без — удобнее делать в одном месте, лучше на самом внешнем сервере. Любой другой уровень должен просто отдавать страницу.
3. Если сервер стоит за прокси или CDN, передавайте ему схему заголовком X-Forwarded-Proto и проверяйте её вместо схемы соединения. В nginx-прокси это строка proxy_set_header X-Forwarded-Proto $scheme;.
4. В Cloudflare включите режим SSL Full или Full (strict) вместо Flexible и поставьте сертификат на сервер.
5. В WordPress сверьте поля «Адрес WordPress» и «Адрес сайта» с тем, куда переводит сервер. Если войти в админку нельзя, их задают константами WP_HOME и WP_SITEURL в wp-config.php.
6. Проверяйте правило кодом 302 и переводите на 301, только когда цепочка чистая. Так ошибка не застрянет в кэше у посетителей.
7. После исправления проверьте снаружи командой curl и в окне инкогнито, а не в своём основном браузере: в нём могут остаться старые переадресации из кэша.
8. Если доступа к настройкам нет, обращайтесь в техническую поддержку хостинга и приложите вывод curl — по нему видно, на каком адресе замыкается цикл.
9. Поставьте сайт на мониторинг. Петля часто появляется после обновлений CMS, плагинов или смены сертификата, и узнать о ней лучше от проверки, а не от клиента.

Как петля влияет на SEO

Робот поисковой системы тоже ходит по переадресациям и тоже не бесконечно. Google пишет в своей документации, что его роботы по умолчанию проходят до 10 переходов, а в Search Console при неудаче появляется ошибка переадресации. Яндекс в справке объясняет, что при переадресации индексирует страницу назначения, если она доступна. В петле доступной страницы нет — индексировать нечего.

Если петля только на одной странице, из поиска выпадет она. Если на всём https или на главной, под ударом весь сайт. А запомненная 301 мешает и после исправления: роботы, в отличие от браузеров, перепроверят адрес сами, но не сразу. Ускорить можно, отправив исправленные адреса на переобход в Вебмастере и Search Console.

Смежные ошибки

Границы замера

• Стенд — Chromium 149 и Firefox 151 на Linux, сервер на том же компьютере, по три прогона. Safari и WebKit мы не проверяли.

• Обход шёл из Германии; петлю у найденного сайта мы перепроверили и через прокси на российском сервере.

• Ещё два сайта при обходе без cookie один раз зациклились, но при повторе ответили 403 и 503 — сработала защита от частых запросов. В счёт мы их не взяли.

Коротко

• ERR_TOO_MANY_REDIRECTS — сайт переадресует по кругу; код −310.
• Chromium 149 сдаётся на 20-м запросе цепочки, Firefox 151 — на 21-м, curl — после 50 переходов.
• На живых сайтах длиннее трёх переходов цепочек мы не нашли, так что ошибка — это петля.
• Частые причины: два спорящих правила, https за прокси без X-Forwarded-Proto, режим Flexible в Cloudflare, cookie, которую браузер не сохраняет, настройки CMS.
• Запомненная 301 держит ошибку после исправления: на стенде петля на 301 и 308 осталась в том же профиле, на 302 и 307 — нет.
• Пользователю — инкогнито, удалить cookie сайта и кэш. Владельцу — curl -sIL, одно правило на действие и проверка правила кодом 302.