Ошибка Too Many Redirects: что означает и как исправить Печать

Ошибка Too Many Redirects означает, что сайт постоянно перенаправляет браузер с одного URL на другой, но в итоге так и не открывает нужную страницу.

Вместо загрузки сайта браузер попадает в бесконечный цикл редиректов.

В зависимости от браузера ошибка может отображаться как:

ERR_TOO_MANY_REDIRECTS

или:

Эта страница не работает
Сайт перенаправил вас слишком много раз

В Firefox может появиться сообщение о том, что страница перенаправляется таким образом, что запрос никогда не будет завершен.

Чаще всего проблема возникает из-за конфликтующих правил редиректа, неправильной настройки HTTPS, Cloudflare, WordPress, reverse proxy или конфигурации веб-сервера.

Как возникает цикл редиректов

Обычный редирект выглядит так:

http://example.com
        ↓
https://example.com
        ↓
Страница сайта

Браузер получает перенаправление, переходит на новый адрес и открывает страницу.

При циклическом редиректе ситуация выглядит иначе:

http://example.com
        ↓
https://example.com
        ↓
http://example.com
        ↓
https://example.com
        ↓
...

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

Еще один распространенный вариант:

https://example.com
        ↓
https://www.example.com
        ↓
https://example.com
        ↓
https://www.example.com
        ↓
...

В обоих случаях сервер так и не возвращает саму страницу сайта.

Основные причины ошибки Too Many Redirects

У этой ошибки нет одной конкретной причины. На практике чаще всего встречаются:

• неправильный редирект с HTTP на HTTPS;

• конфликтующие правила в Nginx или Apache;

• неправильный режим SSL в Cloudflare;

• использование Flexible SSL вместе с принудительным HTTPS на сервере;

• неправильные URL в WordPress;

• несовпадение значений home и siteurl;

• некорректные правила в .htaccess;

• несколько плагинов, управляющих редиректами;

• неправильная настройка canonical URL;

• ошибки в конфигурации reverse proxy;

• неправильная обработка заголовка X-Forwarded-Proto;

• конфликт между www и обычным доменом;

• закешированные старые редиректы;

• cookies или кеш браузера.

Самый быстрый способ разобраться с проблемой — определить, куда именно сервер перенаправляет запрос и какой компонент создает этот редирект.

Проверьте цепочку редиректов

Первое, что стоит сделать, — посмотреть, какой ответ реально возвращает сервер.

На Linux выполните:

curl -I https://example.com

В ответе может быть:

HTTP/2 301
location: https://www.example.com/

Теперь проверьте адрес, на который произошло перенаправление:

curl -I https://www.example.com/

Если сервер снова отвечает:

HTTP/2 301
location: https://example.com/

значит, вы нашли цикл.

Можно сразу попросить curl пройти всю цепочку редиректов:

curl -IL https://example.com

Например:

https://example.com
→ https://www.example.com
→ https://example.com
→ https://www.example.com

Такой вывод сразу показывает, какие URL перенаправляют друг на друга.

Проверьте редирект с HTTP на HTTPS

Одна из самых распространенных причин — неправильная настройка HTTPS.

В нормальной конфигурации должно быть:

http://example.com
        ↓
https://example.com

После этого HTTPS-версия должна открываться без дополнительного перенаправления.

Проверьте HTTP:

curl -I http://example.com

Обычно ответ выглядит примерно так:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Теперь проверьте HTTPS:

curl -I https://example.com

Вместо нового редиректа сервер должен вернуть страницу или обычный HTTP-ответ.

Если HTTPS снова перенаправляет на HTTP, скорее всего, в конфигурации есть конфликтующее правило.

Проверьте конфигурацию Nginx

Если сайт работает через Nginx, сначала посмотрите активную конфигурацию:

nginx -T

Команда выводит полную конфигурацию Nginx, которую сервер использует в данный момент.

Ищите правила вроде:

return 301 https://$host$request_uri;

или:

return 301 http://$host$request_uri;

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

Также проверьте, нет ли нескольких server-блоков, которые одновременно обрабатывают один и тот же домен.

Например, нормальная конфигурация может выглядеть так:

server {
    listen 80;
    server_name example.com;

    return 301 https://example.com$request_uri;
}

И отдельно:

server {
    listen 443 ssl;
    server_name example.com;

    ...
}

Проблема возникает, если HTTPS-конфигурация дополнительно отправляет запрос обратно на HTTP или на другой hostname.

После изменения конфигурации обязательно выполните:

nginx -t

Если проверка прошла успешно:

systemctl reload nginx

Проверьте Apache и .htaccess

На Apache правила перенаправления часто находятся в файле .htaccess.

Например, редирект HTTP → HTTPS может выглядеть так:

RewriteEngine On

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

Само по себе такое правило обычно не вызывает проблем.

Но ситуация меняется, если перед Apache находится Cloudflare или другой reverse proxy, который принимает HTTPS-соединение, а на сервер отправляет обычный HTTP-запрос.

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

Получается цикл:

Пользователь
    ↓ HTTPS
Cloudflare
    ↓ HTTP
