Испытание Cloudflare: можно ли отменить каждое правило на краю сети

Кратко

• Сильнейшее продуктовое заявление Cloudflare — программируемый глобальный контроль. На собственных страницах компания сообщает, что в среднем обрабатывает 102 миллиона HTTP-запросов в секунду и обслуживает данные из 335 городов в более чем 125 странах, а на странице о сети сказано, что трафик клиентов обрабатывается в ближайшем дата-центре и что каждый сервис работает в каждом дата-центре. Такая архитектура коммерчески привлекательна: политика кэша, правило WAF, версия Worker, правило Zero Trust или настройка сетевой защиты могут менять поведение рядом с пользователем, не дожидаясь пересборки каждой исходной среды. Та же архитектура делает дисциплину изменений центральным вопросом надёжности.
• Факты подтверждают узкий, но важный взгляд на Cloudflare Inc: это не просто CDN, не просто WAF и не просто serverless-среда. Это операционная поверхность на краю сети, которая объединяет проксирование трафика, правила, поведение кэша, решения по ботам и WAF, Workers, R2, Access, Tunnel, Logpush, операции со статусом и механизмы отката. Cloudflare владеет управляемыми пограничными сервисами и их документированными механизмами контроля. Ей не принадлежат исходные серверы клиентов, код их Workers, выражения их правил, их выбор в DNS, сторонние облака, сторонние поставщики удостоверений или внутренний процесс релизов каждой команды, использующей Cloudflare.
• Лучшие открытые данные полезно противоречивы. Cloudflare документирует серьёзные механизмы безопасности: версии Workers, постепенные развёртывания, откаты, метрики, Logpush, версии Ruleset Engine, правила WAF, варианты очистки кэша, логику политик Access и публичные API статуса. Компания также опубликовала два отчёта об инцидентах 2025 года, которые показывают, почему механизмы безопасности — это ещё не безопасность. 18 ноября 2025 года ошибка в файле функций Bot Management распространилась по сети и вызвала массовые сбои 5xx. 5 декабря 2025 года изменение, связанное с WAF, затронуло около 28% HTTP-трафика, который обслуживала Cloudflare, примерно на 25 минут. Это не повод отвергать Cloudflare; это самые ясные публичные тесты для оценки реальной эксплуатационной нагрузки продукта.
• Поэтому коммерческий вопрос не в том, умеет ли Cloudflare быстро менять конфигурацию на краю сети. Умеет. Вопрос покупателя в том, снижает ли эта скорость достаточно нагрузки на исходные серверы, трения при развёртывании, затрат на инструменты безопасности, сетевой экспозиции и накладных расходов разработчиков, чтобы оправдать зависимость от вендора, тестирование правил, логи, планирование аварийного переключения, ограничения среды выполнения, миграционные работы и сложность поддержки. В форме 10-K за 2025 год Cloudflare сообщила о 332 466 платящих клиентах и 4 298 клиентах с годовой выручкой выше 100 000 долларов, а в отчёте за I квартал 2026 года — о квартальной выручке в 639,8 млн долларов. Эти цифры доказывают спрос. Они не доказывают, что конкретный покупатель ограничил ложные срабатывания, обеспечил согласованное распространение изменений, полные логи или план восстановления.

Продукт — это контроль, а не только доставка

Cloudflare вышла на рынок как способ ускорять и защищать веб-сайты, но современный продукт Cloudflare правильнее понимать как глобально распределённую панель управления. Компания описывает платформу, в которой SASE, безопасность приложений, доставка приложений, сетевые сервисы и full-stack разработка используют одну глобальную инфраструктуру. На страницеО CloudflareCloudflare говорит, что любой коммит кода автоматически влияет на миллионы интернет-ресурсов и что она в среднем обрабатывает 102 миллиона HTTP-запросов в секунду из 335 городов в более чем 125 странах. На страницеглобальной сетисказано, что каждый сервис работает в каждом дата-центре и что трафик клиентов обрабатывается близко к источнику, с более чем 13 000 межсетевых соединений с сервис-провайдерами, облачными провайдерами и корпоративными сетями.

