Почему Cloudflare это и благословение, и проклятие для интернета

Подключение Cloudflare выглядит как чистая выгода. Пятнадцать минут, две записи у регистратора, и вы получаете сертификат, кэш по всему миру, фильтрацию мусорного трафика и сокрытие адреса сервера. Бесплатно.

Бесплатных обедов не бывает, но платите вы не деньгами, поэтому цену не замечаете. А состоит она из трёх частей, и все три стоит знать заранее.

Первая: шифрование соединения заканчивается не у вас. Вторая: к вашей доступности добавляется чужая, и если упадёт посредник, ваш живой сервер станет недоступен вместе с четвертью интернета. Третья: решение о том, работает ли ваш сайт, теперь принимается в двух местах, а не в одном, причём во втором вас не спросят.

Разговор не про то, что Cloudflare плохой. Он хороший, им пользуюсь и я. Разговор про то, что стоит в счёте, который вам не выставили.

Источники

Сначала честно: что вы получили

Начну с плюсов, потому что иначе дальше получится несправедливо. Cloudflare даёт вещи, которые самому сделать дорого или невозможно.

Фильтрация объёмных атак. Это главное, и это именно та часть, которую с вашего сервера не настроить никак. Как я разбирал в соседней статье, про анатомию DDoS, при исчерпании канала локальные настройки бесполезны: пакеты отбрасываются выше вас. Чтобы фильтровать такое, нужна полоса на стыках, которую частное лицо не купит ни за какие деньги.

Кэш близко к посетителю. Статика отдаётся из точки, которая физически рядом с человеком, а не из вашего единственного сервера. Для аудитории, разбросанной по миру, это разница в разы, и она упирается в скорость света, а не в настройки.

Сертификат, который не надо продлевать. Мелочь, пока не забудешь продлить и не узнаешь об этом от пользователей.

Сокрытие адреса сервера. Работает, пока вы сами его не выдали. Способов утечки больше, чем кажется, я разбирал их в статье про поиск настоящего IP за Cloudflare.

Всё это реально и бесплатно. Теперь про счёт.

Двадцать восемь процентов интернета

Цифры, которые задают масштаб разговора. По данным W3Techs, Cloudflare используют 27,8% всех сайтов, а среди тех сайтов, у которых вообще есть обратный прокси, его доля составляет 85,9%.

Вторая цифра интереснее первой. Восемьдесят шесть процентов рынка это не лидерство, а отсутствие рынка:

И динамика. Использование их CDN за десять лет выросло с 3,9% до 25%, причём только за последний год с 19,6%. То есть концентрация не остановилась и даже не замедлилась.

Теперь зачем я это считаю. Интернет проектировали так, чтобы он выдерживал потерю любого узла: нет центра, есть маршруты в обход. Это свойство никуда не делось на уровне протоколов, но на уровне практики появился слой, через который проходит четверть всего, и обойти его маршрутизация не умеет, потому что проблема не в маршрутах.

Из этого следует простое. Пока всё работает, вы получаете надёжность крупной компании, которая делает свою работу лучше вас. Когда у неё случается сбой, выясняется, что вы и ещё миллионы сайтов лежите одновременно и по одной причине. Ваша доступность теперь произведение двух чисел, а произведение всегда меньше любого из множителей.

Шифрование кончается не у вас

Самая непонятая часть, поэтому разберу механику.

Человек открывает ваш сайт. Браузер устанавливает защищённое соединение и показывает замочек. Замочек настоящий, сертификат настоящий, никто ничего не подделывает. Вопрос только в том, с кем именно установлено это соединение.

С Cloudflare. Шифрованный канал заканчивается на его сервере, там трафик расшифровывается, и дальше до вашего сервера идёт второе, отдельное соединение. Получается два защищённых участка и точка между ними, где содержимое лежит в открытом виде.

И это не дыра. Иначе невозможно работать: чтобы положить страницу в кэш, её надо прочитать. Чтобы отфильтровать запрос по признакам атаки, его надо разобрать. Чтобы показать проверку на робота, надо подменить ответ. Все функции, за которые вы Cloudflare и подключили, требуют доступа к содержимому. Нельзя одновременно хотеть фильтрацию и сквозное шифрование, это взаимоисключающие вещи.

