Cara efektif mengurangi pemblokiran akun di layanan relay AI

Wokey Team · 2026-06-27

Penyedia model baru-baru ini melakukan gelombang besar pemblokiran akun — begitu luas hingga pengguna perorangan dengan pemakaian yang sah pun ikut terkena imbasnya.

Jika Anda menjalankan layanan relay, atau sedang memilih salah satunya, hal ini layak dipikirkan dengan serius: apakah pemblokiran itu soal keberuntungan, atau soal arsitektur?

Jawaban saya adalah yang kedua. Tingkat pemblokiran tidak acak — arsitekturlah yang menentukannya.

Mari lihat gambaran besarnya. Saat penyedia model menilai apakah sebuah akun dipakai bersama atau dijual ulang, mereka biasanya melihat sinyal-sinyal berikut:

• Perubahan IP & jenis IP — permintaan Anda tiba-tiba melompat dari IP residensial ke IP pusat data, atau berpindah-pindah geolokasi.
• Anomali perilaku — frekuensi panggilan, konkurensi, dan sebaran waktu yang jelas tidak tampak seperti satu orang.
• Banyak akun berbagi satu jalur keluar — permintaan puluhan akun mengalir lewat kumpulan IP yang sama.
• Anomali sidik jari klien — header permintaan, sidik jari TLS, dan karakteristik perangkat yang tidak cocok dengan klien normal.

Tumpuk sinyal-sinyal ini, dan sistem risiko penyedia model akan menandai akun Anda.

Namun jika ditanya sinyal mana yang bobotnya paling besar dan paling mudah dideteksi — menurut saya itu IP.

Alasannya sederhana: IP adalah kriteria penyaringan terluar dan termurah. Permintaan dari IP residensial dibanding IP pusat data berada di tingkat risiko yang sama sekali berbeda di mata sistem risiko. ASN pusat data + IP yang berpindah-pindah + anomali geografis — begitu ketiganya muncul bersamaan, itu nyaris sama dengan memberi tahu sistem risiko "ini bukan pengguna normal."

Sejujurnya, arsitektur layanan relay konvensional menginjak ranjau ini tepat di tengahnya: semua permintaan keluar dari server milik relay, dengan puluhan akun berbagi kumpulan IP pusat data yang sama. Bagaimanapun Anda melakukan load balancing atau merotasi kumpulan proxy, titik keluarnya pada dasarnya tetap ruang server. Saya sudah melihat solusi operator relay lain — mereka rajin merotasi proxy, tetapi pengecekan ASN sekilas menunjukkan semuanya penyedia cloud. Topengnya beda, wajahnya sama.

Itulah sebabnya ada orang yang berganti di antara tiga layanan relay dan diblokir tiap dua minggu di masing-masing layanan — bukan karena sial, melainkan karena setiap layanan punya arsitektur yang sama.

Lalu bagaimana menjaga agar IP tidak berubah?

Jika Anda pengguna perorangan, sudah ada pendekatan yang mapan: pasang gateway terpadu seperti New API atau One API di NAS rumah, atau gunakan tool seperti sam-to-API, lalu arahkan semua API penyedia model lewat gateway itu. Ponsel, laptop, klien apa pun yang memanggil model — tidak satu pun menghubungi penyedia model secara langsung. Semuanya lewat perangkat di rumah Anda, yang meneruskan ke API penyedia. Dengan begitu, model apa pun yang Anda panggil, IP keluar dari sudut pandang penyedia selalu IP internet rumah Anda — tidak bisa dibedakan dari Anda yang duduk di rumah dan memakainya secara normal.

Bagaimana saat Anda di luar? Gunakan tool jaringan mesh seperti Tailscale atau WireGuard untuk mengarahkan lalu lintas ponsel atau laptop Anda kembali ke NAS rumah lebih dulu, baru keluar dari rumah. Baik Anda di kafe, di kantor, maupun di kereta, permintaan Anda tetap keluar dari internet rumah. Penyedia model tidak pernah melihat IP Anda melompat hanya karena Anda berganti Wi-Fi atau menyalakan data seluler.

