Как исправить ошибку 'ERR_TOO_MANY_REDIRECTS'

ERR_TOO_MANY_REDIRECTS означает, что браузер проследовал по цепочке перенаправлений, которая так и не разрешилась — чаще всего по схеме URL A → URL B → URL A — и прекратил попытки, достигнув встроенного лимита переходов.

Если вы столкнулись с этой ошибкой, скорее всего, вы изменили какую-то настройку прокси или SSL, после чего каждый запрос начал бесконечно курсировать между двумя URL вместо того, чтобы загрузить страницу. Эта ошибка особенно раздражает тем, что час назад страница работала нормально и ничего явно сломанного не видно. Это не баг браузера и не временный сбой — ошибка сигнализирует о том, что два или более правила перенаправления в вашем стеке конфликтуют между собой в части того, куда должен вести URL. Данное руководство построено по принципу «сначала диагностика»: сначала вы отслеживаете петлю, и лишь потом вносите изменения в конфигурацию, устраняя истинную первопричину. Для большинства разработчиков ею является несоответствие протоколов за прокси или CDN, а не плагин WordPress.

Что означает ошибка ‘ERR_TOO_MANY_REDIRECTS’?

Петля перенаправлений возникает, когда сайт продолжает отвечать на один URL перенаправлением на другой, который в итоге снова указывает на исходный, и браузер никогда не получает финальный ответ 200. Браузеры ограничивают количество переходов, которые они готовы отследить: Chromium и Firefox останавливаются на 20, Safari — раньше, после чего они прекращают запрос и отображают ошибку.

Формулировка сообщения различается в зависимости от браузера, однако все перечисленные ниже варианты описывают одно и то же состояние:

Сами перенаправления представляют собой обычные 3xx-ответы, как правило 301 или 302, каждый из которых содержит заголовок Location. В петле два одинаковых значения Location чередуются до тех пор, пока браузер не сдаётся.

Сначала диагностика: отслеживаем цепочку перенаправлений

Прежде чем менять какую-либо конфигурацию, отследите цепочку из командной строки. Команда curl -I -L https://yourdomain.com выводит заголовки ответа для каждого перехода, а петля проявляется в виде двух одних и тех же URL, чередующихся в последовательных строках Location:. Согласно документации curl, флаг -I (--head) запрашивает только заголовки, а -L (--location) следует каждому заголовку Location до следующего URL.

Исходный сервер с петлей выдаёт вывод следующего вида:

HTTP/2 301
location: https://app.example.com/

HTTP/2 301
location: http://app.example.com/

HTTP/2 301
location: https://app.example.com/
...
curl: (47) Maximum (50) redirects followed

Чередование http:// ↔ https:// здесь является характерным признаком петли из-за несоответствия протоколов. Если вам также нужны тела ответов, используйте curl -sSL -o /dev/null -D - https://yourdomain.com — эта команда выводит все заголовки, отбрасывая тело ответа.

Альтернативы без установки дополнительных инструментов: вкладка Network в DevTools браузера отображает ту же цепочку 301/302 с каждым значением Location; расширение Redirect Path или онлайн-инструмент проверки перенаправлений визуализируют цепочку для любого URL. В любом из этих инструментов ищите URL, который повторяется: повторяющаяся пара и есть петля.

Главная причина у разработчиков: петли HTTP↔HTTPS из-за завершения SSL

Наиболее распространённая петля перенаправлений, с которой сталкиваются разработчики, — это не плагин. Это несоответствие протоколов: прокси или CDN завершает TLS и передаёт обычный HTTP на ваш исходный сервер, приложение видит http, перенаправляет на https, и цикл повторяется бесконечно. Браузер общается с граничным узлом по HTTPS; граничный узел общается с вашим приложением по HTTP; ваше приложение «услужливо» перенаправляет обратно на HTTPS.

