Бесконечный редирект при переходе на HTTPS

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

Редирект с HTTP на HTTPS должен срабатывать только на запросы, пришедшие по HTTP. Цикл возникает, когда веб-сервер или приложение не понимает, что соединение уже защищено. Типичные сценарии: сайт за обратным прокси или CDN (Cloudflare в режиме Flexible), где к серверу запрос приходит по HTTP, а сервер снова перенаправляет на HTTPS; одновременно включены редиректы на нескольких уровнях (nginx, .htaccess, плагин CMS, панель хостинга); в WordPress siteurl и home содержат http://; смешаны www и без www.

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

#Порядок

1. Проследите цепочку редиректов командой curlНа компьютере откройте PowerShell/терминал с curl и выполните curl -IL --max-redirs 10 https://example.com с фактическим доменом. Сравните Location для HTTP и HTTPS, с www и без. Если адреса чередуются, сохраните несколько последовательных ответов: это укажет, какой переход образует цикл.
2. Определите, кто выдаёт каждый редиректВ панели DNS/CDN определите, где завершается шифрованное соединение. При использовании Cloudflare режим Flexible с перенаправлением на HTTPS на исходном сервере может приводить к постоянному циклу. Проверьте реальный сертификат на origin прежде чем переключать режим на Full (strict); при неверном сертификате сначала настройте его.
3. Оставьте редирект на одном уровнеАдминистратор в конфигурации Nginx/Apache найдите правила return 301, rewrite, Redirect и .htaccess; также проверьте CMS/плагины перенаправлений. Запишите действующий канонический URL и решите, на каком одном уровне выполняется окончательное перенаправление. Не вводите сразу несколько взаимных правил для www и HTTPS.
4. Если используется Cloudflare, переключите режим SSL/TLS с Flexible на FullПроверьте настройки адреса сайта в самой CMS: WordPress — «Настройки → Общие», другие движки — раздел основных адресов/конфигурационный файл. Смена http:// на https:// должна соответствовать реальному сертификату, настройкам reverse proxy и правильным заголовкам, передаваемым доверенным прокси. Перед правкой базы сделайте резервную копию.
5. Настройте передачу заголовка X-Forwarded-Proto и его использованиеСохраните прежнюю конфигурацию веб-сервера, измените одно доказанно лишнее правило и выполните nginx -t либо apachectl configtest. Только при успешной проверке примените reload; проверяйте цепочку curl после каждого изменения, чтобы знать, какая именно правка решила проблему.
6. В CMS задайте адрес сайта с https://Если после правки серверной схемы браузер ещё выдаёт цикл, повторите запрос из приватного окна и проверьте cookie/кэш перенаправлений только этого домена. Для HSTS сброс браузера не заменяет действующий HTTPS-сертификат; не отключайте защиту сертификатов и не советуйте посетителям игнорировать предупреждения.
7. Очистите кеш сайта, CDN и браузераВ конце убедитесь, что любой исходный вариант адреса приводит к одному выбранному HTTPS-адресу без возврата к HTTP, а curl -IL заканчивается ответом 200 или другим ожидаемым кодом страницы. Если цикл сохраняется только через CDN, сравните заголовки на origin и прокси и передайте диагностику их администраторам.
8. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Цепочка редиректов

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Цепочка редиректов

   curl -sIL --max-redirs 10 http://example.ru/ | grep -iE "^HTTP|^location|^server"

   Вариант 2Прокси передаёт схему, приложение определяет HTTPS (nginx перед PHP-FPM)

   NginxКомандаКопировать всёВыделить

   Прокси передаёт схему, приложение определяет HTTPS (nginx перед PHP-FPM)

   server {

   listen 443 ssl http2;

   server_name example.ru;

   location ~ \.php$ {

   fastcgi_pass unix:/run/php/php8.2-fpm.sock;

   include fastcgi_params;

   fastcgi_param HTTPS on;

   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

   }

   }

   Вариант 3WordPress за прокси/CDN: считать соединение защищённым, если прокси передал заголовок

   PHPКомандаКопировать всёВыделить

   WordPress за прокси/CDN: считать соединение защищённым, если прокси передал заголовок

   if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {

   $_SERVER['HTTPS'] = 'on';

   }

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

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

   Вариант 4Редирект на HTTPS с учётом прокси (Apache; не используйте вместе с редиректом на другом уровне)

   ТекстКомандаКопировать всёВыделить

   Редирект на HTTPS с учётом прокси (Apache; не используйте вместе с редиректом на другом уровне)

   RewriteEngine On

   RewriteCond %{HTTPS} !=on

   RewriteCond %{HTTP:X-Forwarded-Proto} !=https

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

   Вариант 5WordPress: проверить адреса сайта через WP-CLI

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   WordPress: проверить адреса сайта через WP-CLI

   wp option get siteurl

   wp option get home

   wp option update siteurl 'https://example.ru'

   wp option update home 'https://example.ru'

#Если вы потеряли доступ к админке

Если сайт недоступен из-за цикла, исправьте адреса через базу данных: UPDATE wp_options SET option_value='https://example.ru' WHERE option_name IN ('siteurl','home');. Для других CMS найдите параметр базового URL в конфигурационном файле. Отключите плагины редиректов, переименовав их каталог в wp-content/plugins.