ERR_TOO_MANY_REDIRECTS: как исправить (все браузеры)

Что такое ERR_TOO_MANY_REDIRECTS?

ERR_TOO_MANY_REDIRECTS означает, что страница больше 20 раз отправила браузер на другой адрес и так и не загрузилась: это цикл перенаправлений. Chrome пишет «Страница недоступна. Сайт example.com выполнил переадресацию слишком много раз» (Edge показывает похожую страницу с тем же кодом), Firefox — «Циклическое перенаправление на странице», а Safari — «Safari не может открыть страницу» с пояснением «При попытке открытия „example.com“ произошло слишком много переадресаций».

Если вы просто посещаете сайт, удалите cookies этого сайта и перезагрузите страницу: когда у всех остальных сайт открывается, причина обычно в устаревшем cookie. Если сайт ваш, цикл почти всегда возникает из-за того, что HTTPS (или www) принудительно включён сразу в двух местах, чаще всего это режим Flexible SSL в Cloudflare плюс перенаправление на HTTPS на сервере.

Лимит везде одинаковый, потому что так требует стандарт Fetch, который реализуют браузеры: «If request's redirect count is 20, then return a network error» (если счётчик перенаправлений запроса равен 20, вернуть сетевую ошибку). Сам цикл обычно состоит из двух ответов 301 или 302, указывающих друг на друга: URL A отправляет вас на URL B, URL B — обратно на A, и на 20 браузер прекращает счёт.

Что вызывает циклы перенаправлений?

Циклы перенаправлений возникают, когда два или более правила перенаправления конфликтуют друг с другом. Сервер отправляет браузер на URL, и этот URL отправляет браузер обратно. Вот наиболее частые причины:

• Неправильная настройка SSL/HTTPS — Самая распространённая причина. Ваш сервер принудительно перенаправляет с HTTP на HTTPS, но CDN или балансировщик нагрузки подключается к серверу по HTTP, создавая цикл: CDN → HTTP → сервер перенаправляет на HTTPS → CDN убирает HTTPS → HTTP → цикл
• Cloudflare Flexible SSL — Режим Flexible SSL в Cloudflare отправляет запросы на ваш сервер по HTTP. Если на сервере также настроено перенаправление HTTP на HTTPS, возникает бесконечный цикл между Cloudflare и вашим сервером
• Конфликтующие правила в .htaccess — Несколько правил перенаправления в .htaccess, которые противоречат друг другу, например одно правило принудительно добавляет www, а другое принудительно убирает www одновременно
• Несовпадение URL в WordPress — Адрес WordPress (URL) и Адрес сайта (URL) в Настройки > Общие не совпадают, или один использует HTTP, а другой — HTTPS
• Устаревшие cookies браузера — Старые cookies, содержащие устаревшие инструкции перенаправления или данные сессии, которые направляют браузер на URL, который больше не существует или был перемещён
• Перенаправления в кэше CDN или прокси — Ваш CDN закэшировал старое перенаправление 301, которое теперь конфликтует с текущей конфигурацией сервера
• Конфликты конфигурации сервера — Файлы конфигурации Nginx или Apache с конкурирующими блоками перенаправлений, например перенаправление одновременно в блоке сервера и в .htaccess
• Циклы входа в приложениях — Страница входа перенаправляет неавторизованных посетителей сама на себя, или браузер отказывается сохранять cookie сессии (OAuth, Supabase Auth, NextAuth). См. исправление 8

Как диагностировать цикл перенаправлений

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

Способ 1: используйте curl для отслеживания перенаправлений

Самый быстрый способ увидеть цепочку перенаправлений — использовать curl в терминале. Флаг -I получает только заголовки, -L следует за перенаправлениями, а --max-redirs ограничивает количество переходов:

# Trace redirect chain (limit to 10 hops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example output showing a redirect loop:
# HTTP/2 301
# location: http://example.com/
# HTTP/1.1 301 Moved Permanently
# Location: https://example.com/
# HTTP/2 301
# location: http://example.com/
# (repeats...)

Если вы видите, что одни и те же два URL чередуются в заголовках Location, цикл перенаправлений подтверждён. Обратите внимание на коды состояния: 301 — постоянное перенаправление, которое браузеры кэшируют, а 302 — временное перенаправление, которое не кэшируется, если ответ не указывает иное.

Следите за схемой в каждом заголовке Location: цикл между версиями http:// и https:// одного и того же URL — самый частый вариант, и он прямо указывает на настройку SSL.

Способ 2: вкладка Network в DevTools браузера

