Too Many Redirects через Cloudflare — как исправить ERR_TOO_MANY_REDIRECTS

Быстрое решение

• Проверьте SSL/TLS Encryption mode в Cloudflare.
• Если на origin уже есть SSL-сертификат, используйте Full или Full (strict).
• Не оставляйте Flexible, если origin сам делает HTTP → HTTPS редирект.
• Проверьте Always Use HTTPS и HSTS.
• Проверьте Redirect Rules и старые Page Rules.
• Уберите дублирующие редиректы из .htaccess, Nginx, WordPress и плагинов.
• После исправления очистите кэш Cloudflare и браузера.

Что означает Too Many Redirects через Cloudflare

Ошибка означает, что URL зациклился. Например, сайт перенаправляет пользователя с HTTP на HTTPS, а другая настройка возвращает его обратно на HTTP. Или одна система отправляет на версию с www, а другая — обратно на версию без www. В итоге браузер прекращает попытки и показывает ошибку.

Cloudflare прямо указывает, что чаще всего такой цикл появляется из-за неправильного режима шифрования, настроек Edge Certificates или криво заданных Redirect Rules. :contentReference[oaicite:1]{index=1}

Почему возникает ERR_TOO_MANY_REDIRECTS в Cloudflare

Основные причины обычно такие:

• неверно выбран SSL/TLS Encryption mode;
• включён Always Use HTTPS и похожий редирект уже есть на сервере;
• включён HSTS, который усиливает неправильную HTTPS-схему;
• есть ошибка в Redirect Rules;
• одновременно работают редиректы в Cloudflare, WordPress, .htaccess и Nginx;
• origin неправильно обрабатывает HTTP и HTTPS.

Самая частая причина — неправильный SSL/TLS mode

Cloudflare отдельно объясняет, что redirect loop часто возникает, когда режим SSL/TLS в панели Cloudflare конфликтует с логикой origin-сервера. :contentReference[oaicite:2]{index=2}

Типичный сценарий №1: в Cloudflare стоит Flexible, а origin автоматически перенаправляет HTTP на HTTPS. Тогда Cloudflare идёт к серверу по HTTP, сервер отправляет запрос обратно на HTTPS, и цикл повторяется. Это один из самых частых вариантов redirect loop. :contentReference[oaicite:3]{index=3}

Типичный сценарий №2: в Cloudflare стоит Full или Full (strict), а origin зачем-то перенаправляет HTTPS обратно на HTTP. Тогда цикл снова замыкается, только в обратную сторону. :contentReference[oaicite:4]{index=4}

Когда ошибка появляется чаще всего

На практике ошибка часто появляется после подключения Cloudflare, включения SSL, переноса сайта на новый сервер, изменения www/non-www, включения HSTS, замены редиректов в WordPress или миграции со старых Page Rules на новые Redirect Rules. Cloudflare отдельно отмечает Redirect Rules как одну из типичных причин этой ошибки, а в документации по миграции Page Rules рекомендует переносить старые правила аккуратно, без дублей. :contentReference[oaicite:5]{index=5}

Как исправить Too Many Redirects через Cloudflare: пошаговая инструкция

1. Проверьте SSL/TLS Encryption mode

Откройте Cloudflare → SSL/TLS и посмотрите, какой режим сейчас активен:

• Flexible — Cloudflare идёт к origin по HTTP;
• Full — Cloudflare идёт к origin по HTTPS;
• Full (strict) — Cloudflare идёт к origin по HTTPS и проверяет сертификат origin.

Если на origin установлен нормальный SSL-сертификат, обычно правильнее использовать Full или Full (strict). Именно конфликт Flexible с HTTPS-редиректом на origin Cloudflare называет одним из главных источников redirect loop. :contentReference[oaicite:6]{index=6}

2. Если у вас Flexible, проверьте редирект HTTP → HTTPS на origin

Если origin принудительно отправляет все HTTP-запросы на HTTPS, а в Cloudflare стоит Flexible, цикл почти гарантирован. В таком случае есть два рабочих варианта:

• либо временно убрать HTTPS-редирект на origin;
• либо перевести Cloudflare на Full или Full (strict), если origin уже умеет HTTPS.

Этот сценарий Cloudflare описывает как базовый пример Too Many Redirects. :contentReference[oaicite:7]{index=7}

3. Если у вас Full или Full (strict), проверьте редирект HTTPS → HTTP

При Full и Full (strict) Cloudflare соединяется с origin уже по HTTPS. Если origin при этом по ошибке возвращает пользователя обратно на HTTP, получается новый цикл. Это второй официальный сценарий, который Cloudflare приводит в документации по ERR_TOO_MANY_REDIRECTS. :contentReference[oaicite:8]{index=8}

4. Проверьте Always Use HTTPS

Cloudflare относит настройки на странице Edge Certificates к числу частых причин этой ошибки. На практике одна из первых вещей для проверки — Always Use HTTPS. Если такой же редирект уже задан в WordPress, .htaccess, Nginx или плагине, может возникнуть конфликт.

Для диагностики временно оставьте только одну схему принудительного HTTPS и уберите дубли.

5. Проверьте HSTS

HSTS тоже находится в зоне риска, потому что заставляет браузер всегда использовать HTTPS. Если HTTPS-логика на сайте настроена неправильно, HSTS не создаёт цикл сам по себе, но усиливает проблему и делает её более устойчивой для пользователя. Cloudflare прямо упоминает настройки Edge Certificates как один из источников redirect loop. :contentReference[oaicite:9]{index=9}

6. Проверьте Redirect Rules и старые Page Rules