В этом и состоит операционная идея. Если каждый сервис доступен везде, одна и та же инфраструктура может кэшировать ресурсы, фильтровать атаки, применять политики доступа, маршрутизировать трафик, выполнять код Workers и передавать логи. Клиент видит одну панель и одно семейство API вместо набора региональных устройств. Правило можно изменить один раз и применить во многих местах. Worker можно развернуть на краю сети без управления регионами. Изменение CDN может сократить трафик к исходным серверам, не перемещая их. Политика Zero Trust может защитить приложение, не раскрывая публичный IP, если архитектура построена вокруг Cloudflare Tunnel.

Именно поэтому ценностное предложение Cloudflare отличается от узкого хостинг-провайдера. Продукт становится слоем принятия решений перед приложениями. Одни решения просты: закэшировать объект, пропустить запрос, заблокировать этот диапазон IP, потребовать эту группу удостоверений. Другие — вероятностные или контекстные: присвоить бот-скор, оценить управляемое правило WAF, отправить запрос на проверку, направить трафик через защищённый путь доступа. Третьи — решения разработчиков: запустить эту версию Worker, привязать это пространство имён KV, прочитать этот объект R2, вызвать этот нижестоящий сервис.

Различие важно, потому что риск не только в простое. Плохое решение на краю сети может нанести скрытый бизнес-вред ещё до того, как станет очевидным сбоем. Оно может блокировать реальных клиентов, отдавать устаревший контент, обходить контроль безопасности, направлять трафик на перегруженный исходный сервер, открыто пропускать трафик при превышении лимита Worker, закрывать доступ, когда важнее доступность, или делать логи неполными именно в тот момент, когда оператору они нужны. Компания, покупающая Cloudflare, покупает право перенести решения на край сети Cloudflare.

Она также принимает то, что корректность этих решений становится общей ответственностью.

Что принадлежит Cloudflare Inc и что ей не принадлежит

Граница вокруг Cloudflare Inc важна, потому что Cloudflare появляется во многих историях о сбоях, где она лишь одна часть пути. Сайт может использовать DNS Cloudflare, размещая приложение в другом месте. Клиент может написать ошибочный Worker. Исходный сервер может отдавать неверные заголовки, из-за чего поведение кэша становится неожиданным. Сторонний поставщик удостоверений может сделать политику Access непригодной. Облачный провайдер может отказать за прокси Cloudflare. Запись у регистратора может быть настроена неверно. Клиент может написать выражение WAF, блокирующее реальных покупателей.

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

Отчётность Cloudflare подтверждает коммерческую границу. Вформе 10-K за 2025 годсказано, что выручка в основном поступает от подписок на доступ к сети и продуктам, а также от услуг поддержки, и что клиенты получают непрерывный доступ к сети и продуктам Cloudflare, а не владение ПО, которое управляет сетью. Это сервисный контракт, а не передача права собственности на инфраструктуру. Там же сказано, что удержание и расширение клиентской базы зависят от удовлетворённости безопасностью, производительностью и надёжностью продуктов и глобальной сети Cloudflare.

Именно поэтому рост крупных клиентов Cloudflare работает в обе стороны. В отчёте за 2025 год указаны 332 466 платящих клиентов на конец года и 4 298 клиентов с годовой выручкой выше 100 000 долларов. Крупные клиенты — подтверждение ценности платформы, но в отчёте также сказано, что крупным клиентам могут требоваться более сложные конфигурации, интеграции, развёртывания, помощь с миграцией, обязательства по поддержке и расходы на сетевую инфраструктуру. Иными словами, чем успешнее Cloudflare продаёт корпоративный контроль, тем сильнее продукт оценивают по сложному управлению изменениями, а не по простому маркетингу скорости страниц.

Первый квартал 2026 года показывает то же напряжение. Врезультатах Cloudflare за первый квартал 2026 годасообщается о выручке в 639,8 млн долларов, росте на 34% год к году, скорректированной операционной прибыли (non-GAAP) в 73,1 млн долларов и свободном денежном потоке в 84,1 млн долларов. Это сильный спрос на пакет. Это не решает, стоит ли конкретному клиенту отдавать WAF, CDN, Workers, R2, Access и сетевую защиту одному вендору. Это лишь показывает, что многие клиенты готовы платить за такую возможность.

