ERR_TOO_MANY_REDIRECTS: что вызывает цикл редиректов и как это исправить

2026-09-19

ERR_TOO_MANY_REDIRECTS означает, что браузер прошел цепочку редиректов, которая так и не привела к финальной странице, и сдался. Chrome и большинство других браузеров останавливаются примерно после 20 переходов, и самая частая причина - зацикленность HTTP-в-HTTPS, созданная прокси или CDN, которые расходятся с origin-сервером в том, какой протокол на самом деле используется.

Что означает ERR_TOO_MANY_REDIRECTS

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

Как проявляется ошибка

Chrome и Edge показывают "This page isn't working - redirected you too many times" с кодом ошибки ERR_TOO_MANY_REDIRECTS. Firefox показывает "The page isn't redirecting properly". Safari говорит "Safari can't open the page because too many redirects occurred".

curl с флагом -L следует редиректам так же, как это делает браузер, и вывод каждого перехода точно покажет, где повторяется цикл:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Именно этот паттерн, http в https и обратно в http, - самая частая форма этой ошибки. curl останавливается по собственному лимиту по умолчанию (50 редиректов), а не следует бесконечно, и повторяющиеся строки location делают цикл очевидным, даже не открывая браузер.

Что вызывает цикл редиректов

Несовпадение HTTP-в-HTTPS между прокси или CDN и origin. Это классический случай. Если режим SSL/TLS у Cloudflare выставлен на Flexible, Cloudflare терминирует TLS на edge и подключается к origin по обычному HTTP. Если у origin-сервера также есть правило, перенаправляющее каждый HTTP-запрос на HTTPS (частая настройка безопасности по умолчанию), origin отправляет браузер обратно на HTTPS, Cloudflare на следующем переходе снова понижает до HTTP, и обе настройки бесконечно борются друг с другом.
Правила www и без www, указывающие друг на друга. Одно правило перенаправляет голый домен на www, а отдельное правило, часто добавленное позже другим администратором или плагином, перенаправляет www обратно на голый домен.
Несовпадение siteurl или home в WordPress. Если настроенный URL сайта в базе данных не совпадает с URL, который реально используют посетители (оставшийся staging-URL, несовпадение схемы после добавления SSL), WordPress продолжает перенаправлять к настроенному значению.
Cookie, которые сервер ожидает, но никогда не получает, либо редирект на логин, молча проваливающийся. Страница, перенаправляющая неаутентифицированных посетителей на этап входа, который затем перенаправляет обратно на ту же страницу, потому что cookie сессии так и не была установлена (часто блокируется правилами браузера в отношении сторонних cookie либо отсутствующим атрибутом Secure/SameSite), зацикливается бесконечно.
Конфликтующие правила завершающего слеша или языкового префикса. Одно правило добавляет завершающий слеш, другое его убирает; одно правило добавляет языковой префикс на основе локали браузера, другое убирает его для канонических URL, и оба правила отменяют друг друга.
Слой кэширования отдает устаревший редирект. CDN или обратный прокси закэшировал старый 301, указывавший на URL, который с тех пор изменился и теперь перенаправляет обратно на исходный.

Как понять, кто виноват

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

Как исправить ERR_TOO_MANY_REDIRECTS

Если вы посетитель

Очистите cookie для сайта. В Chrome нажмите на значок замка или настроек рядом с адресной строкой, откройте настройки сайта и очистите cookie и данные сайта только для этого домена.
Попробуйте окно инкогнито или приватное окно. Это исключает расширение браузера или сохраненную cookie как причину, не затрагивая ваш обычный профиль.
Попробуйте другую сеть, например мобильный интернет вместо Wi-Fi. Некоторые корпоративные прокси или прокси на уровне провайдера переписывают запросы так, что цикл создается только в этой сети.
Очистите кэш браузера на случай, если сам ответ-редирект был закэширован еще до того, как сайт исправили.

