ERR_TOO_MANY_REDIRECTS: как найти и убрать цикл редиректов

Ошибка ERR_TOO_MANY_REDIRECTS появляется, когда браузер слишком долго идёт по цепочке перенаправлений и не находит в конце обычную страницу. Типичный сценарий: http://example.com отправляет на https://example.com, тот — обратно на http://example.com, или /login бесконечно перенаправляет сам на себя.

Для пользователя это выглядит как «сайт не открывается», а для владельца сайта проблема обычно в конфигурации: Nginx, Apache, CDN, балансировщик, приложение, CMS, правила HTTPS, cookies или авторизация. Неприятность в том, что сервер формально отвечает, но страница всё равно недоступна.

Разберём, что означает ERR_TOO_MANY_REDIRECTS, как найти конкретный участок цикла и как убрать его, не угадывая настройки.

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

ERR_TOO_MANY_REDIRECTS — это браузерная ошибка, которая означает: клиент получил слишком много HTTP-редиректов подряд и остановил запрос.

Редирект — это ответ сервера с кодом 3xx и заголовком Location. Например:

• 301 Moved Permanently — постоянное перенаправление;
• 302 Found — временное перенаправление;
• 307 Temporary Redirect — временный редирект с сохранением метода;
• 308 Permanent Redirect — постоянный редирект с сохранением метода.

Подробнее про коды ответов можно посмотреть в справочнике «Все коды ответов HTTP».

Браузер автоматически переходит по адресу из Location. Если новый адрес снова отвечает редиректом, браузер идёт дальше. Так продолжается до лимита. В Chrome ошибка выглядит как ERR_TOO_MANY_REDIRECTS, в Firefox — как сообщение о том, что страница перенаправляет запрос циклически.

Простой пример цикла:

1. Пользователь открывает http://site.ru.
2. Сервер отвечает 301 Location: https://site.ru.
3. Следующий слой инфраструктуры отвечает 301 Location: http://site.ru.
4. Браузер снова открывает http://site.ru.
5. Цикл повторяется.

Важно: это не то же самое, что 500, 502 или 504. При цикле редиректов серверы часто живы, сеть работает, DNS резолвится, TLS может быть корректным. Проблема именно в маршруте HTTP-запроса.

Как быстро подтвердить цикл редиректов

Начинать лучше не с панели администратора CMS и не с перезапуска сервера, а с просмотра цепочки ответов. Самый удобный инструмент — curl.

Если нужно освежить базовые опции, пригодится отдельный материал «Что такое curl и как им пользоваться».

1) Посмотреть один ответ без перехода по редиректу — выполните:

curl -I http://example.com

Смотрите на код ответа и заголовок Location:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Если Location ведёт на ожидаемый адрес, сделайте следующий запрос уже к нему:

curl -I https://example.com/

Так можно вручную пройти цепочку и увидеть, где она начинает повторяться.

2) Показать всю цепочку автоматически — используйте -L для следования по редиректам и -v для подробного вывода:

curl -L -v http://example.com/ -o /dev/null

В выводе ищите строки вида:

< HTTP/1.1 301 Moved Permanently
< location: https://example.com/
...
< HTTP/2 301
< location: http://example.com/

Если адреса чередуются, цикл найден.

3) Ограничить число редиректов — чтобы не получать длинный шумный вывод:

curl -L --max-redirs 10 -I http://example.com/

Если curl завершится с ошибкой Maximum redirects followed, проблема воспроизводится не только в браузере.

4) Проверить конкретный путь — цикл может быть не на главной странице, а только на /login, /admin, /checkout, /api/auth/callback:

curl -L -I https://example.com/login

Для сайтов с авторизацией полезно проверять запросы как без cookies, так и с cookies. Иногда редирект появляется только у залогиненного пользователя или только у гостя.

5) Сравнить браузер и терминал — если curl открывает страницу нормально, а браузер показывает ERR_TOO_MANY_REDIRECTS, причина может быть в cookies, кэше HSTS, расширениях или сохранённой сессии. Если ошибка есть и в curl, почти наверняка виновата серверная логика или инфраструктура.

Частые причины ERR_TOO_MANY_REDIRECTS

Цикл редиректов почти всегда возникает из-за двух или более правил, которые противоречат друг другу. Вот самые частые варианты.

1) HTTP ↔ HTTPS туда-обратно — классика: Nginx редиректит http на https, а CDN или приложение считает, что исходный запрос был http, и отправляет обратно. Часто встречается за reverse proxy, балансировщиком или Cloudflare.

2) Неправильный режим SSL на CDN — например, CDN подключается к origin по http, а origin принудительно переводит всё на https. CDN снова делает запрос по http, получает редирект, отдаёт его клиенту — и так по кругу. У Cloudflare это часто связано с режимом Flexible SSL.

