Автор публикации Ааши Патель из Cloudflare объясняет мотивацию просто: память и диски дорожают, а кэш-серверы Cloudflare хранят огромный объём текста, который origin-серверы отдают без сжатия. Прототип реализован внутри Pingora, прокси-фреймворка компании на Rust.

• На контрольном наборе коэффициент сжатия составил 2,834x при zstd уровня 3.
• Кодирование стоит 4,31 нс на байт (около 232 МБ/с), декодирование 1,56 нс на байт (около 641 МБ/с).
• HTML, JSON, CSS и JavaScript давали 67,3% запросов, но только 22,3% байтов; около 71% таких ответов приходили без Content-Encoding.
• Картинки, видео и шрифты занимали 63,3% байтов при 21,4% запросов; повторно сжимать их невыгодно.
• Порог 4 КиБ отсекает мелкие объекты и теряет около 1% потенциально сжимаемых байтов.

Почему сжимать пришлось именно в кэше

Казалось бы, текст в интернете и так сжат. Но по замерам Cloudflare около 71% текстовых ответов приходят от origin-серверов без заголовка Content-Encoding: сжатие для клиента делает уже edge-сервер, а на диск кэша объект ложится сырым. При этом HTML, JSON, CSS и JavaScript составляли 67,3% запросов и 22,3% байтов, а медиа и шрифты 21,4% запросов и 63,3% байтов. Пересжимать медиа бессмысленно: оно уже сжато своими кодеками. Значит, целевая доля кэша, где сжатие даёт эффект, это примерно пятая часть байтов.

Ключевая фраза публикации: «стоимость кодирования оплачивается один раз, когда объект попадает в кэш» (перевод редакции). Дальше объект читают многократно, а декодирование почти в три раза дешевле кодирования. Между дата-центрами через Tiered Cache объект едет уже сжатым, и это экономит ещё и междатацентровый трафик.

Критерии и цифры

В прототипе сжимались только ответы 200 OK с тремя условиями: заголовок Content-Encoding не задан, тип содержимого сжимаемый, известен Content-Length не меньше 4 КиБ. Range-запросы, уже сжатые ответы, тела неизвестной длины и бинарное содержимое проходят без изменений. Порог 4 КиБ исключил много мелких запросов, но потерял, по расчётам компании, около 1% потенциально сжимаемых байтов: «сжатие всего подходящего текста от 4 КиБ и выше дало почти всю измеренную экономию места».

Замеры производительности проводились на более чем миллионе запросов через 10 кэш-серверов. Коэффициент 2,834x получен на двух тестовых объектах размером около 195 и 272 КиБ, а не на всём кэше сервиса. Кодирование zstd уровня 3 стоило 4,31 нс на байт, декодирование 1,56 нс на байт. Дополнительная нагрузка на CPU при выбранных предположениях, по оценке Cloudflare, составила несколько процентов. Это замер вендора на его трафике; на другом профиле содержимого доля текста и коэффициент будут иными.

Как повторить у себя

Приём применим к любому кэширующему слою, где объекты хранятся на диске и читаются чаще, чем пишутся: nginx с proxy_cache, Varnish, самописные кэши на Pingora или Go. Порядок действий по мотивам публикации:

1. Измерить долю ответов без Content-Encoding и их суммарный объём: если origin уже сжимает всё, выигрыша не будет.
2. Ограничить кандидатов по типу содержимого и размеру; порог 4 КиБ у Cloudflare покрыл почти всю экономию.
3. Сжимать один раз при записи, хранить сжатым, декодировать при выдаче; прототип Cloudflare всегда декодирует объект, а отдачу сжатого представления клиенту напрямую компания называет будущей работой.
4. Считать CPU: при 232 МБ/с на кодирование одно ядро обслуживает ограниченный поток записи, и на серверах с высокой долей промахов кэша это может стать узким местом.

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

Что осталось проверить

Компания перечисляет открытые вопросы: другие уровни zstd, другие типы объектов, range-запросы и предварительно сжатые ответы. Zstandard, напомним, разработан Янном Колле и открыт в 2016 году; в более раннем тестировании Cloudflare он сжимал на 42% быстрее Brotli и давал файлы на 11,3% меньше gzip при сопоставимой скорости. Редакция проверит, дойдёт ли прототип до боевой сети и появятся ли цифры по общей экономии.

Источник: Блог Cloudflare: Cache Transcoding

Изображение на обложке: Cloudflare

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

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

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

Сервис Images, написанный на Rust и работающий в Workers, запущен на каждой машине в edge-сети Cloudflare. Чтобы обрабатывать клиентские соединения, мы используем hyper — открытую HTTP-библиотеку для Rust.

В прошлом году мы представили Images binding — он позволяет создавать кастомные программные сценарии обработки удалённых изображений в Workers. В конце 2025 года мы перестроили binding, чтобы сделать связь между Workers runtime и сервисом Images более прямой и локальной.

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

Мы потратили шесть недель на охоту за почти невидимым багом — состоянием гонки, которое проявлялось только при определённых условиях, — в библиотеке hyper, который влиял на то, как Images binding возвращает обработанные изображения клиенту. В итоге исправление заняло четыре строки кода.

Cloudflare Images binding перешёл на прямое локальное соединение через Unix-сокеты в декабре 2025 года.

После выкатки большие изображения стали иногда возвращаться обрезанными: HTTP 200, но тело ответа короче Content-Length.

Причина — состояние гонки в hyper: цикл poll_loop отбрасывал результат poll_flush, даже если тот возвращал Poll::Pending.

Баг существовал в hyper 0.14.x, 1.7 и 1.8; прежний посредник FL читал данные достаточно быстро, чтобы он не проявлялся.

Исправление заняло четыре строки кода: flush теперь выполняется перед shutdown.

Прыжки, передачи и hyper

Когда разработчики создают приложения на Cloudflare, они собирают full-stack приложения из набора платформенных сервисов, доступных Workers через bindings. Bindings предоставляют прямые API к ресурсам Developer Platform: вычислениям, хранилищам, ИИ-инференсу и обработке медиа.

Images binding отделяет оптимизацию изображений от доставки: вы можете транскодировать, компоновать или изменять изображения, не возвращая результат в виде HTTP-ответа. Также он позволяет применять параметры оптимизации в любом порядке, а не в фиксированной последовательности, которую навязывает URL-интерфейс. Вот пример: воркер передаёт данные изображения напрямую в Images API, объединяет операции в цепочку и получает обработанный результат в виде потока:

На высоком уровне так выглядит движение данных через наши сервисы:

Труба на схеме обозначает сокетное соединение между посредником и Images, через которое данные передаются от одного процесса к другому через буфер ядра.

Binding взаимодействует с Images через сокетное соединение, управляемое Workers runtime. Сокет — это канал связи между двумя процессами. У каждого конца сокета есть буферы, управляемые ядром операционной системы; эти буферы — временные области, где данные остаются после записи одной стороной, но до чтения другой.

Hyper управляет соединением на стороне сервиса Images: читает входящие запросы из сокета и пишет ответы обратно в него.

Когда запрос использует Images binding, сервис Images читает входные данные, выполняет запрошенные операции оптимизации и кодирует результат. Затем он передаёт всё закодированное изображение hyper как один непрерывный блок в памяти.

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

Если читатель на другом конце быстрый, hyper может сбросить всё за один проход — в исходящем буфере будет место, потому что читатель потребляет данные по мере поступления. Как только все данные отправлены, hyper вызывает shutdown на сокете, сигнализируя, что соединение завершено и больше данных записано не будет. Но если читатель медленнее (хотя бы на несколько миллисекунд), исходящий буфер заполняется, и hyper должен ждать, пока появится место, чтобы продолжить запись.

Локальное соединение

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

Этот путь хорошо подходил для первого релиза и повторял архитектуру URL-интерфейса. Но со временем связь с FL стала ограничением: любое изменение binding приходилось согласовывать с циклом релизов FL.

В декабре 2025 года команда Images заменила FL новым посредником — внутренним worker binding, который работает на той же машине. В исходной архитектуре данные шли через FL по сетевым сокетам; этот путь нёс накладные расходы полного конвейера обработки FL, такие как DNS-lookup'ы и маршрутизация.

Внутренний binding заменил их на Unix-сокеты, чтобы напрямую соединить сервисы на одной машине, минуя FL и накладные расходы сетевого стека. Это ускорило путь запроса к Images и дало команде независимый контроль над релизами binding.

В течение нескольких дней после выкатки мы получили первый отчёт от клиента.

200 OK (не OK)

Первый признак проблемы пришёл от клиента с нестандартной конфигурацией: два уровня обработки изображений, где один pipeline был вложен в другой.

Сначала их воркер с помощью Images binding компоновал несколько больших исходных изображений из R2 — JPEG-фон и PNG-оверлеи — в один объединённый JPEG. Затем результат дополнительно сжимался, транскодировался и изменялся размер через URL-интерфейс.

Баг возникал на обратном пути внутреннего pipeline, где ответ обрезался до того, как достигал внешнего.

Внутренний pipeline (transformation binding) отвечал за компоновку. Внешний pipeline (transformation URL) отвечал за оптимизации доставки: масштабирование и конвертацию формата. Такая многоуровневая схема означала, что когда внутренний pipeline молча возвращал обрезанный ответ, видимая ошибка появлялась на уровень выше:

Внешний pipeline получал от внутреннего HTTP 200 с заголовком Content-Length, который обещал несколько мегабайт. Фактическое тело было лишь частью от этого: в одном запросе из ожидаемых 3,3 МБ пришло всего около 200 КБ. Ошибка всплывала во внешнем pipeline, но обрезка могла произойти в binding, посреднике, сервисе Images или где-то между ними.

Когда браузер получает обрезанное изображение, результат виден невооружённым глазом. В зависимости от формата изображение либо отрисовывается частично (например, с отсутствующей или серой нижней частью), либо полностью не декодируется и отображается как битое.

Отладка вслепую

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

• Сборка репродукции. Мы собрали воркер, повторяющий вложенную схему клиента, и постепенно убирали уровни, пока не смогли воспроизвести баг только с binding. Небольшой скрипт отправлял запросы пачками. На одном из первых прогонов 19 из 25 запросов упали. Объём данных, которые всё-таки приходили, — примерно 200 КБ — настораживающе близко к размеру сокетного буфера в продакшене. Это подтвердило, что проблема не связана с конфигурацией клиента, и дало надёжный способ воспроизводить баг по запросу.
• Проверка таймаутов. Сначала мы подозревали, что обрезка связана с поведением таймаутов (то есть соединение закрывалось по истечении лимита времени). Эта теория не подтвердилась: обрезка не коррелировала с длительностью запроса.
• Обновление версии hyper. Когда баг впервые зарепортили, мы использовали 0.14.x, а последняя версия hyper была около 1.8.x. Мы протестировали версии 0.14, 1.7 и 1.8 — на случай, если самый очевидный ответ окажется правильным (и самым простым). Но баг проявлялся в каждой версии, значит, upstream-исправления не было.
• Локальное воспроизведение. Мы запускали интеграционные тесты на macOS и Debian-виртуалке. Даже под значительной нагрузкой локальные запросы никогда не падали. Прямые curl-запросы к сокету binding и повтор отловленных запросов всегда работали. Баг проявлялся только на полном продакшен-пути при реальной конкурентности и реальном клиенте Workers runtime на другом конце сокета. Это натолкнуло нас на подозрение, что виноват сам runtime.
• Исключение Workers runtime. Мы изучили HTTP-клиент, который Workers runtime использует для связи с Images через сокет binding. Ни на одной из сторон соединения в трассировках не было системных вызовов, указывающих на неожиданное закрытие или преждевременное завершение. Клиент вёл себя корректно, и несколько других сервисов использовали того же клиента без проблем.
• Распределённая трассировка. Изучив сквозные трассировки запросов, мы подтвердили, что обрезанное тело уже присутствовало до того, как достигало внешнего уровня трансформации в схеме клиента. Это сузило проблему до внутреннего pipeline — пути binding через сервис Images.
• Инструментирование посредника. Мы добавили инструментирование в посредник, чтобы измерять размеры тел перед пересылкой ответа. Тела уже были обрезаны к моменту выхода из сервиса Images, так что посредник был исключён.
• Углублённая трассировка внутри Images. На уровне сервиса запрос обрабатывался, изображение корректно кодировалось, и ответ отправлялся с HTTP 200.

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

Зерно истины

Инструменты отладки на уровне приложения показывали лишь то, что система считала, что делает. Но по мнению системы всё было в порядке: трассировка утверждала, что ответ отправлен; логи не сообщали об ошибках; сервис Images возвращал 200 на каждый запрос.

Чтобы увидеть, что система делала на самом деле, мы подключили strace к сервису Images. strace записывает системные вызовы, которые процесс делает ядру; это позволило показать, какие именно байты были записаны, когда вызывался shutdown и посылал ли клиент сигнал завершения.

Настройка трассировки была деликатной. strace работает, перехватывая системные вызовы по мере их выполнения, что добавляет небольшие накладные расходы по времени к каждому вызову. Фильтрация узкого набора системных вызовов держала эти накладные расходы минимальными. Однако расширение фильтра замедляло процесс ровно настолько, чтобы сдвинуть тайминг между flush и проверкой shutdown — и баг полностью исчезал. Одно это уже подкрепляло теорию о тайминг-зависимости проблемы.

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

При успешном запросе ответ пишется кусками по мере освобождения сокетного буфера, а shutdown вызывается только после отправки всех данных. Например, это может выглядеть так:

Когда мы воспроизвели баг, упавший запрос выглядел так:

Здесь есть только одна запись — лишь заголовки и крошечная часть тела — перед немедленным вызовом shutdown. Из ответа в 14,9 МБ было отправлено около 219 КБ. Оставшиеся ~14,8 МБ данных изображения никогда не покидали внутренний буфер hyper, и не было никакого сигнала завершения от клиента между записью и shutdown. Вместо этого сервис Images преждевременно закрывал соединение самостоятельно, искренне полагая, что работа завершена.

Упавшие запросы подтвердили, что баг — состояние гонки, которое срабатывало непостоянно. Успех или провал зависели от того, перекрывались ли операции flush и shutdown, и это менялось от запроса к запросу. Когда буфер был полон в тот самый момент, когда hyper решил, что соединение завершено, данные терялись.

Когда читатель потребляет медленнее, чем hyper пишет, исходящий буфер заполняется. Если hyper закрывает соединение до того, как буфер опустеет, то лишь часть ответа попадает к посреднику; эти неполные данные пересылаются обратно в Workers runtime и клиенту.

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

Этих нескольких миллисекунд обратного давления, внесённых улучшением, которое ускорило всё остальное, хватило, чтобы выявить изъян, который скрывался на виду.

Внутри цикла dispatch

Жизненный цикл HTTP/1-соединения в hyper управляется конечным автоматом в файле под названием dispatch.rs. Он выполняет цикл, который читает запросы, пишет ответы, сбрасывает буфер записи в сокет и решает, когда закрываться. В упрощённом виде:

Точнее, именно let _ перед poll_flush — это место, где живёт баг.

В Rust let _ = expr отбрасывает результат выражения, включая Poll::Pending — сигнал о том, что flush ещё не завершён. В буфере flush может остаться несколько мегабайт, но цикл об этом никогда не узнаёт.

Когда запрос падает, последовательность событий выглядит так:

1. Сервис Images завершает кодирование изображения и передаёт весь ответ hyper как один блок в памяти.
2. Hyper записывает блок во внутренний буфер и помечает состояние записи как Writing::Closed. С точки зрения кодирования работа сделана — кодировать больше нечего.
3. Hyper вызывает poll_flush, чтобы перенести буферизованные данные в сокет. В нашем примере сокет принял около 219 КБ. Оставшиеся ~14,8 МБ остаются в буфере hyper. Сокет полон, поэтому ядро возвращает Poll::Pending.
4. poll_loop отбрасывает Poll::Pending с помощью let _.
5. Он проверяет wants_read_again(). Полный запрос уже получен, поэтому возвращается false.
6. poll_loop возвращает Poll::Ready(Ok(())), сигнализируя, что цикл завершён, хотя flush ещё не сделан.
7. Срабатывает poll_shutdown(). Выполняется системный вызов SHUT_WR.
8. Клиент получает 219 КБ и EOF (end-of-file), указывающий, что соединение закрыто, хотя он ожидает 14,9 МБ.

На втором шаге hyper помечает операцию записи как завершённую, как только тело ответа оказывается в буфере (то есть когда кодирование закончено), а не когда данные фактически сброшены. В большинстве случаев flush завершается за один проход, и это различие незаметно. В редких случаях, когда сокетный буфер полон, flush приходится ждать — но hyper не ждёт. Байты всё ещё сидят в буфере hyper, ожидая сброса в сокет. Hyper при этом закрывает соединение с этими данными всё ещё в буфере.

Это также объясняет, почему curl никогда не воспроизводил баг. Curl читает данные так быстро, как они приходят: сокетный буфер никогда не заполняется, flush всегда завершается мгновенно, и отброшенное возвращаемое значение безобидно. Продакшен-путь с читателем, который иногда паузил на несколько миллисекунд, был единственной конфигурацией, где буфер заполнялся в нужный момент.

Не забывайте сбрасывать буфер

После недель расследования само исправление было концептуально простым. Hyper должен был проверять, завершён ли flush, прежде чем двигаться дальше.

Наш reproduction-воркер подтвердил, что баг существует, но не мог объяснить, почему падает конкретный запрос. Прежде чем писать исправление, нам нужен был тест, который мог бы спровоцировать точные сокетные условия внутри hyper.

Мы знали условия, вызывающие баг: сокет, который принимает один кусок данных, а затем блокируется. Для контролируемого сценария мы построили обёртку вокруг TCP-потока, имитирующую полный сокетный буфер. Обёртка принимала 8 КБ при первой записи, а затем возвращала Poll::Pending на каждой последующей записи, имитируя читателя, который перестал опустошать буфер.

Тест отправлял 500 КБ ответа через этот ограниченный сокет и проверял, вызывает ли hyper shutdown, пока в буфере остаётся 492 КБ. Без исправления — вызывал. С исправлением — ждал.

Сначала мы применили исправление в цикле dispatch hyper. Вместо отбрасывания результата poll_flush мы проверяли, завершён ли flush на самом деле:

Если flush не завершён, цикл возвращает Poll::Pending асинхронному runtime. Runtime ждёт, пока сокет не станет доступен для записи, а затем будит задачу, чтобы продолжить flush. Соединение закрывается только после того, как все данные отправлены.

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

Хотя первоначальное решение работало, цикл dispatch был неправильным местом для исправления. Ранний возврат Poll::Pending мог замедлять другие операции на том же соединении, уменьшая частоту опроса чтения и вызывая нежелательное обратное давление. Также это корректно не обрабатывает keepalive-соединения, где одно соединение обрабатывает несколько запросов подряд — они должны оставаться пригодными к использованию, даже пока предыдущий ответ всё ещё сбрасывается. Ни одна из этих проблем не затрагивала наш сервис (где keepalive отключён), но обе могли повлиять на других пользователей hyper, если бы исправление было предложено upstream.

Мы проследили жизненный цикл соединения hyper и нашли более точечный подход. Вместо изменения поведения цикла dispatch мы применили исправление в том месте, где shutdown вызывается на самом деле. Перед закрытием сокета hyper должен сначала сбросить оставшиеся данные в буфере:

Это оставляет цикл dispatch без изменений. Flush добавляется только в тот точный момент, где иначе произошла бы потеря данных — непосредственно перед shutdown.

Что осталось с нами

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

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

Прорыв случился благодаря инструментарию уровня ядра — strace, единственному слою, который фиксирует, что на самом деле происходило на сокете. Базовый баг жил в нескольких миллисекундах между частичным flush и преждевременным shutdown — окне, которое открылось только после того, как мы ускорили систему.

Мы влили исправление и детерминированный тест в hyperium/hyper через PR #4018. Оно появится в будущем релизе hyper, гарантируя, что любой сервис, использующий HTTP/1-реализацию hyper, не потеряет данные ответа из-за того же состояния гонки.

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

Изначально Images binding покрывал только трансформации удалённых изображений. В начале этого месяца мы объявили, что Images binding теперь поддерживает операции для hosted-изображений, давая разработчикам единый способ строить медиа-насыщенные приложения на Cloudflare.

Подробнее о том, как работает binding, — в нашей документации.

Сегодня многие пишут код с помощью ИИ-агентов. Но стоит агенту понадобиться что-то задеплоить — а для этого зарегистрироваться и создать аккаунт, — он сталкивается с интерфейсами, рассчитанными на людей: браузерный OAuth-флоу, дашборд, по которому надо кликать, API-токен, который нужно скопировать и вставить, запрос многофакторной аутентификации. Для фонового агента это жёсткий стоп.

Новая функция убирает этот барьер: агенты теперь могут сразу деплоить сайты, API и агентов, не регистрируя аккаунт.

Любой агент теперь может выполнить wrangler deploy --temporary и задеплоить Worker в Cloudflare. Временное развёртывание остаётся живым 60 минут, в течение которых вы можете забрать временный аккаунт и сделать его своим навсегда. Если нет — он истечёт сам.

• Cloudflare запустила временные аккаунты для ИИ-агентов.
• Любой агент может выполнить wrangler deploy --temporary и задеплоить Worker без регистрации.
• Временное развёртывание живёт 60 минут; за это время аккаунт можно забрать навсегда.
• Wrangler подсказывает агенту флаг --temporary, если тот ещё не аутентифицирован.
• Агент может итерировать код и перезаливать его в том же 60-минутном окне.

Почему бесшовные развёртывания важны для ИИ-агентов

Бесшовные временные аккаунты важнее, чем может показаться на первый взгляд:

• Фоновые ИИ-сессии работают без человека в цикле и становятся нормой. Любой шаг аутентификации, требующий браузера, копирования-вставки или «кликните здесь в течение 60 секунд», означает, что агент застрянет и может решить деплоить куда-то ещё.
• Пробовать и ошибаться — суперсила агента. Агентам нужен короткий цикл «написал → задеплоил → проверил». Им нужны дешёвые одноразовые цели для развёртывания, чтобы они могли сделать curl на свой вывод и решить, получилось ли правильно.
• Платформы для агентов строят собственные способы, чтобы деплой кода «просто работал» без лишних шагов и учётных данных. Пользователи начинают ожидать, что процесс работает без необходимости регистрироваться в других сервисах, которыми они раньше не пользовались и о которых не слышали.

Как это работает

Временные аккаунты построены вокруг Wrangler — инструмента командной строки (CLI) для платформы разработчиков Cloudflare, который позволяет создавать новые проекты, управлять их конфигурациями и ресурсами, а также деплоить и обновлять их.

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

Когда агент это обнаруживает и снова запускает wrangler deploy с флагом --temporary, Cloudflare подготавливает временный аккаунт для использования агентом, выдаёт Wrangler API-токен и предоставляет claim URL, который агент может передать человеку.

Как забрать аккаунт

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

Если вы не заберёте эти временные аккаунты в течение 60 минут, они будут автоматически удалены.

Контекст и ограничения

Это лишь один из способов убрать барьер регистрации для агентов. Недавно Cloudflare объявила о партнёрстве со Stripe и о новом протоколе, который позволяет агентам провижионить Cloudflare от имени пользователей — создавать аккаунт, оформлять подписку, регистрировать домен и получать API-токен для деплоя кода, без копирования токенов и ввода данных кредитной карты. В прошлом месяце Cloudflare вместе с WorkOS запустила auth.md, который может принять любой желающий, чтобы агенты могли создавать новые аккаунты с помощью устоявшихся стандартов OAuth.

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

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

Cloudflare приобрела VoidZero — компанию-основателя Vite, Vitest, Rolldown, Oxc и Vite+.

Вся команда VoidZero переходит в Cloudflare, включая Эвана Ю.