Вы также можете визуально отследить перенаправления в Chrome DevTools:

• Шаг 1 — Откройте Chrome DevTools с помощью F12 или Ctrl+Shift+I (Mac: Cmd+Option+I)
• Шаг 2 — Перейдите на вкладку Network и включите Preserve log (это сохраняет записи между перенаправлениями)
• Шаг 3 — Загрузите страницу, которая вызывает ошибку
• Шаг 4 — Посмотрите на последовательность запросов. Каждое перенаправление отображается как отдельная запись со статусом 301 или 302. Столбец Location показывает, куда указывает каждое перенаправление

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

Способ 3: онлайн-проверка перенаправлений

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

Исправление 1: очистить cookies и кэш браузера

Начните с самого простого решения. Устаревшие cookies или закэшированные перенаправления в вашем браузере могут вызывать циклы, даже когда конфигурация сервера правильная. Это особенно часто происходит после миграции сайта с HTTP на HTTPS — старые cookies могут по-прежнему ссылаться на HTTP-адреса.

Очистка cookies в Chrome

Очистите cookies для конкретного сайта, а не все cookies — это сохранит ваши авторизации на других сайтах:

• Шаг 1 — Нажмите на значок замка (или значок настроек) в адресной строке рядом с URL
• Шаг 2 — Нажмите Настройки сайтов
• Шаг 3 — Нажмите Удалить данные, чтобы удалить cookies и кэшированные данные только для этого сайта
• Шаг 4 — Перезагрузите страницу

# Chrome keyboard shortcut to open Delete browsing data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Или удалите всё для всех сайтов: нажмите Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), чтобы открыть окно Удалить данные о работе в браузере, отметьте Файлы cookie и другие данные сайтов и Кешированные файлы и изображения, выберите Все время и нажмите Удалить данные.

Очистка cookies в Firefox и Safari

Firefox: Нажмите Ctrl+Shift+Delete (Mac: Cmd+Shift+Delete), отметьте Куки и данные сайтов и Временные кешированные файлы и страницы, установите временной диапазон Всё и нажмите Удалить.

Safari: Перейдите в Safari > Настройки > Конфиденциальность > Управлять данными сайтов, найдите нужный домен, выберите его и нажмите Удалить. Затем очистите кэш с помощью Cmd+Option+E.

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

Сайт mail.google.com или accounts.google.com выполнил переадресацию слишком много раз (Gmail, Google Диск)

Если в сообщении указан accounts.google.com, mail.google.com или drive.google.com (например, «Страница недоступна. Сайт mail.google.com выполнил переадресацию слишком много раз. Попробуйте удалить файлы cookie.»), цикл возникает между страницами входа Google и cookies вашего браузера, а не из-за сломанного сайта. Вход в Google работает, только когда браузер сохраняет cookies Google, поэтому всё, что их блокирует или переписывает, гоняет вас по кругу:

• Удалите только cookies Google — откройте chrome://settings/content/all, найдите google.com, удалите его данные и войдите снова. Как указано в справке Google, после этого в аккаунт Google в этом браузере придётся войти заново
• Разрешите cookies для Google — уберите google.com из списков сайтов, которым запрещены cookies (в Chrome — «Запрещено сохранять данные на устройстве»), а если вы блокируете сторонние файлы cookie, добавьте [*.]google.com в раздел «Сайты, которым разрешено использовать сторонние файлы cookie» (Chrome: Настройки → Конфиденциальность и безопасность → Сторонние файлы cookie)
• Выйдите из всех аккаунтов и войдите в один — несколько аккаунтов, в которые выполнен вход, или рабочий аккаунт, который передаёт вход на страницу входа компании, могут перекидывать вас между собой
• Отключите расширения для cookies и приватности — расширения, которые удаляют или переписывают cookies во время входа, — частая причина. В режиме инкогнито Chrome не запускает расширения, пока вы их не разрешите, поэтому сначала попробуйте окно инкогнито

Исправление 2: проверить настройки SSL/HTTPS

Неправильная настройка SSL — причина №1 циклов перенаправлений. Самый распространённый сценарий — конфликт между вашим CDN/прокси и сервером-источником относительно использования HTTP или HTTPS.

Вот что обычно происходит: ваш CDN подключается к серверу по HTTP (так как он обрабатывает SSL-терминацию), но на сервере настроено перенаправление HTTP на HTTPS. Сервер отправляет CDN обратно на HTTPS, CDN убирает HTTPS и снова отправляет HTTP — бесконечный цикл.

