Cloudflare Full (Strict): почему режим SSL важнее, чем кажется
Разбираемся, почему для сайта за Cloudflare лучше держать настоящий сертификат на origin и включать Full (Strict), а не Flexible.
Когда сайт стоит за Cloudflare, легко попасть в ловушку: в браузере замочек есть, HTTPS вроде работает, значит все хорошо. Но между посетителем и Cloudflare — это только половина маршрута. Вторая половина начинается там, где Cloudflare идет на origin-сервер: VPS, nginx, Apache, Caddy или другой backend.
И вот там часто начинается путаница с режимами SSL/TLS.
Flexible выглядит удобно, но это компромисс
Flexible шифрует соединение между браузером и Cloudflare, но до origin Cloudflare ходит по обычному HTTP. Для простого лендинга это иногда кажется нормальным: быстро включил, ничего не настраивал на сервере, сайт открылся.
Проблема в том, что origin остается без настоящего HTTPS. Плюс появляются неприятные побочные эффекты: циклические редиректы, странные mixed-mode сценарии, проблемы с приложениями, которые сами смотрят на схему запроса и ожидают HTTPS.
Для продакшена такой режим лучше не считать финальным.
Full и Full (Strict) — не одно и то же
Full уже шифрует участок Cloudflare -> origin. Но в обычном Full Cloudflare не так строго проверяет сертификат на сервере. Это лучше, чем Flexible, но все еще оставляет место для неправильной конфигурации.
Full (Strict) делает то, чего обычно и хочется от HTTPS: Cloudflare проверяет, что сертификат на origin:
- не истек;
- выпущен доверенным центром или Cloudflare Origin CA;
- подходит именно к нужному hostname.
Если что-то не так, Cloudflare не делает вид, что все нормально, а показывает ошибку. Да, это строже. Но именно поэтому режим и полезен.
Мини-чеклист для VPS
На обычном nginx-сайте я бы проверял так:
curl -I https://example.com/
curl -I --resolve example.com:443:ORIGIN_IP https://example.com/Первая команда проверяет публичный путь через Cloudflare. Вторая заставляет curl идти прямо на origin, но с правильным hostname. Если напрямую origin возвращает 200 и сертификат валиден, Full (Strict) обычно включается без сюрпризов.
Еще полезно проверить HTTP:
curl -I http://example.com/Нормальная картина — редирект на HTTPS. Ненормальная — бесконечные 301/302 или ситуация, когда приложение считает, что запрос пришел по HTTP, хотя пользователь уже на HTTPS.
Что я обычно делаю для маленьких сайтов
Мой вариант по умолчанию такой:
- На origin выпускается Let's Encrypt сертификат через certbot.
- nginx слушает 80 и 443.
- HTTP редиректит на HTTPS.
- В Cloudflare включается Full (Strict).
- После этого уже можно думать о кэше, WAF и правилах.
Это не самая сложная схема, зато она хорошо диагностируется. Если сайт не открывается, понятно, где смотреть: DNS, Cloudflare, origin-сертификат или nginx.
Почему это важно даже для блога
Блог кажется маленьким проектом, но его тоже будут обходить поисковые роботы, рекламные системы, браузеры с разными политиками безопасности и пользователи из разных сетей. Если HTTPS настроен криво, часть проблем будет выглядеть как “Google не видит сайт”, “AdSense не проходит проверку” или “у меня не открывается, а у тебя открывается”.
Поэтому Full (Strict) — это не про паранойю. Это просто нормальная базовая настройка, после которой меньше случайных проблем.