3) Дублирующие правила в Nginx, Apache и приложении — редирект может быть настроен одновременно в конфиге веб-сервера, .htaccess, фреймворке и CMS. Каждое правило само по себе выглядит правильным, но вместе они создают петлю.

4) Конфликт www и домена без www — одно правило переводит example.com на www.example.com, другое — обратно. То же возможно с региональными доменами, языковыми префиксами и каноническими URL.

5) Неверная настройка APP_URL, SITE_URL, BASE_URL — приложение генерирует редиректы на адрес, который не совпадает с фактическим публичным URL. Часто после переезда домена, включения HTTPS или переноса за прокси.

6) Ошибки авторизации — пользователь идёт на /dashboard, приложение отправляет его на /login, а /login из-за неверной проверки сессии отправляет обратно на /dashboard. Похожий сценарий бывает в OAuth callback, SSO и middleware.

7) Cookies и сессии — приложение не может прочитать cookie из-за неверных атрибутов Domain, Path, Secure, SameSite, после чего считает пользователя неавторизованным и снова отправляет на страницу входа.

8) CMS-плагины — WordPress, Bitrix, Joomla и другие CMS часто имеют плагины для HTTPS, SEO-редиректов, мультиязычности и кэша. Два активных плагина могут спорить о каноническом URL.

9) Проблемы после миграции — сайт переехал на новый домен, поменял протокол, добавил CDN или reverse proxy, но старые правила остались.

Как найти источник редиректа

Когда цепочка подтверждена, задача — понять, кто именно отдаёт каждый Location: браузер, CDN, веб-сервер, приложение или CMS.

1) Смотрите заголовки ответа — в curl -I обращайте внимание не только на Location, но и на Server, Via, CF-Cache-Status, X-Redirect-By, X-Powered-By.

Например:

HTTP/2 301
server: cloudflare
location: https://example.com/
cf-cache-status: DYNAMIC

Или:

HTTP/1.1 301 Moved Permanently
Server: nginx
Location: https://example.com/

WordPress может добавлять:

X-Redirect-By: WordPress

Это сразу сужает круг поиска.

2) Проверяйте access log — если редирект отдаёт origin-сервер, запрос должен быть виден в логах Nginx или Apache.

Для Nginx обычно смотрят:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Полезно включить в формат логов $scheme, $host, $request_uri, $status, $sent_http_location, $http_x_forwarded_proto. Тогда будет видно, какой протокол видит сервер и куда он отправляет клиента.

3) Обойдите CDN или балансировщик — если есть подозрение на промежуточный слой, проверьте origin напрямую. Например, через curl --resolve:

curl -I https://example.com/ --resolve example.com:443:203.0.113.10

Так вы заставите curl обратиться к конкретному IP, минуя обычный DNS-ответ. Это помогает понять, создаёт ли редирект origin или внешний прокси.

Если причина связана с DNS, полезно отдельно проверить записи домена. Для этого есть материал «Утилита dig. Как проверить DNS-записи и отладить домен».

4) Проверьте DevTools — в Chrome откройте Network, включите Preserve log, перезагрузите страницу и посмотрите последовательность запросов. У каждого запроса будут Status Code, Location, cookies и инициатор.

DevTools особенно полезен, если цикл зависит от cookies или конкретного пользовательского состояния.

5) Сравните разные клиенты — откройте сайт в приватном окне, другом браузере, с другого IP, без VPN, с мобильной сети. Если ошибка есть только у части пользователей, вероятны cookies, гео-редиректы, A/B-тесты или CDN-правила.

Как исправить редиректы в Nginx и Apache

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

1) Правильно разделите HTTP и HTTPS в Nginx — типовой вариант: HTTP-сервер только переводит на HTTPS, HTTPS-сервер обслуживает сайт.

server {
    listen 80;
    server_name example.com www.example.com;
 
    return 301 https://example.com$request_uri;
}
 
server {
    listen 443 ssl http2;
    server_name example.com;
 
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
 
    root /var/www/example.com;
}

Если нужен редирект с www на без www, делайте его явно и только в одну сторону:

server {
    listen 443 ssl http2;
    server_name www.example.com;
 
    return 301 https://example.com$request_uri;
}

Не должно быть второго правила, которое переводит example.com обратно на www.example.com.

Про базовую настройку HTTPS в Nginx есть отдельная инструкция: «Как настроить HTTPS и бесплатный SSL-сертификат в Nginx».

2) Учитывайте reverse proxy — если приложение стоит за Nginx, балансировщиком или ingress, оно должно понимать исходный протокол клиента. Для этого обычно передают заголовки:

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

А приложение должно доверять proxy-заголовкам. В Express это app.set('trust proxy', true), в Django — SECURE_PROXY_SSL_HEADER, в Rails — настройки trusted proxies, в Laravel — TrustProxies.

