SiteGuard4 ноября 202613 мин чтения

ERR_TOO_MANY_REDIRECTS: как исправить слишком много перенаправлений

ERR_TOO_MANY_REDIRECTS означает, что браузер прекратил загрузку после слишком большого количества перенаправлений. Вместо нужной страницы он получает новые адреса, переходит по ним и снова встречает переадресацию. Частая причина — конфликт правил сайта, например между HTTP и HTTPS или версиями с www и без него. Иногда ошибка связана с авторизацией и сохранённой сессией.

Чтобы исправить проблему, сначала запишите цепочку переходов, затем найдите правило, которое отправляет посетителя обратно или продолжает цепочку без необходимости. Очистка cookies помогает только в определённых сценариях. Владельцу сайта важно восстановить доступ к конкретным страницам и проверить результат из условий, в которых появилась ошибка.

Что означает «слишком много переадресаций»

Обычное перенаправление помогает попасть с прежнего адреса на актуальный. Например, посетитель открывает старую страницу каталога, сервер сообщает новый URL, а браузер загружает содержимое по нему. Проблема начинается, когда эта последовательность не приводит к ожидаемому результату.

Простейший циклический редирект выглядит так: адрес A отправляет на B, а B возвращает на A. Бывает и перенаправление страницы на саму себя. Однако одинаковые адреса необязательно повторяются: ошибочное правило может постоянно добавлять новый параметр, префикс или часть пути. Даже конечная, но чрезмерно длинная цепочка способна упереться в ограничение клиента. В стандарте Fetch предусмотрен счётчик переходов; увеличение допустимого числа не устраняет причину лишних шагов.

ERR_TOO_MANY_REDIRECTS — сообщение браузера, а не HTTP-статус. В реальной цепочке обычно встречаются ответы 301, 302, 303, 307 или 308 с заголовком Location. При этом нельзя считать любой 3xx очередной переадресацией: например, 304 относится к проверке сохранённого представления. Общее устройство переходов описано в руководстве MDN по HTTP-редиректам.

Формулировки «сайт выполнил переадресацию слишком много раз» и «страница перенаправляет неправильно» могут описывать один класс проблем в разных браузерах. Для расследования важнее исходный адрес, последовательность переходов и состояние авторизации, чем точный перевод сообщения.

Что делать посетителю сайта

Посетитель может проверить, зависит ли ошибка от его сессии и ссылки. Исправить противоречащие друг другу серверные правила из браузера невозможно, поэтому полезно быстро определить границу самостоятельных действий.

Сохраните исходный URL и адрес, который оказался в строке браузера. Если ссылка пришла из письма, сравните её с официальной главной страницей сервиса.
Откройте публичную страницу в приватном окне. Проверьте тот же адрес, а не другой раздел, который и раньше работал.
Если проблема возникает только после входа, запишите этот факт. Успех без авторизации не доказывает исправность личного кабинета.
Если сравнение указывает на сохранённую сессию, удалите данные только соответствующего сайта, учитывая выход из аккаунта и возможную потерю незавершённой работы.
Если ошибка повторяется, передайте поддержке адрес, время с часовым поясом, браузер и условия воспроизведения.

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

При ошибке после оплаты или отправки заявки сначала проверьте результат операции доступным способом. Цикл мог начаться уже на странице подтверждения, когда действие выполнено. Повторное нажатие кнопки или пересылка формы не нужны для диагностики редиректов.

Как владельцу увидеть цепочку и найти первый неверный переход

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

В Chrome откройте инструменты разработчика и вкладку Network. Включите Preserve log, затем повторите открытие страницы. Эта настройка сохраняет запросы при переходах между страницами; её работа описана в документации Chrome DevTools. Найдите запрос основного документа и последующие переходы. Для каждого сохраните Request URL, метод, статус и Location из ответа.

Записывайте полные адреса: схема, имя хоста, порт, путь и параметры. Разница в одном завершающем слеше или параметре возврата может объяснить весь цикл. Location допускает относительный адрес: значение /login нужно сопоставлять с адресом текущего запроса, а не читать как отдельный домен.

После записи цепочки отметьте первый переход, который противоречит ожидаемому маршруту. Например, HTTPS уже достигнут, но приложение снова требует HTTPS; выбран адрес без www, но другой узел возвращает www. Именно этот переход связывайте с настройкой и журналом, а не меняйте всё, где встречается слово redirect.