Правила: здесь скорость становится риском

Механика правил Cloudflare — центральная для платформы. Вдокументации Ruleset Engineнабор правил определяется как упорядоченный набор правил, применяемых к трафику в глобальной сети Cloudflare. Наборы правил относятся к фазам, версионируются, и каждое изменение создаёт новую версию.Список фазпоказывает, что выполнение правил — не одно общее действие: сетевые фазы, фазы Magic Transit, фазы запросов и продуктовые фазы выполняются в определённом порядке. Ценность в том, что разные решения по безопасности и трафику можно разместить в нужной части пути запроса. Издержка в том, что порядок, область действия и выбор фазы имеют значение.

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

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

Напродуктовой странице WAFCloudflare говорит, что WAF проверяет HTTP/S-запросы на краю сети с помощью управляемых и пользовательских правил, и утверждает, что управляемые правила могут быстро защищать от новых уязвимостей. Это серьёзное преимущество, когда уязвимость фреймворка или библиотеки становится публичной раньше, чем команды приложений успевают установить патч. Но стандарт доказательств для заявления вендора о быстром виртуальном патчинге должен отличаться от решения покупателя применять его. Вопрос не только в том, «может ли Cloudflare написать и развернуть правило?» Вопрос в том, «будет ли это правило корректно работать с нашим реальным трафиком, нашим потоком входа, нашим путём оформления заказа, нашими API-клиентами, нашими мобильными приложениями и нашими партнёрскими интеграциями?»

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

Коммерческая целесообразность зависит от того, снижает ли Cloudflare достаточно дублирующей работы по безопасности, чтобы окупить этот надзор.

Workers превращают изменение на краю сети в релиз ПО

Workers выводят Cloudflare из роли вендора управления трафиком в среду выполнения ПО.Документация разработчика Cloudflareописывает Workers и связанные примитивы как способ создавать и разворачивать serverless-функции и full-stack приложения в глобальной сети Cloudflare. Напродуктовой странице Workersсказано, что команды могут разворачиваться в 330+ городах, постепенно раскатывать изменения на процент пользователей и откатываться при всплеске ошибок. Это ровно то обещание, которое нужно корпоративным платформенным командам: глобальный охват без управления региональными серверными парками.

Подробная документация Workers полезнее маркетингового заявления, потому что раскрывает операционный контракт. В разделе«Версии и развёртывания»сказано, что каждое изменение кода или конфигурации создаёт версию. Развёртывание определяет, какие версии активно обслуживают трафик: либо одна версия на 100%, либо две версии при постепенном развёртывании. По умолчаниюwrangler deployсоздаёт версию и сразу разворачивает её на весь трафик одним шагом, хотя загрузку версии и развёртывание можно разделить.

Это значение по умолчанию важно. Быстрое глобальное развёртывание хорошо, когда изменение безопасно. Оно рискованно, когда изменение ошибочно. Ответ Cloudflare — постепенное развёртывание. Вдокументации по постепенным развёртываниямсказано, что трафик можно разделять между версиями, отслеживать частоту ошибок и исключения и восстанавливать стабильную версию при появлении проблем. Это правильная форма контроля. Она позволяет покупателю проверить релиз на части реального трафика, а не на всём сразу.

Откат тоже документирован, но это не магия. В разделеоб откатах Workersсказано, что откат создаёт новое развёртывание с выбранной предыдущей версией и активирует её на всех маршрутах и доменах. Там также сказано, что связанные ресурсы при откате не меняются и что откат может быть заблокирован, если произошла миграция Durable Субъект или если целевая версия зависит от корзины R2, пространства имён KV или очереди, которых больше нет. Это ограничение — не недостаток; это реальность состояния. Откатить код проще, чем откатить данные. Worker, изменивший только логику, часто можно вернуть. Worker, изменивший привязки, миграции или семантику объектов, — не всегда.