Если reverse proxy настроен неправильно, приложение может думать, что запрос пришёл по http, даже когда пользователь открыл https. Тогда оно будет бесконечно требовать HTTPS. Подробнее про такой слой инфраструктуры — в статье «Что такое Nginx reverse proxy».

3) Проверьте .htaccess в Apache — в Apache циклы часто возникают из-за mod_rewrite. Например, правило без условия может редиректить каждый запрос:

RewriteEngine On
RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Лучше добавлять условия:

RewriteEngine On
 
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]

Если сайт за прокси, обычная переменная %{HTTPS} может быть off, хотя клиент пришёл по HTTPS. Тогда нужно учитывать заголовок X-Forwarded-Proto, но только если вы доверяете прокси.

4) Не смешивайте 301 и эксперименты — пока вы отлаживаете редиректы, используйте временные коды 302 или 307. Постоянный 301 может кэшироваться браузером, CDN и поисковыми системами. После исправления иногда кажется, что цикл остался, хотя клиент использует старое закэшированное правило.

HTTPS, CDN и прокси: где часто ломается схема

Самая распространённая причина ERR_TOO_MANY_REDIRECTS в продакшене — рассинхрон между внешним HTTPS и внутренним HTTP.

Представим схему:

Browser -> CDN HTTPS -> Origin HTTP

Пользователь открывает https://example.com. CDN принимает HTTPS, но к origin идёт по HTTP. Origin видит http и отвечает: «перейди на https://example.com». CDN отдаёт этот редирект браузеру. Браузер снова открывает HTTPS. CDN снова идёт к origin по HTTP. Получается цикл.

1) Включите полный HTTPS до origin — если используется CDN, лучше, чтобы участок CDN -> origin тоже работал по HTTPS. В Cloudflare это обычно режим Full или Full (strict), а не Flexible.

Если проблема проявляется через Cloudflare, полезно сравнить её с другими ошибками проксирования: «Ошибка 520/521/522/523/524 Cloudflare». Там другие симптомы, но логика диагностики слоёв похожа: нужно понять, где ломается путь между клиентом, CDN и origin.

2) Проверьте Page Rules, Redirect Rules и Workers — CDN может редиректить независимо от origin. Например, правило переводит http://*example.com/* на https://example.com/$1, а Worker или origin меняет хост обратно. В интерфейсе CDN проверьте все правила, которые затрагивают URL, протокол, путь и www.

3) Согласуйте HSTS — Strict-Transport-Security говорит браузеру всегда использовать HTTPS. Сам по себе HSTS не создаёт серверный редирект, но может маскировать проблему: браузер даже не попробует HTTP, а сразу пойдёт на HTTPS. Если при этом серверные правила ожидают другой сценарий, диагностика становится запутаннее.

4) Проверьте сертификат origin — при переходе на полный HTTPS CDN должен успешно подключаться к origin. Если сертификат просрочен, самоподписан без доверия или выдан не на тот домен, CDN может вести себя иначе в зависимости от режима. Для понимания TLS-части пригодится статья «Как работает HTTPS».

Приложение, CMS, cookies и авторизация

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

1) Проверьте базовый URL приложения — переменные вроде APP_URL, SITE_URL, PUBLIC_URL, NEXTAUTH_URL, WORDPRESS_HOME, WORDPRESS_SITEURL должны совпадать с публичным адресом сайта. Если сайт доступен как https://example.com, а приложение считает базовым http://example.com или https://www.example.com, оно может генерировать неверные редиректы.

2) Проверьте middleware авторизации — типичный баг:

• /dashboard требует авторизации и отправляет на /login;
• /login видит «почти валидную» сессию и отправляет на /dashboard;
• /dashboard снова не принимает сессию.

Лечится не редиректами в веб-сервере, а исправлением условий: чётко разделите состояния anonymous, authenticated, expired, partially authenticated.

3) Проверьте cookies — если cookie не сохраняется или не отправляется, приложение после каждого запроса считает пользователя новым.

Частые ошибки:

• Secure включён, но локально используется http;
• SameSite=Strict ломает OAuth callback;
• Domain указан как www.example.com, а сайт открыт на example.com;
• Path слишком узкий;
• cookie превышает лимиты браузера;
• разные поддомены используют разные секреты подписи.

4) Отключите плагины редиректов и кэша — в CMS временно выключите SEO-плагины, HTTPS-плагины, мультиязычные редиректы, кэширующие расширения и правила canonical URL. Делайте это по одному, чтобы понять, какой компонент создаёт цикл.

5) Очистите серверный и CDN-кэш — даже после исправления конфигов старый редирект может жить в кэше CDN, reverse proxy, приложения или браузера. Проверьте в приватном окне и через curl, а затем очистите нужные слои.