В Cloudflare установка SSL/TLS в режим Flexible при том, что исходный сервер также принудительно использует HTTPS, гарантированно создаёт петлю, поскольку Flexible всегда отправляет HTTP на исходный сервер. Триггером нередко служит отдельный переключатель «Always Use HTTPS», включённый поверх режима Flexible. Решение: установите сертификат на исходном сервере, затем переключите режим на Full (strict). Актуальный набор режимов — Off, Flexible, Full, Full (strict) и Strict, а не «три режима», которые описывают устаревшие руководства.

За собственным прокси или балансировщиком нагрузки настройте приложение на доверие заголовку переданного протокола вместо повторного перенаправления. Прокси должен отправлять X-Forwarded-Proto с исходной схемой браузера, а приложение должно читать его, а не анализировать незашифрованный переход. В Express включите trust proxy, чтобы req.protocol и req.secure отражали переданное значение:

// Trust the first proxy hop, then req.secure reflects X-Forwarded-Proto
app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(301, `https://${req.headers.host}${req.originalUrl}`);
  }
  next();
});

Без trust proxy значение req.secure остаётся false за TLS-терминирующим прокси, и именно это промежуточное ПО создаёт петлю. В Nginx, выполняющем перенаправление на исходном сервере, добавьте проверку переданной схемы, чтобы правило не срабатывало для трафика, уже пришедшего по HTTPS:

# Only redirect when the edge saw plain HTTP
if ($http_x_forwarded_proto = "http") {
  return 301 https://$host$request_uri;
}

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

Петли из-за куки и защиты аутентификации

Устаревшие куки и некорректная маршрутизация аутентификации — вторая по распространённости категория. Куки с устаревшим состоянием перенаправления или политика HSTS, закешированная браузером, могут загнать одного клиента в петлю, тогда как у всех остальных сайт загружается нормально. Именно это стоит за симптомом «не работает в обычном окне, но работает в режиме инкогнито». Начните с очистки куки и данных сайта для затронутого домена.

Программный вариант — защитник аутентификации, зацикленный на собственной странице входа. Если /login сам находится за правилом «перенаправлять неаутентифицированных пользователей на /login», каждый визит будет возвращаться обратно на /login. Исключите маршрут входа из защитника. То же самое происходит, когда обработчик входа перенаправляет на защищённую страницу, защитник которой немедленно отправляет пользователя обратно, поскольку куки сессии так и не были установлены (частый побочный эффект описанного выше несоответствия req.secure, при котором куки с флагом Secure отклоняются через HTTP-переход прокси).

Ошибки в правилах перенаправления: конфликт двух уровней

Петля перенаправлений почти всегда возникает из-за того, что два уровня конфликтуют в части канонического URL (фреймворк, веб-сервер и CDN применяют разные правила), поэтому надёжное решение заключается в том, чтобы перенаправления HTTP→HTTPS и www/non-www управлялись ровно на одном уровне. Типичные случаи: один уровень принудительно добавляет www, другой — убирает; правило, чья цель по-прежнему соответствует его собственному условию; или одно и то же перенаправление дублируется на уровне фреймворка, хоста и CDN.

Фреймворки являются полноценным уровнем перенаправлений, а не второстепенным инструментом:

• Next.js определяет перенаправления через async redirects() в next.config.js, где permanent: true генерирует 308, а false — 307. Обратите внимание, что начиная с Next.js 16 старое соглашение об именовании файла middleware переименовано в Proxy (proxy.ts); оставшийся middleware.ts по-прежнему работает для сценариев Edge runtime, однако считается устаревшим и будет удалён в будущей версии, поэтому логику перенаправлений и аутентификации следует перенести в proxy.ts.
• Nginx использует директиву return 301: защитите её, как показано выше, чтобы она не срабатывала повторно за прокси.
• Express использует промежуточное ПО; держите в цепочке ровно одно промежуточное ПО для перенаправления на HTTPS.
• WordPress — частный случай той же закономерности: несоответствие между настройками WordPress Address и Site Address — это просто конфликт двух уровней, который устраняется приведением обоих значений к одному виду.