Страницалимитов Workersдобавляет ещё один вопрос к развёртыванию. В документации сказано, что у Workers нет общего лимита запросов в секунду, но у бесплатных тарифов есть дневные лимиты запросов, существуют лимиты подзапросов, а поведение маршрутов можно настроить как «открытый сбой» (fail open) или «закрытый сбой» (fail closed). Этот выбор архитектурный. Критичный для безопасности Worker может требовать поведения fail-closed. Ориентированный на пользователя персонализационный Worker может предпочесть fail-open. Неверный выбор меняет режим отказа с мягкой деградации на экспозицию или простой.

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

Корректность кэша — это бизнес-решение

Слой CDN — самая знакомая часть Cloudflare, но и одна из самых легко упрощаемых. Напродуктовой странице CDNсказано, что CDN кэширует статический и динамический контент в более чем 335 городах и отдаёт его с края сети, ускоряя доставку и поглощая нагрузку с исходных серверов. Это прямая экономическая ценность: меньше запросов к исходным серверам, ниже задержка и выше устойчивость к всплескам трафика.

Сложность — в корректности. Вдокументации о поведении кэша по умолчаниюсказано, что Cloudflare не кэширует ресурс, когдаCache-Controlимеет значение private, no-store, no-cache или max-age=0, когда есть заголовок Set-Cookie или когда метод запроса не GET. Там также сказано, что Cloudflare по умолчанию кэширует некоторые расширения файлов, не кэширует HTML или JSON по умолчанию и использует склейку запросов, чтобы одновременные промахи кэша для одного ресурса в одном дата-центре не создавали дублирующих обращений к исходному серверу. Это разумные настройки по умолчанию, но настройки по умолчанию — не полная политика.

Правила кэшаCloudflare позволяют клиентам настраивать, что может кэшироваться, как долго и где применяется поведение кэша. Это может быть ценно, когда у приложения есть предсказуемые статические страницы, изображения, ответы API или версионированные файлы. Это может быть опасно, когда правило считает кэшируемым персонализированный контент или контент, зависящий от авторизации. Край сети может ускорять правильный ресурс везде — или делать неправильный ответ устойчивым во многих местах.

Очистка кэша — сторона восстановления в вопросе корректности. Вдокументации по очистке кэшаописаны Instant Purge и несколько областей очистки, при этом рекомендуется очистка одного файла. СтраницаPurge Everythingпредупреждает, что полная очистка удаляет ресурсы во всех дата-центрах и заставляет новые запросы возвращаться к исходному серверу, что может существенно увеличить нагрузку на него и замедлить работу высоконагруженных сайтов.

Это предупреждение — коммерческая подсказка. Ценность CDN не только в низкой задержке; это снижение нагрузки на исходные серверы. Небрежная очистка может временно вернуть ту самую нагрузку, которую CDN должен был поглощать. Продуманная политика очистки может удалить плохой контент, не превращая каждого пользователя в запрос к исходному серверу. Поэтому вопрос покупателя о контроле на краю сети — не «поддерживает ли Cloudflare очистку?», а «могут ли наши релизные и аварийные команды быстро выбрать наименьший безопасный объём очистки и знаем ли мы, что произойдёт с исходным сервером, если они выберут слишком широкий объём?»

Наблюдаемость — часть продукта, а не дополнение

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

Cloudflare документирует несколько маршрутов наблюдаемости.Метрики и аналитика Workersпоказывают трафик, успешность запросов, метрики ошибок и статус вызовов.Logpushможет отправлять логи в хранилища, SIEM и системы управления логами.Дашборды здоровья Logpushмогут отслеживать статус задач и диагностировать ошибки, но та же страница отмечает критическое ограничение: Logpush не может восстановить логи задним числом, если данные были потеряны.

Это единственное ограничение меняет модель риска. Логи — не просто записи для разбора после инцидента. Это доказательства, по которым решают, безопасно ли правило, можно ли расширять канареечное развёртывание, сработал ли откат и был ли клиент ошибочно заблокирован. Если экспорт логов падает во время напряжённого изменения, команда может оказаться перед выбором: ждать без доказательств или действовать без уверенности. Уведомления о здоровье и дашборды помогают, но добавляют ещё одну систему для контроля.