А вот где начинается настоящая проблема. В настройках есть режим под названием Flexible, и документация описывает его дословно:

Cloudflare allows HTTPS connections between your visitor and Cloudflare, but all connections between Cloudflare and your origin are made through HTTP.

Посетитель при этом видит замочек и считает, что соединение защищено. Формально его половина действительно защищена. Вторая половина идёт голым текстом через неизвестное количество чужих сетей.

Зачем такой режим существует, в документации сказано честно: «Choose this option when you cannot set up an SSL certificate on your origin». То есть это костыль для случая, когда на сервере вообще нет сертификата. Включают его массово по другой причине: он единственный, который гарантированно работает с первого раза и не даёт ошибок. Та же логика, что с --privileged у Docker, про который у меня есть отдельная статья: выбирают вариант, после которого не придётся разбираться.

Что бывает, когда посередине течёт

Февраль 2017 года, история под названием Cloudbleed. Тавис Орманди из Project Zero обратился в Cloudflare с сообщением, что в ответах некоторых запросов приходит мусор. Мусор оказался содержимым памяти их серверов.

Ошибка жила в разборщике HTML, который Cloudflare использовал для своих функций вроде подстановки обфусцированных почтовых адресов. При определённых условиях он читал за границей буфера и подмешивал в ответ то, что лежало в памяти рядом. А лежали там, по собственному отчёту компании, «HTTP cookies, authentication tokens, HTTP POST bodies, and other sensitive data».

Чужие куки и токены. То есть содержимое сессий посетителей других сайтов, которые тоже работали через Cloudflare.

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

Теперь честно про масштаб, потому что без этого выйдет страшилка. Один запрос из трёх с лишним миллионов это 0,00003%. Нашли проблему исследователи, а не злоумышленники, и признаков использования не обнаружили.

Практический вывод из этого один, и он простой. Если через ваш сервис идёт что-то, что не должно быть видно посреднику, оно должно быть зашифровано на уровне приложения, до того как попало в HTTP. Всё остальное посередине видно, и это нормальная работа системы, а не её поломка.

Год, в котором посредник падал

Теория про единую точку отказа звучит абстрактно, пока не посмотришь на календарь. Последние двенадцать месяцев дают материал, которого хватило бы на отдельную статью.

18 ноября 2025 года. Самый крупный случай. В 11:20 UTC сеть начала массово отдавать ошибки. Причина оказалась прозаичной: изменение прав в одной из баз привело к тому, что служебный файл с признаками для системы определения ботов стал генерироваться с дублями и вырос больше ожидаемого размера. Основной прокси, через который идёт весь трафик, на таком файле падал.

Основное восстановление заняло время до 14:30, полностью всё заработало к 17:06. Матью Принс написал в разборе: «Today was Cloudflare's worst outage since 2019».

Дальше три детали, которые стоят всего разбора.

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

Третья: легли Workers KV, а на них держится куча внутренних вещей, включая Access. Один упавший компонент потянул за собой всё, что на него опиралось.

5 декабря 2025 года, через семнадцать дней. Падение на 25 минут, затронуло около 28% всего HTTP-трафика Cloudflare. Причина: правили логику разбора тела запроса, пока прикрывали свежую уязвимость в React Server Components.

19 декабря 2025 года компания объявила внутренний режим под названием Code Orange: Fail Small, чтобы заниматься устойчивостью. Завершением отчитались 1 мая 2026 года.

И между этими датами ещё три. 14 января 2026-го изменение в 1.1.1.1 поменяло порядок записей в ответах DNS и сломало разрешение имён у части клиентов. 22 января утекли маршруты с их роутера в Майами. 20 февраля у клиентов, которые используют свои адреса, маршруты были отозваны по BGP.

Собираем картину:

Пять разных механизмов, ни один из которых не связан с атакой.

Про последние два стоит сказать отдельно, потому что это самый неприятный жанр. Когда ломаются маршруты или DNS, слово «недоступен» звучит ещё мягко. Сервер работает идеально и при этом не существует для интернета, потому что до него нет пути или его имя не превращается в адрес.

