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

Что такое ERR_TOO_MANY_REDIRECTS?

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

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

HTTP-коды состояния в цикле перенаправлений обычно 301 (постоянное перенаправление) или 302 (временное перенаправление). Типичный цикл выглядит так: ваш браузер запрашивает URL A, сервер отвечает кодом 301 на URL B, URL B отвечает кодом 301 обратно на URL A, и цикл повторяется, пока браузер не достигнет лимита.

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

Циклы перенаправлений возникают, когда два или более правила перенаправления конфликтуют друг с другом. Сервер отправляет браузер на 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

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

Прежде чем пробовать исправления, определите точную цепочку перенаправлений. Это покажет, какие именно 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, цикл перенаправлений подтверждён. Обратите внимание на HTTP-коды состояния: 301 означает постоянное перенаправление (кэшируется браузерами), 302 — временное (не кэшируется).

Способ 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 Headers Checker от DNS Robot для проверки заголовков ответа вне кэша вашего браузера.

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

Если у вас нет доступа к терминалу, используйте Redirect Checker от DNS Robot для отслеживания полной цепочки перенаправлений. Введите URL, и инструмент покажет каждый переход, код состояния и конечный пункт назначения — или подтвердит, что существует цикл. Это удобно, потому что проверка выполняется с нейтральной локации без влияния cookies вашего браузера на результат.

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

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

Очистка cookies в Chrome

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

• Шаг 1 — Нажмите на значок замка (или значок настроек) в адресной строке рядом с URL

• Шаг 2 — Нажмите Настройки сайта

• Шаг 3 — Нажмите Удалить данные, чтобы удалить cookies и кэшированные данные только для этого сайта

• Шаг 4 — Перезагрузите страницу

# Chrome keyboard shortcut to open Clear Browsing Data:
# Windows/Linux: Ctrl + Shift + Delete
# macOS: Cmd + Shift + Delete

Также можно перейти в chrome://settings/clearBrowserData, выбрать Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы, установить временной диапазон За всё время и нажать «Удалить данные».

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

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

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

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

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

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

• Проверьте SSL-сертификат — Используйте SSL Checker от DNS Robot, чтобы убедиться, что ваш сертификат действителен, не истёк и покрывает правильный домен

• Согласуйте протоколы — Если ваш CDN обрабатывает SSL-терминацию, удалите перенаправление HTTP на HTTPS на сервере или настройте CDN для подключения к серверу по HTTPS

• Проверьте настройки принудительного HTTPS — Если у вас есть перенаправление И на уровне сервера (Nginx/Apache), И на уровне CDN для принудительного HTTPS, удалите одно из них

• Проверьте заголовок X-Forwarded-Proto — За прокси ваш сервер должен проверять этот заголовок вместо протокола прямого подключения, чтобы определить, был ли исходный запрос по HTTPS

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

Cloudflare — самый частый источник ERR_TOO_MANY_REDIRECTS из-за особенностей работы его режимов SSL. Решение зависит от того, какой режим шифрования SSL/TLS вы используете.

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

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

• Шаг 1 — Войдите в панель управления Cloudflare

• Шаг 2 — Выберите ваш домен

• Шаг 3 — Перейдите в SSL/TLS > Overview

• Шаг 4 — Измените режим шифрования на Full (Strict), если у вас действительный SSL-сертификат на сервере, или 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;
    }
}

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

• Проверить в режиме инкогнито — Откройте окно инкогнито (Ctrl+Shift+N) и попробуйте открыть URL. Если в инкогнито работает, а в обычном окне нет, причина — закэшированное перенаправление или расширение

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

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

Safari: Safari показывает «too many redirects occurred» и выдаёт менее подробную ошибку, чем Chrome. Перейдите в Safari > Настройки > Конфиденциальность > Управление данными веб-сайтов, найдите домен и удалите его данные. Если проблема сохраняется, попробуйте Safari > Очистить историю (выберите всю историю).

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

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

• Перенаправляйте только в одном месте — Выберите один уровень для HTTPS-перенаправления: CDN, веб-сервер или приложение. Никогда не перенаправляйте на нескольких уровнях одновременно

• Используйте 302 при тестировании — При отладке используйте перенаправления 302 (временные) вместо 301 (постоянные). Браузеры агрессивно кэшируют 301, что затрудняет тестирование изменений. Переключитесь на 301 после подтверждения правильной работы

• Всегда тестируйте с curl — После добавления правила перенаправления выполните curl -ILs https://вашсайт.com | grep -i 'HTTP/\|location:', чтобы убедиться, что цепочка перенаправлений завершается ответом 200

• Мониторьте с помощью инструментов — Регулярно используйте HTTP Headers Checker от DNS Robot, чтобы убедиться, что ваш сайт возвращает чистый ответ 200 без неожиданных перенаправлений

• Документируйте перенаправления — Ведите учёт всех правил перенаправлений в конфигурации сервера, .htaccess, правилах CDN и настройках приложения. Когда несколько членов команды управляют сайтом, недокументированные перенаправления — причина №1 циклов

• Очищайте кэш CDN после изменений — После изменения любого правила перенаправления немедленно очистите кэш CDN. Устаревшие закэшированные перенаправления 301 могут сохраняться днями

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

Циклы перенаправлений напрямую вредят вашему ранжированию в поисковых системах. Краулер Google (Googlebot) следует максимум за 10 перенаправлениями на один URL, после чего прекращает. Если Googlebot обнаруживает цикл перенаправлений, он помечает страницу как ошибку краулинга и перестаёт её индексировать.

Согласно документации Google о перенаправлениях, цепочки перенаправлений должны быть как можно короче. Каждый дополнительный переход добавляет примерно 100-500 мс задержки и тратит ваш бюджет краулинга — количество страниц, которые Google просканирует на вашем сайте за день.

• Потеря индексации — Страницы, застрявшие в циклах перенаправлений, не индексируются и полностью исчезают из результатов поиска

• Расход бюджета краулинга — Googlebot тратит свой ограниченный бюджет краулинга на следование перенаправлениям вместо сканирования реального контента

• Штраф за скорость страницы — Каждое перенаправление 301 добавляет полный цикл «запрос-ответ» (100-500 мс). Три перенаправления могут добавить более секунды ко времени загрузки

• Разбавление ссылочного веса — Обратные ссылки, указывающие на URL с перенаправлением, теряют примерно 1-5% своего значения PageRank за каждый переход

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