Цены и хранение тоже формируют операционную работу. Вдокументации по ценам Workersсказано, что логи Workers включены в бесплатные и платные тарифы с лимитами событий и хранения, а Logpush для событий трассировки Workers платный и тарифицируется за логи запросов, достигающие пункта назначения после фильтрации или сэмплирования. Это не делает продукт слабым. Это означает, что покупателю следует относиться к наблюдаемости как к статье архитектурных расходов, а не бесплатному побочному продукту. Стоимость достаточно полных логов может быть частью реальной стоимости ответственного использования пограничной автоматизации.

Для корпоративных покупателей практический тест прост: прежде чем переносить критическую логику в Cloudflare, решите, какие логи нужны для отмены неверного решения. Команде WAF могут понадобиться ID правила, действие, совпавшее выражение, контекст репутации IP, бот-скор, путь, хост и влияние на пользователей. Команде Workers — ID версии, частота исключений, сбои подзапросов и ошибки привязок. Команде кэша — статус попадания, статус исходного сервера, события очистки и заголовки. Если этих полей нет, они не хранятся и не связаны с процессами инцидентов, у края сети есть скорость, но недостаточно подотчётности.

Cloudflare One распространяет ту же модель на доступ

Cloudflare One переносит модель пограничного контроля в корпоративный доступ и сетевые сервисы.Документация Cloudflare Oneописывает SASE-платформу, включающую Access, Tunnel, Secure Web Gateway, Browser Isolation, CASB, DLP, Email Security и Digital Experience Monitoring. Access аутентифицирует пользователей и записывает каждое событие и запрос. Tunnel подключает ресурсы к Cloudflare, не раскрывая публичный IP, через исходящие соединения из инфраструктуры клиента.

Техническая привлекательность та же, что у CDN и WAF: перенести применение политик распределённому провайдеру и сократить потребность в устаревших устройствах. Риск тоже тот же: корректность политик становится операционной дисциплиной. Вдокументации по политикам Accessсказано, что правила Include работают как OR, Exclude — как NOT, Require — как AND. Во всех политиках Access нужно хотя бы одно правило Include, а Require сужает область действия. Эта логика ясна, но реальные организации неясны. В них есть подрядчики, сервисные учётные записи, аварийные администраторы, слияния, просроченные устройства, сторонние удостоверения и исключения, которые трудно смоделировать.

Access также зависит от взаимодействий продуктов. В той же документации отмечена несовместимость политик bypass, когда в них есть проверки состояния устройств и либо для защищённой зоны включён Zaraz, либо Worker перехватывает запрос. Рекомендуемый обходной путь — изменить действие политики на Service Auth. Это как раз та деталь, которая определяет, зрелый ли раскат Zero Trust. Проблема не в том, что несовместимость существует. Проблема в том, есть ли у клиента управленческая дисциплина, чтобы знать, какие продукты взаимодействуют, кто владеет исключением и как исключение проверяется после последующих изменений на краю сети.

Cloudflare One может сократить количество устройств и сделать доступ более интернет-нативным. Она также может создать новую зависимость от интеграций удостоверений, здоровья клиентов, доступности Tunnel, порядка политик, логов и панели/API Cloudflare. Покупателю, сравнивающему Cloudflare One с VPN-устройствами, стоит сравнивать не только функции. Стоит сравнивать режимы отказа. Если Access недоступен, что продолжает работать? Если поставщик удостоверений деградирует, кто сможет попасть на аварийный путь? Если Worker изменяет запрос до оценки Access, было ли проверено такое взаимодействие?

Эти вопросы определяют, снижает ли консолидация риск или просто делает риск более элегантным.

Magic Transit показывает сетевую версию той же ставки

Magic Transit расширяет роль Cloudflare от прокси приложений до сетевой защиты.Документация Magic Transitописывает корпоративный сервис DDoS-защиты и ускорения трафика для локальных, облачных и гибридных сетей. Он использует глобальную сеть Cloudflare для приёма и смягчения атак вблизи их источника и включает проверки здоровья, управление трафиком, IP Cloudflare и BGP-пиринг в бета-версии.Эталонная архитектураописывает Magic Transit как защиту на основе BGP для сетевой инфраструктуры, обращённой в интернет, и говорит, что Cloudflare имеет сотни Тбит/с мощности смягчения и среднее глобальное время смягчения менее трёх секунд.

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

