SSL/TLS режимы Cloudflare: где теряется безопасность и откуда берутся лишние ошибки
Cloudflare не «включает SSL» одним переключателем. Режим определяет, как шифруется трафик между клиентом, CDN и origin. Ошибка здесь часто выглядит как случайные 525/526, редирект-лупы или внезапный mixed content, хотя причина обычно в несогласованности цепочки.
— Flexible шифрует только до CDN. До origin запрос идёт по HTTP, поэтому на защищённом сайте он допустим лишь как временная мера. Для авторизации, платёжных сценариев и любых сессионных данных это слабое место.
— Full добавляет HTTPS до origin, но не проверяет валидность сертификата. Трафик защищён от перехвата, но не от подмены узла. Это рабочий режим, если на origin есть корректный TLS, но цепочка доверия ещё не выстроена.
— Full (strict) требует валидный сертификат на origin и обычно даёт наилучший баланс безопасности и предсказуемости. Именно он снижает риск скрытых ошибок конфигурации, которые всплывают под нагрузкой.
Частая ошибка — включить редирект на HTTPS и оставить origin недоступным по TLS. Тогда возникают петли: клиент приходит по HTTPS, Cloudflare идёт на HTTP, origin отвечает редиректом обратно. Ещё один типовой сбой — несовпадение имени в сертификате и хоста, когда фронт работает, а часть запросов стабильно падает.
Если нужен устойчивый продакшен-контур, базовый выбор почти всегда один: Full (strict) + корректный сертификат на origin + проверка редиректов и HSTS. Стабильность инфраструктуры — залог масштабируемости.
Оптимизация Cloudflare и CDN
@cloudflare_optimization_pro_arb
SSL/TLS режимы Cloudflare: где теряется безопасность и откуда берутся лишние ошибки
Этот пост опубликован в Telegram-канале Оптимизация Cloudflare и CDN. Подписаться можно по ссылке: @cloudflare_optimization_pro_arb.