Если за той же схемой стоит сломанный сертификат, браузер покажет другую ошибку; см. ERR_SSL_PROTOCOL_ERROR и «Подключение не защищено».

• Проверьте SSL-сертификат — Используйте инструмент Проверка SSL сертификата от DNS Robot, чтобы убедиться, что ваш сертификат действителен, не истёк и покрывает правильный домен
• Согласуйте протоколы — Если ваш CDN обрабатывает SSL-терминацию, удалите перенаправление HTTP на HTTPS на сервере или настройте CDN для подключения к серверу по HTTPS
• Проверьте настройки принудительного HTTPS — Если у вас есть перенаправление И на уровне сервера (Nginx/Apache), И на уровне CDN для принудительного HTTPS, удалите одно из них
• Проверьте заголовок X-Forwarded-Proto — За прокси ваш сервер должен проверять этот заголовок вместо протокола прямого подключения, чтобы определить, был ли исходный запрос по HTTPS

Исправление 3: устранение циклов перенаправлений Cloudflare

Cloudflare — самый частый источник ошибки, потому что от его режима шифрования зависит, обращается он к вашему серверу по HTTP или по HTTPS. На странице устранения неполадок Cloudflare (обновлена в сентябре 2026 года) перечислены пять настроек, которые дают цикл, каждая — в паре с тем, что делает ваш сервер-источник:

Обычное решение для цикла перенаправлений Cloudflare: измените режим шифрования SSL/TLS с Flexible на Full или Full (Strict). Это указывает Cloudflare подключаться к вашему серверу по HTTPS, устраняя цикл HTTP-HTTPS.

Пошаговое исправление Cloudflare

• Шаг 1 — Войдите в панель управления Cloudflare
• Шаг 2 — Выберите ваш домен
• Шаг 3 — Перейдите в SSL/TLS > Overview
• Шаг 4 — Измените режим шифрования на Full (strict), если на сервере действительный сертификат (бесплатный сертификат Cloudflare Origin CA подходит), или на Full, только если сертификат самоподписанный
• Шаг 5 — Перейдите в SSL/TLS > Edge Certificates и проверьте, включён ли Always Use HTTPS. Если ваш сервер уже перенаправляет на HTTPS, отключите эту опцию, чтобы избежать двойного перенаправления
• Шаг 6 — Проверьте Page Rules и Redirect Rules на наличие конфликтующих URL-перенаправлений
• Шаг 7 — Очистите кэш Cloudflare: перейдите в Caching > Configuration > Purge Everything

Исправление 4: исправить правила перенаправления в .htaccess (Apache)

На серверах Apache .htaccess — самое распространённое место для правил перенаправления и самый частый источник циклов перенаправлений. Конфликтующие правила, дублирующиеся перенаправления или отсутствующие проверки условий — всё это может создавать циклы.

• Проверьте дублирующиеся HTTPS-перенаправления — Если ваша панель хостинга (cPanel, Plesk) принудительно включает HTTPS, удалите ручное перенаправление из .htaccess
• Проверьте условия RewriteCond — Каждое правило RewriteRule, выполняющее перенаправление, должно иметь RewriteCond, предотвращающее его срабатывание на URL, которые уже соответствуют условию. Без этого правило выполняется при каждом запросе, включая уже перенаправленный
• Обратите внимание на флаг [L] — Флаг [L] означает «последнее правило», но только для текущего прохода. Если в подкаталоге есть другой .htaccess, он выполнится снова. Используйте [END] на Apache 2.4+ вместо него
• Проверьте заголовки прокси — За CDN используйте %{HTTP:X-Forwarded-Proto} вместо %{HTTPS} для определения исходного протокола

# Correct HTTPS redirect behind Cloudflare/CDN:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

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

Исправление 5: устранение циклов перенаправлений WordPress

Циклы перенаправлений в WordPress обычно возникают из трёх источников: несовпадение URL в настройках, конфликты плагинов или неправильные значения в wp-config.php. Если вы не можете войти в админ-панель WordPress из-за цикла перенаправлений, исправлять придётся через базу данных или файлы конфигурации напрямую.

Проверить настройки URL WordPress

В WordPress есть два параметра URL, которые должны совпадать: Адрес WordPress (URL) и Адрес сайта (URL) в Настройки > Общие. Если один использует http://, а другой https://, или один включает www., а другой нет, вы получите цикл перенаправлений.

Если вы не можете войти в админ-панель, задайте URL напрямую в wp-config.php:

// Add these lines to wp-config.php (above "That's all, stop editing!"):
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

