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

Как исправить ERR_TOO_MANY_REDIRECTS: сначала понять, что браузер попал в цикл переадресаций. Сервер отправляет его с адреса A на B, оттуда снова на A, и так до тех пор, пока Chrome или Firefox не остановятся после 20 переходов. Чаще всего виноват конфликт двух правил: режим Flexible в Cloudflare вместе с принудительным HTTPS на сервере, разные адреса сайта (http и https, с www и без) в WordPress и в панели хостинга или двойные редиректы в .htaccess либо Nginx. Посетителю обычно помогает удаление cookies сайта, а владельцу проверка цепочки командой curl -IL и удаление одного из двух конфликтующих правил.

Что означает ошибка и как она выглядит в разных браузерах

Переадресация (редирект): это ответ сервера с кодом 301, 302, 307 или 308 и заголовком Location, где указан новый адрес. Браузер автоматически переходит по нему. Цепочка из одного-двух шагов нормальна: например, http://www.example.com ведет на https://example.com. Проблема начинается, когда цепочка замыкается в круг или становится слишком длинной. Браузер считает переходы и после лимита прекращает попытки.

Где вы это видите	Текст ошибки (английский интерфейс)	Что происходит
Chrome, Edge, Opera	This page isn’t working. example.com redirected you too many times. ERR_TOO_MANY_REDIRECTS	Исчерпан лимит в 20 переходов
Firefox	The page isn’t redirecting properly	Лимит задает параметр network.http.redirection-limit, по умолчанию 20
Safari	Too many redirects occurred trying to open…	Тот же цикл, другой текст
curl	curl: (47) Maximum (50) redirects followed	Стандартный лимит curl: 50 переходов
Googlebot	Ошибка переадресации (Redirect error) в Search Console	Google проходит не больше 10 переходов

В локализованных браузерах текст переведен, но код ERR_TOO_MANY_REDIRECTS в Chrome одинаков для всех языков. Совет Chrome удалить cookies не случаен: часть циклов возникает именно из-за cookie, например когда сайт проверяет язык, регион или авторизацию и каждый раз отправляет на ту же страницу.

Что сделать посетителю

Если вы не владелец сайта, сначала проверьте свой браузер. Это займет несколько минут:

Откройте страницу в режиме инкогнито (Ctrl+Shift+N в Chrome, Ctrl+Shift+P в Firefox). Если там все работает, причина в cookies или кеше браузера.
Удалите cookies только этого сайта: в Chrome нажмите значок слева от адреса, откройте раздел о файлах cookie и данных сайта и удалите данные домена. Другие сайты это не затронет.
Очистите кешированные изображения и файлы (Ctrl+Shift+Delete). Браузер запоминает переадресацию 301 и может повторять старый редирект даже после того, как владелец его исправил.
Отключите расширения, которые меняют адреса: VPN, прокси, блокировщики рекламы, расширения для принудительного HTTPS.
Откройте сайт с телефона через мобильный интернет. Если ошибка есть везде, проблема на стороне сайта: сообщите владельцу, когда и на каком адресе вы ее увидели.

Основные причины цикла переадресаций

Почти всегда цикл состоит из двух правил, которые тянут адрес в противоположные стороны. Таблица поможет сориентироваться по симптому:

Причина	Как выглядит цепочка	Решение
Cloudflare в режиме Flexible и HTTPS-редирект на сервере	https://example.com → 301 → https://example.com (тот же адрес)	Режим Full (strict) в Cloudflare
Cloudflare в режиме Full, а сервер переводит на http	https → http → https	Убрать редирект на http, исправить адрес в CMS
Вариант с www и без www задан в разных местах	example.com → www.example.com → example.com	Одно правило и одинаковый адрес в WordPress
В WordPress адрес с http, а сервер принуждает к HTTPS	https → http → https	home и siteurl с https://
Сайт за прокси или балансировщиком	https://example.com → https://example.com	Учитывать заголовок X-Forwarded-Proto
Разные правила для слеша в конце адреса	/page/ → /page → /page/	Согласовать с постоянными ссылками
Cookie языка, региона или входа	Цикл только в одном браузере или у одного пользователя	Исправить логику плагина, удалить cookie

