27 июля 2026 года команда Cloudflare Research выложила в открытый доступ pvcli — консольный клиент для приватных сетевых протоколов. Внешне это «curl для OHTTP»: тот же стиль команд, но вместо обычного запроса инструмент собирает трёхсторонний зашифрованный обмен, в котором сервер-получатель не видит вашего IP, а промежуточный узел не видит содержимого запроса. Код лежит под Apache 2.0, в планах — поддержка MASQUE и Privacy Pass.
Для индустрии прокси это не «ещё один релиз на GitHub». Это первый удобный способ пощупать руками стек протоколов, который уже несколько лет тихо внедряют Apple, Google, Mozilla и Meta — и который регулярно преподносят как «замену прокси». Разберём, что там на самом деле, и честно ответим на главный вопрос: закрывает ли этот стек задачи, ради которых люди покупают резидентные и мобильные прокси. Спойлер: нет, и причина — архитектурная, а не «пока не доросли».
Что именно открыли: pvcli в деталях
pvcli написан на Rust и ставится одной командой через cargo install --git. По README это HTTP/2- и HTTP/3-клиент с поддержкой GET и POST, TLS 1.3 и шифрования HPKE (RFC 9180). Основной режим — Oblivious HTTP: клиент указывает первый хоп (relay) и гейтвей, а инструмент сам выполняет всю криптографию и упаковку в binary HTTP.
- Обычный запрос:
pvcli https://example.com/cdn-cgi/trace, с флагом--http3— поверх QUIC. - Режим OHTTP:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Классическое проксирование:
pvcli -x https://proxy.example.com https://target.example.com— то есть HTTP CONNECT никуда не делся.
Авторы честно предупреждают: софт экспериментальный и не проходил аудит, постквантовый HPKE пока не поддерживается, часть спецификаций ещё даже не стали RFC. Это инструмент отладки, а не готовый продукт для продакшена. И именно поэтому он интересен: раньше проверить чужую OHTTP-интеграцию можно было только собственным кодом на Swift или Rust.
Oblivious HTTP: разделяй и не властвуй
OHTTP стандартизован как RFC 9458 ещё 12 января 2024 года. Идея простая до элегантности: разнести знание о том, «кто вы» и «что вы просите», между двумя независимыми участниками.
- Клиент шифрует запрос эфемерным ключом на публичном ключе гейтвея — на каждый запрос генерируется новая пара ключей.
- Relay (облиный релей) видит ваш IP-адрес, но получает шифротекст: он физически не может прочитать, куда и о чём вы спрашиваете.
- Gateway расшифровывает запрос и передаёт его на origin, но видит IP релея, а не ваш.
Ключевая гарантия — unlinkability: origin не может связать два ваших запроса между собой. Ключевое ограничение — доверие: если релей и гейтвей сговорятся или окажутся у одного оператора, вся приватность схлопывается. NCC Group в аудитах отмечала и практические сложности — ротация ключей, rate limiting и допуски по сетевым задержкам.
В продакшене протокол уже работает, и список внушительный:
- Apple — Private Cloud Compute для запросов Apple Intelligence и Enhanced Visual Search в «Фото»; поддержка OHTTP в Swift появилась в августе 2024-го.
- Google — Privacy Sandbox, k-анонимность и проверка URL в Safe Browsing без раскрытия IP; в роли релея выступает Fastly.
- Mozilla — сбор метрик производительности Firefox без идентификации пользователя.
- Meta — Private Processing для Meta AI в WhatsApp (2025), тоже через релей Fastly.
- Flo — «анонимный режим» трекера цикла на базе Cloudflare Privacy Gateway ещё с 2022 года.
Гейтвеи, помимо Cloudflare и Fastly, поднимает Internet Security Research Group в сервисе Divvi Up. То есть инфраструктура реальная, а не бумажная.
MASQUE: вот это уже похоже на прокси
Вторая часть стека, которую Cloudflare обещает добавить в pvcli, — MASQUE. Это семейство протоколов рабочей группы IETF, которое переносит проксирование внутрь HTTP:
- RFC 9298 (август 2022), CONNECT-UDP — проксирование UDP внутри HTTP; клиент шлёт расширенный CONNECT с
:protocol: connect-udp, а прокси перекладывает QUIC DATAGRAM-фреймы в UDP-пакеты. - RFC 9484 (октябрь 2023), CONNECT-IP — уже полноценный IP-уровень: сырые IP-пакеты заворачиваются в HTTP Datagrams, и HTTP/3-сервер превращается в VPN-шлюз, умеющий одновременно TCP, UDP и ICMP.
Обе спецификации требуют фолбэка на HTTP/2 там, где QUIC и UDP зарезаны на сетевом уровне, — что регулярно и происходит в корпоративных и провайдерских сетях. По сути MASQUE — это то, на чём построены современные «приватные релеи» уровня операционной системы, где трафик проходит два независимых хопа: первый знает вас, но не знает адресата, второй наоборот.
Privacy Pass: анонимный пропуск вместо капчи
Третий кирпич — Privacy Pass, стандартизованный тремя документами: RFC 9576 (архитектура), RFC 9577 (HTTP-схема аутентификации) и RFC 9578 (протоколы выпуска токенов, приватно и публично верифицируемых). Логика в двух шагах: issuance — вы один раз доказываете, что вы человек или доверенный клиент, и получаете пачку слепо подписанных токенов; redemption — предъявляете токен сайту, и он пропускает вас без капчи, не имея возможности связать токен с моментом выдачи.
Это ровно тот механизм, который стоит за идеей «дать хорошим ботам законный вход» — она же лежит в основе подписанных агентов и Web Bot Auth. Тренд один и тот же: разделить сетевую идентичность (IP) и права доступа (токен, подпись).
Заменит ли это прокси? Разбор без иллюзий
Каждый раз, когда выходит новость из этого стека, всплывает тезис «зачем теперь прокси, если есть OHTTP». Проблема в том, что приватные протоколы и прокси решают разные задачи, и подмена одного другим ломается на четырёх пунктах.
1. OHTTP работает только там, где сайт сам его развернул
Это не оверлей поверх интернета, а opt-in со стороны получателя: гейтвей поднимает и настраивает сам origin (или его подрядчик). Нельзя «зайти через OHTTP» на произвольный маркетплейс или соцсеть — там просто нет гейтвея. Все перечисленные внедрения — это компании, прячущие IP собственных пользователей от собственных бэкендов. Для сбора данных со стороннего сайта механизм не применим в принципе.
2. Точка выхода — дата-центр, и все об этом знают
Даже если гейтвей есть, наружу запрос выходит с адреса Cloudflare, Fastly или ISRG. Это известные ASN хостинг-провайдеров с публичными диапазонами. Антибот-системы ранжируют IP по типу сети, и адрес облачного релея получает ровно тот же скоринг, что любой другой дата-центровый адрес. Приватность от origin вы получили, а «выглядеть как обычный домашний пользователь» — нет. Именно за это отвечают резидентные прокси с реальными адресами провайдеров и мобильные пулы операторских CGNAT-сетей.
3. Нет географии, ротации и липких сессий
Прокси-инфраструктура даёт то, чего у приватных протоколов нет по дизайну: выбор страны, региона и оператора, управляемая ротация IP, sticky-сессии на нужное количество минут, разные пулы под разные аккаунты. OHTTP не даёт вам выбрать «выйти из Германии, из сети конкретного ISP» — там вообще нет понятия точки выхода в вашем распоряжении. Для проверки локальной выдачи, цен по регионам или работы с гео-ограниченным контентом это неустранимая разница.
4. Модель доверия другая
OHTTP защищает от связывания запросов конкретным origin при условии, что релей и гейтвей независимы. Прокси защищает от того, что сайт увидит ваш настоящий адрес и сетевой профиль. Первое — про приватность телеметрии и запросов пользователя, второе — про доступ и распределение нагрузки. Задачи пересекаются лишь частично, и «переезд» с одного на другое невозможен.
Что из этого реально пригодится на практике
- Если вы разработчик продукта, который шлёт телеметрию или запросы к своему API — OHTTP через Privacy Gateway или Divvi Up реально снижает объём собираемых персональных данных и упрощает разговор с юристами. pvcli теперь позволяет отладить это без написания клиента с нуля.
- Если вы собираете публичные данные — стек ничего не меняет: точка выхода и её репутация остаются вашей задачей. Для массового парсинга по-прежнему рабочая связка — датацентр-прокси с ротацией на лояльных площадках и резидентные там, где включён серьёзный антибот.
- Если вы работаете с несколькими аккаунтами — приватные протоколы не решают вопрос изоляции: сессии на площадках связываются не только по IP, но и по отпечатку браузера и поведению. Разница между IP-слоем и слоем идентичности разобрана в материале про различия прокси и VPN.
- Если вы автоматизируете доступ «в белую» — вот здесь стоит следить внимательно. Privacy Pass и подписанные агенты идут к модели, где боту дают вход по предъявленному токену, а не по «похожести на человека». Это самая перспективная часть новости.
Вывод
Открытие pvcli — хороший индикатор зрелости: приватные протоколы вышли из стадии research-препринтов и обзавелись инструментами отладки. OHTTP, MASQUE и Privacy Pass действительно перекраивают то, как интернет обращается с адресом клиента, и через пару лет «сайт видит ваш IP» перестанет быть аксиомой для пользовательского трафика.
Но для тех, кто собирает данные, управляет множеством аккаунтов или проверяет выдачу по регионам, ничего не отменяется. Приватные протоколы прячут вас от того, к кому вы пришли по приглашению. Прокси нужны там, куда приглашения не выдают, — и там по-прежнему всё решают тип сети, репутация адреса и качество пула. Разумно следить за Privacy Pass как за будущим легальным каналом для ботов и параллельно держать нормальную прокси-инфраструктуру для настоящего.