Но Magic Transit — не наклейка на канал. Он затрагивает BGP-анонсы, префиксы, туннели, приоритеты управления трафиком, проверки здоровья, политику маршрутизации, ожидания файрвола и внутренние регламенты. Покупателю нужно знать, какие префиксы защищены, как обрабатывается асимметричная маршрутизация, чем отличаются режимы по требованию и постоянный режим, что происходит при неверном анонсе и кто имеет право менять приоритеты маршрутов во время инцидента. Публичная эталонная архитектура подтверждает общее продуктовое заявление; она не доказывает, что сетевая команда конкретного клиента внедрила продукт безопасно.

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

R2 меняет экономику хранения, но не ответственность за данные

R2 — ещё один пример того, как Cloudflare использует своё положение на краю сети для атаки на проблему стоимости. Напродуктовой странице R2описан S3-совместимый объектное хранилище без платы за исходящий трафик, с интеграцией Workers и поэтапной миграцией из существующего объектного хранилища. Вдокументации по ценам R2сказано, что R2 взимает плату за хранение плюс операции класса A и класса B, не берёт плату за исходящий трафик для любого класса хранения и применяет правила платы за извлечение и минимальный срок хранения для хранилища Infrequent Access.

Для команд разработчиков привлекательность очевидна. Счета за исходящий трафик делают облачное хранение труднопредсказуемым. S3-совместимые API снижают трение миграции. Интеграция Workers снижает необходимость жонглировать учётными данными между вычислениями и хранилищем. Клиент может размещать логи, медиа, артефакты моделей или объекты приложений рядом со средой выполнения Cloudflare и избегать части боли межоблачной передачи.

Опасность в том, что «без платы за исходящий трафик» может звучать как «без экономики хранения». Это не так. Операции тарифицируются. Извлечение из Infrequent Access имеет стоимость. Инструменты миграции могут создавать операционные сборы. Управление данными, политики жизненного цикла, резервное копирование, шифрование, контроль доступа и ожидания согласованности остаются ответственностью клиента. Если приложение переезжает из хранилища гиперскейлера в R2, команда может снизить стоимость передачи, но увеличить зависимость от платформы разработчика Cloudflare, поведения API, пути поддержки и наблюдаемости.

R2 коммерчески важен, потому что делает Cloudflare более сильной платформой приложений, а не потому, что само хранилище доказывает тезис о пограничном контроле. Его значение для центрального вопроса статьи — состояние. Документация по откатам Workers предупреждает, что связанные ресурсы при откате не меняются. Если Worker и корзина R2 развиваются вместе, откат кода может не восстановить прежний контракт данных. Командам нужна дисциплина миграции, даже когда среда выполнения делает развёртывание кода мгновенным на ощущение.

Сбой ноября 2025 года — самый полезный публичный тест

Инцидент Cloudflare 18 ноября 2025 года — самый ясный публичный пример риска пограничного контроля. Вотчёте об инцидентеCloudflare сообщила, что сеть начала испытывать серьёзные сбои в 11:20 UTC. Проблема была не атакой. Её вызвало изменение прав доступа к базе данных, из-за которого запрос стал возвращать дублирующиеся строки функций для Bot Management. Файл функций стал больше ожидаемого, распространился по машинам сети, превысил лимит в модуле прокси и вызвал сбои. Основной трафик в основном восстановился к 14:30, а все системы работали нормально к 17:06.

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

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

История восстановления тоже важна. Cloudflare остановила генерацию и распространение плохого файла функций, поместила заведомо корректный файл в очередь дистрибуции, перезапустила части системы и постепенно восстановила сервисы. Согласно таймлайну, первый автоматический тест обнаружил проблему в 11:31, созвон по инциденту состоялся в 11:35, работа сосредоточилась на откате Bot Management в 13:37, автоматическое развёртывание остановлено в 14:24, исправленный файл развёрнут глобально в 14:30, а все нижестоящие сервисы восстановлены к 17:06.

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

