Cloudflare mengumumkan closed beta OHTTP Gateway, layanan terkelola yang dirancang untuk membantu aplikasi menerima permintaan HTTP tanpa melihat alamat IP pengguna. Perusahaan mengatakan OHTTP Gateway akan tersedia sebagai add-on berbayar untuk zone Cloudflare pada musim gugur 2026. Pengembang dapat mengaktifkan lalu lintas OHTTP dari dashboard tanpa harus membangun seluruh lapisan relay sendiri.

OHTTP adalah singkatan dari Oblivious HTTP, standar IETF yang memisahkan pengetahuan tentang identitas jaringan pengguna dari isi permintaan. Dalam koneksi web biasa, server tujuan dapat menerima alamat IP klien, lalu menghubungkannya dengan permintaan lain. OHTTP mencoba memecah hubungan itu dengan menempatkan relay di antara klien dan gateway aplikasi.

Dua titik jaringan, dua jenis pengetahuan

Alur OHTTP memiliki beberapa pihak dengan peran berbeda. Klien membuat permintaan, mengenkripsi pesan, lalu mengirimkannya ke relay. Relay mengetahui dari mana permintaan datang dan ke gateway mana permintaan itu harus diteruskan, tetapi tidak dapat membaca isi pesan yang sudah dienkripsi. Gateway kemudian membuka pesan dan meneruskannya ke target aplikasi. Gateway dapat memproses permintaan, tetapi tidak menerima alamat IP asli pengguna dari koneksi ke relay.

Pemisahan ini bukan sekadar proxy biasa. Pada proxy umum, operator perantara mungkin dapat melihat isi lalu lintas atau metadata yang cukup untuk menghubungkan pengguna dengan permintaan. Dalam desain OHTTP, isi permintaan dilindungi dengan encapsulation berbasis HPKE, sementara relay hanya membawa pesan terenkripsi. Model tersebut memang membutuhkan kepercayaan yang terbagi: relay dan gateway tidak boleh menjadi satu titik yang sekaligus mengetahui identitas pengguna dan isi permintaan.

Cloudflare mengatakan OHTTP Gateway akan berjalan di jaringan edge anycast miliknya. Dengan begitu, relay dan gateway dapat ditempatkan lebih dekat ke pengguna serta backend dibandingkan arsitektur yang memusatkan semua lalu lintas di satu lokasi. Penempatan ini ditujukan untuk mengurangi latensi tambahan yang muncul karena setiap permintaan melewati lebih dari satu layanan.

Bukan VPN baru

OHTTP Gateway tidak diposisikan sebagai VPN untuk seluruh aktivitas perangkat. Protokol ini bekerja pada aplikasi yang memang dirancang untuk mengirim jenis permintaan tertentu melalui relay dan gateway OHTTP. Pengembang perlu menambahkan dukungan pada klien, menyiapkan gateway aplikasi, serta memastikan data yang dikirim tidak memuat identitas pengguna yang justru membatalkan manfaat privasi.

Dokumentasi Cloudflare memperingatkan bahwa nama, alamat surel, nomor telepon, atau pengenal unik lain sebaiknya tidak ikut diteruskan dalam payload jika tujuan aplikasinya adalah mengurangi keterkaitan antarpermintaan. Jika aplikasi memasukkan identitas itu ke dalam isi pesan, backend tetap dapat mengenali pengguna meskipun alamat IP tidak terlihat. Crash report juga perlu diperiksa karena dapat membawa data sensitif secara tidak sengaja.

Batas ini membuat OHTTP lebih cocok untuk jenis pekerjaan tertentu, seperti telemetri yang tidak membutuhkan identitas, pengukuran penggunaan, pemeriksaan ketersediaan, atau permintaan aplikasi yang sengaja dirancang tanpa sesi pengguna. OHTTP bukan pengganti autentikasi, cookie, atau alur yang membutuhkan server mengingat pengguna dari satu permintaan ke permintaan berikutnya.

Privasi datang dengan biaya teknis

RFC 9458 mencatat bahwa OHTTP memiliki overhead dibandingkan koneksi langsung. Setiap permintaan perlu melalui relay dan gateway, membawa metadata enkripsi tambahan, serta menjalani proses kriptografi untuk melindungi request dan response. Latensi dapat bertambah, ukuran pesan menjadi lebih besar, dan server perlu mengelola konfigurasi kunci publik gateway.