Заголовки ответа дают подсказки, однако не всегда однозначно называют компонент, сформировавший редирект. Сопоставьте время и идентификатор запроса с журналами CDN, веб-сервера и приложения. В сложной схеме каждый участник может видеть только свой переход и считать его правильным.

Как проверить перенаправления через curl

Для публичной страницы своего сайта сначала посмотрите один ответ без автоматического перехода. В примере для macOS или Linux замените example.com своим доменом:

curl -sS --max-time 20 -D - -o /dev/null https://example.com/

Команда выполняет обычный GET, показывает заголовки и не выводит тело страницы. Она позволяет увидеть первый статус и Location. Затем можно проследить ограниченную цепочку:

curl -sS --max-time 20 -D - -o /dev/null -L --max-redirs 10 https://example.com/

Здесь -L включает следование HTTP-редиректам, --max-redirs ограничивает количество переходов, а --max-time задаёт предел времени операции. Числа 10 и 20 выбраны для диагностики и не являются лимитами браузера. В Windows используйте curl.exe, а вместо /dev/null — NUL. Значение параметров приведено в официальном руководстве curl.

Не подменяйте этот тест командой с -I без учёта различий: она использует HEAD, а сервер может обрабатывать его иначе, чем GET. Не добавляйте к проверке оплату, загрузку файла или повтор отправки формы. Для первого разбора достаточно одного публичного URL и нескольких ограниченных переходов.

Результат curl не обязан совпадать с браузером. У него нет вашей браузерной сессии, сохранённых редиректов и того же поведения JavaScript. Если curl получает страницу, а пользователь зацикливается, сравните условия, cookies и инициатора перехода. Перед передачей заголовков удалите значения сессий и секретные параметры URL.

Какие правила чаще всего создают цикл

Составьте короткую карту мест, где сайт меняет адрес: CDN, панель хостинга, Nginx или Apache, приложение, CMS и её расширения. Для каждого вида нормализации определите ожидаемый результат и ответственный компонент. Наличие нескольких правил само по себе допустимо; проблема возникает, когда они требуют противоположных результатов.

Наблюдаемая последовательность	Вероятный конфликт	Что сопоставить
www появляется и исчезает	Разные настройки основного имени	Правила хостинга, CDN и адрес сайта в CMS
/catalog и /catalog/ сменяют друг друга	Противоположная обработка слеша	Веб-сервер, маршрутизатор приложения, SEO-модуль
HTTPS снова ведёт на HTTP	Несогласованная схема подключения	Правила HTTPS на внешнем и внутреннем участках
/login и /account повторяются	Состояние сессии определяется противоречиво	Cookies, проверку авторизации, адрес возврата
URL постоянно удлиняется	Правило повторно обрабатывает собственный результат	Условия совпадения, параметры, добавляемый префикс

Основной домен, слеш и языковая версия

Сначала выберите ожидаемый адрес для конкретной страницы. Затем проверьте, не отправляет ли следующий слой обратно на старый вариант. Если CDN убирает www, а приложение добавляет его, исправьте несогласованность конфигурации. Добавление ещё одного редиректа поверх существующих может только усложнить цепочку.

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

Параметры и старые адреса

Если каждый переход добавляет return_url, код языка или префикс каталога, точного повторения URL может не быть. Проверьте, исключает ли условие результат, который правило само создаёт. Для перенесённых страниц проследите всю цепочку исторических адресов: несколько отдельных корректных перенаправлений вместе могут образовать круг.

Тег canonical не разрывает HTTP-цикл: браузер должен сначала получить страницу, чтобы прочитать её разметку. Исправляйте источник перехода, а canonical и внутренние ссылки проверяйте после восстановления доступа. Так разные настройки будут указывать на один ожидаемый адрес.

Где искать правило в Nginx и Apache

В Nginx проверьте директивы return и rewrite в нужном виртуальном сервере и подключаемых файлах. Их поведение описано в документации модуля rewrite. Не всякое внутреннее изменение URI означает новый переход браузера: связывайте найденное правило с реальным HTTP-ответом. Иначе можно исправлять маршрут приложения, который вообще не создавал наблюдаемый Location.

Если запрос обрабатывает Apache, проверьте Redirect, RedirectMatch и правила RewriteRule вместе с условиями RewriteCond. Они могут находиться в конфигурации виртуального хоста и разрешённых для использования файлах .htaccess. Руководство Apache объясняет, почему условия и порядок обработки важны. Удаление всего .htaccess затрагивает не только редиректы: в нём могут находиться необходимые правила маршрутизации и доступа.

