ERR_TOO_MANY_REDIRECTS: як зупинити нескінченне перенаправлення сайту

Помилка ERRTOOMANY_REDIRECTS виникає, коли браузер отримує нескінченний ланцюг перенаправлень між сторінками або протоколами. Наприклад, сайт може постійно перемикати відвідувача з HTTP на HTTPS і назад, перенаправляти між версіями з www та без нього або зациклювати редирект через налаштування WordPress.

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

Причини циклічних редиректів

Нескінченне перенаправлення з’являється, коли різні компоненти сайту мають суперечливі правила. Найпоширеніші причини:

• у WordPress задані різні адреси для сайту та головної сторінки;
• сервер примусово перенаправляє HTTP на HTTPS, а проксі або CDN передає запит як HTTP;
• у файлі .htaccess є дубльовані або конфліктні правила;
• плагін кешування, безпеки чи редиректів створює власне перенаправлення;
• у CDN увімкнено режим шифрування, несумісний із налаштуваннями хостингу;
• після перенесення сайту залишилися старі правила домену або протоколу;
• пошкоджені налаштування в базі даних чи конфігураційному файлі.

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

HTTP і HTTPS

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

Перевірте, які варіанти адреси використовуються:

• http://example.com;
• https://example.com;
• http://www.example.com;
• https://www.example.com.

Для сайту має бути визначена одна основна адреса, а всі інші варіанти повинні перенаправляти на неї лише один раз. Також перевірте сертифікат SSL, налаштування примусового HTTPS на хостингу та правила у .htaccess або конфігурації Nginx.

Якщо використовується Cloudflare чи інший CDN, важливо зіставити режим шифрування CDN із реальним станом SSL на сервері. Некоректний режим може спричинити цикл навіть тоді, коли сертифікат для відвідувачів працює справно.

WordPress Address та Site Address

У WordPress є два пов’язані параметри: WordPress Address (URL) і Site Address (URL). Перший визначає адресу встановлення WordPress, другий — адресу, за якою відкривається сайт. У типовій конфігурації вони збігаються та мають використовувати однаковий протокол і домен.

Якщо один параметр містить http, а інший https, або в одному вказано www, а в іншому — ні, WordPress може постійно перенаправляти запит. Перевірити значення можна в адміністративній панелі в розділі загальних налаштувань, якщо доступ до неї зберігається.

Коли панель недоступна, адресу іноді тимчасово задають у файлі wp-config.php:

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

Перед редагуванням зробіть копію файлу. Адресу потрібно замінити на фактичний основний домен сайту, без зайвих пробілів і неправильного завершального символу. Якщо значення вже визначені в wp-config.php, не слід дублювати їх — безпечніше спочатку перевірити наявні рядки.

Окремо перевірте плагіни, які керують SSL, канонічними адресами або редиректами. Тимчасове вимкнення підозрілого плагіна може допомогти локалізувати причину, але перед змінами бажано мати резервну копію.

CDN і кеш

Кешування може зберігати старі правила перенаправлення навіть після того, як помилку вже виправлено на сервері. Через це власник сайту бачить старий цикл, хоча поточна конфігурація вже змінилася.

Після виправлення перевірте та за потреби очистьте:

• кеш у CDN або проксі;
• кеш плагіна WordPress;
• серверний кеш хостингу;
• кеш браузера і cookies для домену.

Не варто одразу змінювати кілька параметрів у CDN, WordPress і на сервері. Краще зафіксувати поточні налаштування, змінити один компонент і перевірити результат. Інакше буде складно визначити, яке саме правило спричинило проблему.

Також перевірте, чи не кешуються перенаправлення з надто тривалим терміном дії. Деякі CDN або браузери можуть запам’ятати статус редиректу, тому результат перевіряйте в інкогніто або за допомогою технічної перевірки HTTP-заголовків.

Виправлення без втрати доступу

Безпечна послідовність дій залежить від того, до яких компонентів зберігся доступ. Загалом дійте так:

1. Зробіть резервну копію файлів сайту, бази даних і поточних конфігурацій.
2. Перевірте адресу сайту та основний протокол у WordPress, wp-config.php і базі даних.
3. Тимчасово виключіть вплив CDN або очистьте його кеш, не змінюючи одразу всі правила.
4. Перевірте .htaccess, конфігурацію Nginx або правила редиректів на панелі хостингу.
5. Тимчасово перейменуйте каталог підозрілого плагіна, якщо адміністративна панель недоступна.
6. Очистьте кеш після внесення змін і повторно перевірте всі варіанти домену.

Якщо разом із ERRTOOMANY_REDIRECTS з’являються помилки PHP, білий екран, повідомлення про проблеми з базою даних або код 500, окремо перевірте журнали сервера та стан WordPress. Корисно також ознайомитися з матеріалом Помилка 500 на сайті: причини та способи відновлення.

До спеціаліста варто звернутися, якщо немає доступу до хостингу, незрозуміло працює проксі, змінено DNS, пошкоджено базу даних або редиректи з’явилися після злому чи зараження. У таких випадках численні експерименти без резервної копії можуть ускладнити відновлення. Фахівець спочатку зафіксує поточний стан системи, перевірить логи, ланцюжок перенаправлень і лише після цього внесе контрольовані зміни.