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

Нужно проверить не только наличие SSL, но и всю цепочку редиректов: HTTP на HTTPS, www на non-www или наоборот, CDN, прокси и правила CMS.

Коротко: что сделать

  • Проверить curl -I для http и https версий
  • Проверить nginx/apache правила редиректа
  • Проверить .htaccess или настройки CMS
  • Проверить CDN и proxy headers
  • Проверить www/non-www и слеши

Основные причины

У проблемы может быть несколько уровней: интерфейс, backend, права, внешняя интеграция, кэш, очередь задач или настройки сервера. Поэтому лучше не гадать, а пройти цепочку от действия пользователя до записи в логах и базе.

  • Редирект настроен только в CMS, но HTTP до нее не доходит
  • nginx и .htaccess конфликтуют
  • CDN завершает HTTPS и передает сайту HTTP
  • Приложение не доверяет X-Forwarded-Proto
  • Для www и non-www настроены разные правила

Пошаговая диагностика

Диагностику удобнее вести на одном воспроизводимом примере: один пользователь, один заказ, один запрос, один файл или одно событие. Так проще отделить реальную причину от случайных совпадений.

  • Построить цепочку curl -IL http://domain
  • Проверить server block для 80 порта
  • Проверить, где возникает 301, 302 или петля
  • Отключить CDN для теста или проверить origin отдельно
  • Проверить HSTS и canonical

Как исправить проблему

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

  • Сделать редирект на уровне веб-сервера
  • Убрать дублирующие правила из CMS или .htaccess
  • Настроить trusted proxy headers
  • Привести www/non-www к одной канонической версии
  • Проверить sitemap и canonical после правки

Безопасный план решения

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

Чего не стоит делать

  • Не делать несколько независимых HTTPS-редиректов в разных местах
  • Не использовать 302 для постоянного HTTPS без причины
  • Не включать HSTS до проверки всех поддоменов
  • Не забывать про www-версию

Что подготовить перед исправлением

  • Домен и нужная каноническая версия
  • Конфиг nginx/apache или доступ к панели
  • Есть ли CDN или reverse proxy
  • Результат curl -IL
  • CMS сайта

FAQ

Почему браузер сам открывает HTTPS, а curl нет?

Браузер может помнить HSTS или кэш редиректа. Curl показывает более честную серверную цепочку.

Где лучше делать редирект?

Обычно на уровне веб-сервера или CDN, до запуска PHP/CMS.

Что опасного в петле редиректов?

Страница не откроется, поисковики не смогут ее обойти, а пользователи увидят ошибку too many redirects.

Когда стоит обратиться за помощью

Обратиться стоит, если на сайте есть SEO-трафик, формы, авторизация или несколько доменных версий.

Итог

Проверьте цепочку `curl -IL`, правила веб-сервера, CDN и proxy headers. Если нужно настроить HTTPS-редирект без петель, пишите в Telegram @rabotator_support.