Независимый анализCisco ThousandEyesдобавляет внешнюю точку зрения. ThousandEyes наблюдала ошибки HTTP 500 в отслеживаемых сервисах, зависящих от Cloudflare, диагностировала отсутствие компонентов проверки при сбое управления ботами и видела, как некоторые организации выполняли переключение DNS в сторону от Cloudflare AS 13335. Это переключение восстановило доступность для некоторых сервисов, но также означало потерю таких сервисов Cloudflare, как управление ботами и пограничный кэш. Это компромисс клиента в одном предложении: обход Cloudflare может восстановить доступность исходного сервера, но только если исходный сервер готов работать без слоя Cloudflare.

Сбой декабря 2025 года показывает, почему тип раската имеет значение

Инцидент 5 декабря 2025 года был короче, но заострил тот же вопрос. Вдекабрьском отчётеCloudflare сообщила, что часть сети испытывала серьёзные сбои с 08:47 UTC и была восстановлена к 09:12 UTC. Cloudflare сообщила, что затронуто около 28% всего HTTP-трафика, который она обслуживала. Триггером была работа над разбором тела WAF, связанная с обнаружением и смягчением критической уязвимости React Server Components.

Ключевая деталь — форма раската. Cloudflare сообщила, что первое изменение, увеличение размера буфера, использовало систему постепенного развёртывания. Во время этого раската внутренний инструмент тестирования WAF не поддерживал увеличенный размер буфера. Второе изменение, отключение этого внутреннего инструмента тестирования, использовало глобальную систему конфигурации, которая не выполняет постепенные раскаты и распространилась за секунды на весь серверный парк. Сбой произошёл не из-за идеи защитить клиентов от срочной уязвимости. Он произошёл из-за пути изменений, где одно действие имело постепенные предохранители, а другое — нет.

Это различие должно влиять на то, как покупатели оценивают каждый механизм контроля Cloudflare. Недостаточно спрашивать, «поддерживает ли Cloudflare постепенный раскат». Реальный вопрос — какой тип изменений использует какой механизм раската. Постепенные развёртывания Workers документированы. Наборы правил версионируются. У некоторых глобальных систем конфигурации могут быть другие свойства безопасности. Обновления управляемых правил, пользовательские правила, функции ботов, изменения разбора WAF, поведение кэша и внутренние инструменты тестирования могут не разделять один путь раската.

Для клиентов это означает, что классификация изменений важна. Команда может безопасно канареечно раскатывать свой Worker и при этом оставаться подверженной изменению управляемого правила или конфигурации на стороне провайдера. Команда может тестировать своё пользовательское правило WAF и при этом зависеть от управляемых правил и модулей прокси Cloudflare. Это не уникально для Cloudflare; у любого облачного сервиса есть риск изменений на стороне провайдера. Но положение Cloudflare перед клиентским трафиком означает, что этот риск может очень быстро стать видимым конечным пользователям.

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

Зависимость — цена консолидации

Предложение Cloudflare становится сильнее всего, когда клиенты пытаются сократить количество инструментов. Веб-команда может не хотеть отдельных вендоров для CDN, DNS, управления ботами, DDoS, WAF, объектного хранилища, serverless-среды, прокси доступа, экспорта логов и управления трафиком. Команда безопасности может предпочесть одну поверхность политик устройствам в каждом регионе. Платформенная команда разработчиков может предпочесть Workers, R2 и Pages сборке облачных вычислений, CDN и объектного хранилища с нуля.

Консолидация может быть рациональной. Число крупных клиентов в 10-K за 2025 год и рост выручки в I квартале 2026 года показывают, что рынок за неё платит. Размещённые у вендора сигналы клиентов на страницах WAF, Workers и R2 указывают на тот же спрос: Carrefour использует WAF и Bot Management Cloudflare на многих e-commerce сайтах, Intercom хвалит скорость Workers от идеи до продакшена, Character.AI описывает R2 как часть мультиоблачной архитектуры данных. К этим примерам следует относиться как к выбранным сигналам клиентов, а не универсальному доказательству, но они показывают, для каких задач покупатели нанимают Cloudflare.