Apache
    ↓ HTTPS redirect
Cloudflare
    ↓ HTTP
Apache
    ↓
...

Проверьте .htaccess:

cat /var/www/html/.htaccess

Путь к файлу зависит от расположения сайта.

Особое внимание уделите:

RewriteRule
RewriteCond
Redirect
RedirectMatch

и правилам, которые меняют http на https, добавляют или удаляют www.

Проверьте настройки SSL в Cloudflare

Cloudflare — одна из распространенных причин циклических редиректов.

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

Flexible

а origin-сервер настроен на принудительный HTTPS.

В таком случае схема может выглядеть следующим образом:

Пользователь
   ↓ HTTPS
Cloudflare
   ↓ HTTP
Origin-сервер
   ↓
Редирект на HTTPS
   ↓
Cloudflare
   ↓ HTTP
Origin-сервер
   ↓
Редирект на HTTPS
   ↓
...

Пользователь в результате получает Too Many Redirects.

Если на origin-сервере установлен SSL-сертификат, проверьте:

Cloudflare → SSL/TLS → Overview

Для корректно настроенного сервера обычно используют Full или Full (strict).

Если сертификат на origin-сервере действительный и доверенный, предпочтительным вариантом обычно является Full (strict).

Проверьте Always Use HTTPS в Cloudflare

Cloudflare также может самостоятельно перенаправлять HTTP-запросы на HTTPS.

Само по себе это нормально.

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

Проверьте:

Cloudflare → SSL/TLS → Edge Certificates

и настройки, связанные с HTTPS.

Также проверьте правила в разделе Rules, особенно если ранее создавались собственные редиректы.

В нормальной конфигурации должен быть простой путь:

HTTP → HTTPS → Сайт

а не:

HTTP → HTTPS → HTTP → HTTPS

Проверьте URL в WordPress

WordPress особенно чувствителен к неправильной настройке URL.

Основные адреса сайта находятся в:

Настройки → Общие

Параметры:

• Адрес WordPress (URL)

• Адрес сайта (URL)

Для HTTPS-сайта они обычно должны выглядеть так:

https://example.com

а не:

http://example.com

Также необходимо проверить использование www.

Например, это две разные конфигурации:

https://example.com

и:

https://www.example.com

Нужно выбрать один основной вариант и перенаправлять остальные на него.

Не следует одновременно настраивать WordPress на один адрес, а Nginx, Apache или Cloudflare — на другой.

Проверьте значения WordPress в базе данных

Если административная панель WordPress недоступна, URL можно проверить непосредственно в базе данных.

Выполните:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Обычно значения должны выглядеть примерно так:

siteurl  | https://example.com
home     | https://example.com

Префикс таблицы может отличаться от wp_.

При необходимости значения можно изменить:

UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'siteurl';

UPDATE wp_options
SET option_value = 'https://example.com'
WHERE option_name = 'home';

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

Проверьте wp-config.php

URL WordPress также могут быть заданы непосредственно в wp-config.php.

Проверьте наличие:

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

Эти параметры имеют приоритет над соответствующими значениями в базе данных.

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

Например:

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

при включенном HTTPS на Cloudflare и сервере может привести к постоянным перенаправлениям.

Проверьте определение HTTPS за Cloudflare

Еще одна распространенная проблема возникает, когда WordPress работает за Cloudflare.

Пользователь подключается к Cloudflare по HTTPS, но Cloudflare может установить соединение с origin-сервером по HTTP.

В результате WordPress может ошибочно считать, что пользователь использует HTTP.

При определенных настройках это приводит к повторному редиректу на HTTPS.

Для передачи этой информации приложение может использовать заголовок:

X-Forwarded-Proto: https

В некоторых конфигурациях WordPress необходимо дополнительно указать, что HTTPS определяется через этот заголовок:

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

Добавлять такой код следует только в том случае, если сайт действительно находится за доверенным reverse proxy и заголовок корректно передается.

Не стоит копировать подобные настройки без проверки фактической схемы подключения.

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

Циклический редирект иногда создают плагины.

Особенно часто это происходит с плагинами, которые отвечают за:

• SSL;

• редиректы;

• кеширование;

• безопасность;

• canonical URL;

• SEO;

• CDN.

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

Если админ-панель WordPress недоступна, можно временно отключить все плагины:

mv wp-content/plugins wp-content/plugins_backup

Проверьте сайт.

Если ошибка исчезла, верните каталог:

mv wp-content/plugins_backup wp-content/plugins

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

Проверьте www и обычный домен

Еще один распространенный вариант — конфликт между www и обычным доменом.

Например, одно правило говорит:

example.com
→ www.example.com

а другое:

www.example.com
→ example.com

Каждое правило по отдельности работает нормально, но вместе они создают бесконечный цикл.

Выберите один основной hostname.

Например:

https://example.com

Тогда остальные варианты должны перенаправляться только на него:

http://example.com
→ https://example.com

http://www.example.com
→ https://example.com

https://www.example.com
→ https://example.com

Сам основной URL:

https://example.com

уже не должен перенаправлять пользователя на другой адрес.

Проверьте reverse proxy