Если вы администрируете сайт

Сравните режим SSL вашего CDN с правилом редиректа на origin. В Cloudflare откройте SSL/TLS и установите режим Full или Full (strict), а не Flexible, всякий раз когда origin перенаправляет HTTP на HTTPS. Full все еще позволяет origin использовать самоподписанный сертификат; Full (strict) требует валидного.
Доверяйте заголовку переданного протокола, а не перенаправляйте вслепую. Когда перед вашим приложением стоит прокси, origin должен перенаправлять на основе X-Forwarded-Proto, а не сырого соединения, которое из-за прокси всегда выглядит как HTTP. В nginx:
```
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}
```
и убедитесь, что CDN или балансировщик нагрузки действительно устанавливает этот заголовок в каждом запросе.
Проверьте свои правила редиректа по порядку, включая .htaccess, блоки server в nginx, промежуточное ПО уровня приложения и любые правила страниц в CDN, на предмет двух правил, указывающих друг на друга. Частый паттерн Apache, зацикливающийся за прокси:
```
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```
проваливается так же, как случай с nginx выше, поскольку %{HTTPS} читает соединение, которое делает прокси, а не то, которое сделал посетитель; вместо этого проверяйте %{HTTP:X-Forwarded-Proto}.
Исправьте URL сайта в WordPress, если это применимо: в wp-admin > Settings > General убедитесь, что и WordPress Address, и Site Address совпадают с URL, который реально используют посетители, включая протокол. Если сама панель администратора недоступна из-за цикла, задайте WP_HOME и WP_SITEURL напрямую в wp-config.php.
Выберите одну каноническую форму и перенаправляйте на нее все остальное за один шаг, а не цепочкой: www или без www, с завершающим слешем или без, - одно правило на одно решение, а не несколько правил, наслоенных разными инструментами с течением времени.
Очистите кэш CDN после исправления правила, поскольку закэшированный 301 или 302 продолжает отдавать старый ответ, пока он не истечет или не будет очищен.

Как предотвратить ERR_TOO_MANY_REDIRECTS

Цикл редиректов почти всегда вносится изменением конфигурации: новым CDN, новым SSL-сертификатом, обновлением плагина либо миграцией, затронувшей URL сайта. HTTP-проверка, следящая за кодом ответа и проходящая редиректы по расписанию, ловит цикл в момент его появления из 300+ контрольных точек в 158 городах, вместо того чтобы ждать тикета в поддержку. HostTracker мониторит сайты с 2004 года и может оповещать по email, SMS, голосовым звонком, через Slack, Telegram и другие каналы в момент, когда проверка начинает проваливаться.

Часто задаваемые вопросы

Сколько редиректов допускает браузер, прежде чем сдаться?

Chrome и браузеры на Chromium останавливаются примерно на 20. Лимит curl по умолчанию с -L - 50. Точное число отличается в зависимости от клиента, но любой из них в итоге остановится, а не будет следовать циклу бесконечно.

Почему цикл начинается сразу после переезда на Cloudflare (или другой CDN)?

Почти всегда дело в режиме SSL/TLS. Режим Flexible общается с origin по обычному HTTP; если origin настаивает на HTTPS, обе стороны бесконечно перенаправляют друг друга. Переключение на Full или Full (strict) обычно решает это немедленно.

Может ли это вызвать расширение браузера?

Да, особенно расширения, принудительно включающие HTTPS, переписывающие запросы либо управляющие cookie. Тест в окне инкогнито с отключенными расширениями быстро это исключает.

Влияет ли это на SEO?

Да. Поисковые краулеры сдаются на цикле редиректов точно так же, как браузер, и зацикленный URL не будет проиндексирован либо выпадет из индекса, если раньше работал.

Я вижу ошибку только на одной конкретной странице, а не на всем сайте. В чем разница?

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

Нужно ли исправлять один редирект (например, без www на www)?

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