Цена — зависимость. Клиент, размещающий многие элементы контроля за Cloudflare, сокращает интеграционную работу, но увеличивает последствия проблем с учётной записью Cloudflare, проблем с панелью/API, инцидентов провайдера, изменений тарифов, задержек поддержки и продуктовых лимитов. Он также увеличивает стоимость выхода. Уйти с простого CDN проще, чем покинуть стек правил WAF, правил кэша, маршрутов Workers, корзин R2, политик Access, туннелей, записей DNS, логов и маршрутизации Magic Transit.

Поэтому обсуждение зависимости (lock-in) должно быть операционным, а не идеологическим. Cloudflare использует много открытых протоколов и знакомых интерфейсов. DNS стандартен. HTTP стандартен. R2 совместим с S3. Workers используют JavaScript и связанные концепции веб-среды. Но операционная зависимость возникает из инструкций (runbook), оповещений, дашбордов, исключений, политик доступа и производственных привычек, которые вырастают вокруг вендора. Команда может суметь перенести код или объекты, но ей всё равно могут понадобиться месяцы, чтобы воссоздать то же поведение безопасности и трафика в другом месте.

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

Серьёзный тест покупателя смотрит на обычные изменения

Cloudflare стоит оценивать меньше по героическим заявлениям, чем по обычным операционным задачам. Важный вопрос — как часто команда может вносить небольшое изменение на краю сети без вреда. Полезное доказательство концепции — не синтетический hello-world Worker и не только тест скорости. Это набор репрезентативных изменений, похожих на обычный месяц в продакшене.

Для WAF и правил покупатель должен проверить поэтапное применение. Где возможно, начинайте с логирования или проверки (challenge), сравнивайте заблокированные запросы с известными легитимными потоками, проверяйте порядок правил, убеждайтесь, что правила пропуска не обходят больше задуманного, и требуйте названных владельцев для широких выражений. У каждого правила должен быть путь отката и причина существования. Если команда не может объяснить, почему правило срабатывает, она, вероятно, не сможет объяснить, почему правило заблокировало клиента.

Для Workers покупатель должен проверить версионную дисциплину. Разверните небольшой реальный сервис с ручной загрузкой версии, постепенным развёртыванием, просмотром метрик, откатом и намеренным изменением привязок. Затем проверьте крайние случаи: отсутствующее пространство имён KV, миграцию Durable Субъект, лимит подзапросов, отказавший нижестоящий сервис и поведение маршрутов fail-open против fail-closed. Цель не в том, чтобы поймать Cloudflare на сбое. Цель — понять, какие сбои восстанавливаются откатом кода, а какие требуют починки данных или конфигурации.

Для кэша покупатель должен проверить поведение заголовков и объём очистки. Пропустите статические ресурсы, персонализированные страницы, ответы API и страницы ошибок через тот же процесс релиза, который будет использовать продакшен-сайт. Убедитесь, что поведение Set-Cookie и Cache-Control совпадает с ожиданиями команды. Потренируйтесь в очистке одного файла, очистке по префиксу и откате после плохого правила кэша. Оцените нагрузку на исходный сервер после широкой очистки до того, как инцидент заставит делать выбор.

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

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

Вердикт условный

У Cloudflare Inc есть обоснованное право называться программируемой глобальной платформой на краю сети. Публичная документация показывает зрелые поверхности контроля для правил, поведения кэша, версий Workers, постепенного развёртывания, откатов, логов, политик Zero Trust и сетевой защиты. Финансовые данные показывают большой и растущий клиентский спрос. Данные об инцидентах показывают, почему заявление нужно проверять в реальных условиях изменений.

Оптимистичный сценарий сильнее всего для команд, которым нужно много механизмов контроля Cloudflare одновременно: публичные веб-приложения с серьёзной поверхностью атак, глобальная пользовательская база, давление на исходные серверы, команды разработчиков, способные использовать Workers, команды безопасности, консолидирующие WAF и политики доступа, и сетевые команды, которые могут оправдать Magic Transit. Для таких клиентов Cloudflare может сократить дублирующую инфраструктурную работу и приблизить защиту к пользователям.

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

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