Основні причини та способи усунення помилки “Забагато перенаправлень”

Помилка "Too Many Redirects" — що відображається в браузерах як ERR_TOO_MANY_REDIRECTS і відповідає HTTP-циклу перенаправлень — виникає, коли веб-сервер і клієнт потрапляють у кругову ланцюжок перенаправлень, яка ніколи не вирішується до кінцевого пункту призначення. Браузер перериває запит після перевищення порогу перенаправлень (зазвичай 20 переходів у Chrome) і відображає цю помилку замість завантаження сторінки.

Це не розмита мережева помилка. Це детермінований збій, спричинений конкретною неправильною конфігурацією у правилах сервера, налаштуваннях SSL, значеннях бази даних CMS, конфігурації CDN або кешованих даних перенаправлень. Кожен випадок має відстежувану першопричину, і кожна першопричина має точне виправлення. Цей посібник розглядає всі з них з технічною глибиною, необхідною для остаточного вирішення проблеми — незалежно від того, чи запускаєте ви сайт на WordPress, власний застосунок або чистий серверний стек у середовищі VPS Хостингу.

Що насправді відбувається під час циклу перенаправлень

Коли браузер запитує URL, сервер може відповісти кодом стану 301 Moved Permanently, 302 Found або 307 Temporary Redirect, що вказує на нове місцезнаходження. Браузер переходить за цим заголовком місцезнаходження, робить інший запит і очікує відповіді 200 OK на якомусь етапі ланцюжка.

Цикл перенаправлень утворюється, коли:

• URL A перенаправляє на URL B, а URL B перенаправляє назад на URL A (двоетапний цикл)
• URL A перенаправляє на URL B, який перенаправляє на URL C, який перенаправляє назад на URL A (багатоетапний цикл)
• Один URL перенаправляє сам на себе (самореференційний цикл)

Браузери не циклюються нескінченно. Chrome і Firefox обидва завершують роботу приблизно після 20 перенаправлень і відображають ERR_TOO_MANY_REDIRECTS. Safari показує "Safari Can't Open the Page." Базова поведінка HTTP однакова у всіх них.

Першопричини та точні виправлення

1. Неправильно налаштовані правила перенаправлень у .htaccess або Nginx

Найбільш технічно поширеною причиною є конфліктуючі або кругові правила перезапису на рівні конфігурації сервера.

Приклад зламаного циклу в Apache .htaccess:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Це правило перенаправляє /page на /page — самореференційний цикл. Аналогічно, два правила, що перенаправляють між /old-url та /new-url у протилежних напрямках, спричинять той самий збій.

Як діагностувати:

Відкрийте файл .htaccess і вручну простежте кожну директиву RewriteRule та Redirect. Шукайте будь-яке правило, де цільовий шаблон може збігатися з джерелом іншого правила.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Для Nginx аналогічна проблема з’являється в блоках server або location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Перевірте конфігурацію Nginx за допомогою:

nginx -T | grep -A3 "return 301|rewrite"

Виправлення: Переконайтеся, що кожне правило перенаправлення має унікальне, неперекривне джерело та призначення. Використовуйте прапорець [L] в Apache, щоб зупинити обробку правил після знаходження збігу. У Nginx надавайте перевагу return 301 над rewrite для ясності та уникнення ненавмисного ланцюжка.

2. Неправильна конфігурація перенаправлення HTTP на HTTPS

Це найпоширеніша причина в сучасних хостингових середовищах, особливо після додавання SSL-сертифіката без оновлення конфігурації на рівні застосунку.

Схема збою виглядає так:

• Веб-сервер примусово перенаправляє весь HTTP-трафік на HTTPS через .htaccess або конфігурацію Nginx
• Застосунок (наприклад, WordPress) має параметр siteurl або home встановлений на http:// в базі даних
• Застосунок потім перенаправляє HTTPS-запити назад на HTTP
• Цикл: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Правильне перенаправлення HTTPS в Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Правильне перенаправлення HTTPS в Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Критична пастка: Якщо ви знаходитесь за балансувальником навантаження або зворотним проксі (включаючи Cloudflare), бекенд-сервер може не бачити HTTPS безпосередньо. Проксі завершує SSL і пересилає запит як HTTP на ваш сервер-джерело. Ваш сервер тоді бачить %{HTTPS} = off і знову перенаправляє на HTTPS — створюючи цикл.