// If behind a reverse proxy (Cloudflare, Nginx proxy):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Отключить плагины для поиска конфликтов

Плагины перенаправлений и кэширования — частые виновники. Такие плагины, как Redirection, Yoast SEO, Really Simple SSL, WP Super Cache и W3 Total Cache, могут добавлять правила перенаправлений, конфликтующие с настройками вашего сервера или CDN.

Если вы не можете войти в админ-панель, отключите все плагины через FTP или SSH:

# Rename the plugins folder to disable all plugins at once:
cd /var/www/html/wp-content/
mv plugins plugins.bak

# If the site loads, rename it back and disable plugins one by one:
mv plugins.bak plugins
# Then rename individual plugin folders to find the culprit:
mv plugins/really-simple-ssl plugins/really-simple-ssl.bak

Если отключение плагинов решает проблему, включайте их по одному, чтобы определить конфликтующий плагин. Самые частые виновники — SSL-плагины, которые добавляют перенаправления HTTP на HTTPS, когда ваш сервер или CDN уже это делает.

Исправление 6: исправить перенаправления на уровне сервера (Nginx и Apache)

Файлы конфигурации сервера могут содержать правила перенаправлений, которые конфликтуют с перенаправлениями на уровне приложения (WordPress, .htaccess) или настройками CDN.

Nginx: поиск конфликтов перенаправлений

Циклы перенаправлений в Nginx обычно возникают, когда блок HTTP-сервера перенаправляет на HTTPS, но что-то в блоке HTTPS перенаправляет обратно на HTTP. Проверьте конфигурацию вашего сайта:

# Correct Nginx HTTPS redirect (separate server blocks):
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # SSL certificate configuration here
    # DO NOT add another redirect to HTTPS here
}

# If behind Cloudflare/proxy, check real protocol:
server {
    listen 80;
    server_name example.com;
    if ($http_x_forwarded_proto != 'https') {
        return 301 https://example.com$request_uri;
    }
}

Выполните nginx -t после редактирования, чтобы найти синтаксические ошибки, затем systemctl reload nginx, чтобы применить изменения без простоя.

Apache: проверка перенаправлений VirtualHost

В Apache проверьте и конфигурацию VirtualHost, и .htaccess. Перенаправление в конфигурации VirtualHost плюс перенаправление в .htaccess создаёт двойное перенаправление, которое может зациклиться:

# Check Apache config for redirect rules:
grep -r 'Redirect\|RewriteRule' /etc/apache2/sites-enabled/
grep -r 'Redirect\|RewriteRule' /etc/httpd/conf.d/

# Check .htaccess:
cat /var/www/html/.htaccess | grep -i 'rewrite\|redirect'

Удалите дублирующиеся перенаправления — оставьте перенаправление только в одном месте. Лучшая практика — обрабатывать HTTPS-перенаправления в конфигурации VirtualHost (не в .htaccess), потому что правила VirtualHost обрабатываются один раз на запрос, тогда как .htaccess обрабатывается при каждом запросе.

Исправление 7: решение проблем для конкретного браузера

Если ошибка появляется только в одном браузере, проблема, скорее всего, в закэшированном перенаправлении или конфликте расширений, а не на сервере.

Chrome: очистка HSTS и пула сокетов

Chrome кэширует политики HSTS (HTTP Strict Transport Security), которые принудительно используют HTTPS. Если сайт ранее отправлял заголовок HSTS, но больше не использует HTTPS корректно, Chrome продолжит перенаправлять на HTTPS даже после очистки cookies.

• Очистить кэш HSTS — Перейдите на chrome://net-internals/#hsts, введите домен в поле Delete domain security policies и нажмите Delete
• Сбросить пулы сокетов — Перейдите на chrome://net-internals/#sockets и нажмите Flush socket pools, чтобы очистить закэшированные соединения
• Очистить DNS-кэш — Перейдите на chrome://net-internals/#dns и нажмите Clear host cache (другие способы — в статье как очистить кэш DNS)
• Проверить в режиме инкогнито — Откройте окно инкогнито (Ctrl+Shift+N) и попробуйте открыть URL. Если в инкогнито работает, а в обычном окне нет, причина — закэшированное перенаправление или расширение

Исправления для Firefox и Safari

Firefox: Введите about:config в адресной строке, найдите network.http.redirection-limit и убедитесь, что значение равно 20 (по умолчанию). Меньшее значение, заданное вручную или корпоративной политикой, приводит к тому, что перенаправления обрываются раньше. Также попробуйте удалить данные сайта: Настройки > Приватность и защита > Управление данными > найдите домен > Удалить выбранное.