На стороне сервера Apache может также выдавать отдельную ошибку «request exceeded the limit of 10 internal redirects», внутренний лимит перезаписи которого равен 10 — это отдельный лимит от 20 переходов браузера, и он является полезным признаком того, что петля находится в .htaccess, а не на стороне клиента. В Cloudflare размещайте перенаправление HTTP→HTTPS в Redirect Rule в современном движке Rules; Page Rules выводятся из эксплуатации в пользу современного движка Rules.

Как предотвратить петли перенаправлений?

Большинство петель возникает в результате изменения конфигурации, поэтому вносите изменения в правила перенаправлений осознанно. Используйте следующий чеклист:

1. Каждым перенаправлением управляет один уровень. Определите, на каком уровне — CDN, веб-сервер или приложение — будет выполняться канонизация HTTPS и www/non-www, и удалите дублирующие правила с двух других уровней.
2. Доверяйте прокси, не перенаправляйте повторно. За любым TLS-терминирующим переходом читайте X-Forwarded-Proto вместо того, чтобы принудительно перенаправлять на HTTPS вслепую.
3. Отслеживайте цепочку после каждого изменения. Запускайте curl -I -L для затронутого URL после любого изменения, связанного с HTTPS, доменом или структурой URL, и убеждайтесь, что цепочка завершается единственным ответом 200.

Самый быстрый выход из петли перенаправлений — всегда трассировка, а не догадки. Запустите curl -I -L для проблемного URL, найдите два URL, чередующихся в заголовках Location, затем исправьте тот единственный уровень, который перенаправляет вопреки логике — чаще всего это прокси, передающий HTTP на исходный сервер, который настаивает на HTTPS.

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

Почему петля перенаправлений исчезает в режиме инкогнито, но сохраняется в обычном окне браузера?

Режим инкогнито запускается без сохранённых куки и закешированной политики HSTS, поэтому петля, которая воспроизводится в обычном режиме, но исчезает в приватном окне, указывает на состояние на стороне клиента, а не на серверное правило. Устаревшие куки с устаревшим состоянием перенаправления или закешированная политика HSTS, принудительно использующая HTTPS на некорректно настроенном исходном сервере, будут создавать петлю только для затронутого профиля, тогда как у других пользователей сайт загружается нормально. Очистите куки и данные сайта для домена, а если подозревается HSTS, проверьте chrome://net-internals/#hsts.

В чём разница между Cloudflare Flexible и Full (strict) SSL применительно к петлям перенаправлений?

Flexible всегда отправляет обычный HTTP от Cloudflare на ваш исходный сервер, поэтому если исходный сервер принудительно перенаправляет HTTP на HTTPS, запрос зацикливается навсегда. Full (strict) отправляет HTTPS на исходный сервер и проверяет наличие доверенного сертификата, что соответствует ожиданиям исходного сервера и разрывает петлю. Сначала установите действительный сертификат на исходном сервере, затем переключите режим SSL/TLS с Flexible на Full (strict). Распространённым триггером является отдельный переключатель «Always Use HTTPS», включённый поверх режима Flexible.

Почему curl и браузер показывают разное поведение перенаправлений для одного и того же URL?

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

Применяются ли перенаправления из next.config.js в Next.js 16 к клиентской навигации через Link или router.push?

При использовании Pages Router перенаправления, определённые в функции redirects() файла next.config.js, не применяются к клиентской маршрутизации через Link или router.push, если только файл Proxy (ранее middleware) не присутствует и не соответствует пути. Перенаправления из next.config.js выполняются на сервере для полных загрузок страниц и начальных запросов, поэтому клиентские переходы могут их обходить. В Next.js 16 соглашение об именовании файла middleware было переименовано в Proxy (proxy.ts); оставшийся middleware.ts следует перенести, поскольку логика перенаправлений и аутентификации, оставленная там, может перестать выполняться.