SSL/TLS режимы Cloudflare: где теряется безопасность и почему ломается origin
Cloudflare предлагает несколько режимов шифрования, и ошибка здесь почти всегда выглядит одинаково: сайт «открывается», но часть запросов уходит в нестабильную схему.
• Flexible — трафик до Cloudflare шифруется, а до origin идёт по HTTP. Это удобно только для временного старта.
• Full — шифрование есть на всём пути, но сертификат на origin может быть самоподписанным.
• Full (strict) — единственный режим, где Cloudflare проверяет валидность сертификата на origin.
Главная проблема Flexible в том, что приложения и редиректы начинают жить в двух протоколах. Cookie с Secure, HSTS и логика авторизации могут вести себя непредсказуемо. Для публичного сайта это технический компромисс, а не нормальная архитектура. Если нужен контроль над безопасностью и корректными редиректами — Flexible лучше исключать.
Full без strict часто маскирует ошибки конфигурации origin. Сертификат может быть просрочен, не совпадать по имени хоста или быть выдан без цепочки доверия, и при этом инцидент обнаружится только под нагрузкой или при смене маршрута. В production это риск ложной стабильности: фронт доступен, но доверие к каналу уже нарушено.
Полезная схема простая: установить валидный сертификат на origin, включить Full (strict), проверить редиректы на HTTPS, затем отдельно проверить заголовки безопасности и поведение авторизации. Без этого SSL/TLS становится не защитой, а источником скрытых отказов. Стабильность инфраструктуры — залог масштабируемости.
Оптимизация Cloudflare и CDN
@cloudflare_optimization_pro_arb
SSL/TLS режимы Cloudflare: где теряется безопасность и почему ломается origin
Этот пост опубликован в Telegram-канале Оптимизация Cloudflare и CDN. Подписаться можно по ссылке: @cloudflare_optimization_pro_arb.