Отдельный случай: закешированный редирект. Браузер хранит 301, плагин кеша или CDN может отдавать сохраненный ответ, а HSTS заставляет браузер самостоятельно переходить на HTTPS. Как устроены эти уровни, мы разбирали в статье про кеш на хостинге. После каждого исправления проверяйте результат в режиме инкогнито или через curl, а не в обычной вкладке.

Как увидеть цепочку редиректов: curl и DevTools

Не угадывайте причину, а посмотрите, куда именно сервер отправляет браузер. Быстрее всего это сделать из командной строки. curl есть в Linux, macOS и Windows 10/11 (в PowerShell пишите curl.exe):

curl -sSIL --max-redirs 10 http://example.com/ | grep -iE "^(HTTP|location|server)"

Так выглядит типичный цикл, когда Cloudflare работает в режиме Flexible:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/2 301
location: https://example.com/
server: cloudflare
HTTP/2 301
location: https://example.com/
server: cloudflare
...
curl: (47) Maximum (10) redirects followed

Как читать результат. Если в Location раз за разом повторяется тот же адрес, который вы запросили, сервер перенаправляет сам на себя. Строка server: cloudflare подсказывает, что ответ проходит через Cloudflare, значит, стоит проверить режим шифрования. Чередование http и https или www и без www показывает, какие именно два правила конфликтуют.

Проверка в обход Cloudflare

curl -sSIL --max-redirs 10 --resolve example.com:443:203.0.113.10 https://example.com/

Вместо 203.0.113.10 укажите IP вашего сервера (он есть в панели хостинга). Если напрямую сайт открывается с одним редиректом или вообще без него, цикл создает связка Cloudflare и сервера, а не сам сайт.

DevTools в браузере

Откройте DevTools (F12), вкладку Network, включите Preserve log и обновите страницу. Каждая строка со статусом 301, 302, 307 или 308: шаг цепочки, а адрес перехода виден в заголовке Location. Статус 307 Internal Redirect с пояснением Non-Authoritative-Reason: HSTS означает, что на HTTPS перенаправил сам браузер из-за сохраненной политики HSTS, а не сервер.

Схема цикла переадресаций в режиме Flexible Cloudflare — Сервер отправляет на HTTPS, а Cloudflare в режиме Flexible снова приходит к нему по HTTP

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

В режиме Flexible Cloudflare принимает посетителя по HTTPS, но к вашему серверу обращается по обычному HTTP. Если на сервере включен принудительный HTTPS (в панели, .htaccess, Nginx или плагине WordPress), сервер отвечает переадресацией на https://. Cloudflare передает ее браузеру, браузер снова приходит по HTTPS, Cloudflare снова идет к серверу по HTTP, и круг замыкается. В документации Cloudflare эта ситуация стоит первой среди причин ERR_TOO_MANY_REDIRECTS.

Убедитесь, что на сервере установлен действующий сертификат. Подробно о выпуске и проверке читайте в статье про SSL-сертификат на общем хостинге. На виртуальном хостинге бесплатный Let’s Encrypt обычно выпускается в панели управления за несколько минут.
В Cloudflare откройте SSL/TLS → Overview → Configure и выберите Full (strict). Режим Full без strict нужен, только если на сервере самоподписанный сертификат.
Если в зоне включен Automatic SSL/TLS, проверьте, какой режим фактически применен, и при необходимости перейдите на Custom SSL/TLS.
Просмотрите раздел Rules: Redirect Rules и устаревшие Page Rules не должны противоречить редиректам на сервере (например, Cloudflare ведет на www, а сервер на домен без www).
Очистите кеш Cloudflare (Caching → Configuration → Purge Everything), если кешируете HTML-страницы. Ответ 301 без заголовков кеширования Cloudflare по умолчанию хранит до 120 минут.

Бывает и обратная ситуация: режим Full, а сервер или WordPress переадресует HTTPS на HTTP. Тогда убирайте редирект на http и исправляйте адрес сайта. Опция Always Use HTTPS (SSL/TLS → Edge Certificates) безопасна в любом режиме, если сервер нигде не отправляет посетителей на http. Шире о работе CDN читайте в материале о том, когда CDN становится спасением.