Cloudflare прямо указывает, что misconfigured redirect rule — одна из основных причин ERR_TOO_MANY_REDIRECTS. Особенно часто ошибка возникает, когда одновременно активны:

• HTTP → HTTPS;
• www → non-www;
• редирект домена на поддомен;
• условные редиректы по пути, которые возвращают пользователя на исходный URL.

Если раньше использовались Page Rules, а потом были добавлены новые Redirect Rules, проверьте, не дублируют ли они друг друга. Cloudflare отдельно напоминает о миграции Page Rules в новые rules-templates и Redirect Rules. :contentReference[oaicite:10]{index=10}

7. Проверьте origin-сервер

После панели Cloudflare обязательно проверьте серверную часть. Ищите редиректы в:

• .htaccess;
• конфиге Nginx;
• конфиге Apache;
• панели хостинга;
• reverse proxy;
• балансировщике нагрузки.

Cloudflare прямо советует обращаться к хостингу или администратору origin, если нужно понять, не отвечает ли origin сам по себе редиректами. :contentReference[oaicite:11]{index=11}

8. Проверьте WordPress и плагины

На WordPress цикл часто создают:

• неправильные WordPress Address и Site Address;
• плагины SSL;
• плагины кэша;
• плагины редиректов;
• самописные редиректы в functions.php.

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

9. Проверьте нестандартные порты

Если сайт работает не на стандартных HTTP/HTTPS-портах, а на нестандартной схеме, проверьте, поддерживается ли этот порт Cloudflare proxy. По умолчанию Cloudflare проксирует только определённые HTTP и HTTPS-порты, включая 80 и 443, а также ряд дополнительных портов вроде 2053, 2083, 8443 и других. Если схема доступа нестандартная, это может осложнять диагностику редиректов и HTTPS-маршрута. :contentReference[oaicite:12]{index=12}

10. Очистите кэш и cookies после исправлений

После исправления конфигурации очистите:

• Cloudflare cache;
• кэш сайта;
• cookies и кэш браузера.

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

Advanced troubleshooting

1. Проверьте цепочку редиректов через DevTools в браузере.
2. Сравните HTTP и HTTPS версии сайта отдельно.
3. Проверьте версию с www и без www.
4. Если используете reverse proxy, проверьте заголовок X-Forwarded-Proto.
5. Временно переведите DNS-запись в DNS only и проверьте, исчезает ли цикл без проксирования Cloudflare.
6. Соберите технические данные по времени ошибки, URL и шагам воспроизведения, если придётся писать в поддержку. Cloudflare рекомендует собирать максимум информации для диагностики сайтов. :contentReference[oaicite:13]{index=13}

Как избежать Too Many Redirects в будущем

• используйте только одну понятную схему HTTPS-редиректа;
• не смешивайте Flexible с origin-редиректом на HTTPS;
• не дублируйте редиректы одновременно в Cloudflare, WordPress и сервере;
• включайте HSTS только после полной стабилизации HTTPS;
• после миграции всегда тестируйте HTTP, HTTPS, www и non-www отдельно;
• при переносе старых Page Rules в новые Redirect Rules проверяйте логику каждого правила.

Когда обращаться в поддержку

• если вы уже убрали очевидные редиректы, а цикл остаётся;
• если неясно, кто именно отдаёт редирект — origin или Cloudflare;
• если используется нестандартный proxy, балансировщик или сложная CDN-цепочка;
• если после миграции нет доступа к серверной конфигурации.

Cloudflare рекомендует при обращении собирать максимум входных данных: URL, точное время ошибки, шаги воспроизведения и другую техническую информацию. :contentReference[oaicite:14]{index=14}

FAQ

Что чаще всего вызывает Too Many Redirects через Cloudflare?

Чаще всего причина — неверный SSL/TLS Encryption mode, особенно Flexible в сочетании с принудительным HTTPS на origin. Это прямо указано в документации Cloudflare. :contentReference[oaicite:15]{index=15}

Поможет ли переход с Flexible на Full?

Да, если на origin уже есть рабочий SSL-сертификат. В таком случае Full или Full (strict) обычно убирают конфликт между Cloudflare и origin. :contentReference[oaicite:16]{index=16}

Может ли Always Use HTTPS вызывать ERR_TOO_MANY_REDIRECTS?

Да. Cloudflare относит настройки Edge Certificates к типичным причинам redirect loop, а Always Use HTTPS — одна из таких настроек. :contentReference[oaicite:17]{index=17}

Могут ли Redirect Rules зациклить сайт?

Да. Cloudflare прямо пишет, что misconfigured redirect rule — одна из основных причин этой ошибки. :contentReference[oaicite:18]{index=18}

Как быстро понять, виноват Cloudflare или сервер?

Самый практичный способ — временно проверить сайт без проксирования Cloudflare, через DNS only. Если цикл исчезает, значит конфликт был в сочетании Cloudflare и origin-настроек.

Вывод

Too Many Redirects через Cloudflare почти всегда вызывается конфликтом между SSL/TLS mode, серверными редиректами, Always Use HTTPS, HSTS или Redirect Rules. Это неприятная, но обычно быстро решаемая ошибка.

Самая рабочая стратегия — сначала проверить SSL/TLS mode, затем убрать дублирующие редиректы, после этого проверить Edge Certificates, Redirect Rules и origin-сервер. В большинстве случаев этого достаточно, чтобы полностью убрать ERR_TOO_MANY_REDIRECTS.

• Cloudflare Redirect Loop — как исправить
• Flexible SSL ошибка — решение
• Error 525 — SSL Handshake Failed
• Error 526 — Invalid SSL Certificate
• ERR_SSL_PROTOCOL_ERROR — исправление
• Error 522 — Connection Timed Out