Артём Савельев 
ERR_TOO_MANY_REDIRECTS: сайт выполнил переадресацию слишком много раз — как исправить
Браузер честно ходил по редиректам — со страницы А на Б, с Б обратно на А — и после пары десятков кругов сдался. Петля переадресации почти всегда рукотворна: два правила, каждое из которых по отдельности правильное, вместе образуют замкнутый круг. Разбираем, откуда берутся петли, как их найти одной командой и почему рекордсмен по этой ошибке — связка «сайт + CDN».
Как рождается петля
Редирект — нормальный инструмент: перенаправить с http на https, с www на без-www, со старого адреса на новый. Мы разбирали их в статье про редиректы. Петля возникает, когда два перенаправления смотрят друг на друга: правило веб-сервера шлёт на https, а прокси перед ним возвращает на http; CMS редиректит на www, а сервер — обратно на апекс. Каждый слой уверен, что делает правильно, — а посетитель бегает по кругу. Браузер прерывает забег после нескольких десятков прыжков (у Chrome лимит около 20) и показывает эту ошибку.
Если вы посетитель
Один раз эта ошибка действительно лечится куками: сайт мог записать вам битую куку (например, региональную или языковую), из-за которой его логика перенаправлений зациклилась именно у вас. Удалите куки этого сайта и попробуйте снова; заодно проверьте в инкогнито. Если не помогло и с других устройств тоже петля — сломан сам сайт, посетителю остаётся только подождать. VPN стоит выключить по обычной причине: гео-зависимые редиректы (на региональные версии сайта) с «плавающей» страной легко зацикливаются.
Если вы владелец: находим круг одной командой
curl -sIL -o /dev/null -w '%{url_effective} -> %{http_code}\n' --max-redirs 10 https://example.ru
# Подробно, каждый прыжок:
curl -sIL https://example.ru | grep -iE '^(HTTP|location)'
Вторая команда печатает всю цепочку: какой код и куда отправляет каждый шаг. Петля видна мгновенно — Location начинает повторяться. Дальше сверяйтесь с картой типовых виновников:
| Петля | Кто крутит | Лечение |
|---|---|---|
| http ↔ https | CDN в режиме Flexible SSL + редирект на https на origin: до origin запрос доходит как http — и его снова шлют на https | Режим Full (strict) у CDN — разбирали в статье про Cloudflare |
| www ↔ без www | Сервер редиректит на апекс, CMS (или .htaccess от старого подрядчика) — на www | Оставить ОДНО правило каноникализации, на одном слое |
| Страница ↔ страница логина | Защищённый раздел шлёт на логин, логин считает вас авторизованным и шлёт обратно (битые куки/сессии) | Чинить сессии; проверить настройки кук (домен, Secure) после переезда на https |
| Гео/языковые версии по кругу | Правила «русским — на /ru, из /ru неопределившихся — на главную» | Редирект по гео — только один раз, с запоминанием выбора |
| Слэш ↔ без слэша | Правило сервера добавляет слэш, правило приложения убирает | Единая политика trailing slash на одном слое |
Общий корень у всех строк таблицы один: редиректами занимаются несколько слоёв одновременно — CDN, веб-сервер, .htaccess, CMS, плагины. Каждый слой добавляли в разное время разные люди. Поэтому и лечение системное: договоритесь, что канонизацией (https, www, слэши) занимается ровно один слой, а остальные — не трогают. После любого изменения — прогон curl-цепочки по главной, разделу и карточке.
Мини-чек-лист после переезда на https
Большинство петель рождается в момент переезда на https или подключения CDN, поэтому проверка после таких работ должна быть ритуалом. Пять пунктов: единый редирект в один прыжок (http://www.домен → сразу https://домен, без промежуточных остановок); curl-цепочка чистая на главной, разделе и карточке товара; куки помечены Secure и не ломают сессии; в вёрстке не остался смешанный контент; и sitemap с внутренними ссылками указывают сразу на финальные https-адреса, а не гоняют роботов через редиректы. Десять минут проверки против недель загадочных симптомов.
Поисковый робот в петле ведёт себя как браузер: делает несколько прыжков и бросает. Страницы в петле перестают обходиться и выпадают из индекса, а краулинговый бюджет сгорает на бессмысленных кругах. Если петля возникла после переезда на https или смены CDN — счёт идёт на дни.
Пруфен в HTTP-проверках следует по редиректам, как браузер, и петля фиксируется как инцидент с первого цикла — из 13 точек, включая гео-зависимые сценарии, которые из одного города не видны. Проверка SSL рядом ловит спутника большинства петель — проблемы после переезда на https.
Частые вопросы
Почему у меня петля есть, а у коллеги сайт открывается? Потому что петля зависит от состояния: кук, региона, того, залогинен ли человек. Ваша битая кука крутит вас по кругу, у коллеги её нет. Именно поэтому диагностировать нужно «чистым» запросом curl, а не браузером.
Ошибка появилась сразу после подключения Cloudflare. Совпадение? Нет, это классика: режим Flexible SSL плюс редирект на https на вашем сервере даёт мгновенную петлю http↔https. Переключите SSL-режим на Full (strict) — подробности в статье про Cloudflare.
Сколько редиректов допустимо в норме? Чем меньше, тем лучше: каждый прыжок — лишние миллисекунды и лишний риск. Норма для канонизации — один редирект (http://www → https://без-www одним шагом, а не двумя). Цепочки из 3+ прыжков — повод переписать правила.
Как застраховаться от петель на будущее? Одно правило канонизации на одном слое, curl-проверка цепочки после каждого изменения редиректов и внешний мониторинг, который ходит по редиректам как браузер и поднимет тревогу, если где-то закрутилось.