Protokol ini juga tidak menghapus seluruh kemungkinan pelacakan. Data di dalam request dapat memuat pengenal yang menghubungkan beberapa permintaan. Respons yang diterima klien juga dapat memengaruhi permintaan berikutnya dan menciptakan pola yang bisa dikenali. Analisis trafik, ukuran pesan, dan kesalahan implementasi berada di luar janji sederhana bahwa alamat IP tidak terlihat oleh gateway.

Karena itu, Cloudflare menempatkan konfigurasi aplikasi sebagai bagian penting dari penerapan. Pengembang tetap harus menentukan data apa yang boleh keluar dari perangkat, bagaimana klien menemukan kunci publik gateway, dan bagaimana aplikasi menangani kegagalan relay. OHTTP memberi fondasi protokol, bukan jaminan bahwa sebuah aplikasi otomatis menjadi anonim.

Dari Privacy Gateway ke dua layanan OHTTP

Cloudflare juga mengganti nama Privacy Gateway menjadi Cloudflare OHTTP Relay agar perannya lebih mudah dibedakan dari OHTTP Gateway yang baru diumumkan. OHTTP Relay adalah layanan terkelola di jaringan Cloudflare yang menangani sisi relay. Dokumentasinya masih menempatkan layanan itu dalam closed beta dan menjelaskan bahwa implementasi membutuhkan tiga bagian: server gateway aplikasi yang dikelola pelanggan, konfigurasi klien, serta koneksi ke relay Cloudflare.

Perubahan bentuk layanan ini penting bagi pengembang. Implementasi OHTTP biasanya memerlukan koordinasi antara aplikasi klien, server gateway, relay, konfigurasi kunci, metrik, dan pemeriksaan terhadap data yang dikirim. Layanan terkelola dapat mengurangi pekerjaan operasional tersebut, tetapi juga menambah ketergantungan pada infrastruktur Cloudflare serta model harga yang belum dirinci dalam pengumuman.

Cloudflare belum memberikan tanggal peluncuran final, daftar paket yang memenuhi syarat, atau rincian tarif OHTTP Gateway. Jadi, pengembang belum dapat menganggap layanan ini sudah siap dipakai dalam produksi hanya berdasarkan pengumuman. Mereka masih perlu menunggu dokumentasi ketersediaan, detail konfigurasi, batas lalu lintas, serta penjelasan tentang log dan metrik yang terlihat oleh setiap pihak.

Bagi pengguna, perubahan ini kemungkinan tidak terlihat sebagai fitur baru di browser atau aplikasi. Nilainya berada di belakang layar: sebuah aplikasi dapat mengurangi pengetahuan server tentang jaringan penggunanya tanpa meminta semua orang memasang VPN atau mengubah pengaturan sistem. Bagi pengembang, tantangannya justru ada pada desain data. Jika request masih membawa akun, token, nomor telepon, atau pola sesi yang mudah dikenali, relay tambahan tidak akan menyelesaikan masalah utama.

OHTTP Gateway menunjukkan arah yang lebih spesifik dalam perdebatan privasi internet. Perlindungan tidak selalu harus berupa pemblokiran total terhadap pelacakan atau penambahan satu aplikasi perantara di sisi pengguna. Sebagian sistem dapat memilih jalur yang hanya menyembunyikan metadata tertentu untuk permintaan tertentu. Pendekatan itu lebih terbatas daripada anonimitas menyeluruh, tetapi juga lebih realistis untuk fitur yang membutuhkan kinerja dan integrasi dengan layanan web yang sudah ada.

Sumber - Cloudflare Blog, “Announcing Cloudflare OHTTP Gateway – expanding access to Cloudflare’s privacy-preserving infrastructure” (2 Oktober 2026): https://blog.cloudflare.com/announcing-cloudflare-ohttp-gateway/

Sumber - IETF, RFC 9458: Oblivious HTTP: https://www.rfc-editor.org/rfc/rfc9458.html - Cloudflare Developers, “Cloudflare OHTTP Relay”: https://developers.cloudflare.com/ohttp-relay/ - Cloudflare Developers, “Get started with Cloudflare OHTTP Relay”: https://developers.cloudflare.com/ohttp-relay/get-started/