Убедитесь, что редактируемый файл относится к работающему экземпляру и действительно подключён. В инфраструктуре с несколькими серверами одна исправленная копия не гарантирует одинакового поведения остальных. Сравните применённые версии конфигурации на узлах, которые обслуживают проблемный домен. Если настройки генерирует панель хостинга, учитывайте её механизм сохранения, чтобы следующая операция не вернула старое правило.

Перед изменением сохраните исходную конфигурацию и конкретную цепочку ответов. Исправьте условие или целевой адрес, выполните штатную проверку синтаксиса и примените изменение предусмотренным способом. Проверка синтаксиса подтверждает пригодность конфигурации для загрузки, но не отсутствие логического цикла между серверами. Поэтому завершающий шаг — повторный внешний запрос с тем же исходным URL и сравнение полученных переходов.

HTTPS, Cloudflare и обратный прокси

Здесь важно разделять соединение посетителя с внешним узлом и соединение этого узла с исходным сервером. Публичный HTTPS-адрес ещё не говорит, как именно CDN обращается к приложению. Противоречие между этими участками часто остаётся незаметным при просмотре одной настройки.

Cloudflare Flexible и принудительный HTTPS на origin

В режиме Flexible Cloudflare обращается к origin по HTTP. Если origin перенаправляет такой запрос на публичный HTTPS-адрес, следующий запрос снова приходит к origin по HTTP, и ситуация повторяется. Этот механизм описан в официальном разборе ERR_TOO_MANY_REDIRECTS.

Для сайта, которому нужен HTTPS на обоих участках, подготовьте HTTPS на origin: доступность нужного порта и подходящий сертификат. Затем согласуйте конфигурацию с требованиями Full (strict). Простое переключение режима без подготовки origin может заменить цикл другой ошибкой. Понижать защиту как универсальный способ устранения редиректов не требуется.

Обратный переход на HTTP

При Full и Full (strict) схема обращения к origin обычно соответствует схеме запроса посетителя; это объясняется в описании Full. Не стоит считать, что само название режима автоматически перенаправляет любой HTTP на HTTPS.

Если origin возвращает посетителя с HTTPS на HTTP, а внешний узел через Always Use HTTPS снова отправляет его на HTTPS, получается противоречие. Похожий конфликт возможен с действующей политикой HSTS в браузере. Найдите обратный редирект и исправьте политику адресов, сохраняя согласованную работу HTTPS. Удаление HSTS у одного пользователя не исправляет серверное правило.

Приложение не распознаёт исходный HTTPS

Балансировщик может завершать TLS и передавать запрос приложению по внутреннему HTTP. Если приложение считает такое обращение обычным внешним HTTP, оно снова требует HTTPS. Проверьте, передаёт ли доверенный прокси сведения об исходной схеме и правильно ли приложение их учитывает.

Заголовок X-Forwarded-Proto нельзя безусловно принимать от любого клиента. Прокси должен корректно устанавливать его, а приложение — доверять предусмотренному инфраструктурой источнику. Например, документация Django отдельно описывает требования к такой настройке. Конкретное исправление выбирайте для своей платформы и числа промежуточных узлов.

Что проверить в WordPress и другой CMS

Если ошибка появилась после переноса, смены домена или установки расширения, начните с соответствующего изменения. Сравните публичный адрес, настройки CMS и правила внешнего сервера. Не отключайте все плагины одновременно на рабочем сайте: тогда можно потерять исходный симптом и затронуть другие функции.

В WordPress проверьте WordPress Address и Site Address, а также значения WP_SITEURL и WP_HOME, если они заданы в конфигурации. По документации общих настроек, эти адреса имеют разные назначения и могут обоснованно различаться при установке ядра в отдельную папку. Поэтому требование «сделайте их одинаковыми» подходит не каждому сайту.

Уточните, какой компонент управляет HTTPS, основным именем и перенаправлениями старых страниц. Сравните настройки плагина с фактическим Location. Если подозрение падает на расширение, проверьте изменение на тестовой копии или в согласованном режиме обслуживания, сохранив возможность возврата.

Для WordPress за обратным прокси дополнительно проверьте распознавание исходной схемы: этот сценарий отдельно рассмотрен в руководстве WordPress по HTTPS. Копирование фрагмента конфигурации без проверки доверия к прокси способно создать новую проблему вместо устранения цикла.

Если цикл возникает при входе в личный кабинет