Проекты сохраняют открытый исходный код, лицензию MIT и независимость от поставщика.

Cloudflare выделяет $1 млн на фонд экосистемы Vite для поддержки сопровождающих.

Vite набирает около 129 млн загрузок в неделю; плагин Cloudflare для Vite — 14 млн.

Дашборд Cloudflare уже работает на Vite, а CLI компания переведёт на него в будущем.

VoidZero появилась как попытка собрать в единую экосистему наиболее востребованные инструменты фронтенд-разработки. Vite — система сборки, ставшая фактическим стандартом для современных JavaScript-приложений. Vitest отвечает за тестирование, Rolldown заменяет Rollup на Rust, а Oxc — это платформа инструментов для JavaScript/TypeScript на Rust, включающая компилятор, линтер Oxlint, форматировщик и другие компоненты.

Cloudflare подчёркивает, что не собирается перекраивать планы развития проектов под свои нужды. По аналогии с приобретением Astro ранее в этом году, команды сохраняют автономию, а код остаётся открытым. Главное отличие в том, что Vite — это не просто фреймворк, а фундамент, на котором строятся Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, TanStack Start и даже Next.js — в экспериментальном проекте vinext.

Что меняется для разработчиков

В краткосрочной перспективе — ничего. Vite, Vitest, Rolldown, Oxc и Vite+ продолжат развиваться по прежним планам. Эван Ю и команда VoidZero остаются лидерами проектов. Cloudflare обещает направлять инженерные ресурсы на развитие инструментов, а не на их смену бренда или закрытие.

В долгосрочной перспективе Cloudflare намерена построить собственный CLI cf поверх Vite. Цель — чтобы команды cf dev, cf build и cf deploy чувствовали себя как расширение привычного vite dev. Это должно упростить развёртывание Vite-приложений на платформу Cloudflare Workers, сохранив при этом переносимость кода между любыми хостингами.

Почему это важно

Vite сегодня — один из немногих инструментов, которые объединяют всю JavaScript-экосистему. По данным Cloudflare, Vite набирает 129 млн загрузок в неделю, а официальный плагин @cloudflare/vite-plugin — 14 млн. С ростом ИИ-агентов, которые генерируют код и выполняют итерации с ним в цикле, скорость сборки, тестирования и линтинга становится критичной. Весь стек VoidZero оптимизирован для таких сценариев: Rust-инструменты работают на порядок быстрее аналогов на JavaScript.

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

Выводы

Приобретение VoidZero — значимый корпоративный вклад в открытую инфраструктуру JavaScript. Cloudflare получает влияние на инструмент, который используют миллионы разработчиков, а сообщество — гарантии независимости и $1 млн на развитие экосистемы.

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

Источник: Cloudflare Blog — VoidZero is joining Cloudflare

Хотите попробовать Vite на Cloudflare прямо сейчас — выполните npm create vite@latest, а затем npx wrangler deploy.

Разбираем ситуацию по материалу Pragmatic Engineer — охватывает технические подробности vinext, экономику и последствия для коммерческого open source.

Cloudflare выпустила vinext — замену Next.js на базе Vite, которая деплоится в Cloudflare Workers одной командой.

Один инженер + ИИ-агент OpenCode + Opus 4.5 = одна рабочая неделя вместо нескольких лет инженерного труда.

По заявлению Cloudflare: сборка до 4 раз быстрее, клиентские бандлы на 57% меньше.

vinext покрывает 94% API Next.js, но официально экспериментальна: не прошла нагрузочного тестирования.

ИИ удешевил переписывание сложного ПО примерно в 100 раз — под угрозой оказались проприетарные «рвы» коммерческих open source-проектов.

Vercel ($9 млрд оценка) потеряла ключевое конкурентное преимущество: уникальный формат билда Next.js.

Next.js и Vercel: как устроен коммерческий «ров»

Next.js — самый популярный полностековый React-фреймворк. По данным Stack Overflow Developer Survey 2025, его используют около половины разработчиков на React. Проект открытый, но содержится преимущественно силами Vercel.

Хитрость в том, что Next.js собирает проекты с помощью Turbopack — опционального инструмента Vercel, написанного на Rust (используется прежде всего в dev-режиме). Результат сборки — проприетарный, недокументированный формат. Инженер Netlify Эдуардо Боукаш объяснял это так:

Формат вывода сборки Next.js является проприетарным и недокументированным — он используется в деплоях Vercel для инициализации нужной инфраструктуры. Это означает, что любые другие хостинг-провайдеры вынуждены опираться на недокументированные API, которые могут менять поведение без предупреждения в минорных и патч-релизах.

В итоге сложилась система: Next.js бесплатен и открыт, но наилучший опыт разворачивания — только на Vercel. Альтернативные провайдеры вынуждены угадывать поведение недокументированного формата. Это умная стратегия, превращающая open source-проект в воронку монетизации.

Чтобы сломать эту схему, нужно заменить Turbopack на стандартный инструмент — например, Vite, который лидирует в экосистеме JS по данным State of JS 2025. Именно это и сделал Cloudflare.

Что такое vinext и как его создали

Идея проста: убрать Turbopack, поставить Vite, сделать так, чтобы приложения на Next.js собирались в стандартный формат и деплоились на любой платформе — в том числе на Cloudflare Workers.

Cloudflare публично заявила, что на это ушла одна рабочая неделя одного инженера, который использовал агент OpenCode (open source coding agent) совместно с моделью Claude Opus 4 (в источнике — «Claude Opus 4 (в источнике — «Opus 4.5»)»; такой модели в публичном портфеле Anthropic нет, по всей видимости имеется в виду Opus 4):

На прошлой неделе один инженер и модель ИИ с нуля пересобрали самый популярный front-end фреймворк. Результат — vinext (произносится «ви-некст»): drop-in замена Next.js на Vite, которая деплоится в Cloudflare Workers одной командой. В ранних бенчмарках сборка production-приложений ускорилась до 4 раз, а клиентские бандлы уменьшились до 57%. И у нас уже есть клиенты, которые запустили его в production. Вся работа обошлась примерно в $1 100 на токены.

Ядро Next.js за 10 лет выросло примерно до 194 000 строк кода. vinext занимает около 67 000 строк — более компактная реализация, которая не поддерживает устаревшие API и охватывает 94% публичного API Next.js. Оставшиеся 6% — сложные граничные случаи.

Что именно сделал Cloudflare

• Взял публичный API Next.js
• Переписал поведение через Vite
• Создал формат вывода сборки, совместимый с поведением оригинала
• Добавил Agent Skill для миграции существующих Next.js-проектов одной командой

Миграционный скилл — отдельная деталь, показательная для эпохи ИИ. Он работает с Claude Code, OpenCode, Cursor, Codex и другими агентами:

Cloudflare не только использовала ИИ для создания vinext, но и встроила ИИ в процесс его распространения — чтобы миграция клиентских проектов тоже была автоматической.

ИИ делает «невозможное» тривиальным

До появления современных ИИ-агентов переписать Next.js «с нуля» было теоретически возможным, но практически исключённым. Это требовало бы многолетних усилий команды инженеров. При этом сообщество сомневалось бы в долгосрочной поддержке любого форка — Vercel доказывала свою надёжность 10 лет, а любой новый игрок не имеет этого кредита доверия.

Теперь ситуация изменилась. По оценке Pragmatic Engineer, ИИ ускорил создание vinext примерно в 100 раз. Cloudflare завершила проект, измеряемый в инженерных годах, за одну инженерную неделю.

Важно, что всеобщий рост продуктивности от ИИ в среднем куда скромнее. По данным The Pragmatic Summit (Сан-Франциско, 2026), самооценка разработчиков даёт около 10% прироста. Ключевое условие для 100-кратного ускорения — наличие полного тестового покрытия, которое позволяет ИИ-агентам верифицировать каждый шаг.

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

Сам факт, что Next.js имеет исчерпывающее тестовое покрытие — это одновременно его сила и слабость: ИИ использовал тест-сюит как спецификацию для переписывания. Cloudflare даже поблагодарила команду Vercel в объявлении:

Мы хотим отметить команду Next.js. То, что их API хорошо задокументирован, а тест-сюит настолько полный, — один из главных факторов, которые сделали этот проект возможным.

Качество под вопросом: экспериментальность vs маркетинг

Cloudflare открыла своё объявление сильным тезисом: «клиенты уже запустили в production». Vercel немедленно указала на уязвимости в безопасности, а CEO Гильермо Рауч связал проект со стереотипом «вайб-кодинга» — небрежной работы без понимания деталей.

Претензия оказалась обоснованной: важная деталь про «production» была закопана в тысяче слов после начала объявления:

Мы хотим быть честными: vinext экспериментален. Ему ещё нет недели, и он не прошёл реального нагрузочного тестирования. (...) Мы работаем с National Design Studio на одном из их бета-сайтов, CIO.gov.

«Клиент в production» у Cloudflare — это бета-сайт без значимого трафика. Это нетипично для компании, обычно отличающейся точностью формулировок. Vercel имела право поднять вопрос безопасности.

Тем не менее это не отменяет главного вывода: ИИ способен снизить стоимость разработки примерно в 100 раз и выдать работоспособный результат за приемлемую сумму. Доработка безопасности и надёжности потребует дополнительного времени — но это уже другой разговор.

Новая угроза для коммерческого open source

Cloudflare и Vercel — известные соперники в борьбе за платформу разработчиков. CEO обеих компаний регулярно обмениваются ударами в публичном пространстве.

Но реальная ставка здесь — бизнес-модель коммерческого open source. Стратегия Vercel была классической:

1. Создать и поддерживать Next.js, обеспечив лучший developer experience.
2. Оптимизировать Vercel под специфический (и недокументированный) формат вывода Next.js.
3. Большинство разработчиков, выбравших Next.js, деплоят на Vercel — ради лучшей интеграции.
4. Повторять годами, пока бизнес не оценят в $9 млрд (оценка октября 2025 года).

В основе стратегии лежали два предположения: (1) переписать Next.js дорого и (2) даже если кто-то это сделает, разработчики усомнятся в жизнеспособности альтернативы. ИИ обнулил оба предположения.

Аналогия с WordPress и WP Engine

Похожая история произошла с WordPress и WP Engine в 2024 году. WP Engine «пиратила» усилия Automattic: почти не вкладывалась в R&D, зато продавала WordPress как managed service — дешевле, чем Automattic, тратящая на разработку сотни миллионов.

Разница в том, что Vercel удавалось избегать «фрирайдеров» — благодаря проприетарному формату билда. Теперь этого барьера больше нет: Cloudflare будет синхронизировать каждое обновление Next.js с vinext через ИИ-агентов, и это не потребует серьёзных инвестиций.

Как защититься: стратегии для коммерческих open source-проектов

Если ИИ позволяет конкурентам тривиально переписать ваш продукт, каковы варианты защиты?

Закрыть тест-сюит

Один из очевидных ответов — сделать тесты приватными. SQLite, например, держит свой наиболее полный тест-сюит (TH3) закрытым и продаёт доступ к нему как сервис. Open source-проект для визуального редактирования tldraw объявил о переносе тестов в закрытый репозиторий (хотя потом оказалось, что это была шутка).

Саймон Виллисон прокомментировал тренд:

За последние несколько месяцев стало очевидно, что полный тест-сюит достаточен для написания совершенно новой реализации любой open source-библиотеки с нуля — потенциально на другом языке.

Другие варианты защиты

• Уменьшить open core, увеличить закрытую часть. Перенести расширенные сервисы из source available в полностью закрытый код.
• Профессиональный support. ИИ может повысить качество поддержки при правильном применении — а это сложно скопировать.
• Живое сообщество. Meetup'ы и реальная аудитория создают связь, которая выходит за рамки кода. Трудно представить встречи vinext-пользователей — а встречи Next.js-разработчиков уже существуют.
• Инфраструктура как ров. В мире, где ПО легко скопировать, владение и управление инфраструктурой становится важнейшим преимуществом: меньшая задержка, выше надёжность, лучшая цена.

Что это значит для индустрии

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

С другой стороны, появится класс «миграционных агентов», которые провайдеры будут создавать для перетягивания клиентов. Cloudflare уже встроила такой агент в vinext. Это «AI-native» стратегия захвата рынка, которую скопируют другие.

Конкуренция в технологической индустрии становится жёстче и быстрее. По словам Laura Tacho с The Pragmatic Summit:

ИИ — это ускоритель, мультипликатор, и он движет организации в разных направлениях.

В частном случае vinext — пока неясно, насколько популярным он станет и насколько глубок «ров» Vercel вокруг экосистемы Next.js в целом. Переписать фреймворк — не то же самое, что стать жизнеспособной платформой-as-a-service. Доверие, стабильность, поддержка и developer experience накапливались 10 лет.

Выводы

Cloudflare переписала Next.js не из любви к open source, а чтобы разрушить конкурентное преимущество Vercel. Это честная бизнес-война. Но побочный эффект оказался важнее самого конфликта: стало ясно, что ИИ-агенты превращают переписывание сложного ПО из многолетней инвестиции в задачу одной недели.

Для разработчиков это хорошая новость: экосистема Next.js получила стандартизированный формат сборки, а деплой на разные платформы станет проще. Для компаний, строящих бизнес на коммерческом open source, — сигнал тревоги: проприетарные технические «рвы» больше не защищают так, как раньше.

Что по-настоящему защищает — живое сообщество, инфраструктура мирового класса, качество поддержки и репутация, накопленная годами. vinext может стать удобной альтернативой деплоя. Но стать полноценной заменой экосистемы Next.js — задача несравнимо более сложная.

Как вы оцениваете угрозу, которую ИИ создаёт для коммерческого open source? Читайте также: другие материалы об ИИ и open source на tproger.ru.

Источники: Pragmatic Engineer — The Pulse; Cloudflare блог — объявление vinext; State of JS 2025.

• Что в GA: hybrid ML-KEM (Module-Lattice-based Key Encapsulation Mechanism — постквантовый алгоритм согласования ключей, стандартизирован NIST как FIPS 203 — федеральный стандарт США по постквантовой криптографии, утверждён в 2024) в Cloudflare IPsec через draft-ietf-ipsecme-ikev2-mlkem. Hybrid — значит, что в одной handshake параллельно идут классический Diffie-Hellman и ML-KEM, а итоговый ключ собирается из обоих.
• С каким железом совместимо: Cisco 8000 Series Secure Routers начиная с прошивки 26.1.1; Fortinet FortiOS 7.6.6 и выше. Это branch-коннекторы — устройства в филиалах, которые держат туннель к глобальной сети Cloudflare. Совместимость подтверждена тестированием с production-Cloudflare. Реализация Palo Alto Networks (на базе RFC 9370) пока не работает с Cloudflare — у них своя ciphersuite, выпущенная до появления draft.
• Зачем это нужно сейчас: Cloudflare сдвинула цель полного перехода на post-quantum cryptography на 2029 — после ускорений в квантовом железе. Защищаются прежде всего от атак harvest-now-decrypt-later: злоумышленник копит зашифрованный трафик сейчас, чтобы расшифровать позже, после Q-Day — момента, когда квантовые компьютеры станут достаточно мощными, чтобы сломать классические алгоритмы (RSA, ECDH, ECDSA).
• Почему IPsec догнал TLS только сейчас: четыре года разрыва. В TLS hybrid-ключи пошли в production в 2022 (на Cloudflare уже больше двух третей TLS-трафика идут через post-quantum). В IPsec спецификация hybrid ML-KEM появилась только в конце 2025. Часть задержки — споры вокруг QKD (Quantum Key Distribution).
• QKD не вариант: национальные службы информбезопасности США (NSA), Германии (BSI) и Великобритании (NCSC) предупреждают: полагаться только на QKD нельзя. Нужно специальное железо и выделенный физический канал, она не работает в масштабах интернета и не закрывает аутентификацию — подробнее — в FAQ.

Cloudflare IPsec в одном абзаце

Cloudflare IPsec — это WAN-as-a-service (Network-as-a-Service): он заменяет легаси-сетевые архитектуры тем, что подключает дата-центры, филиалы и облачные VPC к глобальной IP Anycast-сети Cloudflare. Клиенты получают упрощённую конфигурацию, high availability (если дата-центр падает, трафик уходит на ближайший живой) и масштаб глобальной сети Cloudflare. Туннели — IPsec, поддерживают site-to-site WAN, исходящие интернет-соединения и подключение к платформе Cloudflare One SASE.

Post-quantum в IPsec: hybrid ML-KEM

Cloudflare IPsec теперь использует post-quantum encryption через hybrid ML-KEM (FIPS 203), чтобы остановить harvest-now-decrypt-later атаки. Так называют сценарий, когда злоумышленник собирает зашифрованные данные сегодня — а расшифровывает их позже, после Q-Day, когда появятся достаточно мощные квантовые компьютеры, способные сломать классическую public-key криптографию, на которой построена безопасность интернета. Cloudflare пишет, что про эти атаки задумывается всё больше организаций, потому что Q-Day приближается быстрее, чем ожидалось.

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) — это алгоритм post-quantum криптографии, основанный на математических задачах решёточной криптографии, для которых пока не известно эффективных квантовых атак. Он не требует специального железа или выделенного физического канала: ML-KEM спроектирован так, чтобы его можно было реализовать программно на обычных процессорах и шифровать им сетевой трафик.

Сам draft-ietf-ipsecme-ikev2-mlkem описывает post-quantum шифрование для IPsec через hybrid ML-KEM: классическая безопасность Diffie-Hellman (хорошо изученная и выдержавшая годы реальных атак) совмещается с post-quantum безопасностью ML-KEM в одном стандартизированном handshake. Конкретно: сначала отрабатывает классический Diffie-Hellman, его выходной ключ шифрует второй обмен с ML-KEM, и выходы обоих обменов подмешиваются в session keys, которые шифруют трафик IPsec data plane через ESP (Encapsulating Security Payload — основной протокол передачи зашифрованных пакетов в IPsec).

Совместимость, проверенная на железе

Раньше Cloudflare объявляла closed beta своей реализации draft-ietf-ipsecme-ikev2-mlkem — её выкатили в production в IPsec-сервисе и тестировали против эталонной реализации strongSwan (популярный open-source IPsec-стек для Linux). Теперь, после GA, подтверждена совместимость с другими вендорами:

• Cisco: клиенты Cisco 8000 Series Secure Routers с прошивкой 26.1.1 и выше могут поднять post-quantum Cloudflare IPsec туннели по draft-ietf-ipsecme-ikev2-mlkem.
• Fortinet: клиенты Fortinet FortiOS 7.6.6 и выше могут поднять post-quantum Cloudflare IPsec туннели до глобальной сети Cloudflare по тому же draft.

Почему совместимость важна (и почему это болит)

Обновить криптографию — задача на годы. Цель Cloudflare 2029 требует концентрированной работы. Поэтому компания надеется, что IPsec-сообщество продолжит фокусироваться на разработке совместимых стандартов вроде draft-ietf-ipsecme-ikev2-mlkem.

Важность стандартов проще понять на сравнении с TLS. Полная спецификация hybrid ML-KEM для IPsec, draft-ietf-ipsecme-ikev2-mlkem, стала доступна только в конце 2025 года. Это примерно на четыре года позже, чем поддержка hybrid ML-KEM появилась в TLS. (Cloudflare включила hybrid post-quantum key agreement для TLS ещё в 2022, до того как NIST окончательно утвердил стандартизацию ML-KEM, — потому что TLS-сообщество быстро сошлось на одном совместимом подходе и продавило его в production. Сегодня более двух третей человеко-генерированного TLS-трафика к сети Cloudflare защищены hybrid ML-KEM.)

Четырёхлетнее отставание частично объясняется тем, что IPsec-сообщество долго присматривалось к Quantum Key Distribution (QKD). Механизм её интеграции в IKEv2 (Internet Key Exchange version 2 — протокол согласования ключей IPsec) описан в RFC 8784, опубликованном в 2020 (сам RFC посвящён подмешиванию pre-shared keys в IKEv2 — а такие ключи могут поставляться, в частности, через QKD). Cloudflare уже писала, почему QKD не входит в их post-quantum стратегию: для QKD нужны специализированные устройства и выделенный физический канал между двумя сторонами — а это значит, что в масштабах интернета QKD не работает. Плюс QKD не решает задачу аутентификации, поэтому post-quantum криптография всё равно нужна, чтобы остановить активных атакующих. Найти реализации QKD, которые совместимы между разными вендорами, тоже сложно.

Американская NSA (National Security Agency), немецкая BSI (Bundesamt für Sicherheit in der Informationstechnik) и британская NCSC (National Cyber Security Centre) — все три национальные службы информбезопасности — предупреждают: нельзя полагаться только на QKD. Post-quantum криптография, в свою очередь, работает на железе, которое у вас и так есть, аутентифицирует обе стороны и работает end-to-end через интернет.

RFC 9370 и ciphersuite bloat

RFC 9370, опубликованный в 2023, открыл двери post-quantum криптографии в IPsec — он разрешил параллельно с классическим Diffie-Hellman прогонять до семи дополнительных обменов ключами. Однако RFC 9370 не указал, какие именно ciphersuite (наборы криптографических алгоритмов) должны использоваться в этих параллельных обменах. В отсутствие такой спецификации часть вендоров выпустила ранние реализации на базе RFC 9370 ещё до того, как появился draft hybrid ML-KEM, — и определили собственные ciphersuite, в том числе не стандартизированные NIST. Это ровно тот «ciphersuite bloat», от которого предостерегал NIST в SP 800-52 r2. И риск для совместимости проявился на практике: Cloudflare IPsec пока не взаимодействует с реализацией Palo Alto Networks по RFC 9370, потому что та была запущена до появления draft-ietf-ipsecme-ikev2-mlkem.

Хорошая новость в том, что теперь у нас есть draft-ietf-ipsecme-ikev2-mlkem, который заполняет пробелы RFC 9370 — явно прописывая hybrid ML-KEM как один из механизмов согласования ключей, который можно гонять параллельно с классическим Diffie-Hellman. Cloudflare надеется добавить Palo Alto Networks в список совместимых post-quantum branch-коннекторов по мере того, как индустрия будет консолидироваться вокруг draft-ietf-ipsecme-ikev2-mlkem.

Но путь к совместимым post-quantum IPsec-стандартам ещё не пройден. draft-ietf-ipsecme-ikev2-mlkem закрывает шифрование. Но IPsec нужны стандарты для post-quantum аутентификации — иначе после Q-Day атакующие смогут проводить активные атаки на живые системы (подменять стороны handshake), даже если шифрование стоит. Cloudflare надеется, что IPsec-сообщество сосредоточится на совместимых PQC-реализациях, а не уходит в нишевые сценарии с QKD.

Зачем это всё клиентам Cloudflare

Cloudflare обещает не брать с клиентов отдельных денег за post-quantum: фича включена в существующие тарифы IPsec и не требует обновления железа на стороне клиента — нужны только свежие прошивки Cisco/Fortinet и поддержанная их сторона.

В TLS-мире уже больше двух третей человеко-генерированного трафика к сети Cloudflare идёт через post-quantum шифрование. В мире site-to-site IPsec до этого момента всё было иначе.

Что делать сегодня

Если у вас Cloudflare IPsec и Cisco 8000/Fortinet FortiGate в филиале, начните с чек-листа: версия прошивки (Cisco 26.1.1+, FortiOS 7.6.6+), включить параметр post-quantum hybrid в конфигурации IKEv2-туннеля, проверить логи на успешный обмен ML-KEM. Если у вас Palo Alto Networks или другой вендор, который пока запускает RFC 9370 без draft-ietf-ipsecme-ikev2-mlkem, — следить нужно за обновлениями прошивок самого вендора (Palo Alto обещает присоединиться к draft, как только индустрия консолидируется). До этого момента катить ранний vendor-specific вариант не стоит — легко получить туннели, которые не поднимаются между разными вендорами.