Канонический пример этого жанра не у Cloudflare, а у Facebook, 4 октября 2021 года. Там команда по оценке пропускной способности магистрали случайно отключила магистраль целиком. Дальше сработала защита: серверы DNS настроены отзывать свои маршруты, если не видят дата-центры, потому что это признак нездоровья. Они и отозвали, честно и по инструкции. В результате компания исчезла из интернета, а инженеров пришлось отправлять в дата-центры физически, потому что внутренние инструменты тоже работали через то, что отвалилось. В их собственном разборе написано, что попасть внутрь оказалось трудно: помещения проектировались как защищённые, и быстро туда не входят.

Отдельно про Россию

Эту часть нельзя обойти, если вы делаете сайт для русскоязычной аудитории, потому что она превращает защиту в проблему.

С 9 июня 2025 года российские операторы ограничивают трафик к сетям Cloudflare. Технически это выглядит так: соединение устанавливается, начинает передаваться содержимое, и после первых 16 килобайт обрывается. Сама компания описала механику в своём блоге: «the throttling allows Internet users to load only the first 16 KB of any web asset».

Шестнадцать килобайт это десять-четырнадцать пакетов. Простая страница с текстом может загрузиться. Любая страница со шрифтом, картинками или современным фронтендом не загрузится никогда, причём не с ошибкой, а зависанием, которое выглядит как «интернет плохой».

Ограничение, по наблюдениям Cloudflare, работает для всех протоколов: HTTP/1.1 и HTTP/2 поверх TCP и TLS, а также HTTP/3 поверх QUIC. В публикации перечислены операторы, у которых это зафиксировано: Ростелеком, Мегафон, Вымпелком, МТС и МГТС.

Самая важная для вас фраза в том же тексте:

we are unable, at this time, to restore reliable, high performance access to Cloudflare products and protected websites for Russian users in a lawful manner.

Перевод короткий: со своей стороны они сделать не могут ничего. Это не инцидент, который починят, и не настройка, которую можно поправить в панели.

Результат измерим. По публикациям со ссылкой на данные Cloudflare Radar, за полгода трафик в России упал примерно на 30%. Отдельно отмечу, что ещё в ноябре 2024 года подведомственная Роскомнадзору структура рекомендовала владельцам российских сайтов отказаться от услуг компании.

Чужие правила и человек в плохом настроении

Последняя часть счёта, и она не техническая.

Когда ваш сайт работает через посредника, решение о его доступности принимается в двух местах. У вас и у него. И правила второго места написаны не вами, меняются без вашего участия, а процедура обжалования выглядит как форма обратной связи.

Лучшее высказывание на эту тему принадлежит самому директору Cloudflare. В 2017 году компания отключила сайт Daily Stormer, и Матью Принс написал сотрудникам внутреннее письмо, которое потом опубликовали. Там есть фраза, которую я считаю самой честной во всей индустрии:

«Literally, I woke up in a bad mood and decided someone shouldn't be allowed on the Internet. No one should have that power.»

Буквально: проснулся в плохом настроении и решил, что кому-то не место в интернете. Ни у кого не должно быть такой власти.

Обратите внимание, что это не претензия критиков. Это признание человека, который таким решением распорядился и сам же считает, что распоряжаться им не должен никто. Сути конкретного сайта тут не касаюсь вообще, речь исключительно о механизме: он существует, работает быстро и не требует ничьего согласия.

К этому добавляется прозаическая часть. Автоматические правила фильтрации иногда срабатывают на живых посетителей, и вы об этом узнаёте не из панели, а по упавшей конверсии. Разбираться потом долго, потому что правила чужие.

Что с этим делать

Призыва отключать тут не будет, это было бы глупо. Фильтрацию объёмных атак и кэш по миру взять больше негде. Речь про то, чтобы перестать быть заложником.

