Pada 27 Juli 2026, tim Cloudflare Research merilis pvcli — klien konsol untuk protokol jaringan privat. Secara eksternal, ini adalah "curl untuk OHTTP": gaya perintah yang sama, tetapi alih-alih permintaan biasa, alat ini mengumpulkan pertukaran terenkripsi tiga arah, di mana server penerima tidak melihat IP Anda, dan node perantara tidak melihat isi permintaan. Kode ini berada di bawah lisensi Apache 2.0, dengan rencana untuk mendukung MASQUE dan Privacy Pass.
Bagi industri proxy, ini bukan "rilis lain di GitHub". Ini adalah cara pertama yang nyaman untuk merasakan tumpukan protokol yang telah diimplementasikan secara diam-diam oleh Apple, Google, Mozilla, dan Meta selama beberapa tahun — dan yang secara teratur dipresentasikan sebagai "pengganti proxy". Mari kita bahas apa yang sebenarnya ada di sana, dan secara jujur menjawab pertanyaan utama: apakah tumpukan ini menyelesaikan tugas yang membuat orang membeli proxy residensial dan mobile. Spoiler: tidak, dan alasannya adalah arsitektural, bukan "belum siap".
Apa yang dibuka: pvcli dalam detail
pvcli ditulis dalam Rust dan diinstal dengan satu perintah melalui cargo install --git. Menurut README, ini adalah klien HTTP/2 dan HTTP/3 dengan dukungan untuk GET dan POST, TLS 1.3, dan enkripsi HPKE (RFC 9180). Mode utama — Oblivious HTTP: klien menunjukkan hop pertama (relay) dan gateway, dan alat ini melakukan semua kriptografi dan pengemasan dalam binary HTTP.
- Pemintaan biasa:
pvcli https://example.com/cdn-cgi/trace, dengan flag--http3— di atas QUIC. - Mode OHTTP:
pvcli --ohttp --first-hop https://relay --proxy https://gateway -X POST https://target. - Proxy klasik:
pvcli -x https://proxy.example.com https://target.example.com— jadi HTTP CONNECT tidak hilang kemana-mana.
Para penulis dengan jujur memperingatkan: perangkat lunak ini eksperimental dan belum diaudit, HPKE pasca-kuantum belum didukung, dan beberapa spesifikasi bahkan belum menjadi RFC. Ini adalah alat debugging, bukan produk siap pakai untuk produksi. Dan itulah mengapa ini menarik: sebelumnya, untuk memeriksa integrasi OHTTP orang lain, Anda hanya bisa menggunakan kode Anda sendiri dalam Swift atau Rust.
Oblivious HTTP: pisahkan dan jangan kuasai
OHTTP distandarisasi sebagai RFC 9458 pada 12 Januari 2024. Ideanya sederhana hingga elegan: memisahkan pengetahuan tentang "siapa Anda" dan "apa yang Anda minta" antara dua peserta independen.
- Klien mengenkripsi permintaan dengan kunci efemeral pada kunci publik gateway — untuk setiap permintaan, pasangan kunci baru dihasilkan.
- Relay (relay oblivious) melihat alamat IP Anda, tetapi menerima ciphertext: ia secara fisik tidak dapat membaca ke mana dan tentang apa Anda bertanya.
- Gateway mendekripsi permintaan dan meneruskannya ke origin, tetapi melihat IP relay, bukan IP Anda.
Jaminan kunci — unlinkability: origin tidak dapat mengaitkan dua permintaan Anda satu sama lain. Pembatasan kunci — kepercayaan: jika relay dan gateway berkolusi atau berada di bawah operator yang sama, seluruh privasi runtuh. NCC Group dalam audit mencatat juga kesulitan praktis — rotasi kunci, pembatasan laju, dan toleransi terhadap keterlambatan jaringan.
Dalam produksi, protokol ini sudah berfungsi, dan daftarnya mengesankan:
- Apple — Private Cloud Compute untuk permintaan Apple Intelligence dan Enhanced Visual Search di "Foto"; dukungan OHTTP dalam Swift muncul pada Agustus 2024.
- Google — Privacy Sandbox, k-anonimitas, dan verifikasi URL dalam Safe Browsing tanpa mengungkapkan IP; Fastly berperan sebagai relay.
- Mozilla — pengumpulan metrik kinerja Firefox tanpa identifikasi pengguna.
- Meta — Private Processing untuk Meta AI di WhatsApp (2025), juga melalui relay Fastly.
- Flo — "mode anonim" pelacak siklus berbasis Cloudflare Privacy Gateway sejak 2022.
Gateway, selain Cloudflare dan Fastly, juga dioperasikan oleh Internet Security Research Group dalam layanan Divvi Up. Jadi infrastruktur ini nyata, bukan sekadar di atas kertas.
MASQUE: ini sudah mirip proxy
Bagian kedua dari tumpukan yang dijanjikan Cloudflare untuk ditambahkan ke pvcli adalah MASQUE. Ini adalah keluarga protokol dari kelompok kerja IETF yang memindahkan pemrosesan proxy ke dalam HTTP:
- RFC 9298 (Agustus 2022), CONNECT-UDP — pemrosesan proxy UDP di dalam HTTP; klien mengirimkan CONNECT yang diperluas dengan
:protocol: connect-udp, dan proxy meneruskan bingkai QUIC DATAGRAM ke dalam paket UDP. - RFC 9484 (Oktober 2023), CONNECT-IP — sudah pada tingkat IP yang sepenuhnya: paket IP mentah dibungkus dalam HTTP Datagrams, dan server HTTP/3 berubah menjadi gateway VPN yang dapat menangani TCP, UDP, dan ICMP secara bersamaan.
Kedua spesifikasi ini memerlukan fallback ke HTTP/2 di mana QUIC dan UDP diblokir di tingkat jaringan — yang sering terjadi di jaringan perusahaan dan penyedia. Pada dasarnya, MASQUE adalah apa yang membentuk "relay privat" modern di tingkat sistem operasi, di mana lalu lintas melewati dua hop independen: yang pertama mengenal Anda, tetapi tidak tahu tujuan, yang kedua sebaliknya.
Privacy Pass: tiket anonim sebagai pengganti captcha
Bagian ketiga — Privacy Pass, distandarisasi dalam tiga dokumen: RFC 9576 (arsitektur), RFC 9577 (skema otentikasi HTTP), dan RFC 9578 (protokol penerbitan token, yang dapat diverifikasi secara privat dan publik). Logika dalam dua langkah: issuance — Anda sekali membuktikan bahwa Anda adalah manusia atau klien tepercaya, dan menerima sekumpulan token yang ditandatangani secara buta; redemption — Anda menunjukkan token ke situs, dan ia membiarkan Anda masuk tanpa captcha, tanpa kemampuan untuk mengaitkan token dengan saat penerbitan.
Ini adalah mekanisme yang mendasari ide "memberikan akses yang sah kepada bot yang baik" — yang juga menjadi dasar agen yang ditandatangani dan Web Bot Auth. Tren yang sama: memisahkan identitas jaringan (IP) dan hak akses (token, tanda tangan).
Apakah ini akan menggantikan proxy? Analisis tanpa ilusi
Setiap kali berita dari tumpukan ini muncul, tesis "mengapa sekarang proxy, jika ada OHTTP" muncul. Masalahnya adalah bahwa protokol privat dan proxy menyelesaikan tugas yang berbeda, dan penggantian satu dengan yang lain terhambat oleh empat poin.
1. OHTTP hanya berfungsi di tempat di mana situs itu sendiri mengimplementasikannya
Ini bukan overlay di atas internet, tetapi opt-in dari pihak penerima: gateway mengangkat dan mengatur origin itu sendiri (atau kontraktornya). Anda tidak dapat "masuk melalui OHTTP" ke pasar atau jejaring sosial sembarangan — di sana tidak ada gateway. Semua implementasi yang disebutkan adalah perusahaan yang menyembunyikan IP pengguna mereka sendiri dari backend mereka sendiri. Untuk mengumpulkan data dari situs pihak ketiga, mekanisme ini tidak dapat diterapkan sama sekali.
2. Titik keluar — pusat data, dan semua orang tahu tentangnya
Even if there is a gateway, requests go out with the address of Cloudflare, Fastly, or ISRG. Ini adalah ASN penyedia hosting yang dikenal dengan rentang publik. Sistem anti-bot mengurutkan IP berdasarkan jenis jaringan, dan alamat relay cloud mendapatkan skor yang sama dengan alamat pusat data lainnya. Privasi dari origin telah Anda dapatkan, tetapi "terlihat seperti pengguna rumahan biasa" — tidak. Itulah sebabnya proxy residensial dengan alamat nyata penyedia dan kumpulan mobile dari jaringan CGNAT operator tetap diperlukan.
3. Tidak ada geografi, rotasi, dan sesi lengket
Infrastruktur proxy memberikan apa yang tidak dimiliki oleh protokol privat secara desain: pilihan negara, wilayah, dan operator, rotasi IP yang dikelola, sesi lengket selama jumlah menit yang diperlukan, kumpulan berbeda untuk akun yang berbeda. OHTTP tidak memberi Anda pilihan "keluar dari Jerman, dari jaringan ISP tertentu" — di sana tidak ada konsep titik keluar yang dapat Anda kendalikan. Untuk memeriksa hasil lokal, harga berdasarkan wilayah, atau bekerja dengan konten yang dibatasi secara geografis, ini adalah perbedaan yang tidak dapat dihindari.
4. Model kepercayaan berbeda
OHTTP melindungi dari pengaitan permintaan dengan origin tertentu dengan syarat bahwa relay dan gateway independen. Proxy melindungi dari fakta bahwa situs akan melihat alamat dan profil jaringan Anda yang sebenarnya. Yang pertama — tentang privasi telemetri dan permintaan pengguna, yang kedua — tentang akses dan distribusi beban. Tugas-tugas ini hanya sebagian tumpang tindih, dan "pindah" dari satu ke yang lain tidak mungkin.
Apa yang benar-benar berguna dalam praktik
- Jika Anda adalah pengembang produk yang mengirimkan telemetri atau permintaan ke API Anda — OHTTP melalui Privacy Gateway atau Divvi Up benar-benar mengurangi jumlah data pribadi yang dikumpulkan dan menyederhanakan pembicaraan dengan pengacara. pvcli sekarang memungkinkan Anda untuk melakukan debug tanpa menulis klien dari awal.
- Jika Anda mengumpulkan data publik — tumpukan ini tidak mengubah apa pun: titik keluar dan reputasinya tetap menjadi tanggung jawab Anda. Untuk pengambilan data massal, kombinasi yang masih bekerja adalah proxy pusat data dengan rotasi di platform yang loyal dan proxy residensial di tempat di mana ada anti-bot yang serius.
- Jika Anda bekerja dengan beberapa akun — protokol privat tidak menyelesaikan masalah isolasi: sesi di platform terhubung tidak hanya melalui IP, tetapi juga melalui sidik jari browser dan perilaku. Perbedaan antara lapisan IP dan lapisan identitas telah dibahas dalam materi tentang perbedaan antara proxy dan VPN.
- Jika Anda mengotomatiskan akses "dengan cara yang sah" — di sini Anda harus berhati-hati. Privacy Pass dan agen yang ditandatangani menuju model di mana bot diberikan akses berdasarkan token yang diajukan, bukan berdasarkan "kemiripan dengan manusia". Ini adalah bagian berita yang paling menjanjikan.
Kesimpulan
Peluncuran pvcli adalah indikator yang baik dari kedewasaan: protokol privat telah keluar dari tahap penelitian dan mendapatkan alat debugging. OHTTP, MASQUE, dan Privacy Pass benar-benar mengubah cara internet memperlakukan alamat klien, dan dalam beberapa tahun ke depan "situs melihat IP Anda" akan berhenti menjadi aksioma untuk lalu lintas pengguna.
Tetapi bagi mereka yang mengumpulkan data, mengelola banyak akun, atau memeriksa hasil berdasarkan wilayah, tidak ada yang berubah. Protokol privat menyembunyikan Anda dari siapa yang Anda datangi dengan undangan. Proxy masih diperlukan di tempat di mana undangan tidak diberikan — dan di sana, jenis jaringan, reputasi alamat, dan kualitas kumpulan tetap menjadi faktor penentu. Bijak untuk mengikuti Privacy Pass sebagai saluran legal masa depan untuk bot dan sekaligus mempertahankan infrastruktur proxy yang baik untuk yang nyata.