Оригинальный пост Sharon Goldberg и Amos Paul — на blog.cloudflare.com. Спецификация: draft-ietf-ipsecme-ikev2-mlkem на datatracker.ietf.org. Стандарт ML-KEM: FIPS 203 на csrc.nist.gov.

Релиз состоялся 13 апреля 2026 года в рамках Agents Week — тематической недели Cloudflare, посвящённой инфраструктуре для ИИ-агентов. В бете продукт был 9 месяцев — первый анонс прошёл в июне 2025-го. Sandboxes доступны как часть платформы Cloudflare Workers.

— Что это. Persistent Linux-окружение на базе Cloudflare Containers. Запрос по имени: если сэндбокс запущен — получаете его, если нет — стартует on-demand, засыпает в простое, пробуждается на следующем вызове.

— Для чего. Безопасное исполнение кода, который пишут LLM-агенты (coding agents, data-analysis, CI-like задачи). Публичный partner — Figma Make.

— Цена. Active CPU Pricing — $0,00002 за vCPU-секунду. За idle не платите, только за реально использованные циклы.

— Лимиты. На standard-плане: 15 000 одновременных lite-инстансов (урезанные CPU и RAM для коротких задач), 6 000 basic (сбалансированные) и 1 000+ больших (увеличенные ресурсы, доступ по запросу).

— Безопасность. Secure credential injection через programmable egress proxy — агент не видит токенов, они подставляются на сетевом уровне.

Что это за сэндбокс

Sandbox в терминах Cloudflare — это полноценный контейнер с shell, файловой системой и background-процессами. Не V8 isolate (эфемерные изоляты для одноразовых задач в миллисекундах закрывает соседний продукт Dynamic Workers, он анонсирован в ту же неделю), а именно Linux-контейнер. Запросили по имени — получили его же; в простое спит, при обращении просыпается. ID доступен из любой точки сети Cloudflare.

Внутри сэндбокса работает persistent code interpreter для Python, JavaScript и TypeScript. Состояние переменных и импортов сохраняется между вызовами, как в Jupyter notebook. Это значит, что агент выполняет код пошагово и держит промежуточные результаты в памяти — не поднимая контекст заново на каждом вызове. Остальные языки внутри сэндбокса тоже работают, но без сохранения состояния — как обычные shell-команды.

Что внутри

SDK и API

Официальный SDK — @cloudflare/sandbox, актуальная версия 0.8.9. Базовое использование из Cloudflare Worker:

Методы SDK покрывают типовой жизненный цикл: запуск shell-команд, gitCheckout для клонирования репозиториев, writeFile, runCode, createCodeContext, startProcess, exposePort, terminal, watch, snapshot, backup и restore.

Терминал и файловая система

Для интерактивных сценариев есть полноценный pseudo-terminal через WebSocket, совместимый с xterm.js (поставляется отдельный addon @cloudflare/sandbox/xterm). Буфер вывода хранится на сервере — реконнект воспроизводит пропущенные строки без потерь.

Изменения файловой системы можно отслеживать в реальном времени: SSE-стрим поверх Linux inotify. Эта фича вышла в марте 2026-го и особенно полезна для агентов, которые должны реагировать на появление артефактов сборки.

Бэкапы и быстрый старт

Cloudflare сохраняет полный disk state сэндбокса — OS-конфиг, установленные зависимости, исходники — в R2 с tiered caching. Холодный старт с git clone axios и npm install занимает 30 секунд, а восстановление из backup — 2 секунды. Для таких сценариев, как параллельное исследование нескольких гипотез агентом, это меняет правила: каждую ветку стартуют из одного сохранённого состояния. Полноценные snapshots (более лёгкие, чем backup) Cloudflare обещает выкатить в ближайшие недели.

Безопасность credentials

Самая интересная часть — programmable egress proxy. Все исходящие запросы сэндбокса проходят через outbound Worker, который подставляет токены на сетевом уровне. Агенту не нужно знать секреты API — он делает обычный HTTP-запрос, а токен инжектится по пути. Поддерживаются identity-aware policies и динамическое сужение сети по прогрессу задачи.

A Sandbox today is a full development environment: a terminal you can connect a browser to, a code interpreter with persistent state, background processes with live preview URLs, a filesystem that emits change events in real time, egress proxies for secure credential injection, and a snapshot mechanism that makes warm starts nearly instant.

Для кого это

• Coding agents, которым нужно запускать сгенерированный код без доверия к его содержимому
• Code interpreter для data-analysis-сценариев с сохранением состояния между вызовами
• CI-подобные задачи, где нужна изоляция и контроль выхода в сеть
• Fork-сессии для параллельного исследования гипотез — запуск нескольких сэндбоксов из общего снапшота
• Продуктовая интеграция в app, где пользователь пишет и запускает свой код (как сделала Figma Make)

Чем отличается от конкурентов

Рынок изолированного исполнения кода для агентов уже густонаселён. E2B строит на Firecracker microVM и заявляет покрытие ~50% Fortune 500. Daytona делает Docker-контейнеры с sub-90ms созданием. Modal специализируется на serverless GPU/Python. Vercel Sandbox — тоже Firecracker, сейчас в бете.

Главное отличие Cloudflare — двухуровневая схема: Dynamic Workers (V8 isolates, эфемерное исполнение) для одноразовых задач и Sandboxes (полноценная ОС, persistent state) для сложных сценариев. Всё это доступно в 330+ городах edge-сети Cloudflare, что упрощает работу с региональными пользовательскими данными.

Figma Make создан, чтобы помочь создателям с разным бэкграундом быстрее переходить от идеи к продакшену. Для этого нам нужна была инфраструктура, которая давала бы надёжные и масштабируемые сэндбоксы для запуска недоверенного кода агентов и пользователей.

Что это значит

Sandboxes закрывают важный пробел в стеке agent-infra у Cloudflare: раньше для безопасного исполнения кода LLM-агентов приходилось интегрироваться с E2B, Modal или поднимать Firecracker самостоятельно. Теперь можно остаться в экосистеме Cloudflare — Workers, Durable Objects, R2 и Sandboxes живут в одной сети, с общим биллингом и единым SDK.

Главное конкурентное преимущество — edge-распределение. Для агентов, которые работают с пользовательскими данными в конкретном регионе, это снижает latency и упрощает compliance. Минус — пока нет бенчмарков cold start относительно E2B и Vercel Sandbox в independent-тестах; обещанные 2 секунды восстановления Cloudflare нужно проверять на реальных нагрузках.

Если строите собственный coding agent или code interpreter, попробовать Cloudflare Sandboxes стоит. SDK ставится через npm install @cloudflare/sandbox, для первых экспериментов хватит минимального плана Workers. Полный анонс, deep dive по egress proxy, разбор InfoQ.

Свежий тред на Hacker News снова показал: на прошлых выходных docker pull из Испании стабильно ломался. Причина — судебный приказ от декабря 2024-го, который разрешает La Liga просить всех испанских ISP мгновенно блокировать любые IP без предварительной проверки, если лига считает, что на них ведётся нелегальный стрим футбольного матча.

• Судебный приказ Торгового суда №6 Барселоны (декабрь 2024) разрешает La Liga блокировать любые IP-адреса на время матчей без уведомления сервисов-владельцев.
• Пиратские стримы прячутся за CDN Cloudflare, Vercel, Netlify, где один IP обслуживает тысячи легитимных сайтов — в итоге блокируются Docker Hub, Twitch, Steam, LinkedIn, X, часть ИИ-провайдеров.
• Cloudflare и RootedCON проиграли апелляцию в марте 2025. Правительство Испании в октябре 2025 отказалось вмешиваться. Сезон 2025/26 продлится до 24 мая 2026 — до этого блокировки регулярны.
• Docker уже падал по всей Испании осенью 2025 на несколько дней. Новые жалобы в апреле 2026 — это уже рутина, а не единичный случай.
• Обход — VPN или прокси вне Испании. Для команд с испанскими разработчиками — зеркало реестра, резервный CI-раннер вне страны, жалоба в Еврокомиссию по регламенту 2015/2120.

Что именно ломается

Разработчики из Испании (в основном из Мадрида и Барселоны) сообщают о регулярных сбоях по субботам и воскресеньям во время матчей La Liga. Конкретно ломается:

• docker pull для образов, раздающихся через Docker Hub (Cloudflare CDN)
• GitHub Actions на self-hosted runners в Испании, а также у GitHub-hosted runners, если они тянут образы через испанский ISP
• Vercel-хостинг (фронтенд-сайты внезапно возвращают 5xx)
• Twitch, Steam, LinkedIn, часть Twitter/X — всё, что висит за Cloudflare
• API некоторых LLM-провайдеров, которые используют Cloudflare Workers

По словам Guillermo Rauch (CEO Vercel), La Liga даже не связывается с владельцами инфраструктуры — просто присылает ISP IP-адрес для блокировки. Даже после открытия официального канала связи (апрель 2025) Vercel в мае 2025 жаловался, что их CDN продолжают блокировать «без разбора».

Почему страдает именно инфраструктура

La Liga идентифицирует сайты, где, по их мнению, идёт пиратский стрим, и записывает IP серверов этих сайтов. Но сами стримы стоят за Cloudflare/Vercel/Netlify — эти CDN используют anycast: один и тот же IP-адрес объявляется из десятков дата-центров и обслуживает тысячи клиентов одновременно. Когда La Liga просит ISP заблокировать конкретный IP, отваливаются не только пиратские стримы, но и Docker Hub, SaaS-панели, виджеты поддержки и всё остальное, что делит IP с «подозреваемым».

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

Как мы сюда пришли

• Декабрь 2024: Торговый суд №6 Барселоны выдаёт La Liga разрешение на блокировки без предварительной проверки. Условие одно: «не затрагивать третьих лиц» — условие, которое физически невозможно соблюсти.
• Февраль 2025: первая крупная блокировка IP Cloudflare, массовые сбои в Испании. La Liga обвиняет Cloudflare в «защите преступных организаций».
• Март 2025: Cloudflare и RootedCON проигрывают апелляцию. Суд заявил, что доказательств влияния на третьи стороны нет.
• Апрель–май 2025: CEO Vercel Guillermo Rauch публично жалуется, что La Liga игнорирует обращения и продолжает блокировать IP CDN без согласования.
• Осень 2025: Docker падал по всей Испании на несколько дней после старта нового сезона.
• Октябрь 2025: испанский парламент отклоняет инициативу остановить блокировки. RootedCON публикует шаблон коллективного иска.
• Апрель 2026: сезон 25/26 в разгаре, свежий тред на HN показывает, что docker pull всё ещё не работает по выходным.

Что делать, если вас задело

1. Проверьте, затронут ли ваш сервис, на hayahora.futbol — сайт мониторит IP, которые La Liga активно блокирует. Список меняется каждую неделю.
2. Для быстрой разблокировки команды: корпоративный VPN с выходом вне Испании (Нидерланды, Ирландия, Франция) или SSH-туннель через зарубежный VPS. Для российских разработчиков SSH-туннель через собственный VPS — надёжнее публичных VPN-сервисов, которые в РФ могут быть недоступны.
3. Для CI/CD: поставьте self-hosted runner в AWS/GCP/Yandex Cloud за пределами Испании. GitHub-hosted runners тоже затронуты, если трафик идёт через CDN.
4. Для docker pull: поднимите pull-through mirror — это локальный прокси-кэш Docker-образов, который живёт на вашем сервере вне Испании. Демон тянет слои через него, и трафик к Docker Hub (а значит, к Cloudflare) идёт уже не из Испании.
5. Для сайтов на Vercel/Cloudflare Pages: рассмотрите резервный деплой на AWS CloudFront или Yandex Cloud CDN — хотя бы как fallback на время матчей.
6. Подайте жалобу в Европейскую комиссию (регламент 2015/2120, нарушение сетевой нейтральности). Массовые жалобы — единственный реальный путь давления на Испанию.

Вывод

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

Проблема не в том, что они это делают. Проблема в том, что они МОГУТ это делать. Это вид государственной цензуры, который не должен быть возможен в принципе.

Для разработчиков прагматичный вывод один: если у вас есть критическая зависимость от CDN Cloudflare или Vercel и хоть одно звено инфраструктуры физически в Испании, заложите план-B. Зеркало реестра, резервный CI-раннер, fallback-домен — мелочь в обычное время, страховка в выходные.

Источники: Hacker News, daniel.es, TechRadar.

EmDash — это новая open-source CMS (система управления контентом) на TypeScript от Cloudflare, которую компания называет «духовным наследником WordPress». Главная идея: плагины работают в изолированных песочницах и не могут навредить сайту, даже если содержат уязвимости.

• Cloudflare выпустила EmDash v0.1.0 — open-source CMS на TypeScript с MIT-лицензией
• Каждый плагин запускается в изолированной песочнице (Dynamic Workers) и декларирует нужные разрешения в манифесте
• 96% уязвимостей WordPress-сайтов приходится на плагины — EmDash решает эту проблему архитектурно
• Под капотом — Astro, serverless-архитектура, Portable Text вместо HTML, встроенный MCP-сервер для ИИ-агентов
• Проект создан за 2 месяца с помощью ИИ-агентов, доступен на GitHub (3200+ звёзд за сутки)

WordPress исполнится 23 года в этом году (основан в 2003 году). Платформа обслуживает более 40% всех сайтов в интернете, но её архитектура родом из эпохи, когда AWS EC2 ещё не существовал. Плагинная система WordPress — главное преимущество и главная боль одновременно.

Почему безопасность плагинов WordPress — нерешаемая проблема

В WordPress плагин — это PHP-скрипт, который встраивается напрямую в ядро и получает полный доступ к базе данных и файловой системе. Нет изоляции, нет ограничений. Установить плагин — значит полностью ему довериться.

Статистика Wordfence и других ИБ-компаний неутешительна:

• 96% уязвимостей WordPress-сайтов происходят из плагинов
• В 2025 году нашли больше критических уязвимостей в экосистеме WordPress, чем за два предыдущих года вместе
• Очередь ревью в маркетплейсе WordPress.org — 800+ плагинов, ожидание — минимум 2 недели

WordPress не может решить эту проблему, не переписав архитектуру с нуля. Cloudflare решила это сделать.

Как EmDash изолирует плагины

В EmDash каждый плагин запускается в собственном изолированном воркере (Dynamic Worker — легковесная v8-песочница, запускающаяся за миллисекунды). Вместо полного доступа ко всему, плагин декларирует в манифесте, какие возможности ему нужны:

Этот плагин запрашивает ровно два разрешения: чтение контента и отправку email. Ничего другого он сделать не может — ни обратиться к внешнему серверу, ни прочитать файловую систему, ни получить доступ к базе данных напрямую.

Модель напоминает OAuth: при установке плагина вы видите, какие именно разрешения он запрашивает, и принимаете осознанное решение. Администратор может задать политики — какие capabilities допустимы для каких ролей.

Архитектура и стек

EmDash построен на современном стеке:

• TypeScript — весь код, включая плагины и темы
• Astro — фреймворк для контентных сайтов, рендеринг тем
• Portable Text — структурированный JSON вместо HTML, контент не привязан к DOM
• Serverless — масштабируется до нуля, работает на Cloudflare Workers или любом Node.js-сервере
• Passkeys — аутентификация без паролей по умолчанию (WebAuthn)
• MIT-лицензия — без ограничений GPL, плагины могут иметь любую лицензию

Хранение и совместимость

На Cloudflare EmDash использует D1 (база данных), R2 (файлы), Workers (вычисления). Но абстракции портируемы: можно запустить на SQLite, PostgreSQL, AWS S3 или локальном файловом хранилище. Команда для развёртывания:

ИИ-нативная CMS: MCP, CLI, Agent Skills

EmDash спроектирован для работы с ИИ-агентами:

• Встроенный MCP-сервер — Claude, ChatGPT и другие ИИ-инструменты могут управлять сайтом напрямую через Model Context Protocol
• Agent Skills — файлы-инструкции для ИИ-агентов: как писать плагины, портировать темы с WordPress, работать со схемами контента
• CLI — программное управление контентом, медиа, схемами

По сути, рутинную работу — миграцию контента, создание плагинов, адаптацию тем — можно поручить ИИ-агенту, и EmDash даст ему весь необходимый контекст.

Встроенная монетизация через x402

Каждый сайт на EmDash поддерживает стандарт x402 — нативные интернет-платежи. Клиент (например, ИИ-агент) отправляет HTTP-запрос, получает ответ 402 Payment Required и оплачивает доступ к контенту на лету. Настроить монетизацию можно без единой строчки кода — указать, какой контент платный, и привязать кошелёк.

Миграция с WordPress

EmDash поддерживает импорт существующих WordPress-сайтов:

1. Экспорт WXR-файла (WordPress eXtended RSS) из WordPress-админки
2. Или установка плагина EmDash Exporter, который создаёт защищённый endpoint для миграции
3. Автоматический перенос постов, страниц, медиафайлов и таксономий

Кастомные типы контента (которые в WordPress требуют Advanced Custom Fields) в EmDash задаются через визуальный конструктор схем в админке.

Что стоит учесть

EmDash находится в статусе бета-превью (v0.1.0). Несколько моментов:

• Проект молодой — 62 коммита, 4 контрибьютора, 34 релиза
• Песочница для плагинов через Dynamic Workers требует платного аккаунта Cloudflare (от $5/мес), но EmDash запускается и без неё — плагины будут работать в safe mode без изоляции
• Экосистема плагинов и тем ещё не сформировалась — на старте доступны формы, встраивания, SEO, аудит-лог
• Привязка к инфраструктуре Cloudflare — можно запустить на Node.js, но максимальную производительность даёт именно Cloudflare

Выводы

WordPress — триумф open source, который дал возможность публиковаться миллионам. Но экосистеме нужен вариант, который даёт ту же свободу и доступность, решая при этом проблемы, которые WordPress не может решить.

EmDash — амбициозная заявка Cloudflare на рынок CMS. За 24 часа после анонса проект набрал более 3200 звёзд на GitHub и 600+ баллов на Hacker News. Продакшн-готовности пока нет — это бета. Но идея изолированных плагинов с декларативными разрешениями решает реальную проблему, которая мучает WordPress-экосистему десятилетиями.

Попробовать EmDash можно в онлайн-песочнице или развернуть локально через CLI.

WordPress часто не любят backend-разработчики, и у каждого на это есть свои причины. Кому-то не нравится функциональный стиль разработки, кто-то критикует form-builder и экосистему плагинов. У других WordPress как CMS и PHP как язык программирования до сих пор ассоциируются со стереотипами 10–15-летней давности - будто они устарели и уступают современным технологиям.

При этом реальность такова, что и PHP, и WordPress - отличные и современные инструменты, которые очень хорошо выполняют свои задачи. Опустим PHP - статья не об этом. Что же можно сказать про WordPress как про продукт и как CMS?

WordPress по‑прежнему остаётся самой популярной системой управления контентом. Согласно данным команды WordPress, платформа обслуживает более 43% всех веб-сайтов и занимает долю в 61% на рынке CMS. Также статистика показывает, что WordPress используется примерно на 59% сайтов, где известна CMS (это около 42% всего веба).

Данные были взяты из официального блога WordPress и сайта w3techs.com:

• https://wordpress.com/blog/2025/04/17/wordpress-market-share/
• https://w3techs.com/technologies/overview/content_management
• https://w3techs.com/technologies/details/cm-wordpress

При этом, традиционный WordPress объединяет CMS, шаблоны на PHP и монолитные темы. Такая связка усложняет разработку с использованием современных JS фреймворков, а также затрудняет независимое масштабирование фронтенда и бэкенда, и оптимизацию производительности и безопасности. Жёсткая связка страниц, устаревшие PHP‑функции и не самый удобный девелоперский опыт часто заставляют команды искать альтернативы.

Headless WordPress решает эти проблемы: CMS становится админ-панелью для управления контентом, а отдельный фронтенд отвечает за UI. Такое разделение обязанностей даёт несколько преимуществ: четкое разделение ответственности, независимое масштабирование интерфейса и CMS, упрощенную локальную разработку и CI/CD. CMS превращается в API‑ориентированное хранилище, а современные фреймворки вроде Next.js берут на себя маршрутизацию и рендеринг.

Headless WordPress с использованием WPGraphQL

Чтобы использовать WordPress как headless‑CMS, нужен API. Также есть интересный пост про headless wordpress в их официальном блоге.

В WordPress из коробки есть REST API, но для frontend и mobile приложений часто удобнее использовать GraphQL. WPGraphQL - это open source плагин, который добавляет GraphQL API в WordPress. Используя WPGraphQL, мы получаем:

• Гибкие запросы к таким сущностям, как посты, страницы, произвольным типам постов, таксономиям и пользователям.
• Систему расширений которая позволяет расширять функционал GraphQL бекенда и таким образом поддерживать популярные плагины, тем самым позволяя возвращать дополнительные поля которые не относятся к стандартным полям Wordpress.
• GraphQL API, который даёт очень удобный формат для интеграции фронтенд фреймворков таких как Next.js, Astro и SvelteKit.
• Оптимизацию производительности, поскольку клиент запрашивает только нужные поля и данные делая один запрос вместо группы REST запросов + отдельный фронтенд забирает на себя часть запросов.

В дополнение к доступному функционалу WPGraphQL можно добавлять дополнительные плагины-расширения, такие как WPGraphQL Yoast SEO и WooGraphQL (WPGraphQL для WooCommerce). Таким образом добавив несколько плагинов в базовую инсталляцию CMS можно из коробки получить полностью функциональный GraphQL бекенд, который может покрыть запросы для блога, сео функционал, онлайн-магазин и тд.

Важно отметить, что изначальная идея использовать WPGraphQL пришла из статьи в блоге Vercel.

Фронтенд на Next.js

Next.js - production-ready React-фреймворк, который разрабатывается компанией Vercel. Многие используют его по умолчанию для разных headless‑проектов. Наш пример headless-wordpress не исключение. Фреймворк предлагает удобную маршрутизацию на базе файловой системы, где любой файл в папке pages автоматически становится маршрутом и поддерживает несколько стратегий рендеринга:

• Server‑side rendering (SSR) позволяет генерировать HTML при каждом запросе.
• Статическая генерация (включая [Incremental Static Regeneration])
• React Server Components, стратегия которая дает гибкость в балансировании производительности и кэширования.

Это делает Next.js хорошей платформой для работы с GraphQL API и рендеринга страниц React‑компонентами. Если у вас нет опыта с Next.js и React, то это не повод не попробовать набросать POC в свободное время. Современные Next.js и React templates + хороший AI agent помогут адаптировать UI под GraphQL для вас.

Почему Cloudflare?

Vercel очень часто является платформой по умолчанию для Next.js‑приложений. Более того Next.js адаптирован для запуска из коробки на серверах Vercel. При этом нужно добавить, что идея этой статьи не в том чтобы как-то компрометировать Vercel. Что же нужно знать про Cloudflare чтобы обратить внимание на этот сервис с точки зрения альтернативы для хостинга Next.js?

Согласно статистике, реверс-прокси сервисы Cloudflare используются примерно на 21,9% всех сайтов в интернете, а это более 82% сайтов, где используется прокси‑сервисы в принципе. Такая распространённость говорит о масштабе, надежности и глобальном охвате сервиса. Но Cloudflare - это не только reverse-proxy. Компания разрабатывает целую группу облачных сервисов, включая такие сервисы, как Cloudflare Pages - альтернатива Github Pages, Workers - Serverless functions (по аналогии с AWS Lambda), Контейнеры, Очереди, AI сервисы, R2 Object Storage, и другие. В дополнение ко всему, компания предоставляет такие сервисы, как защита сайта (site-protection), VPN и капча (human-detection captcha). Такое разнообразие сервисов делает сервис очень распространенным.

Лимиты бесплатного тарифа Cloudflare

