ERR_TOO_MANY_REDIRECTS: причина циклу перенаправлень і виправлення

2026-09-19

ERR_TOO_MANY_REDIRECTS означає, що браузер пройшов ланцюжком перенаправлень, який так і не привів до фінальної сторінки, і здався. Chrome й більшість інших браузерів зупиняються приблизно після 20 переходів, а найпоширеніша причина - цикл HTTP-HTTPS, створений проксі чи CDN, що не погоджується з origin-сервером щодо того, який протокол використовується.

Що означає ERR_TOO_MANY_REDIRECTS

Перенаправлення каже браузеру "сторінка, яку ти хочеш, десь-інде, іди туди натомість." Одне перенаправлення, чи навіть два-три поспіль, - нормально: голий домен, що веде на www, чи стара URL-адреса, що веде на свою заміну. Цикл трапляється, коли URL-адреса перенаправляє на другу URL-адресу, що перенаправляє назад на першу, чи на саму себе. Оскільки браузер так і не дістається сторінки, яка справді повертає вміст, він обриває ланцюжок і показує помилку замість того, щоб зависнути назавжди.

Як з'являється помилка

Chrome й Edge показують "This page isn't working - redirected you too many times" з кодом помилки ERR_TOO_MANY_REDIRECTS. Firefox показує "The page isn't redirecting properly." Safari каже "Safari can't open the page because too many redirects occurred."

curl із прапорцем -L йде за перенаправленнями так само, як браузер, і друк кожного переходу показує точно, де повторюється цикл:

curl -sIL https://example.com/ | grep -E "^(HTTP|location)"
HTTP/1.1 301 Moved Permanently
location: http://example.com/
HTTP/1.1 301 Moved Permanently
location: https://example.com/
HTTP/1.1 301 Moved Permanently
location: http://example.com/

Саме цей патерн, з http на https і назад на http, - найпоширеніша форма цієї помилки. curl зупиняється на своєму власному ліміті за замовчуванням (50 перенаправлень), а не йде за ним вічно, а рядки location, що повторюються, роблять цикл очевидним без потреби взагалі відкривати браузер.

Що спричиняє цикл перенаправлень

Невідповідність HTTP-HTTPS між проксі чи CDN і origin-сервером. Це класичний випадок. Якщо режим SSL/TLS у Cloudflare встановлено на Flexible, Cloudflare завершує TLS на edge-вузлі й з'єднується з origin-сервером через звичайний HTTP. Якщо origin-сервер також має правило, що перенаправляє кожен HTTP-запит на HTTPS (поширене налаштування безпеки за замовчуванням), origin-сервер відправляє браузер назад на HTTPS, Cloudflare знову знижує до HTTP на наступному переході, і два налаштування борються вічно.
Правила www і non-www, що вказують одне на одного. Одне правило перенаправляє голий домен на www, а окреме правило, часто додане пізніше іншим адміністратором чи плагіном, перенаправляє www назад на голий домен.
Невідповідність siteurl чи home у WordPress. Якщо налаштована URL-адреса сайту в базі даних не збігається з URL-адресою, яку справді використовують відвідувачі (залишкова staging-адреса, невідповідність схеми після додавання SSL), WordPress продовжує перенаправляти на налаштоване значення.
Кукі, яких сервер очікує, але ніколи не отримує, чи перенаправлення на вхід, що мовчки провалюється. Сторінка, що перенаправляє неавтентифікованих відвідувачів на крок входу, який тоді перенаправляє назад на ту саму сторінку, бо кукі сесії так і не встановилося (часто заблоковано правилами сторонніх кукі браузера чи відсутнім атрибутом Secure/SameSite), зациклюється нескінченно.
Конфліктні правила кінцевого слеша чи мовного префікса. Одне правило додає кінцевий слеш, інше його прибирає; одне правило додає мовний префікс на основі локалі браузера, інше прибирає його для канонічних URL-адрес, і вони скасовують одне одного.
Шар кешування, що видає застаріле перенаправлення. CDN чи зворотний проксі закешував старий 301, що вказував на URL-адресу, яка, з того часу змінена, перенаправляє назад на оригінал.

Як зрозуміти, хто винен

Якщо цикл трапляється для кожного відвідувача в кожній мережі, це проблема конфігурації сервера чи CDN, а не щось локальне. Якщо це трапляється лише у вас, спершу очистіть кукі для сайту, оскільки погана чи прострочена кукі сесії спричиняє значну частку циклів в одного відвідувача. Запуск HTTP-перевірки з кількох локацій вирішує це за один запит: якщо той самий ланцюжок перенаправлень (чи той самий збій) з'являється з кожної локації, виправлення потрібне на боці сервера.

Як виправити ERR_TOO_MANY_REDIRECTS

Якщо ви відвідувач

Очистіть кукі для сайту. У Chrome клацніть на іконку замочка чи налаштувань поруч з адресним рядком, відкрийте налаштування сайту й очистіть кукі та дані сайту лише для цього домену.
Спробуйте вікно інкогніто чи приватного перегляду. Це виключає розширення браузера чи збережену кукі як причину, не торкаючись вашого звичайного профілю.
Спробуйте іншу мережу, наприклад мобільний інтернет замість Wi-Fi. Деякі корпоративні проксі чи проксі на рівні провайдера переписують запити так, що це створює цикл лише в тій мережі.
Очистіть кеш браузера на випадок, якщо саму відповідь перенаправлення закешували ще до того, як сайт виправили.

