Материал подготовлен по официальной статье Cloudflare от 2 октября 2026 года. Ниже — русская адаптация с пояснением архитектуры и практических ограничений.

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

Cloudflare запускает OHTTP Gateway — управляемый gateway для протокола Oblivious HTTP. Идея OHTTP в том, чтобы разделить личность пользователя и содержимое запроса между разными участниками инфраструктуры.

В результате приложение может обработать запрос, не получая исходный IP пользователя.

Что такое Oblivious HTTP

Oblivious HTTP, или OHTTP, — стандарт IETF для передачи HTTP-запросов через архитектуру с разделением доверия.

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

• relay видит сетевые идентификаторы клиента, включая IP, но не может прочитать содержимое запроса;
• gateway расшифровывает запрос и передаёт его приложению, но не знает исходный IP клиента.

Критический принцип здесь в том, что relay и gateway должны управляться независимыми сторонами. Тогда ни один участник не видит одновременно и личность клиента, и содержимое его запроса. citeturn878141view0

Cloudflare уже работала с OHTTP Relay

Ранее Cloudflare предлагала продукт Privacy Gateway, который теперь переименован в Cloudflare OHTTP Relay.

Relay скрывает клиентские идентификаторы от приложения, но для полноценной архитектуры требуется отдельный gateway.

Cloudflare приводит реальные примеры использования OHTTP. Flo Health применяет эту технологию в Anonymous Mode, а Apple использует OHTTP в Private Cloud Compute, чтобы отделять AI-запросы от идентичности пользователя. citeturn878141view0

Зачем понадобился отдельный OHTTP Gateway

Проблема возникала у приложений, серверы которых уже работают за Cloudflare.

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

Поэтому новая схема предлагает обратный вариант: использовать Cloudflare OHTTP Gateway, а relay держать у независимого провайдера.

Такой вариант подходит, если backend уже находится за Cloudflare CDN или Workers либо приложение должно принимать OHTTP-запросы от стороннего relay.

Gateway работает на глобальной edge-сети Cloudflare

Cloudflare размещает Gateway на своей глобальной сети.

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

Если приложение также работает на инфраструктуре Cloudflare, расшифрованный запрос может быть обработан без лишнего дальнего перехода между gateway и origin. citeturn878141view0

Подключение через .well-known/ohttp-gateway

Cloudflare проектирует Gateway как функцию конкретной zone.

После включения OHTTP-клиенты отправляют запросы на endpoint:

https://example.com/.well-known/ohttp-gateway

Gateway перехватывает корректный OHTTP-запрос, расшифровывает его, делает внутренний subrequest к приложению и возвращает зашифрованный ответ.

Обычные HTTP-запросы при этом продолжают идти в приложение без участия OHTTP Gateway.

Поддерживается обычный и chunked OHTTP

Cloudflare заявляет поддержку стандартного OHTTP и chunked OHTTP.

Для производительности компания рекомендует chunked-вариант, где запрос можно обрабатывать постепенно, а не ждать получения всего зашифрованного сообщения целиком. citeturn878141view0

Ключами управляет Cloudflare

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

Вместо самостоятельного управления ключами Cloudflare берёт эту часть на себя.

Публичные ключи можно получить через тот же /.well-known/ohttp-gateway. При этом Cloudflare рекомендует для усиления приватности получать ключи и отправлять сами запросы с разных IP, если архитектура клиента это позволяет.

Relay можно аутентифицировать до расшифровки запроса

Поскольку gateway почти ничего не знает о конечном клиенте, возникает другой вопрос: как убедиться, что трафик пришёл от доверенного relay.

Cloudflare помещает Access перед этапом расшифровки OHTTP.

Это позволяет применять стандартные политики Cloudflare Access, включая:

• mutual TLS;
• service credentials;
• внешнюю пользовательскую логику проверки.

Проверка выполняется до того, как внутренний запрос будет расшифрован. citeturn878141view0

Cloudflare специально блокирует опасную конфигурацию

Одна из интересных деталей — защита от случайного нарушения самой модели OHTTP.

Если разработчик попробует отправить запрос в Cloudflare OHTTP Gateway через Cloudflare Workers или другой proxied host Cloudflare, Gateway откажется его расшифровывать.

Причина проста: Cloudflare не должна одновременно видеть клиентские идентификаторы на relay-стороне и расшифрованный внутренний запрос на gateway-стороне.

То есть часть privacy-модели enforced самой инфраструктурой.

OHTTP не скрывает данные, которые приложение отправило само

Это важное ограничение.

OHTTP защищает приватность на сетевом уровне, но не переписывает тело внутреннего HTTP-запроса.

Если приложение само положило внутрь JSON email, username, номер телефона или другой идентификатор, gateway не сможет сделать эти данные анонимными.

Cloudflare отдельно предупреждает об этом: разработчик сам отвечает за то, чтобы не передавать идентифицирующие данные внутри payload, если цель системы — действительно анонимный запрос. citeturn878141view0

Чем OHTTP отличается от обычного proxy

Обычный reverse proxy тоже может скрыть реальный IP клиента от origin, но оператор proxy при этом обычно имеет техническую возможность видеть и клиента, и содержимое запроса.

В OHTTP payload дополнительно шифруется между клиентом и gateway с помощью HPKE.

Relay видит, откуда пришёл трафик, но получает зашифрованное содержимое. Gateway получает содержимое, но видит в качестве источника relay.

Эта модель и создаёт так называемую double-blind архитектуру.

Когда Cloudflare OHTTP Gateway подходит лучше Relay

Новый Gateway логичнее выбирать, если:

• сервер приложения уже работает за Cloudflare CDN;
• backend построен на Workers;
• приложение принимает OHTTP-трафик от стороннего клиента и relay;
• разработчик не хочет самостоятельно поддерживать gateway-инфраструктуру;
• важно уменьшить задержку между gateway и приложением.

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

Что нужно для запуска

Cloudflare OHTTP Gateway пока запускается в закрытой beta, а полноценный запуск компания планирует этой осенью как платное дополнение к Cloudflare zone. Для доступа используется waitlist. citeturn878141view0

Со стороны разработчика всё равно понадобится OHTTP-клиент и независимый relay.

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

Почему это интересно не только privacy-приложениям

OHTTP полезен там, где backend должен выполнить действие, но ему необязательно знать сетевую личность пользователя.

Это может быть:

• анонимный доступ к чувствительным данным;
• часть privacy-preserving AI-инфраструктуры;
• сервисы проверки или lookup, где IP не нужен бизнес-логике;
• приложения с повышенными требованиями к разделению данных;
• системы, где разработчик хочет сознательно уменьшить объём собираемой пользовательской телеметрии.

Практический вывод

Cloudflare OHTTP Gateway — не «анонимайзер в один клик», а инфраструктурный компонент для приложений, которые хотят технически разделить сетевую идентичность пользователя и содержимое запроса.

Сильная сторона OHTTP не в том, что он прячет IP через ещё один proxy, а в разделении доверия: relay и gateway получают разные части информации, а payload защищён криптографически.

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

Из других свежих обновлений Cloudflare можно посмотреть материалы про Web Search API в AI Gateway, decision-модели Clef и Cloudflare AI Search.

Официальный источник

Cloudflare Blog — Announcing Cloudflare OHTTP Gateway