Pendekatan ini sudah teruji di komunitas fnOS dan kalangan self-hosting AI, dengan banyak tutorial dan praktisi. Bagi pengguna perorangan, saat ini inilah solusi penguncian IP yang paling andal.

Tetapi ini hanya menyelesaikan masalah satu orang.

Layanan relay mengelola akun dari puluhan atau ratusan Provider. Anda tidak mungkin mendatangi rumah tiap orang untuk memasang NAS dan mengonfigurasi gateway. Anda butuh solusi sistematis yang memungkinkan tiap Provider memasang node ringan dan terhubung ke platform — permintaan tetap keluar dari jaringan Provider sendiri, tetapi pembagian pesanan dan perutean lalu lintas ditangani secara terpusat oleh platform.

Arsitektur ini disebut provider-side exit — permintaan keluar dari jaringan Provider sendiri, bukan dari server milik relay.

Sebuah analogi: pendekatan NAS ibarat membuka toko sendiri di pinggir jalan — Anda mengirim dari rumah, serta mengurus pengadaan, pemilihan, dan pesanan sendirian. Provider Node ibarat bergabung dengan waralaba platform — Anda tetap mengirim dari rumah, tetapi pesanan dibagikan kepada Anda oleh platform. Alamat pengirimannya tidak berubah; yang berubah adalah siapa yang membagikan pesanan.

Inilah yang dilakukan Wokey Provider Node.

Instalasinya sederhana — satu perintah, mendukung macOS, Linux, Windows, dan Docker. Setelah instalasi, buka konsol lokal, tautkan akun Wokey Anda, dan impor kredensial langganan lokal Anda. Begitu node berjalan, ia menjaga koneksi WebSocket dengan platform Wokey. Platform mengirimkan permintaan pengguna, dan node memulai permintaan ke API vendor secara lokal. Seluruh proses keluar dari IP Provider sendiri — bagi vendor, ini identik dengan Provider yang memakai langganannya sendiri secara normal.

Vendor yang saat ini didukung mencakup OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI, dan lainnya.

Setelah menjalankan arsitektur ini sendiri, kesimpulan yang paling terasa adalah: ini bukan "melawan" kontrol risiko — ia memang tidak pernah memicu prasyarat deteksi risiko. Dari sudut pandang vendor, ini hanyalah pengguna normal di rumah yang memakai langganannya sendiri, tanpa anomali apa pun yang perlu dijelaskan.

Seluruh proyek ini open-source di bawah Apache-2.0, dengan whitelist jalur keluar ditulis langsung di kode sumber. Ia aman bukan karena saya yang mengatakannya — ia aman karena setiap baris kodenya bisa diaudit.

Tentu saja, saya tidak akan mengklaim bahwa provider-side exit menjamin nol pemblokiran. IP hanyalah satu faktor pemblokiran — frekuensi panggilan, pola konkurensi, dan sebaran waktu juga bisa memicu kontrol risiko. Tidak ada solusi yang bisa menjamin tingkat pemblokiran nol.

Namun logikanya jelas: jika sinyal terbesar belum Anda tangani, setiap optimasi lain dibangun di atas pasir.

Kunci menurunkan tingkat pemblokiran adalah membuat pemakaian Anda tidak bisa dibedakan dari pemakaian normal. Menjaga IP tidak berubah adalah bagian yang paling krusial. Pengguna perorangan punya solusi perorangan; layanan relay butuh pendekatan provider-side exit yang sistematis.

Ketika persaingan relay sampai di babak akhirnya, yang menentukan bukan siapa yang punya lebih banyak model atau harga lebih rendah — melainkan arsitektur siapa yang membuat penyedia model tidak bisa mengenali Anda sebagai relay. Layanan yang sedang Anda pakai sekarang — permintaannya keluar dari jaringan siapa?