Типичный сценарий: кабинет считает пользователя неавторизованным и отправляет на вход, а страница входа считает сессию действующей и возвращает в кабинет. Здесь важно воспроизвести именно переход после авторизации, а не только проверить публичную страницу.

В DevTools посмотрите, устанавливается ли cookie сессии и отправляется ли она в следующем запросе. Проверьте домен, путь, срок действия и ограничения передачи. Атрибуты Secure и SameSite описаны в документации Set-Cookie. Смена домена, схемы или способа входа через внешний сервис может изменить условия, в которых cookie отправляется.

Не назначайте всем cookies SameSite=None и не убирайте Secure ради проверки. Исправление зависит от реального маршрута входа и требований системы. При едином входе через SSO сопоставьте адрес возврата, завершающий callback и состояние сессии на обеих сторонах. Для теста используйте предусмотренную тестовую учётную запись.

Если запросы распределяются между несколькими экземплярами приложения, проверьте доступность состояния сессии для каждого из них. Ситуация «один узел узнаёт пользователя, другой нет» может объяснить непостоянный цикл. Это гипотеза для проверки по журналам, а не вывод из одного сообщения браузера.

Условный пример: ошибка после включения нового CDN

Предположим, после подключения CDN главная магазина показывает ERR_TOO_MANY_REDIRECTS. До изменения основной адрес работал с www, а в новой панели настроили переход на домен без www. Это условный пример расследования, а не результат проверки конкретного сайта.

Владелец сохраняет цепочку: www.example.com направляет на example.com, а тот возвращает www.example.com.
Сопоставляет ответы с журналами и выясняет: первый переход создаёт CDN, второй — настройка основного адреса в приложении.
Подтверждает ожидаемый публичный адрес и согласует с ним оба компонента. Меняет противоречащее правило, сохраняя остальные нужные переходы.
Проверяет исходный URL и обе версии имени. Они приводят к ожидаемой странице без возврата.
Отдельно проверяет вход, карточку товара и ссылки из рекламы, затем обновляет соответствующий кэш там, где хранится прежний ответ.

Здесь очистка cookies посетителей не устранила бы конфликт. Ключевое доказательство — два конкретных Location и настройки, которые их создают. Если после изменения цепочка сохраняется, нужно выяснить, какой слой продолжает выдавать старый ответ, а не добавлять третий редирект.

Как подтвердить исправление и заметить повторение

Проверьте первоначальный адрес с теми же условиями, при которых возникала ошибка. Затем сравните чистую сессию и авторизованный сценарий, если он был затронут. Убедитесь, что цепочка заканчивается ожидаемым содержимым: исчезновение сообщения при переходе на заглушку или неправильную страницу ещё не означает восстановление.

После изменения постоянного редиректа учитывайте сохранённые ответы браузера и промежуточных кэшей. Обновляйте только относящиеся к изменению данные и повторяйте проверку. Успех в чистом профиле при старом поведении обычного профиля указывает на различие условий, которое нужно объяснить.

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

Зафиксируйте найденный конфликт, изменённую настройку и контрольные адреса. После следующих обновлений проверяйте именно эти переходы. Так диагностика превращается в короткую проверку известных рисков, а владельцу не приходится заново разбирать всю цепочку по жалобе клиента.

Частые вопросы

Нужно ли удалять все редиректы?

Нет. Часть переходов нужна для старых ссылок, выбранного имени и HTTPS. Сначала найдите шаг, который противоречит ожидаемому результату, и исправьте его. Массовое удаление правил может восстановить одну страницу и одновременно нарушить другие адреса.

Почему curl работает, а браузер показывает ошибку?

Сравните авторизацию, cookies, сохранённые ответы и переходы, запускаемые JavaScript или разметкой страницы. curl следует HTTP-редиректам при включённом -L, но не выполняет браузерный сценарий целиком. В Network найдите, какой именно запрос или инициатор начинает повторение.

Поможет ли замена 301 на 302?

Она меняет смысл ответа и особенности его использования, но не согласует противоположные адреса. Если A направляет на B, а B возвращает A, конфликт сохранится. Сначала исправьте маршрут, затем выберите подходящий статус для каждого необходимого перехода.

Ошибка только у части пользователей — сайт исправен?

Такого вывода делать нельзя. Различаться могут сессии, кэш, язык, вход через внешний сервис и сервер, обработавший запрос. Сравните успешный и неудачный сценарии при близком времени проверки. Полезнее найти различие, чем просить всех посетителей повторять одну очистку.