Виправлення полягає в перевірці заголовка X-Forwarded-Proto натомість:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Невідповідність режиму SSL між Cloudflare та CDN

Якщо ви використовуєте Cloudflare або інший CDN перед вашим сервером-джерелом, режим шифрування SSL/TLS повинен відповідати фактичному стану сертифіката вашого джерела.

Найпоширеніший сценарій циклу Cloudflare: Режим SSL встановлено на Flexible, а сервер-джерело має правило .htaccess, що примусово перенаправляє HTTP на HTTPS. Cloudflare надсилає HTTP до джерела, джерело перенаправляє на HTTPS, Cloudflare отримує це перенаправлення, знову надсилає HTTP — нескінченний цикл.

Виправлення: Встановіть режим SSL Cloudflare на Full (Strict) і переконайтеся, що ваше джерело має дійсний сертифікат. Або, якщо ви повинні використовувати Flexible, повністю видаліть перенаправлення HTTP→HTTPS з вашого сервера-джерела і дозвольте Cloudflare обробляти його через Page Rule або перемикач "Always Use HTTPS".

Також вимкніть Automatic HTTPS Rewrites у Cloudflare, якщо ваше джерело вже обробляє перенаправлення — наявність обох активних подвоює логіку перенаправлень.

4. Невідповідність налаштувань URL WordPress

WordPress зберігає свої канонічні URL у двох полях бази даних: siteurl (URL встановлення ядра WordPress) та home (публічний URL). Коли ці значення конфліктують з правилами перенаправлень сервера або між собою, цикл майже неминучий.

Перевірте поточні значення через WP-CLI:

wp option get siteurl
wp option get home