Одним из самых интересных аргументов в пользу Cloudflare можно считать их бесплатный тариф. Защита от DDoS, Universal SSL и глобальную CDN доступны бесплатно. Также бесплатный тариф включает большинство из вышеперечисленных облачных сервисов. Например, Cloudflare Workers, который можно использовать для хостинга Next.js-проектов, бесплатно даёт 100,000 запросов в день. Или R2 object storage - альтернатива S3 по умолчанию дает 10GB пространства, которое можно использовать для хранения статики или других данных. Этого более чем достаточно чтобы поэкспериментировать на выходных с новым стеком и вполне достаточно для того, чтобы бесплатно хостить ваш проект до тех пор пока у вас не пойдет серьезный трафик. Ниже приведена таблица с некоторыми из Cloudflare сервисов и что включено в бесплатный тариф.

Запуск Serverless функций на edge-серверах

Cloudflare Workers позволяют запускать серверлесс‑код по всей сети Cloudflare. Ниже приведено изображение показывающее как работает Edge CDN, когда например статика продублирована на все доступные сервера и таким образом пользователь получает ресурсы с самого близлежащего сервера.

Эта картинка хороша тем, что аналогично CDN статике на этих же серверах можно запускать и Workers (Lambda) функции, тем самым ускоряя вашу инфраструктуру еще больше.

Одной из интересных особенностей Workers-функций является отсутствие cold-starts. Любой cloud provider обычно подымает docker container или виртуализированное окружение в момент первого запуска программы, а это всегда задержка. Минусом Workers-функций является тот факт что их Runtime API требует чтобы код мог использовать их Web platform APIs. А это в свою очередь ограничивает выбор языка программирования: Javascript, Typescript и WebAssembly. Но благодаря такому подходу Workers используют изолированную модель запуска и могут быть прогреты еще до момента запуска кода этого воркера. Прогрев начинается еще на этапе TLS-соединения между клиентом и серверами Cloudflare. Полный текст статьи можно почитать в их блоге.

Воркеры выполняются на edge-серверах, которые находятся ближе всего к пользователям, тем самым уменьшая задержку и разгружая origin‑сервер (в нашем случае WordPress backend). По аналогии с другими cloud-провайдерами, код внутри Workers Runtime может использовать другие сервисы Cloudflare, такие как:

• Cache API - позволяет читать и записывать данные в глобальный edge‑кэш через caches.default, что удобно для кэширования GraphQL‑ответов или страниц Next.js.
• Workers KV - распределенное key‑value‑хранилище для конфигурации и небольших наборов данных; можно хранить и получать данные глобально с низкой задержкой.
• Cron Triggers - можно сопоставить cron‑выражение с обработчиком scheduled(), чтобы запускать периодические задачи, например, уборку кэша или обновление данных. Триггеры выполняются на малоиспользуемых машинах, максимизируя эффективность.

Наличие доступа к дополнительным сервисам, таким как базы данных (D1), объектное хранилище (R2), очереди и AI даёт свободу строить более сложные и гибкие архитектуры, что очень полезно в дальнейшем на больших масштабах.

OpenNext: мост между Next.js и Cloudflare

Самостоятельный деплой Next.js на разные платформы непрост, поскольку среда исполнения Vercel отличается от других. Можно поднять Next.js на Node‑сервере, но его работа отличается от edge‑режима Vercel. OpenNext - это проект с открытым исходным кодом, который адаптирует Next.js для разных серверлесс‑платформ. Важно сказать что у Next.js нет нативного способа само разворачивания на других платформах, кроме Vercel; существующие отдельные адаптеры разрознены и сложны в поддержке. OpenNext объединяет усилия в одном адаптере, переводя выход сборки Next.js в формат, совместимый с основными облачными платформами. Проект поддерживают сообщество SST (AWS), команда Cloudflare и Netlify. Соответственно, с помощью OpenNext можно развернуть Next.js на Cloudflare Workers, сохраняя SSR, статическую генерацию и API‑маршруты.

Cloudflare‑адаптер устанавливается через @opennextjs/cloudflare. Далее следует установить Wrangler, настроить wrangler.toml с вашим Account ID и создать open-next.config.ts для управления кэшем и ассетами. Адаптер собирает приложение Next.js под среду Cloudflare, создает edge‑воркер и конфигурирует кэш для статики и ISR‑страниц (например, используя R2). После публикации Git‑интеграция Cloudflare автоматически разворачивает приложение при каждом пуше в GitHub или GitLab, а для pull‑request создает превью.

Кэширование и уровни производительности

Архитектура headless WordPress + Next.js + Cloudflare обычно включает несколько уровней кэша:

1. Кэш браузера - стандартный HTTP‑кэш на стороне клиента.
2. Кэш edge‑рантайма - Cache API Cloudflare Workers сохраняет HTML‑страницы или GraphQL‑ответы рядом с пользователем; при попадании в кэш контент отдаётся мгновенно, а промахи идут к воркеру или origin.
3. Кэш ISR Next.js - технология Incremental Static Regeneration сохраняет отрендеренные страницы на сервере и обновляет их по запросу, снижая нагрузку на WordPress API.
4. Кэш GraphQL - API WPGraphQL может реализовывать кэширование по времени или тегам (например, через WPGraphQL Smart Cache), чтобы управлять сроком жизни ответов.

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

Пример конечной архитектуры показан на изображении ниже.

Автоматизация периодических задач

Headless‑сайтам часто требуются периодические действия - например, обновление кэша ISR или синхронизация данных. Cron Triggers Cloudflare позволяют планировать запуск воркера по cron‑выражению. Обработчик scheduled() срабатывает по расписанию и подходит для обслуживания и получения сторонних данных. Триггеры выполняются на малоиспользуемых машинах по всему миру и легко управляются через Wrangler или панель Cloudflare.

Модернизация PHP‑стека с Roots toolkit

Хотя headless WordPress переносит рендеринг на JavaScript, CMS всё ещё нужно поддерживать. В качестве бонуса хочется порекомендовать экосистему Roots, которая предлагает современный инструментарий для разработки на WordPress:

• Bedrock - шаблон WordPress, которая устанавливает ядро, плагины и темы через Composer. Таким образом Bedrock дает современную для PHP проектов структуру проекта, улучшает структуру папок, использует концепты Двенадцать факторов для конфигурации приложения с помощью .env‑файлы и тд. Более того, управление зависимостями через Composer повышает надежность и позволяет делать деплой приложения на разные сервера без страха что-то забыть или упустить.
• Sage - стартовая тема WordPress, использующая Blade от Laravel для шаблонов и интегрирующая Tailwind CSS. Sage автоматически генерирует theme.json из конфигурации Tailwind, поддерживает live preview блокового редактора с Vite и позволяет создавать компоненты на Blade. Это помогает фронтенд‑разработчикам отойти от устаревших подходов для разработки тем Wordpress с нуля.
• Trellis - DevOps‑инструмент на базе Ansible, который поднимает серверы и автоматизирует деплой. Trellis предоставляет LEMP‑стек (Ubuntu 24.04, Nginx, PHP 8.3, MariaDB), выполняет деплой без downtimes и из коробки поддерживает SSL‑сертификаты. CLI помогает создавать и настраивать серверы, а также разворачивать проекты с атомарными релизами и откатами.
• Acorn - интеграция, позволяющая использовать функционал Laravel в WordPress. С Acorn становятся доступны такие инструменты как Blade‑шаблоны, миграции, роутинг, кэширование и Artisan‑подобный CLI внутри WordPress. Это позволяет разработчикам строить плагины и фичи WordPress с использованием современных PHP‑подходов и современного фреймворка .

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

Собираем всё вместе

Архитектура приложения headless WordPress + Next.js + Cloudflare выглядит приблизительно так:

1. WordPress (headless) - работает на традиционном сервере или в контейнере. Редакторы управляют контентом в админке. WPGraphQL и его расширения предоставляют GraphQL‑endpoint с данными, SEO и другой информацией, например данными о магазине.
2. Next.js фронтенд - React‑приложение, которое получает данные через GraphQL, рендерит страницы на сервере (SSR) или статически (ISR/SSG) и обрабатывает маршрутизацию и взаимодействие с клиентом. Код хранится в Git и автоматически разворачивается благодаря Git‑интеграции Cloudflare.
3. Cloudflare Workers - размещают приложение Next.js на edge через OpenNext. Workers исключают cold-starts и работают по аналогии с CDN как можно ближе к пользователю. Они также выполняют кэширование, обрабатывают API‑маршруты и запускают cron‑задачи.
4. Кэш на edge и в браузере - несколько уровней кэша гарантируют быструю отдачу статики и отрендеренных страниц. KV, R2 или D1 могут хранить дополнительные данные вроде сессий или объектов.

Заключение

Headless‑архитектура объединяет универсальность WordPress и гибкость современных JavaScript‑фреймворков. Экспонируя контент через WPGraphQL и потребляя его в Next.js, можно получить больше контроля над рендерингом и тем самым улучшить производительность. Размещение фронтенда на Cloudflare Workers через OpenNext позволяет приблизить фронтенд код к пользователям, устраняет cold-starts, позволяет использовать free-tier и продвинутые уровни кэширования. Инструменты вроде Bedrock, Sage, Trellis и Acorn модернизируют PHP/Wordpress‑сторону и делают CMS такой же удобной в работе, как и современный Next.js/React-фронтенд. Вместе эти технологии создают мощный стек для создания быстрых, масштабируемых и безопасных сайтов, будь то хакатон, pet‑проект или серьёзный продакшн.

Пользователи по всему миру начали массово жаловаться на проблемы примерно с 21:55 по московскому времени.

По данным Downdetector, количество жалоб быстро превысило 10 000 только в американском сегменте. В России также фиксировались тысячи обращений на Downdetector.su. Проблема носила глобальный характер.

Что не работало

Игроки сообщали о невозможности войти в аккаунт, скачать игры или обновления. У многих не запускались онлайн-матчи, не синхронизировались сохранения, не работал чат.

Сильнее всего пострадали сетевые проекты — в том числе Counter-Strike 2 и Dota 2. Пользователи жаловались, что не могут подключиться к серверам или вылетают из матчей.

Причина — инфраструктура

На странице статуса Steam указывалось, что сбой связан с проблемами у Cloudflare.

Также сообщалось о неполадках у Akamai — в частности, в системе управления сертификатами (CPS) через портал Akamai Control Center.

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

Онлайн рухнул втрое

Косвенное подтверждение масштаба сбоя — статистика онлайна.

Если около 20:00 в Steam находилось примерно 34 млн пользователей, то к 22:00 число активных игроков упало до 9,2 млн. Для платформы такого размера это резкое и аномальное снижение.

Valve отметила, что страницу статуса Steam за час просмотрели более 368 000 раз — показатель, который обычно сопровождает крупные инциденты.

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

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

Чтобы изменить ситуацию, OpenAI, Anthropic и Block объявили о создании Agentic AI Foundation (AAIF) — нового фонда под управлением Linux Foundation, который займется развитием открытых стандартов для ИИ-агентов.

Поддержку инициативе оказывают Google, Microsoft, AWS, Bloomberg и Cloudflare.

MCP, Goose и AGENTS.md объединяют в один стандарт

В рамках AAIF свои ключевые технологии передали сразу три компании:

• MCP (Model Context Protocol) от Anthropic — стандарт связи между агентами и внешними инструментами. За год появилось уже более 10 000 MCP-серверов, а Microsoft встроила поддержку MCP прямо в Windows и Visual Studio. Это превращает агентов в «первоклассных граждан» ОС и упрощает автоматизацию разработки.
• Goose от Block — локальный агентный фреймворк, способный работать на устройстве пользователя без облака. Он использует MCP как базовый коммуникационный слой.
• AGENTS.md от OpenAI — открытый формат, который стал «README для ИИ-агентов». Файл описывает проект в машинно-читаемом виде: тесты, сборку, архитектуру, стили кода, политику безопасности и рабочие процессы. Формат уже используют 60 000+ open-source проектов, включая VS Code.

Зачем это индустрии

Майк Кригер из Anthropic подчеркивает, что передача MCP под управление Linux Foundation гарантирует нейтральность стандарта.

В OpenAI заявили, что объединение технологий под одной организацией создает прочную основу для разработки надежных агентов.

Что значит создание AAIF для рынка

Появление AAIF может стать переломным моментом: впервые крупнейшие игроки не конкурируют стандартами, а объединяют их.

Это шаг к единой экосистеме, где агенты смогут взаимодействовать с инструментами, IDE, операционными системами и сервисами. И все это без кастомных протоколов и закрытых API.

По словам CEO Cloudflare Мэттью Принса, это был «худший сбой с 2019 года».

Что пошло не так

Проблема возникла не из-за DDoS-атаки, DNS или генеративного ИИ — хотя именно на это компания грешила изначально.

Источник оказался куда менее очевидным: внутренний сбой в системе Bot Management, которая определяет, какие запросы принадлежат людям, а какие — ботам и парсерам.

Система использует ML-модель и большой конфигурационный файл с признаками, по которым определяется бот-трафик. Этот файл регулярно пересчитывается в ClickHouse.

Cloudflare обнаружила, что изменение поведения запросов в ClickHouse привело к появлению множества дублирующихся строк в конфигурации.

Файл стал быстро расти, превысил лимиты памяти и в итоге «уронил» центральный прокси-слой Cloudflare, через который проходит трафик миллионов сайтов.

Клиенты, использующие бот-фильтры, начали получать массу ложных срабатываний — легитимные запросы считались ботами и блокировались. Те, кто не использовал Bot Management, пережили сбой почти незаметно.

Почему масштаб оказался таким большим

Cloudflare сегодня — один из крупнейших игроков интернет-инфраструктуры:

• по данным самой компании, 20% всех сайтов в мире используют Cloudflare;
• сервисы завязаны на ее CDN, защиту от DDoS, балансировку и маршрутизацию;
• сбой в одном модуле приводит к лавинообразному эффекту.

Фактически, произошла та самая проблема «единой точки отказа», о которой уже давно говорят эксперты сетевой инфраструктуры.

Что Cloudflare планирует изменить

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

• усилить проверку внутренних конфигов перед распространением;
• ввести новые глобальные «kill switch» переключатели для быстрого отключения проблемных подсистем;
• устранить сценарии, при которых отчеты об ошибках могут съедать ресурсы и вызывать деградацию;
• пересмотреть отказоустойчивость всех модулей центрального прокси.

Почему это важно

За последние месяцы это уже третий крупный сбой глобального масштаба: ранее проблемы в Azure и AWS также обрушивали сотни сервисов.

Чем больше интернет завязан на нескольких инфраструктурных компаниях, тем сильнее и заметнее эффект любого сбоя.

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

Что произошло

Cloudflare официально заявила о «всплеске аномального трафика», который вызвал массовые ошибки в сетевой маршрутизации:

«Мы пока не знаем причину всплеска, но задействованы все ресурсы, чтобы восстановить работу трафика», — Cloudflare.

Проблемы сразу ударили по крупным сервисам:

• X показывал ошибку про «внутренний сервер» из-за сбоя в Cloudflare.
• ChatGPT выдавал: «please unblock challenges.cloudflare.com to proceed».
• Downdetector — сервис, который должен мониторить сбои сам лег и отдавал ту же ошибку Cloudflare.

Насколько все было плохо

Cloudflare обслуживает около 20% всех сайтов в мире, от CDN и DNS до защиты от DDoS. Когда у нее проблемы — проблемы в целом почти у всего интернета.

NetBlocks, например, назвал происходящее «катастрофическим нарушением инфраструктуры Cloudflare». И добавил, что гигант стал критически важной точкой отказа для интернета слишком многое завязано на его защите.

Почему так больно?

Многие компании вынуждены зависеть от Cloudflare, AWS или Azure — альтернативы есть, но их мало. И такие сбои вытаскивают наружу неприятный факт: интернет стал слишком централизованным, а единичные инфраструктурные игроки — слишком важными.

Что сейчас

На момент написания новости, Cloudflare заявила, что сервисы «постепенно восстанавливаются», но часть пользователей все еще может видеть ошибки.

Причина аномального трафика пока не раскрыта.

Cloudflare связала учащение «фатальных паник» на arm64 с кодом, где выполнялась работа с Netlink, но корневая причина оказалась глубже — в связанке компилятор ↔ ассемблер Go для arm64 и в том, как разбивалось большое смещение стека на две инструкции ADD со «сдвигом на 12 бит». Если прерывание попадало между этими двумя ADD, стековый указатель оказывался «наполовину скорректирован», и трассировщик стека считывал нерелевантные данные как адрес возврата, что заканчивалось segfault/фатальной паникой. Схожие аварии ранее отмечали и другие команды, в частности Datadog: именно в runtime.(*unwinder).next на Linux/arm64 (Go 1.23.x/1.24.x).

Что именно ломалось

• Сценарий сбоя: асинхронная предвыборка (preemption) попадает между двумя инструкциями корректировки SP (split ADD), после чего GC/трассировка начинают разворачивать некорректный фрейм, обращаясь по невалидному SP. Итог — падение в (*unwinder).next.
• Подтверждение на практике: сходные трассы стеков и «рандомные» крэши на arm64 фиксировались у сторонних команд; проблема оформлена в ишью #73259 в репозитории Go и была признана кандидатом на бэкпорт.

Как починили (и какие версии содержат фикс)

Исправление прошло через бэкпорт и доступно в поддерживаемых ветках Go:

• Go 1.24.6 — явное упоминание бэкпорта по ишью #73259.
• Go 1.23.12 — минор с правками рантайма (включая бэкпорт по связанным arm64-сбоям).
• Go 1.25.0 и новее — фиксация на мажорной ветке.

Суть изменения: вместо двух поочерёдных ADD для большого смещения теперь собирают оффсет в временный регистр и выполняют одну атомарную корректировку SP.

