Как исправить бесконечный цикл редиректов

Бесконечный цикл редиректов (redirect loop) — ситуация, когда браузер переходит по цепочке URL, которая замыкается сама на себя. В результате страница не загружается, пользователь видит ошибку «Слишком много редиректов» или «ERR_TOO_MANY_REDIRECTS». В этой статье разберём причины и способы устранения.

Как работает redirect loop

Цикл возникает, когда:

1. URL A редиректит на URL B
2. URL B редиректит на URL A (или на другой URL, который в итоге ведёт на A)

Браузеры ограничивают длину цепочки (обычно 20–30 редиректов) и прерывают загрузку.

Типичные причины

Причина	Сценарий
Конфликт HTTP/HTTPS и www	Правила редиректят друг на друга
Неправильный порядок правил	Правило для HTTPS срабатывает на HTTP-запросе и наоборот
Прокси/балансировщик	Заголовок X-Forwarded-Proto не передаётся, сервер не видит HTTPS
Кэш/плагины	Устаревшие правила в кэше или конфликт плагинов
Cookie/сессия	Редирект на логин, логин редиректит обратно

Диагностика

1. Просмотр цепочки редиректов

Используйте инструмент проверки редиректов reChecker. Введите URL и посмотрите цепочку. Если в цепочке повторяется один и тот же URL — это цикл.

2. Проверка через curl

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

Флаг -I — только заголовки, -L — следовать редиректам. Ищите повторяющиеся Location:.

3. Режим инкогнито

Откройте сайт в режиме инкогнито (без расширений и cookies). Если цикл исчезает — проблема в cookies или расширениях.

Сценарий 1: HTTP/HTTPS и www

Проблема: правила для www и HTTPS редиректят друг на друга.

Неправильный порядок в .htaccess:

# Плохо: www редиректит на https://example.com, но правило HTTPS может сработать неверно
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

При запросе http://www.example.com первое правило даёт https://example.com. Второе правило не должно срабатывать для HTTPS. Но если HTTPS не передаётся корректно (например, за прокси), сервер может считать запрос HTTP и редиректить снова.

Решение: Убедиться, что за прокси/балансировщиком передаётся X-Forwarded-Proto: https. В Apache:

# Для работы за прокси
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Правильный порядок для Apache

RewriteEngine On
RewriteBase /

# 1. HTTP → HTTPS (с учётом прокси)
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# 2. www → без www (только для HTTPS)
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [L,R=301]

Сценарий 2: Прокси (Nginx, Cloudflare, Load Balancer)

Сервер получает запрос по HTTP (прокси терминирует SSL), но пользователь обращается по HTTPS. Нужно доверять заголовку X-Forwarded-Proto.

Nginx перед приложением

# Передавать в backend
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Apache за прокси

В .htaccess или конфиге:

SetEnvIf X-Forwarded-Proto "https" HTTPS=on

Или в RewriteCond:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Cloudflare

Режим SSL должен быть Full или Full (strict). Cloudflare передаёт X-Forwarded-Proto: https для HTTPS-запросов.

Сценарий 3: WordPress

Причина 1: Неверный URL в настройках

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

• Адрес WordPress (URL) и Адрес сайта (URL) должны быть https://example.com (без www, если канонический домен без www).

Если указан http://, WordPress может редиректить на HTTPS при включённом принудительном SSL, а сервер — обратно на HTTP.

Причина 2: Плагин Really Simple SSL

Плагин добавляет редирект и правит mixed content. Если сервер уже редиректит HTTP → HTTPS, возможен конфликт. Решение: отключить редирект в плагине и оставить его только на уровне Apache/Nginx, или наоборот — отключить редирект в .htaccess и оставить плагин.

Причина 3: FORCE_SSL_ADMIN

В wp-config.php:

define('FORCE_SSL_ADMIN', true);

Если сайт доступен по HTTPS, это нормально. Если SSL настроен некорректно (например, сертификат только для www, а канонический домен без www), может возникнуть цикл. Проверьте, что сертификат покрывает оба варианта домена.

Сценарий 4: Nginx — дублирование правил

# Плохо: оба server-блока могут ловить один и тот же запрос
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ... конфиг
    if ($scheme = http) {
        return 301 https://$host$request_uri;
    }
}

Проблема: if внутри location или server может вести себя неожиданно. Используйте отдельные server-блоки для HTTP и HTTPS.

Правильно:

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

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

server {
    listen 443 ssl;
    server_name example.com;
    # ... основной конфиг
}

Чек-лист устранения

1. Проверить цепочку редиректов в инструменте reChecker
2. Убедиться, что за прокси передаётся X-Forwarded-Proto
3. Проверить порядок правил: сначала HTTP → HTTPS, затем www → без www
4. В WordPress — проверить URL в настройках и отключить дублирующий редирект в плагинах
5. Очистить кэш браузера, CDN, Cloudflare
6. Временно отключить плагины кэширования и редиректов для диагностики

Итог

Redirect loop чаще всего возникает из-за конфликта правил HTTP/HTTPS и www или из-за некорректной передачи X-Forwarded-Proto за прокси. Проверьте цепочку редиректов, настройте правильный порядок правил и убедитесь, что прокси и приложение согласованы в определении протокола.