6) Не решайте всё очисткой cookies — совет «почистите cookies» помогает пользователю, если цикл связан с битой сессией. Но для владельца сайта это не решение. Если новые пользователи снова попадают в цикл, нужно исправлять Set-Cookie, авторизацию или базовый URL.

Чеклист исправления без лишнего риска

Чтобы не усугубить ситуацию, двигайтесь от наблюдения к минимальному изменению.

1) Зафиксируйте цепочку — сохраните вывод:

curl -L -I --max-redirs 10 https://example.com/

Отдельно проверьте http, https, www, без www и проблемный путь.

2) Определите владельца каждого редиректа — по заголовкам, логам, DevTools и проверке origin напрямую. Не меняйте конфиг Nginx, если редирект отдаёт WordPress или CDN.

3) Выберите один канонический URL — например, https://example.com. Все остальные варианты должны вести к нему:

• http://example.com → https://example.com;
• http://www.example.com → https://example.com;
• https://www.example.com → https://example.com.

Обратных правил быть не должно.

4) Уберите дубли — оставьте редирект на одном уровне: CDN, веб-сервер или приложение. Для простых правил хоста и HTTPS часто удобнее веб-сервер или CDN. Для бизнес-логики — приложение.

5) Проверьте staging — если есть тестовый контур, воспроизведите схему с тем же proxy/CDN. Циклы часто не видны локально, потому что локально нет TLS-терминации и X-Forwarded-Proto.

6) Временно используйте 302 — пока проверяете, не закрепляйте ошибку постоянным 301. Когда убедитесь, что цепочка корректная, можно заменить на 301 или 308.

7) Проверьте после деплоя снаружи — не только из серверной консоли. Запрос с самого сервера может обходить CDN, локальный DNS или балансировщик. Нужна внешняя проверка из сети, похожей на пользовательскую.

Для таких случаев полезен uptime monitoring: он регулярно открывает URL извне и фиксирует момент, когда сайт перестал отдавать ожидаемый ответ. В Statuser можно задать интервал проверки и получать уведомление о сбое, чтобы узнать о цикле редиректов раньше пользователей.

Как не допустить повторения

Циклы редиректов часто возвращаются после миграций, включения CDN, обновления CMS или изменения авторизации. Профилактика проще аварийной диагностики.

1) Документируйте канонический URL — в проекте должно быть явно записано, какой протокол, хост и базовый путь считаются основными. Это снижает риск, что SEO-специалист, разработчик и DevOps настроят разные правила.

2) Держите редиректы в одном месте — не плодите одинаковую логику в CDN, Nginx, .htaccess, приложении и CMS. Чем больше слоёв, тем труднее понять, кто отправил пользователя не туда.

3) Тестируйте цепочки в CI/CD — для критичных URL можно добавить smoke-тесты: главная, логин, callback авторизации, корзина, API healthcheck. Тест должен проверять, что число редиректов ограничено и финальный код ожидаемый.

Пример идеи:

curl -L --max-redirs 5 -fsS https://example.com/ -o /dev/null

Если редиректов больше пяти или финальная страница не открылась, деплой лучше остановить.

4) Следите за изменениями инфраструктуры — включение CDN, перенос SSL-терминации, смена ingress-контроллера, обновление плагина HTTPS — всё это должно попадать в план проверки. После таких изменений обязательно проверяйте http, https, www и ключевые пользовательские маршруты.

5) Настройте мониторинг доступности — цикл редиректов может не поднять CPU, не заполнить диск и не вызвать ошибку процесса. С точки зрения сервера «всё работает», но пользователи видят пустой тупик. Поэтому внешняя HTTP-проверка часто ловит проблему быстрее, чем серверные метрики. Если вы только выстраиваете процесс, начните с материала «Что такое uptime monitoring и как он работает».

Также полезно иметь общий план диагностики на случай, когда сайт не открывается: «Не открывается сайт: пошаговая диагностика».

FAQ

Что значит ERR_TOO_MANY_REDIRECTS?
Браузер получил слишком много HTTP-редиректов подряд. Обычно это цикл: один URL перенаправляет на второй, а второй — обратно или на уже посещённый адрес.

Поможет ли очистка cookies?
Иногда да, если цикл связан с битой сессией конкретного пользователя. Но если проблема в конфигурации сервера, CDN или приложения, очистка cookies только временно скроет симптом.

Какой инструмент лучше всего использовать для диагностики?
Начните с curl -L -I --max-redirs 10 https://example.com/. Он покажет цепочку редиректов и поможет понять, где адреса начинают повторяться.

Почему ошибка появилась после включения HTTPS?
Чаще всего из-за конфликта между HTTPS-редиректом на origin и настройками CDN или reverse proxy. Проверьте, какой протокол видит приложение и корректно ли передаётся X-Forwarded-Proto.