Если перед приложением используется Nginx, HAProxy, балансировщик или другой reverse proxy, проверьте передачу информации о протоколе.

Обычно используется заголовок:

X-Forwarded-Proto: https

Backend должен понимать, что первоначальное подключение пользователя было выполнено по HTTPS.

Если proxy принимает HTTPS, а приложение считает каждый запрос HTTP, оно может постоянно отправлять пользователя обратно на HTTPS.

Проблема особенно часто встречается с:

• WordPress;

• Laravel;

• Django;

• Node.js;

• приложениями за load balancer.

Точная настройка зависит от используемого приложения и reverse proxy.

Проверьте правила редиректов самого приложения

Помимо веб-сервера, редиректы могут выполняться непосредственно приложением.

Например:

Приложение
   ↓
HTTPS redirect
   ↓
Nginx
   ↓
HTTPS redirect
   ↓
Cloudflare
   ↓
HTTPS redirect

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

Чем больше таких правил, тем выше вероятность конфликта.

Очистите cookies и кеш браузера

Иногда сервер уже настроен правильно, но браузер продолжает использовать старую информацию о перенаправлениях или cookies.

Для проверки откройте сайт в режиме инкогнито.

Также можно удалить cookies для конкретного домена.

Если в приватном окне сайт открывается нормально, возможно, проблема уже устранена на сервере.

Однако очистку кеша браузера не стоит использовать как первый способ диагностики. Сначала лучше проверить реальную цепочку редиректов через curl.

Проверьте кешированные редиректы

Старый редирект может быть сохранен в:

• Cloudflare;

• CDN;

• плагине кеширования;

• reverse proxy;

• браузере.

Особенно часто это происходит после изменения:

• HTTP → HTTPS;

• настроек домена;

• Cloudflare Rules;

• URL WordPress;

• .htaccess;

• конфигурации Nginx.

После исправления конфигурации очистите соответствующий кеш.

Если используется Cloudflare, выполните очистку кеша в панели управления.

Также очистите кеш WordPress, если на сайте установлен соответствующий плагин.

Проверьте ответ сервера через curl

Для подробной проверки используйте:

curl -IL https://example.com

Можно проверить и конкретную страницу:

curl -IL https://example.com/test

Смотрите на каждый заголовок:

Location:

Например:

HTTP/2 301
location: https://www.example.com/test

HTTP/2 301
location: https://example.com/test

HTTP/2 301
location: https://www.example.com/test

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

Проверьте origin-сервер без Cloudflare

Если есть подозрение на Cloudflare, полезно проверить origin-сервер напрямую.

Конкретный способ зависит от вашей инфраструктуры.

Например, можно отправить запрос на IP origin-сервера, указав нужный hostname:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Замените 203.0.113.10 на IP вашего origin-сервера.

Так можно сравнить ответ origin-сервера с ответом, который пользователь получает через Cloudflare.

Если напрямую origin работает нормально, а через Cloudflare возникает цикл, ищите проблему в настройках Cloudflare.

Если оба варианта дают одинаковый результат, проблема, скорее всего, находится на origin-сервере или непосредственно в приложении.

Практический порядок диагностики

При возникновении Too Many Redirects удобно проверять систему в следующем порядке:

1. Цепочка редиректов
        ↓
2. Cloudflare
        ↓
3. Nginx / Apache
        ↓
4. WordPress / приложение
        ↓
5. Reverse proxy
        ↓
6. Плагины и правила редиректов
        ↓
7. Кеш

Начните с:

curl -IL https://example.com

Посмотрите, какой URL постоянно появляется в заголовке Location:.

После этого определите, какой именно компонент создает этот редирект.

Когда источник найден, исправление обычно занимает гораздо меньше времени.

Быстрый список проверок

Если появляется ошибка Too Many Redirects, проверьте:

1. Корректно ли HTTP перенаправляется на HTTPS.

2. Не перенаправляет ли HTTPS обратно на HTTP.

3. Не перенаправляют ли www и обычный домен друг на друга.

4. Режим SSL/TLS в Cloudflare.

5. Настройки HTTPS в Cloudflare.

6. Cloudflare Rules.

7. Конфигурацию Nginx.

8. Apache и .htaccess.

9. Значения home и siteurl в WordPress.

10. WP_HOME и WP_SITEURL в wp-config.php.

11. Заголовок X-Forwarded-Proto.

12. Плагины SSL и редиректов.

13. Кешированные редиректы.

14. Cookies и кеш браузера.

15. Фактическую цепочку редиректов через curl.

Как избежать циклических редиректов

URL-структуру сайта лучше делать максимально простой.

Сначала определите основной URL, например:

https://example.com

Затем все остальные варианты должны перенаправляться только на него:

http://example.com
http://www.example.com
https://www.example.com
        ↓
https://example.com

Основной URL не должен делать дополнительный редирект.

Также не стоит одновременно заставлять Cloudflare, Nginx, .htaccess, WordPress и несколько плагинов независимо управлять одними и теми же перенаправлениями, если в этом нет необходимости.

Каждый дополнительный уровень увеличивает вероятность появления конфликтующих правил.