for net in $(curl -s https://www.cloudflare.com/ips-v4); do
  ufw allow from "$net" to any port 443 proto tcp
done

Частые ошибки

• Считать, что между вами и посетителем больше никого. Между вами посредник, который расшифровывает трафик, потому что иначе не умеет ни кэшировать, ни фильтровать.
• Оставлять режим Flexible. Половина пути до сервера идёт без шифрования, а посетитель видит замочек и считает иначе.
• Думать, что кэш спасёт при падении посредника. Падал в этом году core proxy, резолвер и маршруты. Кэш в этих сценариях не помогает.
• Не закрывать сервер от прямых обращений. Прокси не защищает, если к серверу можно постучаться мимо него.
• Держать суточный TTL. При аварии это превращает пятиминутное переключение в сутки ожидания.
• Не иметь плана на случай падения. Атаки короткие, а аварии посредника измеряются часами. Решать на ходу придётся без панели, если вход в неё тоже не работает.
• Полагаться на один посредник для DNS и трафика сразу. Тогда любая его поломка выключает вас целиком, включая возможность переключиться.
• Игнорировать ограничения для российской аудитории. С июня 2025 года загружаются первые 16 килобайт, и сама компания пишет, что исправить это со своей стороны не может.

Где это держать

Практическая мысль, ради которой полезно понимать всё вышеописанное.

Из разбора следует не «не пользуйтесь посредником», а кое-что скучнее: у вас должно быть куда переключиться. Это требует двух вещей: сервера, который умеет обслуживать трафик сам, без посредника, и заранее проверенного переключения.

Отсюда простые требования к площадке. Нормальная полоса и защита на входе, чтобы прямой режим не означал «лежим от первой же атаки». Чистый адрес, потому что при прямом обращении репутация адреса начинает значить всё, я про это писал отдельно. И живая поддержка, потому что переключаться вы будете в неудобное время.

Короткий итог

• 27,8% всех сайтов и 85,9% рынка обратных прокси за одной компанией. За десять лет использование их CDN выросло с 3,9% до 25%.
• Шифрование заканчивается на границе посредника, и это не дыра, а условие работы: чтобы кэшировать и фильтровать, содержимое надо прочитать.
• Режим Flexible отправляет трафик до вашего сервера без шифрования. Посетитель при этом видит замочек. Нужен Full (strict), сертификат дают бесплатно.
• Cloudbleed показал свойство архитектуры: посредник держит в памяти расшифрованный трафик всех клиентов, и утечка коснулась чужих куки и токенов, часть которых попала в кэш поисковиков.
• За последний год пять разных публичных аварий: падение прокси 18 ноября 2025 года (худшее с 2019-го), падение 5 декабря с 28% трафика, поломка резолвера, утечка маршрутов и отзыв маршрутов.
• Во время главной аварии их собственная проверка на робота заблокировала вход в панель тем, у кого не было активной сессии.
• Маршруты и DNS это худший жанр отказа: сервер работает идеально и при этом не существует для интернета.
• С 9 июня 2025 года в России грузятся первые 16 килобайт. Касается всех протоколов, включая HTTP/3, и сама компания пишет, что законного решения со своей стороны у неё нет.
• Решение о доступности вашего сайта принимается в двух местах. Про второе лучше всех сказал директор компании: ни у кого не должно быть такой власти.
• Работает скучное: строгий режим шифрования, закрытый от прямых обращений сервер, короткий TTL, второй DNS и заранее проверенный план переключения.

Вообще я микроразработчик, со мной можно связаться как угодно, я открыт ко всему

Сторонний мой проект: Zapret2UI.

Источники

• W3Techs: доля Cloudflare среди обратных прокси и всех сайтов
• W3Techs: обзор рынка обратных прокси целиком
• Cloudflare: режим Flexible, трафик до сервера по HTTP
• Cloudflare: все режимы шифрования и рекомендация использовать Full strict
• Cloudflare: отчёт по Cloudbleed, что именно утекало и в каком объёме
• Cloudflare: разбор аварии 18 ноября 2025 года
• Cloudflare: разбор аварии 5 декабря 2025 года
• Cloudflare: все публичные разборы инцидентов одной страницей
• Cloudflare: об ограничении доступа для пользователей из России
• Хабр: о падении трафика Cloudflare в России за полгода
• Ведомости: о рекомендации отказаться от услуг Cloudflare, ноябрь 2024
• CNBC: письмо Матью Принса сотрудникам про отключение сайта
• Engineering at Meta: разбор падения 4 октября 2021 года
• Cloudflare: публикуемые списки сетей для правил файрвола