Або запитайте базу даних безпосередньо:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Обидва значення повинні використовувати однаковий протокол (https://) та однаковий формат домену (з або без www), який застосовує ваша конфігурація сервера.

Виправлення через WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Виправлення через wp-config.php (перевизначає значення бази даних, корисно при відсутності доступу до адмін-панелі):

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

Конфлікти плагінів: Плагіни керування перенаправленнями (Redirection, Simple 301 Redirects, модуль перенаправлень Yoast SEO) можуть створювати збережені в базі даних правила перенаправлень, що конфліктують з правилами на рівні сервера. Тимчасово перейменуйте директорію плагінів для ізоляції проблеми:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Повторно вмикайте плагіни по одному після підтвердження зникнення циклу.

5. Кеш браузера та кешовані перенаправлення 301

Браузери агресивно кешують відповіді 301 Moved Permanently — за задумом. Якщо перенаправлення 301 раніше було надано для URL, а потім ціль перенаправлення змінилася, браузер може все ще слідувати старому кешованому перенаправленню, яке може вказувати на тепер циклічне призначення.

Це особливо оманливий сценарій, оскільки цикл може не відтворюватися у свіжому браузері або на іншому пристрої, що змушує адміністраторів помилково вважати, що сервер в порядку.

Кроки діагностики:

1. Відкрийте URL у вікні інкогніто/приватному вікні (без кешованих даних)
2. Тестуйте з curl для повного обходу кешування браузера:

curl -I -L --max-redirs 10 https://example.com

1. Використовуйте онлайн-трасувальник ланцюжка перенаправлень (наприклад, redirect-checker.org або httpstatus.io), щоб побачити кожен перехід на стороні сервера

Виправлення: Очистіть кеш браузера та файли cookie для ураженого домену. У Chrome: Налаштування > Конфіденційність та безпека > Очистити дані перегляду > виберіть Кешовані зображення та файли + Файли cookie.

Для кешування на стороні сервера (Varnish, Redis, OPcache або плагін кешування, як W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Конфлікти перенаправлень www та не-www

Часто overlooked джерелом циклів перенаправлень є непослідовна обробка субдомену www. Якщо ваш сервер перенаправляє www.example.com на example.com і одночасно перенаправляє example.com на www.example.com, у вас є цикл.

Перевірте поточну конфігурацію DNS та перенаправлень:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Правильна конфігурація Apache (канонічний non-www):

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

Переконайтеся, що це правило не поєднане з іншим правилом, яке перенаправляє версію без www назад на www.

7. Пошкоджені або конфліктуючі файли cookie

Деякі застосунки використовують файли cookie для керування станом перенаправлень (наприклад, перенаправлення після входу, визначення локалі, фреймворки A/B-тестування). Якщо файл cookie зберігає ціль перенаправлення, яка сама по собі ініціює інше перенаправлення, цикл керується логікою застосунку, а не конфігурацією сервера.

Діагностика: Протестуйте URL з усіма очищеними файлами cookie для цього домену. У Chrome DevTools (F12) перейдіть до Application > Storage > Cookies, виберіть домен і видаліть усі записи. Перезавантажте сторінку.

Якщо помилка зникає після очищення файлів cookie, проблема в логіці сесії або перенаправлень вашого застосунку, а не в конфігурації сервера.

Порівняння: Поширені сценарії циклів перенаправлень та їх виправлення

Систематичний робочий процес діагностики

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

Крок 1 — Відтворіть без кешу:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Це показує кожен перехід перенаправлення та кінцевий код відповіді. Якщо ви бачите повторення одних і тих самих URL, ви підтвердили цикл і визначили, які URL задіяні.

Крок 2 — Перевірте журнали помилок сервера:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Крок 3 — Ізолюйте рівень:

• Якщо цикл зникає при коментуванні правил .htaccess, проблема в конфігурації Apache
• Якщо він зникає при обході Cloudflare (тестування через пряму IP), проблема в налаштуваннях CDN
• Якщо він зникає при перейменуванні директорії плагінів, проблема в плагіні WordPress
• Якщо він зникає в режимі інкогніто, але не в звичайному режимі, проблема в кеші браузера або файлах cookie

Крок 4 — Перевірте прив’язку SSL-сертифіката:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Недійсний або невідповідний сертифікат може спричиняти збої перенаправлення HTTPS, що проявляються як цикли.

Запобігання циклам перенаправлень у виробничому середовищі

Після вирішення ці практики запобігають повторенню:

• Використовуйте єдине канонічне правило перенаправлення, яке обробляє і HTTP→HTTPS, і www→non-www за один прохід, а не два окремі правила, що можуть взаємодіяти
• Тестуйте ланцюжки перенаправлень перед розгортанням за допомогою curl -L або онлайн-перевірника перенаправлень після будь-яких змін конфігурації
• Встановлюйте перенаправлення 301 лише коли вони постійні — використовуйте 302 під час тестування, щоб браузери не кешували перенаправлення
• Документуйте кожне правило перенаправлення у вашому .htaccess або конфігурації Nginx з вбудованими коментарями, що пояснюють намір
• Моніторте за допомогою інструментів uptime, які відстежують ланцюжки перенаправлень і сповіщають, коли кількість переходів перевищує поріг

Для команд, що керують кількома сайтами на VPS з cPanel, модуль Redirects у cPanel надає візуальний інтерфейс для керування правилами перенаправлень, але він записує в .htaccess — завжди перевіряйте результат вручну після використання GUI.

Якщо ви керуєте сайтом з високим трафіком або кількома доменами, Виділений сервер надає вам повний контроль над конфігурацією Nginx або Apache на системному рівні, усуваючи обмеження спільного середовища, які можуть ускладнити налагодження перенаправлень.

Для сайтів, що використовують Панелі керування VPS, як Plesk або DirectAdmin, правила перенаправлень можуть керуватися як через інтерфейс панелі, так і безпосередньо у файлах конфігурації — перевіряйте обидва місця, щоб переконатися, що вони не суперечать одне одному.

Технічний контрольний список ключових висновків

Використовуйте це як передпольотний контрольний список при діагностиці ERR_TOO_MANY_REDIRECTS:

• [ ] Запустіть curl -v -L --max-redirs 25 для відображення повного ланцюжка перенаправлень перед зміною будь-якої конфігурації
• [ ] Підтвердіть, що siteurl та home у WordPress відповідають протоколу та домену, який застосовує ваш сервер
• [ ] Перевірте, що режим SSL Cloudflare встановлено на Full (Strict), якщо ваше джерело має дійсний сертифікат
• [ ] Перевірте, що .htaccess або конфігурація Nginx використовує X-Forwarded-Proto замість %{HTTPS} при роботі за проксі
• [ ] Переконайтеся, що перенаправлення www та non-www є однонаправленими — лише одна канонічна форма
• [ ] Тимчасово вимкніть усі плагіни, пов’язані з перенаправленнями, і вмикайте їх по одному
• [ ] Очистіть кеш браузера та протестуйте в режимі інкогніто, щоб виключити кешовані відповіді 301
• [ ] Перевірте файли cookie застосунку на наявність стану перенаправлення, який може керувати циклом
• [ ] Перевірте, що SSL-сертифікат дійсний і правильно прив’язаний до домену
• [ ] Після виправлення тимчасово використовуйте 302 перед переходом на 301, щоб запобігти повторному кешуванню зламаного перенаправлення

FAQ

У чому різниця між ERR_TOO_MANY_REDIRECTS та HTTP-кодом стану 310?

ERR_TOO_MANY_REDIRECTS — це помилка браузера на стороні клієнта, що виникає після перевищення браузером ліміту переходів за перенаправленнями (зазвичай 20). HTTP 310 — це рідко використовуваний код стану, що означає "Too Many Redirects" на рівні протоколу. На практиці майже всі помилки циклу перенаправлень, з якими ви стикаєтесь у виробничому середовищі, є браузерними ERR_TOO_MANY_REDIRECTS — а не відповіддю сервера 310.

Чому цикл перенаправлень з’являється лише в деяких браузерах або на деяких пристроях, але не в інших?

Найпоширенішою причиною є кешоване перенаправлення 301, збережене в браузері, яке вказує на тепер недійсне призначення. Оскільки відповіді 301 кешуються безстроково за замовчуванням, браузер, який раніше відвідував URL, може слідувати застарілому ланцюжку перенаправлень. Тестування в режимі інкогніто або на новому пристрої обходить цей кеш і відображає поточну поведінку сервера.

Як виправити цикл перенаправлень у WordPress, коли я не можу отримати доступ до адмін-панелі?

Додайте наступні рядки безпосередньо до wp-config.php, щоб перевизначити значення URL бази даних, а потім отримайте доступ до адмін-панелі для правильного виправлення налаштувань:

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

Або оновіть значення безпосередньо в базі даних за допомогою wp-cli або прямого MySQL-запиту до таблиці wp_options.

Чи може цикл перенаправлень впливати на рейтинги SEO?

Так. Цикл перенаправлень не повертає відповіді 200 OK, тобто Googlebot не може сканувати або індексувати уражений URL. Якщо цикл впливає на вашу головну сторінку або ключові цільові сторінки, це призведе до деіндексації з часом. Крім того, будь-який 301 ваговий коефіцієнт посилань, що проходить через циклічний URL, фактично втрачається. Швидке вирішення циклу та перевірка можливості сканування в Google Search Console є обов’язковими.

Як запобігти тому, щоб Cloudflare спричиняв цикли перенаправлень з моїм налаштуванням SSL?

Встановіть режим шифрування SSL/TLS Cloudflare на Full (Strict) у панелі SSL/TLS. Це гарантує, що Cloudflare спілкується з вашим джерелом через HTTPS з використанням перевіреного сертифіката, усуваючи цикл HTTP↔HTTPS, який створює режим Flexible, коли сервер-джерело також застосовує HTTPS. Крім того, вимкніть "Automatic HTTPS Rewrites", якщо ваше джерело або .htaccess вже обробляє перенаправлення HTTP на HTTPS, щоб уникнути подвійної логіки перенаправлень.