WordPress: адрес сайта, плагины и wp-config.php

WordPress сам перенаправляет посетителей на адрес из настроек «Адрес WordPress (URL)» и «Адрес сайта (URL)», то есть из параметров siteurl и home таблицы wp_options. Если там http://example.com, а сервер принуждает к HTTPS, или там www.example.com, а панель хостинга ведет на домен без www, получится цикл. Проверьте значения через WP-CLI:

wp option get home
wp option get siteurl
# исправление: одинаковый адрес с https и нужным вариантом www
wp option update home 'https://example.com'
wp option update siteurl 'https://example.com'

Если админка недоступна, а SSH нет, задайте адрес в wp-config.php над строкой /* That's all, stop editing! */. Эти константы имеют приоритет над значениями из базы данных:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Сайт за прокси или балансировщиком

Когда HTTPS завершается на прокси, PHP получает запрос по HTTP и считает соединение незащищенным. WordPress с FORCE_SSL_ADMIN или SSL-плагином снова отправляет посетителя на https, и так по кругу. Документация WordPress советует в таком случае учитывать заголовок X-Forwarded-Proto. Добавьте код в wp-config.php выше строки require_once ABSPATH . 'wp-settings.php';:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
     && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Этот прием рассчитан на собственный Nginx-прокси или балансировщик. Для Cloudflare правильнее не латать WordPress, а перейти на режим Full (strict).

Плагины и кеш

Цикл часто добавляет плагин: SSL-плагин (например, Really Simple Security), плагин переадресаций, мультиязычность, кеш страниц или плагин безопасности, который переносит страницу входа. Отключите все плагины и проверьте сайт:

wp plugin deactivate --all
# без SSH: переименуйте папку wp-content/plugins в plugins-off в файловом менеджере

Если цикл исчез, включайте плагины по одному командой wp plugin activate имя-плагина и после каждого проверяйте сайт. После перевода сайта на HTTPS замените старые http-адреса в базе, сначала в тестовом режиме:

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

Цикл со слешем в конце адреса (/page/ и /page) обычно означает, что правило сервера противоречит структуре постоянных ссылок WordPress. Оставьте что-то одно: уберите правило с сервера или измените структуру в разделе «Настройки → Постоянные ссылки».

Сервер: правила в .htaccess, Nginx и панели хостинга

Apache и .htaccess

Самая частая ошибка в .htaccess: правило без условия, которое перенаправляет на HTTPS даже запросы, уже пришедшие по HTTPS. Правильный вариант проверяет протокол и хост, а http и www обрабатывает одним переходом (пример для домена без www):

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteCond %{HTTP_HOST} ^(?:www\.)?(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]

Ставьте эти строки в начало файла, до блока # BEGIN WordPress. Если Apache работает за прокси, который сам завершает HTTPS, переменная HTTPS на сервере всегда равна off. Тогда перенаправляйте только запросы, которые не пришли по HTTPS ни напрямую, ни через прокси:

RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx

В Nginx редирект на HTTPS должен стоять только в блоке server, который слушает порт 80. Цикл возникает, если return 301 попал в блок с listen 443 или в общий блок, слушающий оба порта. Корректная схема для домена без www:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com.crt;
    ssl_certificate_key /etc/ssl/example.com.key;
    root /var/www/example.com;
    # остальная конфигурация сайта
}

Найти все редиректы в конфигурации и проверить синтаксис помогут команды:

sudo grep -RnE "return 30[1278]|rewrite .* (permanent|redirect)" /etc/nginx/
sudo nginx -t && sudo systemctl reload nginx

Если Nginx стоит за Cloudflare в режиме Flexible или за балансировщиком, условие if ($scheme = http) всегда истинно, потому что на сервер приходит HTTP. Проверяйте $http_x_forwarded_proto или, что лучше, переведите Cloudflare в Full (strict). Каждый шаг цикла оставляет в access.log запись со статусом 301 или 302, по ним легко найти виновное правило.