Якщо ви керуєте сайтом

Звірте режим SSL вашого CDN із правилом перенаправлення origin-сервера. У Cloudflare відкрийте SSL/TLS і встановіть режим на Full чи Full (strict), а не Flexible, щоразу, коли origin-сервер перенаправляє HTTP на HTTPS. Full усе ще дозволяє origin-серверу використовувати самопідписаний сертифікат; Full (strict) вимагає валідного.
Довіряйте заголовку переданого протоколу замість сліпого перенаправлення. Коли перед вашим застосунком стоїть проксі, origin-сервер має перенаправляти на основі X-Forwarded-Proto, а не сирого з'єднання, яке завжди виглядає як HTTP з-за проксі. На nginx:
```
if ($http_x_forwarded_proto = "http") {
    return 301 https://$host$request_uri;
}
```
і переконайтеся, що CDN чи балансувальник навантаження справді встановлює цей заголовок на кожному запиті.
Перевірте свої правила перенаправлення по порядку, включно з .htaccess, блоками server у nginx, проміжним ПЗ на рівні застосунку й будь-якими правилами сторінок CDN, на два правила, що вказують одне на одного. Поширений патерн Apache, що зациклюється за проксі:
```
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```
провалюється так само, як випадок з nginx вище, оскільки %{HTTPS} читає з'єднання, яке робить проксі, а не те, що зробив відвідувач; перевіряйте натомість %{HTTP:X-Forwarded-Proto}.
Виправте URL-адресу сайту WordPress, якщо це застосовно: у wp-admin > Settings > General підтвердьте, що і WordPress Address, і Site Address збігаються з URL-адресою, яку справді використовують відвідувачі, включно з протоколом. Якщо сама панель адміністратора недоступна через цикл, встановіть WP_HOME і WP_SITEURL напряму в wp-config.php.
Оберіть одну канонічну форму й перенаправляйте на неї все інше один раз, а не ланцюжком: www чи non-www, кінцевий слеш чи ні, одне правило на рішення, а не кілька правил, накладених різними інструментами з часом.
Очистіть кеш CDN після виправлення правила, оскільки закешований 301 чи 302 продовжує надсилати стару відповідь, доки вона не закінчиться чи її не очистять.

Пов'язані помилки

Коди статусу перенаправлення 3xx пояснює, що означають 301, 302, 303, 307 і 308.
301 проти 302 охоплює, коли перенаправлення має бути постійним, а коли тимчасовим, що важливо для пошукових систем і кешування, а не лише для циклів.

Як запобігти ERR_TOO_MANY_REDIRECTS

Цикл перенаправлень майже завжди виникає через зміну конфігурації: новий CDN, новий SSL-сертифікат, оновлення плагіна чи міграцію, що торкнулася URL-адреси сайту. HTTP-перевірка, що стежить за кодом відповіді й іде за перенаправленнями за розкладом, ловить цикл тієї миті, коли він з'являється, з понад 300 контрольних точок у 158 містах, а не чекає на звернення в підтримку. HostTracker моніторить вебсайти з 2004 року й може сповіщати електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами тієї миті, коли перевірка почне провалюватися.

Часті запитання

Скільки перенаправлень браузер дозволяє, перш ніж здатися?

Chrome та браузери на основі Chromium зупиняються приблизно на 20. Ліміт curl за замовчуванням із -L - 50. Точна цифра відрізняється залежно від клієнта, але будь-який з них врешті-решт зупиниться, а не піде за циклом вічно.

Чому цикл трапляється саме одразу після переходу на Cloudflare (чи інший CDN)?

Майже завжди через режим SSL/TLS. Режим Flexible говорить з origin-сервером звичайним HTTP; якщо origin-сервер наполягає на HTTPS, обидві сторони перенаправляють одна одну нескінченно. Перемикання на Full чи Full (strict) зазвичай вирішує це одразу.

Чи може розширення браузера це спричинити?

Так, особливо розширення, що примусово вмикають HTTPS, переписують запити чи керують кукі. Тестування у вікні інкогніто з вимкненими розширеннями швидко це виключає.

Чи впливає це на SEO?

Так. Краулери пошукових систем здаються на циклі перенаправлень так само, як браузер, і URL-адреса, що зациклюється, не потрапить в індекс чи випаде з нього, якщо раніше працювала.

Я бачу помилку лише на одній конкретній сторінці, а не на всьому сайті. Що в ній інакше?

Перевірте правило, специфічне для сторінки: сторінку, що вимагає входу, закешоване старе перенаправлення саме для цієї URL-адреси чи невідповідність кінцевого слеша, що існує лише на цьому маршруті. Порівняйте точний ланцюжок перенаправлень для цієї URL-адреси з робочою сторінкою за допомогою curl -sIL.

Чи потрібно виправляти одне перенаправлення (наприклад, non-www на www)?

Ні, одне перенаправлення саме по собі нормальне й очікуване. Проблема, яку описує ця помилка, - лише повторюваний ланцюжок, що ніколи не досягає фінальної відповіді 200.