Safari: Safari показывает «Safari не может открыть страницу» с текстом «При попытке открытия „…“ произошло слишком много переадресаций»; консоль Web Inspector пишет «Load cannot follow more than 20 redirections». Перейдите в Safari > Настройки > Конфиденциальность > Управлять данными сайтов, найдите домен и удалите его данные. Если цикл остаётся, проверьте в частном окне: если и там цикл, сайт настроен неправильно.

Исправление 8: циклы перенаправлений при входе в веб-приложениях

В веб-приложении цикл часто создаёт ваш собственный код: страница, которой нужен авторизованный пользователь, перенаправляет на /login, а что-то отправляет /login (или callback входа) прямо обратно. В консоли браузера это видно как net::ERR_TOO_MANY_REDIRECTS на запросе, который не удался.

• Страница входа тоже защищена — middleware авторизации, которое работает на всех маршрутах, перенаправляет на /login и саму страницу /login, и маршрут callback. Исключите их из проверки
• Cookie сессии не сохраняется — cookie с SameSite=None должен быть ещё и Secure, иначе браузер его отбросит; cookie, выставленный для другого домена, никогда не отправляется обратно. В обоих случаях каждый запрос по-прежнему выглядит как запрос без входа
• URL callback не совпадает — провайдер (Google, GitHub, Supabase Auth) отправляет пользователей на callback, который ваше приложение не обрабатывает, и этот маршрут снова перенаправляет на вход
• HTTP и HTTPS за прокси — приложение строит URL перенаправлений с http://, потому что игнорирует X-Forwarded-Proto: тот же цикл, что в исправлении 2, только уровнем выше

// Next.js: proxy.ts (middleware.ts before Next.js 16).
// Never run the sign-in check on the sign-in pages themselves.
export const config = {
  matcher: ["/((?!login|auth/callback|_next/static|_next/image|favicon.ico).*)"],
};

Проверьте исправление в инструменте «Проверка редиректов» или командой curl -IL без входа в аккаунт: здоровая цепочка заканчивается на странице входа с кодом 200, а не очередным перенаправлением.

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

После устранения ошибки следуйте этим рекомендациям, чтобы предотвратить повторение циклов перенаправлений:

• Перенаправляйте только в одном месте — Выберите один уровень для HTTPS-перенаправления: CDN, веб-сервер или приложение. Никогда не перенаправляйте на нескольких уровнях одновременно
• Используйте 302 при тестировании — При отладке используйте перенаправления 302 (временные) вместо 301 (постоянные). Браузеры агрессивно кэшируют 301, что затрудняет тестирование изменений. Переключитесь на 301 после подтверждения правильной работы
• Всегда тестируйте с curl — После добавления правила перенаправления выполните curl -ILs https://yoursite.com | grep -i 'HTTP/\|location:', чтобы убедиться, что цепочка перенаправлений завершается ответом 200
• Мониторьте с помощью инструментов — Регулярно используйте инструмент Проверка HTTP-заголовков от DNS Robot, чтобы убедиться, что ваш сайт возвращает чистый ответ 200 без неожиданных перенаправлений
• Документируйте перенаправления — Ведите учёт всех правил перенаправлений в конфигурации сервера, .htaccess, правилах CDN и настройках приложения. Когда несколько членов команды управляют сайтом, недокументированные перенаправления — причина №1 циклов
• Очищайте кэш CDN после изменений — После изменения любого правила перенаправления немедленно очистите кэш CDN. Устаревшие закэшированные перенаправления 301 могут сохраняться днями

Здоровая цепочка содержит не больше одного-двух переходов (например, HTTP → HTTPS → 200 OK). Три и больше обычно означают перенаправление, которое вам уже не нужно.

Влияние циклов перенаправлений на SEO

Циклы перенаправлений убирают страницы из поиска. В документации Google о сканировании сказано, что краулеры Google проходят не больше 10 перенаправлений подряд; цикл никогда не доходит до контента, поэтому Search Console сообщает об ошибке перенаправления, и URL выпадает из индекса, пока цикл не исправлен.

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

• Потеря индексации — Страницы, застрявшие в циклах перенаправлений, не индексируются и полностью исчезают из результатов поиска
• Расход бюджета краулинга — Googlebot тратит свой ограниченный бюджет краулинга на следование перенаправлениям вместо сканирования реального контента
• Более медленные страницы — Каждый переход — это ещё один запрос и ещё один цикл «запрос-ответ» до загрузки любого контента, а переход на другой хост требует ещё и нового соединения