Это исключает «окно» между ADD-инструкциями и делает разворачивание стека предсказуемым даже при async preemption. (Подробные обсуждения и сопутствующие arm64-проблемы рантайма см. также в #63830, #65449, #73413.)

Кому это важно

• Все сервисы Go на arm64, где возможны большие стековые фреймы и активна асинхронная предвыборка (по умолчанию с Go 1.14+). В условиях продакшн-нагрузок редкая гонка становится статистически вероятной. Читайте подробнее: https://unskilled.blog/posts/preemption-in-go-an-introduction/

Что делать инженерам прямо сейчас

1. Обновиться до: Go 1.25.x или минимум до 1.24.6 / 1.23.12 (если «зажаты» веткой).
2. Пересобрать сервисы, критичные по доступности, и раскатить обновления в первую очередь на arm64-инфраструктуру.
3. Если апгрейд временно невозможен — минимизируйте большие стек-фреймы (вынос больших буферов в heap), снизьте вероятность попадания preemption в эпилог и проверьте зависимости на предмет собственного asm/unsafe-кода.
4. Отслеживайте релизы Go и связанные тикеты об unwinding/arm64 (см. #73259 и бекпорт #74694).

Источники и материалы:

• Обсуждение с примерами падений: runtime: segfaults in runtime.(*unwinder).next (GitHub, #73259).  https://github.com/golang/go/issues/73259
• Бэкпорт фикса в ветку 1.24: (GitHub, #74694) — релиз Go 1.24.6. https://github.com/golang/go/issues/74694
• История релизов, минор Go 1.23.12 с правками рантайма. https://go.dev/doc/devel/release
• Release notes Go 1.25 (фикс присутствует в мажорной ветке).  https://tip.golang.org/doc/go1.25
• Ранние разборы проблем разворачивания стека/прерываний на arm64 https://github.com/golang/go/issues/63830

Речь идёт не о взломе самих сервисов Cloudflare — инфраструктура компании осталась в безопасности. Но с 12 по 17 августа злоумышленники получили текстовое содержимое тикетов, включая переписки с саппортом и контактные данные клиентов.

Что именно утекло

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

Файлы и вложения, прикреплённые к тикетам, не пострадали. Но всё, что вы писали в свободной форме — стоит считать скомпрометированным.

Как Cloudflare отреагировала

Компания отозвала все сторонние интеграции с Salesforce, провела расследование и отключила Drift от своей системы.

Из 104 обнаруженных утекших API-токенов Cloudflare, ни один пока не был использован, но все они уже отозваны «на всякий случай».

Кто за этим стоит

Атаку провела хакерская группа GRUB1. Они использовали доступ к OAuth-токену Drift, чтобы входить в Salesforce и выгружать данные. Атака была многодневной: сначала разведка, затем массовая выгрузка и удаление следов.

GRUB1 использовали инфраструктуру AWS и DigitalOcean, а также популярные open-source инструменты вроде Trufflehog. Cloudflare опубликовала IOCs (индикаторы компрометации), чтобы другие компании могли отследить похожие атаки.

Масштаб и риски

Cloudflare — не единственная жертва. Взлом Drift затронул сотни компаний, использующих эту интеграцию в своих Salesforce-средах. Это классическая атака на цепочку поставок.

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

Что делать пользователям Cloudflare

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

• проверить переписки в техподдержке через Support Portal;
• отозвать любые ключи, токены или пароли, которые могли быть в тикетах;
• провести аудит сторонних SaaS-интеграций с CRM;
• отключить Drift, если он используется в вашей системе;
• пересмотреть политику доступа сторонних сервисов и настроить регулярную ротацию секретов.

Что произошло?

Cloudflare сообщила, что за последние недели ее инфраструктура отражала сотни гиперобъемных DDoS-атак.

Самая крупная достигла 11,5 Тбит/с и была реализована через UDP-флуд, преимущественно с IP-адресов, относящихся к Google Cloud. Пиковая частота пакетов составила 5,1 млрд в секунду.

Компания опубликовала визуализацию атаки, где видно, как трафик буквально «взрывает» сеть за считанные секунды:

DDoS-атаки становятся сильнее и чаще

Инцидент случился спустя два месяца после предыдущего рекорда — атаки на 7,3 Тбит/с в июне 2025-го. А еще в октябре 2024 года Cloudflare остановила атаку на 3,8 Тбит/с.

За 2024 год Cloudflare:

• Зафиксировала 21,3 млн атак на своих клиентов.
• Пережила 6,6 млн атак на собственную сеть.
• Отразила рост атак на 358% год к году.
• Отметила 509% рост сетевых атак (SYN, SSDP, Mirai и др).

А при чем тут Google Cloud?

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

Тем не менее, инцидент поднимает вопрос о контроле за злоупотреблением облачными платформами: AWS, Azure и Google все чаще становятся площадками для DDoS-генерации.

Почему это важно?

• 11,5 Тбит/с — это в три раза больше, чем предыдущий максимум 2024 года.
• Защита от таких атак требует колоссальной инфраструктуры, которую потянут далеко не все.
• Боты и ботнеты становятся мощнее, а облака — более удобным инструментом в их руках.
• Растет тренд к многоуровневым (multi-vector) атакам, комбинирующим разные типы трафика.

Что дальше?

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

Если нужно комплексное решение, единая платформа с привычным набором: DDoS-защита, антибот, WAF, DNS, CDN и другие необходимые для веба вещи, то есть платформа NGENIX — одна из ведущих российских альтернатив Cloudflare для проектов любого масштаба.

Что такое NGENIX и почему его выбирают?

NGENIX — российская облачная платформа, которая сочетает в себе защиту от атак, ускорение загрузки, управление DNS и SSL-сертификатами, фильтрацию вредоносного трафика. Инфраструктура развернута в России и СНГ. Переезд с Cloudflare возможен за считанные часы, без риска блокировок Роскомнадзором и с техподдержкой, которая отвечает на русском с понятным SLA.

Основные функции и возможности платформы:

• Защита от DDoS — отражение атак до 7+ Тбит/с и 5 млн RPS, включая атаки на DNS;
• Фильтрация вредоносных ботов — блокировка парсеров, скрейперов и автоматизированных атак;
• Облачный WAF — предотвращает взломы и эксплуатацию уязвимостей;
• Доставка контента (CDN) — благодаря распределённой сети из 50+ узлов в России и СНГ, запросы обслуживаются ближайшим к пользователю сервером;
• Авторитативный DNS — отказоустойчивая система с обработкой до 100+ млн запросов в секунду;
• SSL/TLS-сертификаты — поддержка стандартов шифрования RSA, ECDSA и ГОСТ 34.10, автоматический выпуск и продление SSL-сертификатов Let's Encrypt, поддержка загрузки и использования собственных сертификатов (включая самоподписанные);
• Управление доступом — организация доступа к сайту или приложению при помощи простых правил или подписанных ссылок;
• Стриминг видео — стабильная передача в высоком качестве и в различных форматах;
• Распределенный мониторинг доступности — возможность отслеживать доступность сайта 24/7, оперативно реагировать на инциденты и получать метрики доступности в формате Prometheus;
• Аналитика — 35+ готовых отчётов с задержкой всего в 1 минуту.

Всё это доступно через единый интерфейс.

Инфраструктура под задачи любого масштаба

• 50+ узлов в РФ и СНГ — максимальная близость к пользователю;
• Пропускная способность 7+ Тбит/с — запас на любые пиковые нагрузки;
• На платформе используются разные виды балансировки: Anycast BGP, DNS и HTTP;
• Единый SLA на все сервисы платформы;
• Поддержка 24/7 с быстрой реакцией.

Реальный кейс: переход с Cloudflare за несколько часов

Один из клиентов NGENIX — крупный московский девелопер — столкнулся с блокировкой Cloudflare со стороны Роскомнадзора. Благодаря оперативной техподдержке переход на NGENIX занял всего несколько часов.

В ходе миграции была подключена система защиты от DDoS и настроены индивидуальные правила доступа, что позволило не только полностью заменить функционал Cloudflare, но и сократить расходы на защиту без потери качества фильтрации и безопасности.

Тарифы — под любые масштабы

У NGENIX есть тарифы как для стартапов, так и для корпораций:

• Promo — 6 900 ₽
• Lite — 13 900 ₽
• Start — от 23 900 ₽
• Pro — от 59 900 ₽
• Ultimate — индивидуально, с кастомной настройкой, премиальным SLA и выделенным менеджером.

Кому подойдёт?

• Владельцам, администраторам и командам как небольших и средних сайтов и сервисов, так и крупных проектов в сферах: e-commerce, SaaS, OTT, а также госструктурам и финтеху.
• Компаниям, утратившим доступ к зарубежным облачным сервисам, нуждающимся в быстром и удобном переходе;
• Командам с ограниченным количеством специалистов по безопасности — платформа обеспечивает комплексный набор функций под единым интерфейсом.

Если вы использовали Cloudflare ради скорости, защиты и стабильности — NGENIX даст тот же набор инструментов, но с локальной инфраструктурой, без проблем с регуляторами и с поддержкой, которая говорит с вами на одном языке.

DDoS-Guard: кастомная защита от атак уровня L3–L7 с гибкой настройкой под ваш проект

Если вы думаете, что защита сайта от DDoS-атак — это что-то вроде базового щита на периметре, который «где-то там» на краю сети отсекает подозрительный трафик, то стоит взглянуть, как работает DDoS-Guard. Эта платформа предлагает куда более глубинный подход: защита на всех уровнях от L3 до L7, с возможностью тонкой настройки под архитектуру вашего проекта.

Не просто фильтр, а эшелонированная оборона

DDoS-Guard — это инфраструктурная экосистема, которая умеет:

• отражать любые типы DDoS-атак: как волюметрические, так и прикладного уровня;
• анализировать HTTP-трафик и блокировать вредоносные запросы в реальном времени;
• оптимизировать TTFB и ускорять загрузку контента за счёт встроенного CDN;
• маскировать реальный IP и строить эшелонированную защиту через Reverse Proxy;
• управлять правилами фильтрации на уровне каждого домена, поддомена или даже URI;
• кастомизировать защиту под конкретные угрозы: от скрейпинга до TOR-трафика.

Защита на базе собственного софта и ИИ

Вся фильтрация работает на программном обеспечении собственной разработки. Запросы анализируются на соответствие RFC, проверяются сигнатуры, выявляются аномалии — и только после этого принимается решение: пропустить, заблокировать или отправить на дополнительную проверку.

За счет использования anycast-маршрутизации и собственной сети узлов, DDoS-Guard минимизирует задержки — запросы обрабатываются на ближайшем к пользователю центре фильтрации. Это критично для e-commerce и финансов, где лишняя секунда отклика может стоить клиентской корзины.

Реальный кейс: защита одного из крупнейших онлайн-сервисов по продаже лекарств

Один из клиентов DDoS-Guard — сервис из топ-3 аптечных агрегаторов в России — обратился с проблемой: высокий TTFB, нестабильная маршрутизация после сбоев и уязвимость к ботам и парсерам.

После миграции с Cloudflare результат оказался ощутимым:

• скорость сайта выросла на 40%;
• появились гибкие правила фильтрации и кастомный каскад антискрейпинга;
• доступность под нагрузкой восстановлена полностью.

И всё это — без «боли» переезда: миграция прошла быстро, с сопровождением инженеров DDoS-Guard.

Кому подойдёт?

DDoS-Guard — это решение не только для корпораций. Сервис работает с банками, госорганами, e-commerce и телекомом, но в то же время:

• небольшим проектам подойдёт тариф Basic (визитка, лендинг, каталог);
• малому и среднему бизнесу — Normal и Medium с фильтрацией TOR, кастомными TLS-наборами;
• крупным продуктам — Premium и Enterprise, где возможны уникальные L7-модули и фильтры на уровне API.

Сегменты, где защита особенно критична: СМИ, маркетплейсы, финтех, игровые платформы, госуслуги.

Что говорят внутри

«Мы анализируем HTTP-запросы на лету, сверяясь с интернет-стандартами и нашими сигнатурами, — рассказывает Дмитрий Никонов, руководитель веб-направления DDoS-Guard. — Это позволяет блокировать атаки без ложных срабатываний и без тормозов. Наши клиенты могут гибко настраивать правила, в том числе каскадные сценарии защиты на каждый поддомен».

StormWall: когда защита сайта — дело минут, а не дней

Если ваш проект работает в интернете, то вопрос киберзащиты — это не «если», а «когда». DDoS-атаки стали буднями даже для малого бизнеса, не говоря уже о финансовых сервисах, SaaS, e-commerce или онлайн-играх. И вот тут в игру вступает StormWall — российский разработчик решений для защиты сайтов, сетей и онлайн-сервисов с опытом более 12 лет.

Быстрая и комплексная защита от DDoS — без компромиссов

StormWall — это не просто прокси с анти-DDoS, а целая облачная экосистема, заточенная под разные типы инфраструктуры. Заказчику доступны сразу три варианта защиты:

• Для сайтов и приложений — включает DDoS-защиту, антибот, WAF;
• Идеально для интернет-магазинов, медиа, финтеха и госсайтов;
• Для сетей и автономных систем — работает на уровнях L3/L4, актуально для провайдеров, дата-центров и телекомов;
• Для сервисов на базе TCP/UDP — используется в играх, VoIP, стриминге, VPN и других чувствительных к задержкам сервисах.

За счёт собственной сети фильтрации с пропускной способностью 5+ Тбит/с и 9 дата-центров по всему миру, платформа может нейтрализовать даже самые сложные мультивекторные атаки.

Антибот, WAF, CDN — всё из одного окна

StormWall — это не только анти-DDoS. В арсенале платформы есть и другие полезные инструменты:

• Web Application Firewall (WAF) — защита L7 от SQL-инъекций, XSS и других попыток взлома;
• Антибот — фильтрация трафика по сигнатурам и поведенческим признакам;
• CDN — для ускорения контента, доставки видео, апдейтов и стабильной работы под нагрузкой;
• DNS, reverse proxy, API gateway — всё интегрировано в инфраструктуру с управлением через личный кабинет.

Быстрая миграция, как это было у АТОЛ

Весной 2022 года на облачные сервисы и онлайн-кассы АТОЛ обрушились мощные DDoS-атаки. Компания была вынуждена срочно искать профессиональное решение для защиты — и выбрала StormWall. За 10 минут специалисты развернули защиту, и уже через 30 минут вредоносный трафик был отфильтрован.

Даже при ежедневных DDoS-атаках мощностью 50–100 Гбит/с сервисы разработчика продолжают работать бесперебойно — клиенты-ритейлеры уверены в стабильности и надёжности его ПО.

Кому подойдёт StormWall?

• E-commerce и ритейл — устойчивость к пикам в «чёрную пятницу»;
• Банки и финансы — SLA и отказоустойчивость на уровне инфраструктуры;
• Госуслуги — соответствие реестру российского ПО;
• Разработчики игр, стриминговые платформы, SaaS — защита TCP/UDP и CDN для скорости;
• Малый бизнес — тарифы от 7 200 ₽ в месяц и помощь при миграции.

Почему выбирают StormWall

• Поддержка 24/7, ответ до 15 минут;
• Сервис как услуга — от настройки до сопровождения;
• Собственные технологии на C с eBPF и DPDK, асинхронные микросервисы на Python и JavaScript;
• Реестр российского ПО, лицензии СЗКИ/ТЗКИ;
• Модульность и кастомизация фильтрации под каждого клиента;
• Поддержка BGP, reverse proxy, API gateway, машинное обучение внутри фильтров.

Тарифы — от малого до enterprise

• Для сайтов: от 7 200 ₽/мес;
• Для сетей и сервисов: от 18 000 ₽/мес;
• Enterprise — по запросу, под SLA, с кастомными модулями фильтрации.

Вывод: российские аналоги уже закрывают ключевые задачи Cloudflare

После ухода зарубежных провайдеров рынок не остался пустым. NGENIX, DDoS-Guard и StormWall доказали, что могут обеспечить не только базовую защиту, но и полный набор сервисов для ускорения сайтов, фильтрации трафика и борьбы с ботами.

Если нужен комплекс «всё в одном» — с CDN, WAF, DNS и отказоустойчивостью, стоит смотреть на NGENIX: инфраструктура в России, понятный SLA и миграция за часы без проблем с регуляторами. DDoS-Guard — выбор для проектов, которым нужна глубина кастомизации и защита на всех уровнях L3–L7. StormWall берут за скорость внедрения и большой спектр решений — от сайтов до сетей и игровых сервисов.

Главный вывод: закрыть задачи Cloudflare в России сегодня реально — выбор зависит от масштаба бизнеса, критичности инфраструктуры и требований к гибкости настроек.

По данным Cloudflare, Perplexity использует обходные методы для сбора данных с сайтов, даже если те явно запрещают такую активность через файл robots.txt.

В частности, расследование показало, что когда сайты блокируют официальный бот Perplexity, тот переключается на неуказанные user-agent — например, маскируется под обычный браузер Chrome.

Также Perplexity якобы использует IP-адреса вне заявленного пула и постоянно меняет автономные системы (ASN), чтобы избежать обнаружения. Cloudflare отмечает, что подобное поведение было замечено на десятках тысяч сайтов и включало миллионы запросов ежедневно.

Больше не в белом списке

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

Для сравнения: компании вроде OpenAI указывают свои краулеры явно, уважают robots.txt и не пытаются обойти запреты. Cloudflare протестировала краулеры ChatGPT и подтвердила, что они прекращают сканирование при наличии disallow-директивы.

Эвристическая защита — автоматическая оборона

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

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

Перспективы: регулирование и стандарты

Cloudflare подчеркивает, что работает с экспертами по технической и политической части — в том числе с IETF — чтобы разработать новые расширения к robots.txt и зафиксировать стандарты поведения для «добросовестных» операторов ботов.

Это должно помочь отделять этичных игроков от тех, кто действует в обход.

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

Генеративный ИИ больше не просто инструмент для текстов. Он становится полноценной точкой входа в интернет: здесь ищут товары, сравнивают характеристики и даже принимают решения о покупке — всё в одном окне. За один только праздничный сезон 2024 года трафик из ИИ-инструментов в американском онлайн-ритейле вырос на 1300% — такие данные приводит исследование Adobe.

По умолчанию ChatGPT работает без выхода в интернет и отвечает на основе своих знаний, накопленных при обучении. Но можно включить функцию вручную, нажав на значок глобуса 🌐 «Искать в сети». Модель сама понимает, что вам нужна актуальная инфа, и подключается к интернету автоматически — тогда вверху появляется плашка «Поиск в сети».

Гуглить стало старомодно. Аналитики заметили, что в англоязычной молодёжной среде глагол «гуглить» постепенно исчезает — они говорят просто «search it». ChatGPT уже обрабатывает около 1 млрд поисковых запросов ежедневно. Это влияет на воронку продаж: многие шаги теперь проходят внутри чат-ботов. Бренды начинают перестраивать свои стратегии: мало быть видимым в поиске. Теперь нужно быть понятным и убедительным для нейросетей. Потому что завтра товары будут искать не люди, а их ИИ-агенты.

Что не так с классической поисковой выдачей

Слишком много кликов. Первая страница выдачи забита рекламой, SEO-статьями, агрегаторами и рерайтами рерайтов. Чтобы получить один ответ, мало вбить запрос. Нужно пролистать рекламу, открыть пару сайтов, закрыть поп-апы с чатами и ещё проверить, что инфа свежая. И если результат не подошёл — начинаем всё заново.

SEO-мусор. Ещё одна беда — это тонны переоптимизированного контента. Статьи написаны по шаблонам, чтобы понравиться алгоритмам и вписаться в критерии ранжирования. Если вы искали «что посмотреть в городе Х», то наверняка в топе были тревел-агрегаторы, забитые рекламой. Вместо живых впечатлений мы получаем скучные списки с дежурным набором достопримечательностей и призывом купить тур. Кроме того, такие статьи, как правило, обезличены, и не понятно, кто за ними стоит.

ИИ-контент. Пользователь Reddit заметил, что при поиске «John Wick 5» Google выдал кучу сгенерированного контента о проекте, который даже не анонсирован.

В комментариях посоветовали использовать операторы — минус-ключи: -ai или -sponsored, чтобы исключить из результатов страницы с этими словами.

Проект deaddit документирует явление мёртвого интернета в формате ИИ-клона Reddit — поддельные посты, комментарии и целые сообщества, сгенерированные ИИ. С поддельными сабреддитами, названиями и описаниями, профилями пользователей с прописанными личностями и интересами, постами с заголовками, содержанием и даже количеством апвоутов, а также комментариями.

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

Популярный лайфхак: добавлять в поисковые запросы слово «reddit» или оператор «site: reddit.com».

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

Но не все так оптимистичны: звучат подозрения, что часть постов пишут боты.

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

Пользователи всё больше ощущают потерю «аутентичного интернета» и ищут обходные пути — обращаются к альтернативным поисковикам, вроде DuckDuckGo или Brave, и к другим площадкам, например, Discord или Telegram-чатам, которые не индексируются поисковиками. Или создают собственные поисковые движки — например, через Google Custom Search Engine, чтобы искать только по выбранным источникам.

Почему ИИ-поиск быстрее выдает желаемое

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

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

Мэт Хонан, главный редактор MIT Technology Review, сравнил Google AI Mode и ChatGPT. Он отметил ключевое преимущество последнего — функцию памяти и персонализации. Когда он спросил ChatGPT «Что ты знаешь обо мне?», модель ответила живо и подробно: рассказала о вкусах в кино, отношении к ужастикам и даже вспомнила историю с постройкой сарая. В то время как Google, обладая огромной базой пользовательских данных — почтой, историей поиска, фотографиями, — выдал сухой профиль: «Вы интересуетесь комедиями, музыкой, подкастами и классикой». Такой ответ скорее полезен рекламодателям, чем самому пользователю. На данный момент Google недотягивает до уровня персонализации, эмпатии и гибкости, которыми уже обладает ChatGPT.

Длинные запросы и эра диалогового поиска

ИИ меняет то, как мы ищем информацию. Если средний запрос в Google состоял из 3–4 слов, то в диалоге с нейросетью мы составляем запрос на естественном языке в 20+ слов — с нюансами и уточнениями. Но главное новшество — возможность задавать follow-up вопросы: уточнения к предыдущему запросу. Раньше нужно было начинать с чистого листа. Теперь ИИ «помнит» контекст и способен адаптироваться и уточнять ответы. Причём вернуться к этому чату можно и через год, не объясняя задачу заново. А еще можно сразу адаптировать найденную информацию под нужный стиль — «а попроще?», «а на русском?», «а в одну строку кода?».

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

Исследование Semrush показывает, что ChatGPT меняет привычные представления о поисковых намерениях. Если в классическом поиске запросы обычно делят на четыре типа: навигационные (найти сайт), информационные (узнать что-то), коммерческие (исследовать товар) и транзакционные (купить), то у ChatGPT только около 30% запросов вписываются в эти категории. Остальные 70% — это совсем другие задачи, которые редко встречаются в традиционных системах. Люди обращаются к ИИ не просто за фактами, а чтобы генерировать идеи, проводить мозговой штурм и глубоко копать в теме.

На самом деле «умный» поиск — не всегда быстрее обычного гугления. В режиме глубокого исследования (Deep Research) ИИ-система может тратить десятки минут, чтобы собрать источники и выдать аналитику. Это уже не просто поиск, а полноценный ассистент-аналитик, который помогает подготовить обзор или черновик по сложной теме.

Почему ChatGPT пока что плох в поиске: галлюцинации, спам и фейк-источники

1. Короткие запросы — всё ещё вотчина Google. Пока что у ChatGPT получается не очень.
2. Слабая фильтрация SEO-спама — классические поисковики годами инвестировали в борьбу с ним. Генеративные движки пока не так придирчивы: в ответах часто появляются вторичные источники и полусырые сгенерированные статьи.
3. Чрезмерное обобщение в ответах. Из-за «переупаковки» контента в ответ модели мы получаем «усреднённую» версию истины, в которой важные нюансы могут быть утеряны. Даже если ИИ не выдает ложную информацию, он все равно суммаризует и переформулирует контент способами, которые могут вводить в заблуждение.
4. Поддакивание и стремление угодить. Модель натренирована, чтобы быть вежливой и полезной. Она пытается выдать ответ даже тогда, когда не может его найти. Не потому что хочет нас обмануть, а потому что не умеет сказать «нет». Поэтому соглашается с нами и может поддержать самые безумные идеи, например, призывает есть камни.
5. Проблемы с локальными запросами. ChatGPT не расскажет, во сколько приедет ваш поезд, и не уточнит, открыт ли ближайший супермаркет. Он может найти рестораны в районе, но за актуальным меню — всё равно придётся идти в Google.
6. Цитирование — боль. Недавний рисерч Columbia Journalism Review выявил серьёзные проблемы в способности ИИ-поисковиков цитировать новости. Анализ восьми нейросетей показал, что они часто предоставляют неверные или вымышленные ссылки, даже если у них есть издательская лицензия.

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

Давайте будем реалистами — люди чрезвычайно ленивы. Они будут прилагать минимум усилий для достижения результатов. Даже если эти результаты отстойные. Людей это не волнует.

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

Один из важных вопросов: как не потерять способность анализировать информацию самостоятельно? Ведь когда мы получаем готовый ответ от ИИ, можем перестать задумываться о том, как этот ответ был сформирован. Когда нейросеть даёт готовый, «отполированный» ответ, появляется соблазн воспринимать его как истину в последней инстанции — и перестать критически мыслить.

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

И это правда. Но и Google не гарантирует 100% точности в топе выдачи. Там тоже бывают ошибки, устаревшие данные или некачественные источники. Поэтому в любом случае важно проверять информацию и не полагаться слепо ни на ИИ, ни на поисковики.

Как генеративный ИИ крадет трафик и деньги бизнеса

ИИ теперь — как посредник: он «пережевывает» контент с сайтов: статьи, обзоры, новости — и выдает это пользователю в интерфейсе чат-бота. При этом юзер зачастую не доходит до первоисточника. Рэнд Фишкин из SparkToro назвал это «поисками с нулевым кликом». И таких запросов становится всё больше.

Что это значит? Контент журналистов, блогеров и брендов используется как сырьё, а сами авторы как будто остаются в тени — их труд не приносит прямого трафика.

Почему эта ситуация — головная боль для бизнеса и контент-мейкеров?

• Меньше посетителей — меньше клиентов. Если пользователи не заходят на сайт, то и конвертировать их в покупателей или подписчиков становится гораздо сложнее. Трафик просто утекает в интерфейс ИИ. Если нейросеть пересказывает суть статьи прямо в чате, зачем открывать оригинал?
• Потеря контроля над голосом бренда. ИИ решает, как преподнести ваш контент — может вырвать из контекста, искажать или просто упустить важные детали. Бренд уже не может поправить этот «пересказ». А ещё никто не увидит ваш уникальный дизайн и фирменный стиль.
• Рост нагрузки на серверы. ИИ-ассистенты и агенты автоматически перебирают десятки источников при каждом запросе. Опенсорс-сообщество уже жалуется: их ресурсы просто падают под лавиной ботов. А если этим займутся ИИ-агенты от имени миллионов пользователей — нагрузка на сайты вырастет в разы.
• Нарушение правил индексации. Раньше страницы индексировали Google и пара конкурентов, которые уважали robots.txt — файл, который говорит, где можно, а где нельзя. Сейчас же десятки ИИ-моделей парсят сайты без разбора, игнорируя эти ограничения.
• Проблемы с обучением ИИ и конфиденциальностью. ИИ-боты могут брать контент с сайтов не только для ответов, но и для обучения своих моделей. То есть ваша статья, обзор или даже комментарий могут стать частью «учебного корпуса», который помогает ИИ выдавать более «умные» ответы. При этом авторы часто не получают ни копейки и даже не знают, что их материалы используются таким образом. Многие сайты начали блокировать ИИ-ботов, чтобы защитить свой контент. Wired сообщает, что практически 90% новостных сайтов, таких как NYT, Guardian, Atlantic и др., блокируют краулеры OpenAI и других ИИ-компаний.

Если ИИ-разработчики продолжат брать контент без разрешения, их ждёт либо платный доступ к данным (они должны платить авторам за данные или переходить на лицензионную модель), либо война протоколов с нарушением веб-этикета. Ahrefs провели исследование — они проанализировали около 140 миллионов сайтов и обнаружили, что за последний год количество блокировок ИИ-ботов существенно выросло. Вот ключевые цифры:

• Число активных ИИ-ботов в сети удвоилось с августа 2023 года, сейчас насчитывается 21 крупный бот на основе ИИ.
• Самый блокируемый бот — GPTBot от OpenAI: его блокируют почти 6% всех сайтов.
• ClaudeBot (Anthropic) показал самый резкий рост блокировок — +32,67% за год.

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

Cloudflare разработали «кнопку» блокировки AI‑ботов, чтобы снизить подобные нагрузки. Подключить эту функцию может любой пользователь Cloudflare, включая бесплатные тарифы. Компания, которая специализируется на защите сайтов от атак, заметила, что ежедневно на её сеть приходится около 50 миллиардов запросов от ИИ-ботов. В ответ они запустили AI Labyrinth — «лабиринт ИИ-контента», куда попадают незваные боты, игнорирующие директивы no crawl, где они застревают в бесконечной цепочке перелинкованных страниц.

Переосмысление SEO в эпоху ИИ

Классическое SEO уходит в прошлое. Чтобы оставаться на плаву, брендам и авторам нужно учиться говорить с ИИ на его языке. Вот почему появляются новые методы и направления — AIEO и GEO:

• AIEO (Artificial Intelligence Engine Optimization) — оптимизация контента под ИИ-системы. Неважно, это голосовой помощник или чат-бот — задача AIEO сделать контент максимально понятным и «перевариваемым» для ИИ, чтобы он попадал в их ответы.
• GEO (Generative Engine Optimization) — это оптимизация именно под генеративные поисковые системы (например, Bing Chat, Google AI Mode).

Пока никто толком не знает правил новой ИИгры. Но уже есть общие признаки, которые могут помочь нейросети выбрать именно ваш контент для цитирования:

1. Чёткая структура: подзаголовки H2 и H3, чтобы разбить текст на логичные блоки.
2. Короткие, простые абзацы — никаких длинных занудных объяснений, только по делу.
3. Контент, который отвечает на вопросы: «что это», «зачем нужно», «пример на практике». Не просто набор ключевых слов, а полезная информация.
4. Внешние упоминания и ссылки — ИИ нравится, когда ваш контент не в изоляции, а подтверждён другими источниками.
5. Участие в специальных программах: можно подать заявки в ChatGPT Product Discovery, чтобы товар показывался в ответах ChatGPT или Perplexity Merchant Program — для крупных продавцов с доставкой в США, чтобы товары попадали в виджеты Perplexity.

Как оценить эффективность? Сейчас в аналитике уже можно увидеть переходы с нейросетей — они отображаются в отчетах по источникам трафика. Плюс появились метрики видимости бренда в ответах ИИ. Например, Ahrefs теперь показывает, как часто ваш бренд упоминается в ответах нейросетей. А новые сервисы помогают мониторить появление бренда в ИИ-результатах, отслеживать тональность упоминаний и анализировать динамику.

Это похоже на SEO начала 2000-х, когда с каждым обновлением алгоритма приходилось перестраиваться. С ИИ та же история: модели постоянно меняются, и нам придётся учиться работать с ними заново — иначе рискуем потерять трафик.

Конец эры поисковиков? Действительно ли нейросети заменят Google

Стоит ли ожидать полного исчезновения поисковиков? Вряд ли. Так же, как и исчезновения библиотек с появлением интернета. ИИ пока не заменит Google в роли поисковой системы, но классические поисковики со временем станут не актуальны из-за изменения природы потребления контента.

Пока Google лидирует, оставаясь примерно в 26 раз популярнее ChatGPT по ежедневным визитам. Совокупно ИИ-сервисы генерируют всего около одного процента от всех поисков Google. Но скорость роста говорит сама за себя: чат-боты за год выросли по количеству обращений на 80,92%. Впервые с 2015 года, к концу 2024-го, доля Google на рынке поиска опустилась ниже отметки в 90%. Однако аналитики OneLittleWeb считают, что чат‑боты и поисковики не конкурируют, а дополняют друг друга — каждый решает свои задачи. Чат-боты расширяют возможности поиска, превращая его в диалог и помощь в генерации идей, а поисковики интегрируют ИИ-сводки, чтобы ускорить выдачу информации.

Поисковики превращаются в умных ассистентов, которые сами сканируют интернет и дают готовые ответы. Но есть проблема: Google AI Overviews уже бьют по доверию и трафику. А главное — эти сводки не всегда точны. Техногигант тестирует ещё и AI Mode — чат прямо в поиске, который синтезирует инфу из разных источников. Кнопка «Мне повезёт» уходит в прошлое — теперь вам повезёт, если ИИ не нафантазирует лишнего. В России аналогичный тренд: Яндекс Нейро тоже объединяет классический поиск с генеративными нейросетями и умеет отвечать на комплексные запросы, копаясь в нескольких темах сразу. Поиск уходит в сторону диалогов и действий, и это уже не эволюция — это смена парадигмы.

Кто и как будет искать информацию завтра? Мир движется к более удобным и быстрым способам получения информации. Возможно, скоро все мы перестанем вводить запросы в строку поиска и будем давать задания своим ИИ-агентам. Пока зарождаются новые стандарты — GEO и AIEO, бизнесу стоит задуматься не только о том, как попасть в ответ ИИ, но и как ИИ сможет воспользоваться его услугами. Нужны будут инструкции и цифровая инфраструктура, понятная для агентов. В мире, где задачи будет выполнять не человек, а агент, нужны понятные инструкции и цифровая инфраструктура. Намечается новый тренд — agent-responsive design: сайты, которые удобны не только для людей, но и для ИИ.

Казалось бы, код — это просто текст. Но каждый запрос к API, каждая компиляция и даже холостой цикл требуют энергии. Например, обучение GPT-4 в 2023 году «съело» столько же электричества, сколько 120 домохозяйств за год. А теперь представьте, что таких моделей тысячи, а серверов — миллионы.

Почему это важно? Во-первых, регуляторы ужесточают требования: в ЕС с 2025 года IT-компании обязаны раскрывать углеродный след своих продуктов. Во-вторых, инвесторы все чаще смотрят на ESG-рейтинги — показатели экологического и ответственного производства. В-третьих, оптимизация кода снижает затраты на инфраструктуру.

Эта статья — не манифест экоактивистов, а руководство для разработчиков, архитекторов и технических директоров компаний (СТО), которые стремятся более эффективные и экологичные проекты.

Углеродный след кода: что скрывается за строчками

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

Откуда берутся выбросы

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

Прямые выбросы — это энергия, которую потребляют серверы при выполнении вашего кода. Например, один средний веб-сервер на AWS EC2 (тип t3.large) в год вырабатывает около 400 кг CO₂ — как небольшой автомобиль, проехавший 2000 км. При этом нагрузка на серверы постоянно растет: с 2020 по 2025 год энергопотребление дата-центров увеличилось на 35%.

Косвенные выбросы часто упускают из виду. Производство серверного оборудования — процесс крайне энергоемкий. Для создания одной только микросхемы памяти DDR5 требуется около 200 кВт⋅ч энергии — столько же, сколько средний холодильник потребляет за год. А после выхода оборудования из строя лишь 20% компонентов перерабатывается должным образом (Global E-Waste Monitor 2024).

Системы охлаждения — еще один скрытый источник выбросов. Современные дата-центры работают 24/7, и даже с использованием жидкостного охлаждения на поддержание температуры уходит до 40% всей потребляемой энергии. В жарких странах, ОАЭ или Сингапуре, этот показатель может достигать 50%.

Яркий пример — крупные языковые модели. Если в 2023 году обучение GPT-4 потребовало ~10 ГВт⋅ч (эквивалент годового потребления 120 домохозяйств), то к 2025 году из-за увеличения размеров моделей этот показатель вырос в 1,5 раза. Один запрос к такому ИИ теперь генерирует около 2 г CO₂ — как если бы вы проехали 10 метров на бензиновом автомобиле.

Но проблема не только в ИИ. Обычное веб-приложение с посещаемостью 100 000 пользователей в месяц может производить до 1 тонны CO₂ в год — и это без учета мобильных клиентов и API. При этом 30% этой нагрузки приходится на неоптимизированный фронтенд: тяжелые изображения, избыточные JavaScript-библиотеки и частые запросы к серверу.

Ситуацию усугубляет географический фактор. Дата-центр в Норвегии, где 98% энергии поступает от ГЭС, будет «чище», чем такой же центр в Польше, где угольные электростанции дают 70% энергии. Разница в углеродном следе может быть 20-кратной для идентичных операций.

При этом стандарты измерения все еще остаются разрозненными. PUE (Power Usage Effectiveness), который используют Google и Microsoft, учитывает только эффективность инфраструктуры, но не источник энергии. Новый стандарт CUE (Carbon Usage Effectiveness), разработанный в 2024 году, уже включает эти данные, но его поддерживают менее 30% провайдеров.

Где код тратит энергию впустую

Некоторые части систем особенно вредны для экологии. Главные «пожиратели» ресурсов:

• Неоптимизированные алгоритмы. Сортировка пузырьком (O(n²)) на большом массиве данных может потреблять в 100 раз больше энергии, чем быстрая сортировка (O(n log n)).
• Микросервисный хаос. Архитектура из сотен микросервисов увеличивает нагрузку на сеть. Каждый вызов API между сервисами — это дополнительные 0,5–1 Вт⋅ч.
• Облачные провайдеры. Не все одинаково зеленые. AWS и Google используют 60–70% ВИЭ (возобновляемых источников энергии), но в Азии и Африке их дата-центры часто работают на угле.

Как измерить углеродный след

В 2025 году появились инструменты, которые помогают оценить влияние кода:

• Cloud Carbon Footprint — анализирует выбросы AWS, GCP и Azure.
• Scaphandre — мониторит энергопотребление серверов в реальном времени.
• Greenframe.io — симулирует нагрузку на веб-приложение и считает CO₂.

Климатические инициативы в IT больше не просто красивые слова в корпоративных отчетах. В 2025 году за неэффективный код можно получить не только порицание сообщества, но и вполне реальный штраф.

Европейский союз уже ввел санкции против пяти крупных SaaS-компаний за превышение углеродных квот, а Amazon Web Services выплатила 2,7 млн евро штрафа за неоптимизированные алгоритмы в своих сервисах.

Как изменились подходы к разработке

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

Экологичный DevOps — новая реальность

Современные системы автоматического масштабирования стали умнее. Kubernetes Horizontal Pod Autoscaler теперь учитывает не только нагрузку на CPU, но и текущий углеродный след дата-центра. Если в регионе пиковое потребление энергии и работают угольные электростанции, система сознательно ограничивает масштабирование.

Технология, разработанная Google в партнерстве с WattTime, уже снижает выбросы CO₂ на 27-33% по сравнению с традиционным подходом.

CI/CD-цепочки тоже стали «зеленее». Вместо запуска полного набора тестов при каждом коммите, современные системы определяют, какие именно модули затронуты изменениями.

GitHub Actions представил Carbon-Aware Runner, который планирует выполнение задач на время максимальной доступности возобновляемой энергии в регионе. По данным Microsoft, это сокращает углеродный след тестирования на 40%.

Языки программирования: война за эффективность

Rust продолжает набирать популярность не только из-за безопасности, но и благодаря энергоэффективности. Тесты Benchmarks Game показывают, что один и тот же алгоритм обработки данных на Rust потребляет на 38-42% меньше энергии, чем на Python. В 2025 году Rust вошел в топ-5 языков для enterprise-решений, вытеснив Java в 17% крупных проектов.

Но настоящим открытием стал Zig — язык, который сочетает производительность C с простотой синтаксиса. Его компилятор потребляет в 3 раза меньше ресурсов, чем LLVM-бэкенд Rust, что делает его идеальным выбором для встраиваемых систем.

ИИ на грани: когда меньше значит лучше

TinyML-революция набирает обороты. Современные нейросети для микроконтроллеров занимают менее 256 КБ памяти, но справляются с задачами, которые раньше требовали облачных вычислений.

Например, новые датчики Nest анализируют звук прямо на устройстве, определяя не только дым, но и тип возгорания. Это экономит до 150 МБ трафика в месяц на одно устройство.

На фронте больших языковых моделей тоже произошли изменения. Meta* выпустила LLaMA-3 Nano — модель с 500 млн параметров, которая работает на смартфоне и по качеству ответов не уступает GPT-3.5. Ее углеродный след при обучении в 1200 раз меньше, чем у GPT-4.

(*Компания запрещена в РФ)

Новые правила игры: регуляторы и бизнес

С января 2025 года в Евросоюзе действует Углеродный налог на цифровые продукты (Digital Carbon Border Tax). Теперь любое ПО, продающееся в ЕС, должно иметь сертификат углеродной эффективности.

Для крупных enterprise-решений максимально допустимый углеродный след составляет 500 г CO₂ на 1000 пользователей в месяц. Нарушители платят 7% от оборота продукта в регионе.

Венчурные фонды радикально изменили подход к инвестициям. Согласно отчету PwC, 43% фондов требуют ESG-отчетность перед заключением сделки, а 28% вообще не рассматривают стартапы без «зеленой» стратегии. В Кремниевой долине появился первый акселератор Carbon Neutral Startups, который дает бонусы в $50 000 проектам с нулевым углеродным следом.

Корпорации тоже не остались в стороне. Microsoft ввела внутренний углеродный налог — теперь каждое подразделение платит $100 за каждую тонну CO₂, связанную с его продуктами. Эти деньги идут на развитие возобновляемой энергетики.

Но самое интересное происходит на рынке труда. Разработчики с навыками «зеленого» программирования получают на 15-20% больше предложений. Появилась появилась новая категория навыков — «Устойчивая разработка ПО», а спрос на таких специалистов вырос на 300% за последний год.

Как писать «зеленый» код

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

Оптимизация запросов к базе данных

Типичный пример — использование SELECT * вместо явного перечисления полей. Когда приложение запрашивает все поля таблицы users (включая редко используемые avatar_blob или metadata_json), сервер БД тратит дополнительные ресурсы на чтение и передачу этих данных. В крупных системах с миллионами запросов в день это приводит к значительному перерасходу вычислительных ресурсов.

Современные ORM типа Prisma и Drizzle добавили автоматическую оптимизацию запросов. Теперь при использовании select() они анализируют, какие поля действительно нужны на клиенте, и генерируют оптимальный SQL. В тестах это снижает нагрузку на БД на 12-18%.

Работа с циклами и алгоритмами

Классическая ошибка — продолжать перебор массива после нахождения нужного элемента. В 2025 году статический анализатор кода в WebStorm и VS Code автоматически предупреждает о таких ситуациях. Особенно критично это для мобильных приложений: лишние итерации цикла на слабых устройствах увеличивают энергопотребление на 5-7%.

Новые версии JavaScript и TypeScript ввели оптимизированные методы для массивов. Например, array.findLast() работает в 1,5 раза эффективнее ручной реализации с циклом. Для сложных алгоритмов появились «зеленые» библиотеки вроде EcoCollections для Java, которые минимизируют энергопотребление при работе с структурами данных.

Сжатие и передача данных

Формат Brotli стал новым стандартом для API: он обеспечивает лучшее сжатие, чем gzip, особенно для JSON-ответов. Компания Cloudflare провела эксперимент: после перехода на новую версию Brotli нагрузка на их серверы снизилась на 18%, что эквивалентно годовому потреблению энергии 2000 домохозяйств.

Но сжатие — не панацея. Грамотное проектирование API может дать больший эффект. GraphQL-подход, где клиент запрашивает только нужные данные, в среднем почти вдвое уменьшает объем передаваемой информации по сравнению с REST. А технология Server-Sent Events (SSE) для реального времени потребляет в 3 раза меньше ресурсов, чем WebSockets, когда не нужна двусторонняя связь.

Современные фреймворки начали учитывать энергоэффективность. Next.js 15 представил «зеленый» режим компиляции, который оптимизирует сборку под минимальное энергопотребление. В тестах это дало 8% экономии на процессоре при работе приложения. А Deno 2.0 автоматически кэширует зависимости на уровне ОС, сокращая число повторных загрузок.

Эти изменения кажутся мелкими, но в масштабах индустрии они имеют огромное значение. Если бы все репозитории на платформе применили базовые оптимизации, глобальное энергопотребление дата-центров сократилось бы на несколько процентов. Для отрасли, которая потребляет 700 ТВт⋅ч в год, это десятки миллионов долларов и тысячи тонн CO₂.

Выбор технологий

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

Языки программирования: баланс между скоростью и эффективностью

Rust и Go продолжают доминировать в высоконагруженных системах. Тесты показывают, что веб-сервер на Rust потребляет на 35-40% меньше энергии при одинаковой нагрузке по сравнению с Node.js. Особенно заметна разница в облачных средах, где каждый ватт на счету.

C++ остается выбором для задач, где важна предсказуемая производительность. Новый стандарт C++26 добавил энергоэффективные режимы работы алгоритмов STL, что особенно важно для встраиваемых систем.

Python по-прежнему хорош для прототипирования, но в продакшене его лучше заменять на компилируемые языки. PyPy 8.0 сократил энергопотребление интерпретатора на 25%, но даже с этими улучшениями Python проигрывает Rust в 3-4 раза по эффективности.

Базы данных: от малого к большему

SQLite — идеальный выбор для небольших проектов и edge-устройств. Его новая версия 3.45 добавила режим «энергосбережения», который снижает потребление на 15% при фоновых операциях.

PostgreSQL 17 сделал большой шаг в энергоэффективности. Функция автоматического партиционирования теперь учитывает не только производительность, но и энергопотребление. В тестах это дало 20% экономии на крупных аналитических запросах.

Для высоконагруженных систем появилась альтернатива — ScyllaDB 5.0. Эта Cassandra-совместимая СУБД потребляет втрое раза меньше энергии при аналогичной нагрузке, благодаря полному переписыванию на Rust.

Кейсы: что работает, а что нет

Российские компании тоже внедряют экологичные IT-решения. МТС разработала мобильное приложение, где пользователи получают бонусы за раздельный сбор мусора — их можно обменять на подписки или скидки. За первый год проект привлек 500 тысяч участников и сократил количество непереработанных отходов в регионах присутствия.

НИУ ВШЭ, совместно с Росприроднадзором, автоматизировал сбор экологической отчетности с помощью ИИ. Нейросеть анализирует данные с датчиков и заполняет формы вместо специалистов. Это сократило время обработки с 100 до 10 часов в месяц и уменьшило количество ошибок.

Некоторые архитектурные решения приносят больше вреда, чем пользы. Один московский стартап без необходимости разбил монолитную систему на 50 микросервисов — в результате затраты на инфраструктуру выросли в 3 раза, а углеродный след увеличился на 180%.

Проблемы возникают и на уровне зависимостей. История с left-pad повторилась в 2024 году, когда один npm-пакет потянул за собой 80 МБ ненужных библиотек. Теперь крупные компании проверяют каждую зависимость через Bundlephobia и устанавливают лимит на размер node_modules.

Что нас ждет

В 2025 году отрасль стоит на пороге радикальных изменений, которые перевернут наши представления о «зеленом» программировании.

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

Google уже тестирует эту технологию в Северной Европе: когда в Норвегии дует сильный ветер и ветряные электростанции работают на пике, система переносит вычисления именно туда. По предварительным оценкам, это снижает углеродный след на 18-22% по сравнению со статичным распределением.

Но настоящий прорыв ожидается в сегменте квантовых вычислений. Хотя современные квантовые компьютеры потребляют колоссальное количество энергии (система IBM Quantum System One требует около 25 кВт⋅ч для работы одного кубита), их потенциал для оптимизации классических алгоритмов огромен.

В 2024 году исследователи из ЦЕРНа предложили квантовый алгоритм, который сокращает время сложных расчетов в 1000 раз при той же точности. Когда такие решения станут массовыми (прогноз — 2028-2030 годы), энергопотребление дата-центров может сократиться на 30-40%.

Государственное регулирование становится строже. В 2025 году в силу вступает EU Digital Product Passport — требование указывать углеродный след для всего ПО, продающегося в Европе.

Компании, которые не смогут предоставить эти данные, столкнутся с дополнительными налогами до 7% от оборота. В ответ на это крупнейшие IT-корпорации создали Carbon Neutral Software Alliance — консорциум по разработке единых стандартов измерения.

Не отстает и аппаратная часть. Производители чипов переходят на новые техпроцессы: TSMC анонсировала 2-нм процесс, который на 30% энергоэффективнее предыдущего поколения. А стартапы вроде британской ZeroPoint Technologies разрабатывают память с нулевым энергопотреблением в режиме ожидания — технология может сократить энергопотребление серверов на 15%.

Но главный тренд — децентрализация вычислений. Edge-устройства (от смартфонов до промышленных датчиков) становятся мощнее и берут на себя часть нагрузки. Например, новый алгоритм Apple для обработки фото на iPhone 16 выполняет 90% операций локально, а не в облаке. По оценкам компании, это экономит сотни тысяч тонн CO₂ в год только для пользователей в США.

Однако остаются и проблемы. Бум генеративного ИИ привел к взрывному росту энергопотребления: одна тренировка модели Gemini Ultra потребляет столько же энергии, сколько небольшой город за месяц. OpenAI и Anthropic уже работают над более эффективными архитектурами, но прорыва пока не случилось.

В ближайшие 3-5 лет нас ждет:

• массовый переход на углеродно-нейтральные дата-центры — к 2027 году их доля превысит 60%;
• внедрение AI-оптимизаторов кода, которые автоматически сокращают энергопотребление;
• появление «зеленых» рейтингов для приложений — аналог энергоэффективности для бытовой техники.

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

Технологии будущего уже здесь. Вопрос в том, насколько быстро мы сможем их адаптировать. Как сказал Дженсен Хуанг из NVIDIA на последней конференции GTC:

«Следующее десятилетие определит, станет ли IT частью климатического решения или останется проблемой. Выбор за нами».

Итоги

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

С чего начать? Начните с малого:

1. Запустите аудит через Cloud Carbon Footprint.
2. Уберите «мусор» из зависимостей.
3. Выберите хостинг с ВИЭ.

Как говорил Дональд Кнут, автор книги «Искусство программирования»:

«Преждевременная оптимизация — корень всех зол. Но и запоздалая — тоже».

В 2025 году это актуально как никогда.

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

Что произошло

В 20:50 по московскому времени в системе IAM Google Cloud начались сбои. Этот сервис отвечает за проверку доступа и выдачу токенов всем API.

Когда IAM перестал справляться с запросами, это затронуло почти все остальные сервисы GCP — от хранилищ и баз данных до ИИ-сервисов.

Хронология событий

• 20:51 — внутренние алерты Google: IAM возвращает ошибки 5xx
• 21:05 — на DownDetector резко растут жалобы на Gmail, Drive и Meet
• 21:19 — Cloudflare сообщает о сбоях в Access
• 21:25 — Anthropic отключает загрузку файлов, чтобы снизить нагрузку
• 22:41 — Google внедряет исправления в IAM, большая часть регионов восстанавливается
• 23:30 — Cloudflare восстанавливает работу Access, KV и WARP
• 00:05 — Anthropic сообщает о полном восстановлении Claude
• 04:18 — полное восстановление сервисов GCP, включая Vertex AI

Причины сбоя

Google подтвердила, что сбой произошел из-за некорректного обновления бэкенда IAM. Обновление попало в продакшен раньше, чем его смогли отловить тесты в ограниченных зонах.

Ошибка распространилась по всем регионам, и только откат, удаление некорректной конфигурации и принудительное обновление кэша токенов помогли восстановить систему.

Уроки для разработчиков

Произошедшее показало, что сбои в control-plane (аутентификация, метаданные) опаснее сбоев в data-plane (файлы, запросы). Также стало более явно, что даже multi-cloud архитектуры могут зависеть от одного слабого звена в глубине стека.

Из прочих уроков аварии можно отметить:

• Страницы статуса должны обновляться оперативно — Google потребовался почти час
• Необходимы обходные маршруты для критичных точек (например, авторизации)
• План реагирования должен включать редкие, но возможные каскадные сбои

Итоги

Ошибка в одном компоненте Google Cloud вызвала сбои в десятках сервисов по всему миру. В течение семи часов компании теряли доступ к данным, пользователи не могли авторизоваться, а инженеры — найти причины проблемы.

Полный отчет от Google и Cloudflare пока в разработке. Но уже ясно, что даже самые крупные игроки не застрахованы от сбоя, если в центре — непротестированное обновление и скрытые зависимости.

Этап 1: Простой MVP за $0

Изначально нужно создать максимально простое приложение для управления задачами: веб-страница с несколькими категориями и возможностью добавлять таски. На фронте разработчик использует библиотеку Shad CN UI, а на бэке — Flask. Данные хранятся просто в словаре Python. Все приложение — это один файл. Оно запускается в Docker-контейнере через docker compose.

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

Этап 2: Инфраструктура на $30

Чтобы приложение стало более удобным и приближенным к продакшену, разраб добавляет несколько главных компонентов:

• База данных: PostgreSQL.
• Веб-сервер: Nginx для проксирования запросов и избавления от портов.
• Аутентификация: авторизация через JWT и интерфейсы входа и регистрации на фронтенде.

Все эти компоненты подключаются к существующему приложению через docker-compose.yml. Благодаря этому теперь можно запускать приложение на localhost, а не по порту, и все будет работать как полноценное веб-приложение. Размещение такой системы на бесплатном облачном тарифе или VPS обойдётся в пределах 30 долларов.

Этап 3: Допиливание до $100

Разработчик добавляет допфункции:

• Уведомления по email: вместо стороннего API — система очередей с RabbitMQ и воркером, который отправляет письма.
• Обновления в реальном времени: WebSocket’ы для синхронизации задач на разных устройствах.
• Кэширование: Redis для хранения данных в памяти, что значительно ускоряет работу.

Также подключается Docker Build Cloud — сервис для параллельной сборки контейнеров и шаринга кеша между проектами. Это повышает производительность и ускоряет разработку.

Теперь в системе работает очередь заданий, кеш, WebSocket-сервер, SMTP и полноценная база данных. Все эти компоненты увеличивают инфраструктурные затраты до примерно $100 в месяц.

Этап 4: Мониторинг и масштабирование за $500

Разработчик внедряет:

• Логирование: стек ELK (Elasticsearch, Logstash, Kibana).
• Мониторинг: Prometheus и Grafana.
• Горизонтальное масштабирование: добавляются реплики некоторых сервисов и балансировка нагрузки через Nginx.

Эти инструменты позволяют отслеживать метрики, визуализировать логи, следить за состоянием приложений и быстро выявлять сбои. Инфраструктура становится ближе к корпоративному уровню. Стоимость такого комплекса достигает уже около 400–500 долларов в месяц.

Этап 5: Целых $2000 долларов

Разработчик решает перейти на Kubernetes и развернуть приложение в разных дата-центрах по всему миру. Для управления трафиком используется глобальный балансировщик нагрузки (например, Cloudflare). А чтобы все работало стабильно, внедряются:

• Postgres с репликацией в реальном времени,
• Redis для быстрой отдачи данных.

Сейчас без ИИ приложение уже не имеет смысла. Поэтому разработчик решает добавить серверлесс-функции с категоризацией задач, приоритетами и предложениями на основе поведения пользователей, а также с использованием обработки естественного языка для создания тасков. Также подключаются правовые ограничения — поддержка GDPR и CCPA.

Для мониторинга:

• Jaeger — для распределённой трассировки,
• ELK Stack — для логов,
• Grafana + PagerDuty — для алертов и инцидентов.

Вишенка на торте — план восстановления после катастроф: бэкапы, автоматическое переключение на другие регионы и подготовка команды.

Хотя вся система началась с одного Python-файла и простого UI, шаг за шагом разработчик добавлял в нее компоненты, которые делают её пригодной для реального продакшена: защита, масштабируемость, отказоустойчивость, мониторинг, кеширование и очереди. И оно вполне может стоить несколько сотен или даже тысяч долларов в месяц при развертывании в облаке.

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

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

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

Основные причины утечек

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

Разберем основные причины утечек.

Хардкодинг ключей в исходном коде

Пожалуй, самая распространенная и опасная практика — прямое внедрение API-ключей в исходный код приложения. Разработчики часто делают это для удобства тестирования, забывая удалить секретные данные перед релизом.

Особенно критично, когда ключи остаются:

• в конфигурационных файлах (config.php, .env);
• в закомментированных блоках кода;
• в тестовых сборках, которые по ошибке попадают в продакшен;
• в шаблонах и примерах кода.

Яркий пример — инцидент с Microsoft в 2023 году, когда утечка ключа MSA (Microsoft Account) через устаревший код позволила хакерам получить доступ к почтовым ящикам правительственных организаций США, включая Министерство торговли. Как показало расследование Microsoft Security Response Center, проблема возникла из-за ключа подписи, который продолжал использоваться в legacy-системах и попал в руки злоумышленников.

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

Случайные коммиты в публичные репозитории

Системы контроля версий типа Git хранят полную историю изменений, что создает дополнительные риски. Даже если ключ удален из текущей версии кода, он может остаться в истории коммитов.

Типичные сценарии:

• временное добавление ключа для отладки с последующим «удалением»;
• позднее добавление .env-файла в .gitignore;
• слияние веток с чувствительными данными;
• автоматические коммиты IDE и инструментов разработки.

В публичные репозитории GitHub ежедневно попадают сотни активных ключей — некоторые из них даже предоставляют доступ к платежным системам и базам данных.

Ошибки в настройке CI/CD

Автоматизированные системы сборки и деплоя могут невольно способствовать утечкам:

• передача ключей через аргументы командной строки;
• попадание секретов в логи сборки;
• неправильная настройка переменных окружения;
• хранение ключей в незащищенных артефактах;
• избыточные права доступа для CI-сервисов

Особенно опасны ситуации, когда CI-пайплайн настроен на публикацию артефактов сборки, включающих конфигурационные файлы с ключами.

Логирование чувствительных данных

Разработчики часто добавляют отладочный вывод, который затем забывают удалить:

• console.log (“API Key: “, secretKey);
• погирование полных HTTP-запросов с заголовками авторизации;
• дампы ошибок с конфиденциальными данными;
• журналирование параметров запросов.

Такие записи могут попасть в системные логи, инструменты мониторинга (Kibana, Grafana), браузерную консоль (для фронтенд-приложений) и облачные сервисы хранения логов.

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

Неправильное управление доступами

Часто проблема кроется не в технических решениях, а в процессах управления:

• отсутствие ротации ключей — некоторые из них используются годами;
• использование одних ключей для разных сред (dev/stage/prod);
• избыточные права доступа — принцип минимальных привилегий не соблюдается;
• хранение ключей в общих хранилищах и чатах;
• отсутствие аудита использования ключей.

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

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

Безопасное хранение и использование API-ключей

API-ключи — это критически важные элементы инфраструктуры, и их утечка недопустима. Чтобы минимизировать риски, важно соблюдать несколько принципов.

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

Сканер секретов GitHub ежедневно обнаруживает сотни случайно залитых ключей, несмотря на предупреждения. Переменные окружения позволяют отделить конфиденциальные данные от кода, но важно убедиться, что файлы .env не попадают в билды или логи.

Для более сложных сценариев стоит рассмотреть специализированные хранилища секретов, такие как HashiCorp Vault, AWS Secrets Manager или Doppler. Они не только обеспечивают безопасное хранение, но и добавляют функции ротации ключей, аудита доступа и интеграции с системами мониторинга.

• Vault динамически генерирует временные ключи для отдельных сервисов, сводя к нулю риск их повторного использования. Однако такие решения требуют настройки и контроля — при некомпетентном подходе компании сталкиваются с ошибками конфигурации при внедрении.
• AWS Secrets Manager — инструмент, который позволяет централизованно хранить конфиденциальную информацию, извлекать ее, управлять доступом, ротировать и мониторить.
• Doppler — кроссплатформенное решение с удобным интерфейсом и историей изменений. Особенно популярно среди стартапов.

Главное преимущество таких систем — централизованное управление. При увольнении сотрудника или компрометации ключа его можно отозвать мгновенно для всех сервисов.

Шифрование обязательно как при передаче, так и при хранении. Даже если злоумышленник получит доступ к базе данных или логам, зашифрованные ключи останутся бесполезными без расшифровки. Современные стандарты, такие как AES-256 или алгоритмы на основе PQC (постквантовой криптографии), уже встроены в большинство облачных провайдеров. Но важно не забывать про управление ключами шифрования (KMS): их утечка сведет на нет всю защиту.

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

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

Важно: ни один метод не дает 100% защиты API. Нужно комбинировать подходы и регулярно аудировать систему. Безопасность API-ключей — это не разовая настройка, а процесс, требующий регулярного пересмотра политики адаптации к новым угрозам.

Лучшая практика работы с ключами

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

Вот самые эффективные практики:

• Первое правило — никогда не оставлять ключи в коде. Даже если репозиторий приватный, всегда существует риск случайной публикации или утечки через резервные копии. Инструменты вроде pre-commit хуков помогают предотвратить подобные инциденты, автоматически проверяя изменения перед отправкой. Например, скрипт может сканировать коммиты на наличие строк, похожих на ключи, и блокировать их сохранение.
• Регулярная ротация снижает потенциальный ущерб от возможной компрометации. Ключи, которые не обновлялись годами, представляют особую опасность. Современные системы, такие как HashiCorp Vault или AWS Secrets Manager, позволяют автоматизировать этот процесс.
• Принцип минимальных привилегий должен применяться ко всем ключам. Если токен нужен только для чтения данных, он не должен иметь прав на запись или удаление. Ограничение области действия каждого токена — простой, но эффективный способ снизить риски.
• Мониторинг использования помогает выявлять аномалии в реальном времени. Неожиданные всплески активности, запросы из новых регионов или попытки доступа к неиспользуемым методам API — все это сигналы потенциальной компрометации. Инструменты типа AWS CloudTrail или Elastic SIEM позволяют отслеживать подобные события и оперативно реагировать на угрозы.
• Обучение команды не менее важно, чем технические меры. Регулярные тренинги и чек-листы помогают поддерживать уровень осведомленности.

Централизованное управление упрощает контроль за ключами. Когда все токены хранятся в одном защищенном месте, проще отслеживать их использование, вовремя обновлять и отзывать при необходимости. Это также облегчает аудит, который часто требуется для соответствия стандартам вроде PCI DSS или ГОСТ Р 56939-2024.

Процесс отзыва должен быть максимально оперативным. В случае компрометации ключа важно не только сгенерировать новый, но и убедиться, что старый уже недействителен. Некоторые сервисы, например Google Cloud, позволяют автоматически блокировать ключи при обнаружении подозрительной активности.

Автоматическое выявление утечек

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

Эффективный мониторинг начинается с проверки исходного кода. Такие инструменты, как GitGuardian и TruffleHog, сканируют git-репозитории, включая историю коммитов, на наличие случайно оставленных ключей. Они используют комбинацию шаблонов и энтропийного анализа, что помогает находить даже замаскированные секреты. Интеграция этих проверок в CI/CD-пайплайны позволяет перехватывать потенциальные утечки до их попадания в основную ветку.

Для обнаружения ключей за пределами репозиториев существуют специализированные сервисы, которые мониторят открытые площадки вроде Pastebin и технических форумов. Некоторые решения способны анализировать контекст, отличая реальные ключи от случайных последовательностей символов.

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

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

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

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

Как реализовать безопасный доступ на фронтенде

Основная проблема фронтенд-разработки в контексте работы с API — невозможность полностью защитить клиентский код. В отличие от серверной части, JavaScript остается открытым для анализа, а сетевые запросы легко перехватываются. Однако существуют проверенные подходы, позволяющие минимизировать риски утечки ключей.

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

Вместо этого рекомендуется использовать архитектурный паттерн Backend-for-Frontend (BFF), когда фронтенд общается с промежуточным сервером, а тот уже взаимодействует с основными API. Так ключи остаются на защищенной стороне, а клиент получает только временные токены с ограниченным сроком действия.

Для аутентификации пользователей оптимально подходит OAuth 2.0 с расширением PKCE (Proof Key for Code Exchange). Этот механизм обеспечивает безопасный обмен токенами даже в публичных клиентах. В отличие от обычного потока авторизации, PKCE добавляет дополнительный уровень защиты через одноразовые ключи верификации, что предотвращает перехват кодов злоумышленниками.

В случаях, когда фронтенду необходим доступ к публичным API без аутентификации пользователя, стоит использовать ограниченные токены. Например, для картографического сервиса можно выпускать ключи, разрешающие только чтение данных с жестким лимитом запросов. Такой подход применяют многие крупные платформы, включая Яндекс.Карты. Даже если токен будет скомпрометирован, его полезность для злоумышленников окажется минимальной.

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

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

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

Главный вывод: фронтенд действительно представляет угрозу для безопасности API-ключей, но грамотная архитектура и продуманные механизмы авторизации позволяют снизить риски до приемлемого уровня. Ключевой принцип защиты API — минимализм в правах доступа и максимальное делегирование ответственности серверной части.

Хочешь писать код, который не стыдно показывать? Всё для фронтендеров и бэкендеров в одном месте.

Причины переноса сайта на другой хостинг могут быть разными:

• Юзабилити. Страницы сайта начнут грузиться быстрее, плюс он будет более удобным и поднимется в поиске.
• Затраты. Хостеры с выгодными тарифами или оптимальными предложениями позволят снизить эксплуатационные расходы.
• Стабильность. Смена провайдера с частыми сбоями на более устойчивого партнера обеспечит бесперебойную работу ресурса.
• Поддержка. Более квалифицированная служба поддержки поможет быстрее справляться с возникающими проблемами;
• Масштабирование. Хостер с возможностью масштабирования ресурсов поддержит растущий трафик и потребности вашего сайта;
• Безопасность. Повышенные меры защиты предотвратят угрозы кибератак и утечек данных;
• Расположение. Серверы, расположенные рядом с основной аудиторией, обеспечат ускоренную загрузку и лучшее восприятие пользователями.

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

Шаг первый

Начать стоит с планирования и подготовки к миграции. Выберите оптимальное время для переезда. Запланируйте перенос на наименее загруженный период работы сайта (например, поздней ночью или в выходные). Одновременно с этим приостановите публикацию нового контента и изменения на странице на время миграции, и предупредите команду, чтобы редакторы, авторы или клиенты не вносили правки: любые изменения во время переноса могут не попасть на новый сервер, что приведёт к потере данных. Если ожидается заметный простой или отключение функций (например, оформление заказов), предупредите пользователей о предстоящих технических работах. Разместите баннер или уведомление на сайте с указанием времени обслуживания и извинениями за неудобства.

При переносе необходимо подготовить новую хостинг-платформу заранее: зарегистрировать и настроить аккаунт у нового провайдера — желательно за 1-2 недели до переключения. Важно, чтобы тариф и ресурсы нового хостинга не уступали старому, а лучше превосходили его по параметрам (производительность, объем хранилища, оперативная память и пр.). Обязательно стоит проверить совместимость нового сервера с имеющимся стеком технологий: версии ОС, PHP/Node.js, СУБД, требуемые модули и библиотеки должны соответствовать или превышать текущие, чтобы избежать ошибок совместимости.

Далее нужно провести аудит всех компонентов вашего проекта. Составьте подробный список того, что нужно перенести: файлы сайта, базы данных, аккаунты пользователей, контент (изображения, видео, документы), настроенные задачи (cron jobs), DNS-записи (A, CNAME, MX и пр.), сертификаты SSL, иные интеграции.

Заранее стоит продумать, как минимизировать downtime. Помимо выбора ночного времени и контент-фриза существуют технические приемы: например, сокращение TTL DNS (см. раздел про DNS ниже) позволяет быстрее переключить домен на новый IP, а предварительное тестирование сайта на новом сервере до обновления DNS помогает выявлять проблемы — причем пользователи ничего не заметят.

Шаг второй

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

Шаг третий

Переходим непосредственно к переносу файлов и баз данных. Для этого нужно перевести сервисы в режим миграции и перед началом копирования данных переключить сайт в оффлайн-режим (режим обслуживания).

Далее — скопировать файлы сайта на новый сервер. Самый простой способ — загрузить бэкап на новый хост и развернуть его там, после чего перенести на него базу данных, связанные сервисы и настройки. Помимо основного кода и БД, переносится и все окружение сайта. До переключения DNS запускаем тестирование на новом сервере, чтобы убедиться в работоспособности сайта в новом окружении, прежде чем направлять на него пользователей.

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

Шаг четвертый

Чтобы сократить TTL DNS перед переключением, за день-два до планируемой миграции стоит уменьшить TTL (Time to Live) для DNS-записей вашего домена, а также обновить DNS-записи на новые. Когда новый сервер полностью готов и протестирован, нужно изменить DNS-записи домена, указывающие на старый хост, чтобы они указывали на новый. Если домен обслуживается у регистратора или внешнего DNS-сервиса — поменяйте A-запись (IPv4) и AAAA-запись (IPv6), или NS-записи (если менялся DNS-провайдера целиком). В случае смены хостинга часто требуется обновить NS (nameservers) на стороне регистратора на NS нового провайдера.

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

После проверки переноса или перенастройки всех связанных DNS-записей стоит проверить и обновления DNS. Для этого можно использовать утилиты вроде nslookup или онлайн-сервисы (Google DNS, Cloudflare DNS, WhatsMyDNS), чтобы убедиться, что домен теперь указывает на новый сервер по всему миру.

Шаг пятый

Перенос состоялся. Что дальше? Пост-миграционное тестирование и мониторинг

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

Не стоит забывать следить за журналами и метриками: просматривать логи веб-сервера и приложений на новом сервере, искать ошибки (PHP fatal errors, 500 Internal Server Error, проблемы подключения к БД и т.д.) и устранять их. После перехода на новый хостинг нужно проверять и SEO-показатели и индексацию, чтобы убедиться, что сайт по-прежнему правильно индексируется поисковиками.

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

Лайфхаки для безопасной и простой миграции

Вот несколько универсальных советов для тех, кто планирует переезжать на новый хостинг:

• Делайте бэкапы на каждом этапе.
• Планируйте и документируйте. Подготовьте чек-лист миграции и строго ему следуйте.
• Тщательно проверяйте окружение до запуска. Никогда не переключайте пользователей на новый хостинг, пока сами не убедитесь, что там всё работает на 100%.
• Минимизируйте окно простоя.
• Общайтесь с аудиторией. Предупредите постоянных пользователей о небольшом перерыве в работе.
• Учитывайте SEO-факторы. Небольшие просадки SEO в возможны, но правильная миграция их минимизирует.
• Следите за качеством данных. После переезда организуйте своеобразный аудит данных: сопоставьте количество записей в базах, количество файлов, размер медиа-библиотеки до и после.

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

Чтобы не потерять данные, нужно использовать лучшие подходы. Как раз рассказываем о таких в нашем тг-канале.

Уязвимость связана с тем, как фреймворк обрабатывает заголовок x-middleware-subrequest. Он задумывался как внутренний механизм защиты от бесконечной рекурсии, но злоумышленник может добавить этот заголовок в обычный запрос и тем самым отключить middleware полностью.

Это позволяет получить доступ к защищенным маршрутам — например, /dashboard/admin — даже без авторизации.

Как это работает

При наличии заголовка x-middleware-subrequest с нужным значением Next.js пропускает выполнение middleware и передает запрос напрямую. Пример:

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

Кто под ударом

Подвержены все приложения, использующие Next.js:

• версий 11.1.4–13.5.6
• версий 14.x до 14.2.25
• версий 15.x до 15.2.3

Развертывания на Vercel уже защищены, но self-hosted инсталляции уязвимы, если не обновлены или не настроены вручную.

Риски и последствия

Эксплуатация уязвимости позволяет:

• обойти авторизацию и получить доступ к закрытым разделам;
• обойти заголовки безопасности, например CSP;
• влиять на кэширование контента, отравляя кэш на стороне CDN.

Для атаки не нужны специальные инструменты — только корректный заголовок в HTTP-запросе.

Как защититься

Решения два:

1. Обновиться до безопасных версий — 14.2.25 или 15.2.3.
2. Если обновление невозможно, заблокировать или удалить заголовок x-middleware-subrequest до того, как он попадет в Next.js.

Это можно реализовать на уровне:

• WAF или балансировщика (например, Cloudflare);
• web-сервера (Nginx, Apache);
• Express-сервера, если используется кастомная сборка.

Что такое Firewall и зачем он нужен?

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

Firewall (читается как фаервол) — система безопасности, которая фильтрует трафик между устройствами в сети и Интернетом. Она контролирует, какие данные могут входить и выходить, и блокирует вредоносные или подозрительные соединения.

Когда нужен Firewall?

1. Защита офисной сети. Например, в компании есть корпоративная сеть, и руководство не хочет, чтобы сотрудники открывали небезопасные сайты или скачивали вирусы. Firewall можно настроить так, чтобы блокировать доступ к определённым ресурсам.
2. Фильтрация внешних подключений. Допустим, у вас есть сервер с важными данными, и вы хотите, чтобы он был доступен только с определённых IP-адресов. Firewall может заблокировать всех, кроме разрешённых пользователей.
3. Защита от вредоносных атак. Хакеры могут пытаться сканировать сеть на наличие уязвимостей или отправлять вредоносный трафик. Firewall помогает остановить такие атаки.

Что такое WAF и почему его недостаточно заменить Firewall?

Если Firewall – забор вокруг дома, то WAF (Web Application Firewall) – умный домофон, который проверяет каждого гостя по видео и может отказать в доступе, если что-то не так.

WAF защищает конкретно веб-приложения, анализируя HTTP/HTTPS-запросы и предотвращая атаки, направленные на уязвимости сайта. Обычный Firewall не разбирается в веб-запросах на таком глубоком уровне.

Когда нужен WAF?

Защита от SQL-инъекций

SQL-инъекция – атака, при которой злоумышленник вводит вредоносный код в текстовые поля веб-приложения, чтобы изменить работу базы данных.

Пример на PHP:

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

Защита от XSS (кросс-сайтового скриптинга)

XSS – атака, при которой хакер внедряет вредоносный JavaScript-код на сайт, который затем выполняется у пользователей.

Пример уязвимого кода на JavaScript:

Если злоумышленник введёт <script>alert('Взлом!')</script>, браузер выполнит этот код, открыв всплывающее окно. WAF может предотвратить подобные инъекции.

Можно ли ставить WAF и Firewall на один сервер?

Обычно WAF и Firewall работают на разных уровнях и ставятся на разные устройства:

1. Firewall чаще устанавливается на отдельный сервер или маршрутизатор, через который проходит весь трафик.
2. WAF может быть облачным (например, Cloudflare) или локальным (установленным на сервере веб-приложения).

Но бывают и комплексные решения, где оба механизма объединены.

Популярные Firewall и WAF

Популярные Firewall:

1. pfSense — бесплатный и мощный firewall с гибкой настройкой
2. Cisco ASA — аппаратный межсетевой экран от Cisco, часто используется в крупных компаниях
3. Fortinet FortiGate — мощное решение для корпоративных сетей

Популярные WAF:

1. ModSecurity — один из самых известных WAF, который можно интегрировать с веб-серверами
2. Cloudflare WAF — облачное решение, защищающее сайты от атак
3. AWS WAF — WAF от Amazon, используется для защиты приложений, развернутых в AWS

Обычно настройкой занимаются DevOps-инженеры, системные администраторы или сетевые инженеры. Они устанавливают firewall на сетевых узлах.

Cloudflare — это WAF или Firewall?

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

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

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

Что нужно выбрать?

Если у вас обычный сервер, то:

1. Firewall — защита на уровне сети, нужен для фильтрации трафика;
2. WAF — защита веб-приложения от специфичных атак (SQL-инъекции, XSS);
3. Cloudflare — может дополнять их, предоставляя облачную защиту.

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

И помните: безопасность — это не одна технология, а комплекс мер, которые помогают защитить ваш проект!

Если вам интересно разобраться в этих темах подробнее и в доступной форме, загляните в мой блог СистемныйАрхитектор.рф — там много полезных материалов.

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

Суть проблемы

Zendesk использует автоматическую систему создания тикетов на основе электронных писем.

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

Поскольку многие компании интегрировали Zendesk с системой единого входа (SSO), такая атака могла привести к захвату аккаунтов в таких сервисах, как Slack.

Проблема с политикой Zendesk

После обнаружения уязвимости, Даниэль обратился в программу вознаграждений за уязвимости Zendesk через платформу HackerOne, однако его сообщение было отклонено, так как использованная техника считалась «вне рамок».

Несмотря на это, после того как Даниэль стал уведомлять компании напрямую, Zendesk пересмотрела свою позицию и признала проблему.

Последствия

Даниэль заработал более $50 тыс за сообщения о проблеме различным компаниям, однако сам Zendesk не выплатил вознаграждение.

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

В процессе судебного разбирательства выяснилось, что патенты Sable Networks либо устарели, либо вообще не должны были быть выданы.

Теперь компания не только обязана выплатить Cloudflare $225 тыс, но и предоставить бесплатную лицензию на все свои патенты, а также сделать их общедоступными.

Кто такие патентные тролли?

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

Sable Networks – яркий пример такой деятельности. Она предъявила Cloudflare обвинения в нарушении более чем 100 патентов, большинство из которых касались устаревших технологий маршрутизаторов.

В результате разбирательства Cloudflare доказала, что обвинения были необоснованными и что патенты не могли быть использованы в её продуктах.

Как Cloudflare разоблачила Sable Networks

Cloudflare удалось убедить суд в недействительности патентов, которые использовала Sable Networks для своих обвинений.

Например, ключевой патент 7012919 касался технологии «микропотока», которая, как выяснилось, была описана в более ранних документах других компаний.

Этот факт убедил судей в том, что патент Sable был выдан ошибочно. В результате Cloudflare не только избавилась от претензий, но и обернула ситуацию так, что Sable Networks теперь должна ей деньги.

Последствия для Sable Networks

После сокрушительного проигрыша в суде, сайт Sable Networks перестал функционировать, а офисные телефоны компании больше не отвечают.

Судебное поражение стало ударом по ее репутации. При этом компания также подавала иски против таких гигантов, как Cisco и Juniper Networks. Правда, эти IT-гиганты решили урегулировать дела вне суда.

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

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

Работы в Сингапуре и Нэшвилле

Cloudflare сообщает о запланированных технических работах в Сингапуре и Нэшвилле, но страница статуса сервиса не отображает каких-либо проблем.

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

Сообщения о проблемах поступают со всего мира

Сбой подтверждается также мониторинговым сервисом Downdetector, где около 20:45 PM по московскому времени начали поступать массовые жалобы на Cloudflare.

Одновременно пользователи соцсети X.com заявили, что сайты недоступны по протоколу IPv4, но все еще доступны через IPv6.

Представители NodeJS.org также заявили, что сбой Cloudflare влияет на доступ к их сайту и загрузке Node.js.

На момент написания материала, комментариев от представителей Cloudflare не последовало.

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

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

С какими проблемами столкнулись разработчики при переносе игры?

• В веб-страницах невозможно запустить цикл main(). Решили её просто — заменив цикл на функцию emscripten_set_main_loop().
• Использование в сетевом коде игры UDP-протокола. В итоге разработчики написали новый сетевой модуль Chocolate Doom. С его помощью они использовали протокол TCP и WebSockets вместо UDP.

О полном процессе переноса DOOM на рельсы воркеров можно почитать в блоге Cloudflare. Там команда, занимавшаяся портированием, максимально подробно расписала весь процесс.

Отметим, что Cloudflare Workers — очень удобный инструмент. Но у него есть и свои недостатки. Главный из них — вендор лок.

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

Источник: Блог Cloudflare

Источник — блог Cloudflare

Что такое gRPC?

Такие протоколы, как JSON-REST, уже продолжительное время являются основой для API-интерфейсов. Они хороши тем, что работают поверх HTTP, легко читаются и обладают внушительным набором инструментов для быстрой настройки API. Однако использование JSON, например, может быть достаточно ресурсоёмким с вычислительной точки зрения.

В 2015 году Google представила новый протокол gRPC. Высокая производительность достигается за счёт использования протокола HTTP/2 и Protocol Buffers:

Источник — блог Cloudflare

Да, это делает данные трудно читаемыми, но приводит к более эффективной обработке. Таким образом, gRPC становится особенно популярным в эпоху микросервисов, поскольку устраняет недостатки, изложенные выше.

Если копнуть глубже, RPC (Remote Procedure Call) эффективнее REST благодаря возможности делать batch-запросы — то есть вызов сразу нескольких процедур за один раз. В то же время за счёт того, что для каждого запроса нужно устанавливать соединение, REST-запросы медленнее.

Основные преимущества gRPC

1. Генерирует API на основе спецификаций.
2. Является более производительным, чем REST.
3. Реализован компанией Google.
4. Open Source.

Преимущества gRPC в Cloudflare

Проксируя свои gRPC API в Cloudflare, вы сразу получаете все плюсы, которые предоставляет сервис:

1. Возможность добавить такие элементы безопасности, как WAF и Bot Management.
2. Наличие Argo Smart Routing для увеличения производительности.
3. Можно использовать Load Balancer для повышения надёжности: настройте несколько gRPC-бэкэндов для обработки нагрузки и разрешите Cloudflare распределять нагрузку между ними.
4. Удобно для тех, кто уже пользуется Cloudflare.

Чтобы начать использовать перечисленные преимущества в связке с надёжностью и безопасностью Cloudflare, достаточно подписаться на бета-версию в панели управления. Представители сервиса призывают оставлять отзывы о тестируемой поддержке gRPC.

Ребятам из Cloudflare тоже однажды понадобились случайные числа. Решили они эту задачу интересно: написали алгоритм, который генерирует случайные числа на основе фотографии стены с лава-лампами.

Подробно о процессе разработки можно почитать здесь.

Штатную поддержку протокола в ветке 1.17 обещают обеспечить через 6−12 месяцев. Для сборки на основе версии nginx 1.16 нужен патч (есть на GitHub) и код библиотеки quiche — после этого nginx нужно пересобрать с опциями -- with-http_v3_module, --with-quiche=../quiche. Поддержка TLS должна стоять на BoringSSL, OpenSSL пока не работает.

Про сам HTTP/3 можно почитать у нас на сайте.

Google Chrome, Mozilla Firefox и Cloudflare начинают поддерживать HTTP/3. Это новая итерация протокола HTTP, с ним передача данных станет быстрее, надёжнее и безопаснее. Почему этот протокол такой крутой и зачем он нужен, рассказывает Cloudflare.

Чтобы передача данных проходила с использованием HTTP/3, протокол должны поддерживать и сайт, и браузер. В Canary-сборке Chrome поддержку уже реализовали, скоро её добавят в Firefox Nightly. Владельцам сайтов на Cloudflare достаточно ткнуть одну кнопку в панели управления, остальным придётся подключать поддержку самостоятельно.

Чтобы включить поддержку HTTP/3 в Chrome Canary, надо дать команду --enable-quic --quic-version=h3-23. Как это сделать, описано на сайте проекта Chromium.

Как отмечает The Seattle Times, Epik случалось и раньше предоставлять свои сервисы клиентам, от которых отказывались другие компании. К примеру, два года назад Cloudflare отказала в хостинге форуму неонацистов Daily Stormer. Сейчас тот хостится у Epik.

С 8chan это не сработало. Поначалу Epik склонялась к сотрудничеству, даже успела в понедельник перенести портал на свои серверы. Однако «после долгих размышлений» компания решила тоже уйти в сторону.

Но и это ещё не всё. Сегодня днём Комитета Министерства внутренней безопасности США сообщила, что вызвала владельца 8chan Джима Уоткинса на допрос на тему борьбы с экстремистским контентом. Об этом представители Комитета сообщили в твиттере.

Cloudflare недавно отказалась предоставлять услуги порталу 8chan (начало истории тут). Цензура это или нет, но компания Epik ему тоже отказала.

The Seattle Times говорит, что Epik случалось и раньше предоставлять свои сервисы клиентам, от которых отказывались другие провайдеры. Два года назад она приютила неонацистский форум Daily Stormer, изгнанный с серверов той же Cloudflare.

Поначалу Epik склонялась к сотрудничеству, даже успела в понедельник перенести портал на свои серверы. Однако «после долгих размышлений» решила самоустраниться.

Это ещё не всё. Комитет Министерства внутренней безопасности США вызвал владельца 8chan Джима Уоткинса на допрос. Ему предлагается предстать перед чиновниками и объясниться за экстремистский контент на своём сайте.

***

«Русская служба BBC News» заявила, что проблемы с мобильным интернетом на московских митингах всё-таки устроили власти. По информации издания, один из больших операторов якобы разослал сотрудникам call-центров письмо:

Коллеги, на территории Москвы в Пресненском, Басманном районах и центре Москвы часть БС [базовых станций] отключена по требованию силовых ведомств.

При этом признавать наличие аварий или сбоев со стороны компании руководство неназванного оператора запретило.

Никто из «большой тройки» официально информацию не подтвердил.

Искусственный интеллект

В Государственном университете управления в октябре поставят стойки с камерами для распознавания эмоционального состояния студентов. Специалисты будут следить, как настроение студентов меняется в зависимости от их расписания, дня недели, времени суток. Эти данные помогут составлять «индивидуальные треки обучения».

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

Разработчики хотят в будущем увеличить количество распознаваемых эмоций и маркеров эмоционального состояния и выйти с продуктом на рынок.

Уязвимости

Spectre: нашлась новая уязвимость в механизме спекулятивного выполнения процессоров Intel (и в некоторых случаях — AMD). Её назвали SWAPGS. Она так же основана на восстановлении данных из кэша процессора после спекулятивного выполнения инструкций. Предыдущие патчи от неё не защищают, но для Linux, ChromeOS, Android и Windows уже есть исправления.

Steam: на «Хабре» вышла статья о том, как один специалист попытался доложить Valve об уязвимости повышения привилегий в Windows-клиенте Steam. Специалисту дали от ворот поворот, сказав, что эта проблема не входит в область исследований, но при этом запретив публиковать по ней отчёт.

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

Ещё Twitter повинилась, что показывала рекламу на основе выводов о том, каким устройством пользуется человек. Разрешения на это соцсеть тоже не получала.

Проблемы уже исправлены. Никакие личные данные в чужие руки не попали, пароли менять тоже не надо. И то хлеб.

Перед терактом стрелок выложил свой манифест на 8chan. Так же поступил и стрелок в новозеландском городе Крайстчёрч (рассказывали об этом в обзоре новостей за 15 марта).

Cloudflare назвала 8chan «выгребной ямой ненависти», обвинила администраторов в том, что они не способны создать адекватную атмосферу на портале. По словам компании, «8chan теперь не наша проблема, но он остаётся проблемой всего Интернета».

При этом Cloudflare не уверена, что её отказ от сотрудничества с 8chan приведёт к закрытию портала. Вакантное место могут занять конкурирующие сервисы.

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

Cloudflare сегодня опубликовала заявление об отказе сотрудничать с порталом 8chan. Всё из-за вчерашней стрельбы в техасском городе Эль Пасо, в результате которой погибло 20 человек. О происшествии можно почитать на «Медузе».

Перед терактом стрелок выложил свой манифест на 8chan. Так же поступил стрелок в новозеландском городе Крайстчёрч (рассказывали об этом в обзоре новостей за 15 марта).

Cloudflare назвала 8chan «выгребной ямой ненависти», обвинила администраторов в том, что они не способны создать адекватную атмосферу на портале. «8chan теперь не наша проблема, но он остаётся проблемой всего Интернета».

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

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

(не)Зелёный Гоблин?

Французский изобретатель за 22 минуты перелетел на своём реактивном ховерборде Ла-Манш — это 35 километров. Средняя скорость полёта была 160−170 километров в час, но устройство умеет разгоняться до 195 километров в час. (Если без человека, то до 400. Человек с возу, ховерборду легче.)

Парой строк о прочем

Шатдаун: международная организация NetBlocks заметила, что во время субботних протестов в Москве отключали сети Wi-Fi и мобильный интернет. Мобильные операторы говорят, что во всём виноваты перегрузки. Что в некоторых частях города собиралось слишком много людей, и это провоцировало сбои. Чётких доказательств того, что шатдаун организовали власти, нет.

Утечка: в апреле из-за уязвимости в системах «Бинбанка» утекли данные клиентов — ФИО, паспортные данные, телефон, адрес. Уязвимость закрыли, но данные пошли гулять по Интернету. Сейчас базу из 70 тысяч строк продают в даркнете по 5 рублей за строку. Источники «Коммерсанта» говорят, что полиция приняла больше сотни заявлений о краже средств у московских клиентов банка.

Неправильные настройки: из-за неправильных настроек в Jira в публичном доступе оказалась информация о сотрудниках и внутренних проектах крупных компаний: Google, Yahoo, NASA, Lenovo, 1Password, Zendesk. Ошибка кроется в фильтре видимости. По умолчанию ставится «видят все», но это значит не «все сотрудники», а «все в Интернете».

Невидимая клавиатура: корейские разработчики создали алгоритм, который позволяет набирать текст на тачскрине с воображаемой клавиатурой. Руки можно располагать в любой части тачскрина, главное, чтобы набор шёл по QWERTY-раскладке. ML-алгоритм предугадывает, какой текст вводит пользователь.

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

В результате пользователи сервисов видели ошибку 502 — «Bad Gateway».

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

После этого разработчики перепроверили правила, исправили ошибку, протестировали и снова развернули, уже успешно. Это произошло через сорок минут после отката.

Второй раз за две недели Cloudflare утянул за собой на дно половину Интернета (включая Tproger). На короткое время отказал даже Downdetector, куда все бросаются посмотреть: «Это у всех или я один такой?».

Неполадки начались примерно в 17 часов по Москве. На момент подготовки обзора всё уже починили. Cloudflare описала ситуацию так:

По всему миру во всех сервисах Cloudflare произошёл крупный сбой. Мы засекли всплеск нагрузки на ЦП — он привел к отказу первичных и вторичных систем. Мы завершили процесс, который спровоцировал этот всплеск <…> Мы продолжаем расследовать причины произошедшего.

Вот так, одна компания, а какое влияние.

Медиа: аватары

Есть такой мессенджер — Chudo. В нём пользователи могут на основании своей фотографии сделать мультяшного аватара. 2D или 3D, на выбор. Автор издания Bored Panda попробовал сделать аватары знаменитостей, и получилось вполне узнаваемо. Вот так выглядит Уилл Смит:

Парой строк о прочем

«Яндекс» говорит, что готова подумать о размещении конкурентов в колдунщиках, если это будет стандартом для отрасли. Это продолжение вчерашней истории.

Microsoft отказывается от крупных фич в осеннем обновлении Windows 10, чтобы сосредоточиться на улучшении производительности.

Google подготовила документы, чтобы веб-стандарту REP (Robots Exclusion Protocol) присвоили статус официального. Это протокол исключений для поисковых роботов, и работает он уже 25 лет.

GitHub ввела обязательную верификацию при входе с новых устройств. Это касается тех, кто не включил в профиле 2FA. Код для верификации будет приходить на email-адрес.

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

Как это произошло?

Пенсильванский интернет-провайдер DQE Communications использовал BGP Optimizer — инструмент, который разбивает блоки IP-адресов на мелкие части и таким образом конкретизирует маршрутизацию внутри сети. Если проводить аналогию с географией, вместо области или штата он указывает на конкретный город в области или штате. Более «конкретные» маршруты всегда приоритетнее «общих».

DQE начал передавать эти маршруты своему клиенту, Allegheny Technologies. У того, оказалось, также было настроено подключение к транзитному провайдеру Verizon. «Приоритетные» маршруты перетекли к нему, а он стал транслировать их на весь интернет.

В результате большое количество трафика пошло через Verizon к DQE, и они просто не справились с такой нагрузкой на свои сети.

Когда начались сбои, специалисты из Cloudflare попытались связаться с Verizon или DQE. В США было раннее утро, так что связаться получилось не сразу. Verizon так и не ответил, зато эксперты из DQE после небольшой задержки помогли перекрыть утечку.

Чем полезен Cloudflare Workers для создания приложений?

Разработчики приложений использовали Cloudflare Apps для интеграции средств JavaScript, HTML, CSS и модификации таких настроек Cloudflare, как DNS, на веб-сайтах. С началом бета-тестирования они получили возможность экспериментировать с персонализацией, A/B-тестированием, безопасностью, проверкой содержимого и локализацией.

Чтобы добавить код в приложение, достаточно разместить ссылку на скрипт в файле install.json:

Также доступно введение переменных со ссылкой в скрипте Workers. Они могут содержать необходимые для установки приложения токены.

Cloudflare представила стабильную версию Workers для облачного администрирования веб-приложений на JavaScript в середине марта 2018 года. Сервис позволяет разворачивать JS-скрипты по облачной сети компании в пределах 30 секунд. В конце сентября 2018 года Cloudflare запустила хранилище «ключ-значение» Workers KV. Специалисты Cloudflare утверждают, что Workers обеспечивает считывание данных с низкой задержкой и позволяет создавать приложения, сопоставимые по производительности с сетями доставки содержимого (CDN).

Защита API

Cloudflare Access проверяет токен (JSON Web Token) при выполнении запроса через браузер или командную строку. Инструмент подписывает токен в момент успешной авторизации поставщика идентификатора. Токен содержит идентификационные данные и данные о сессии. Проверяя его, сеть Cloudflare разрешает или ограничивает доступ к приложению.

Авторизация

Вход через браузер перенаправляет пользователя к поставщику идентификатора, а данные токена хранятся в cookie-файлах. В то же время инструмент Cloudflare CLI помогает авторизоваться с помощью командной строки. cloudflared открывает окно браузера для авторизации через поставщик идентификатора, после чего Access создаёт токен. Второй вариант доступен в бета-режиме, а правила использования описаны на странице.

Вместо его размещения в cookie-файлах, он передаётся на устройство, поэтому повторная авторизация не требуется. Время действия токена пользователь задаёт в настройках Cloudflare Access. Во время запроса Access ищет HTTP-заголовок cf-jwt-access-assertion вместо cookie-файлов. При использовании c URL cloudflared использует подкоманду для вставки токена в заголовок.

Использование cloudflared обусловлено двумя причинами:

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

Работа с Cloudflare Access

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

В конце сентября 2018 года Cloudflare добавила в свою сеть доставки контента поддержку TLS-расширения ESNI. Оно передает имя хоста при HTTPS-соединении пользователя в зашифрованном виде и таким образом затрудняет отслеживание трафика.

Как это работает?

Злоумышленники используют шлюз IPFS для отображения сохранённого в файловой системе IPFS документа HTML.

Страница подписывается действительным сертификатом безопасности Cloudflare SSL, что убеждает пользователя в подлинности заполняемой формы.

Когда пользователь заполнит и отправит форму авторизации, введенные мобильный номер и адрес электронной почты будут отправлены на страницу в домене searchurl.bid, контролируемую мошенниками. Затем жертве показывают документ PDF с названием «Бизнес-модели, бизнес-стратегия и инновации».

Стандартная схема?

В списке URL-адресов, которые попали в базу VirusTotal и принадлежат домену searchurl.bid, находится большое количество фишинговых страниц. Самые ранние датируются июлем 2018 года. Многие них уже заблокированы, но некоторые всё ещё отображают формы авторизации Google, Windows, DocuSign и т.д. Хотя адреса этих сайтов мало похожи на настоящие, пользователь может не заметить этого и отправить свои данные злоумышленникам.

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

Возможности брандмауэра

После общения с клиентами, специалисты Cloudflare выделили несколько моментов, которые и постарались учесть в разработке брандмауэр. По их мнению, Firewall Rules должен предоставлять возможность выбора нескольких правил с частичным соответствием заданных для них параметров, например: User-Agent: *Firefox*.

При этом клиент сможет постоянно контролировать службы при помощи пользовательского интерфейса или Cloudflare API.

Составляющие Firewall Rules

Конфигурацию правил можно задать как при помощи API, так и с помощью инструмента Terraform. Модуль брандмауэра состоит из двух компонентов.

• Распознавание: определение правила. Правила предоставляют пользователям доступ к свойствам HTTP-запроса. Заголовки запроса сравниваются по нескольким операторам, в числе которых частичное (contains) и полное (equals) совпадение, а также функция сопоставления по образцу (matches). Последняя позволяет использовать регулярные выражения и доступна для частных предприятий и организаций.
• Действие: выбор действий для выполнения запроса. Доступны 3 действия: JS-проверка, проверка и блокировка. Помимо этого, к стандартным решениям добавили allow, создающее условие с запретом выполнения дальнейших правил при соответствии определённого параметра.

Положительная и негативная модели безопасности

Первая модель предполагает разрешает специальные запросы и отклоняет остальные, вторая — напротив, запрещает специальные и разрешает любые другие. По умолчанию Firewall Rules разрешает любой запрос. Противоположная этой политика «Zero Trust» блокирует любой запрос.

Инструменты Visual Rule Builder and Expression Editor

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

Более сложные требования можно написать с помощью инструмента Rule Editor. Пользователь пишет выражения на языке программы Wireshark и на их основе задаёт правила брандмауэра.

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

Возможности

Помимо размещения кода на сервере и устройстве пользователя, служба Cloudflare Workers позволяет разместить код в хранилище. Таким образом, часть кода можно оставить в хранилище, вторую часть — на сервере и оставшуюся часть — на устройстве пользователя.

Также Cloudflare Workers KV предоставляет FaaS-нативное хранилище в виде «ключ-значение». Данные можно переписать или считать при помощи Cloudflare API или при помощи службы Cloudflare Worker.

Помимо этого, Cloudflare Workers KV можно использовать для:

• Хранения данных корзины покупателя интернет-магазина. Cloudflare API позволяет сохранять или отменять операции в корзине. Данные не нагружают движок сайта или локальное хранилище браузера.
• A/B-тестирования. Информация об уникальных профилях для A/B-тестирования каждого пользователя хранится в Workers KV.
• Аутентификации и верификации. После входа пользователя на сайт, информация о логине, включая токен, переносится в хранилище. Разработчики Cloudflare утверждают, что отсутствие проверки токенов сервером позволяет быстрее отклонять и принимать запросы при аутентификации.

• Создания страниц. Workers KV хранит данные шаблона или кэша страницы, а также своевременно обновляет их при помощи бэкенд-приложений.

Ограничения и цены

На конец сентября 2018 года хранилище запущено в бета-версии. Cloudflare обещает увеличить объёмы хранилища и предоставить доступ большему количеству пользователей. Стоимость составляет 5 $ в месяц за 1 ГБ места в хранилище и до 10 млн считываний из него, при доступности:

• до 1 млн ключей для одного пространства имён;
• ключей размером до 2 Кбайт;
• значений размером до 64 Кбайт;
• согласования данных в течение 10 с;
• более 100 тысяч считываний одного ключа в секунду;
• до одной записи ключа в секунду.

В конце сентября 2018 года Cloudflare объявила о запуске регистрации доменных имён в Registrar без наценки. В предложение включены двухфакторная аутентификация, предоставление бесплатного SSL-сертификата и набор расширений DNSSEC.

Собственный регистратор доменных имён и безопасность

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

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

Ценовая политика

Специалисты из Cloudflare уверены, что SSL-сертификат клиент должен получать бесплатно. Кроме того цены на домены они изменят только при их росте для всего рынка без каких-либо наценок.

Компания бесплатно предоставляет редактирование данных для протокола WHOIS. VeriSign, к примеру, поддерживает 2 из 13 корневых DNS-серверов и устанавливает свою цену, которую Cloudflare оставляет прежней:

Перенос или регистрация домена

Cloudflare рассылает приглашения пользователям и компаниям, которые оставили заявку на регистрацию. Чем больше срок пользования услугами компании, тем быстрее придёт приглашение. Другой вариант попадания в число первых — пожертвование движению Girls Who Code.

Перенос с одного домена на другой пользователь осуществляет в три этапа:

1. Сообщает новому регистратору о желании перенести домен. Необходимо ввести имя домена в новом регистраторе, который проверит возможность переноса. Действие невозможно, если операция уже производилась в течение последних 60 дней.
2. Выполняет разблокировку домена. Код состояния домена необходимо перевести в «разблокирован». Блокировка ставится для предотвращения несанкционированных, нежелательных или случайных изменений имени домена.
3. Получает код авторизации. Пользователь получает код от старого регистратора и предоставляет новому. Перенос домена продлевает срок его существования.

В середине сентября 2018 года руководство некоммерческой Интернет-корпорации, которая управляет доменными именами и IP-адресами (ICANN) определило дату смены криптографического ключа. Он призван защитить корневую систему доменных имён. В организации полагают, что это может привести к локальным сбоям.