Панель хостинга

В панелях управления хостингом в настройках домена обычно есть три опции, влияющие на редиректы:

Автоматическое перенаправление на HTTPS обычно добавляет return 301 https://$host$request_uri; только в HTTP-блок Nginx, поэтому само цикла не создает. Цикл появляется в паре с Cloudflare в режиме Flexible.
Перенаправление домена ведет на www или на домен без www. Выбранный вариант должен совпадать с адресом в WordPress, иначе панель и CMS будут отправлять посетителя друг к другу.
HSTS (HTTP Strict Transport Security) добавляет заголовок Strict-Transport-Security, часто с max-age=31536000: браузеры год будут помнить, что сайт открывается только по HTTPS. Включайте, когда HTTPS уже работает стабильно.

Если принудительный HTTPS включен в панели, на время диагностики его можно временно отключить там же, а после исправления включить снова.

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

Одно правило на каждую задачу. HTTPS и вариант www задавайте в одном месте (панель, .htaccess или Nginx), а адрес в WordPress должен просто с ним совпадать.
Один переход вместо цепочки. http://www.example.com должен вести сразу на https://example.com. Google проходит не больше 10 переходов, а каждый лишний шаг добавляет задержку.
Тестируйте с 302, закрепляйте 301. Браузеры кешируют постоянный редирект 301, поэтому ошибочное правило с кодом 301 посетители будут видеть и после исправления.
HSTS включайте последним, когда HTTPS работает на всех адресах сайта.
Проверяйте результат. После изменений запустите curl и посмотрите отчет «Индексирование страниц» в Search Console: страницы с циклом там отмечены как ошибка переадресации.
Планируйте переезды. При смене хостинга или домена составьте карту редиректов заранее, в этом поможет чеклист миграции хостинга без потери SEO-позиций.

Чеклист исправления ошибки ERR_TOO_MANY_REDIRECTS — Восемь проверок, которые убирают большинство циклов переадресаций

Частые вопросы

Почему ошибка появляется только в одном браузере?

Скорее всего, дело в cookies, закешированном редиректе 301 или сохраненной политике HSTS. Проверьте сайт в режиме инкогнито: если там он работает, удалите данные сайта. Политику HSTS в Chrome можно сбросить на странице chrome://net-internals/#hsts в блоке Delete domain security policies.

Почему ошибка появилась сразу после подключения Cloudflare?

Почти всегда из-за режима Flexible: Cloudflare обращается к серверу по HTTP, а сервер возвращает посетителя на HTTPS. Проверьте, что на сервере есть SSL-сертификат, и включите Full (strict).

Как зайти в админку WordPress, если цикл есть и на wp-admin?

Через файловый менеджер панели или FTP: задайте WP_HOME и WP_SITEURL в wp-config.php и переименуйте папку wp-content/plugins. После входа исправьте адреса в настройках и верните плагинам их папку.

Вредит ли ERR_TOO_MANY_REDIRECTS позициям в Google?

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

Что лучше для перехода на HTTPS: 301 или 302?

Для постоянного перехода используйте 301 (или 308). Код 302 удобен на время настройки: браузер не запоминает его надолго, поэтому ошибку проще исправить.

Может ли причина быть в DNS?

DNS сам по себе цикл не создает, но после переезда домен может указывать на старый сервер со старыми правилами. Проверьте IP в записи A и посмотрите цепочку на новом сервере через curl --resolve.

Заключение

ERR_TOO_MANY_REDIRECTS: это всегда два правила, которые противоречат друг другу. Посмотрите цепочку через curl, определите, кто перенаправляет (Cloudflare, сервер или WordPress), и оставьте по одному правилу для HTTPS и для www. В большинстве случаев достаточно переключить Cloudflare на Full (strict) или исправить адрес сайта в WordPress. На тарифах виртуального хостинга RichHost есть собственная панель управления с ИИ-помощником и бесплатный SSL Let’s Encrypt, поэтому режим Full (strict) в Cloudflare работает без дополнительной настройки.

ERR_TOO_MANY_REDIRECTS: как исправить цикл переадресаций