Shadowsocks dan Xray: Saat VPN Diblokir

Saya sering bekerja dengan VPN. Bukan sebagai teori, tetapi dalam pekerjaan nyata: menghubungkan lokasi, memberi pelanggan akses ke jaringan perusahaan, menjaga server tetap bisa dijangkau, mengonfigurasi firewall, memperbarui sertifikat, menstabilkan tunnel IPsec, men-debug klien SSL VPN, dan mencari tahu mengapa sebuah lokasi tiba-tiba tidak bisa terhubung.

Biasanya ini pekerjaan jaringan yang solid dan membosankan. Memang seharusnya begitu.

Namun ada kasus ketika VPN yang secara teknis benar tetap tidak cukup. Pada pelanggan dari negara dengan Internet yang sangat diatur, misalnya China atau Rusia, kita sering melihat protokol VPN klasik diblokir, diganggu, atau dikenali secara sengaja. Karena saya bekerja di Dubai dengan pelanggan yang sangat internasional, ini bukan topik abstrak. Pertanyaan operasionalnya adalah: bagaimana akses sah ke infrastruktur sendiri tetap berjalan ketika koneksi difilter di tengah jalan?

Di sinilah muncul istilah seperti Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY, atau XHTTP. Awalnya terlihat seperti campuran proyek, fork, dan singkatan yang membingungkan. Dan jujur saja, sebagian memang begitu.

Mengapa Shadowsocks muncul

Shadowsocks tidak berasal dari dunia VPN enterprise klasik. Ia tidak dibuat untuk mengganti IPsec atau membangun solusi site-to-site yang lebih rapi. Asalnya jauh lebih langsung: pada 2012, pengembang dengan nama samaran clowwindy ingin jalur ringan untuk keluar dari jaringan yang sangat difilter menuju Internet terbuka.

Desainnya mengikuti kebutuhan itu. Shadowsocks harus ringan, cepat, dan praktis: bukan klien VPN besar, bukan gateway lengkap, bukan suite remote access dengan identity management dan compliance. Idenya adalah proxy SOCKS5 lokal yang mengenkripsi traffic dan mengirimnya ke server di luar blokade.

Kebutuhannya bukan “fitur keamanan enterprise tambahan”, tetapi “saya butuh jalur keluar yang bekerja dari jaringan yang memfilter protokol dan tujuan tertentu”. Karena itu Shadowsocks tetap menarik, tetapi juga mudah disalahpahami. Ia bagus sebagai komponen transport yang ramping, bukan otomatis VPN perusahaan lengkap.

Pada 2015, kisahnya menjadi politis: clowwindy menulis di GitHub bahwa polisi datang dan ia harus berhenti mengerjakan proyek itu. Setelah itu pengembangan berlanjut lewat fork dan implementasi lain. Banyak alat seperti ini lahir dari rasa sakit teknis yang sangat konkret, lalu masuk ke perlombaan antara pengguna, pengembang, dan infrastruktur penyaringan.

Mengapa VPN terlihat

Banyak orang memikirkan enkripsi saat mendengar VPN. Itu benar, tetapi hanya sebagian.

Sensor, provider, atau firewall nasional tidak selalu perlu membaca isi koneksi terenkripsi untuk mengganggunya. Sering kali cukup mengenali bungkusnya. IPsec, SSL VPN, WireGuard, dan OpenVPN punya ciri khas: port, ukuran paket, pola handshake, perilaku sertifikat, timing, penggunaan UDP, retry, pesan error, atau IP server yang sudah dikenal.

Bayangkan bukan isi suratnya, tetapi amplopnya. Isi surat terenkripsi, tetapi amplop punya ukuran, warna, cap, dan pengirim tertentu. Orang yang hanya menyortir amplop tidak perlu membaca teks untuk berkata: jenis amplop ini saya kenal, kirim ke pemeriksaan khusus.

Traffic jaringan mirip seperti itu. Deep Packet Inspection dan Traffic Classification tidak hanya melihat port, tetapi pola. Pada TLS, Client Hello fingerprint, SNI, rantai sertifikat, atau ALPN bisa menonjol. Pada protokol yang sepenuhnya terenkripsi, justru tampilan acak pada paket awal bisa menjadi sinyal. Riset tentang Great Firewall menunjukkan bahwa panjang paket, entropi, dan karakter ASCII yang dapat dicetak pada paket awal juga penting.

Poin yang tidak nyaman: “semuanya terlihat acak” tidak otomatis berarti tidak mencolok. Kadang justru itu yang mencurigakan.

Apa yang ditunjukkan riset

Poin pentingnya bukan sekadar bahwa sistem sensor bisa “mendeteksi VPN”. Itu sudah diketahui secara umum. Yang menarik adalah betapa tidak dramatisnya banyak deteksi dari sisi teknis.

Titik awal yang baik adalah penelitian pengukuran GFW Report yang dipresentasikan pada 2020 di ACM Internet Measurement Conference. GFW Report bukan produk atau vendor, melainkan proyek riset dan pengukuran tentang Great Firewall.

Intinya: ini bukan serangan dekripsi ajaib. Great Firewall menggabungkan pengamatan pasif dan active probing. Pertama, koneksi menjadi mencurigakan karena panjang dan entropi paket data pertama. Lalu sensor melakukan probe aktif: ia menghubungi server yang dicurigai, memutar ulang paket lama atau yang dimodifikasi, dan melihat apakah sisi lain merespons seperti server Shadowsocks.

Bagi administrator, ini menunjukkan dua lapisan pertahanan:

• Traffic tidak boleh terlalu mencolok secara pasif.
• Server tidak boleh menjawab probe aktif seperti proxy.

Pada 2023, studi GFW lain menunjukkan bahwa traffic yang sepenuhnya terenkripsi dapat diblokir dengan heuristik sederhana. Jika payload TCP pertama tidak terlihat seperti TLS, HTTP, atau teks yang dapat dicetak, melainkan blok acak, itu sudah bisa menjadi sinyal. Jadi “acak semaksimal mungkin” tidak selalu menjadi tujuan kamuflase terbaik.

Pada 2024, riset tentang handshake TLS yang dienkapsulasi menambah masalah: meskipun tunnel luar terenkripsi dan tersamarkan, handshake TLS di dalamnya dapat muncul sebagai pola dalam stack protokol bertingkat. Padding acak hanya membantu terbatas; multiplexing stream tampak lebih menjanjikan, tetapi tidak otomatis menyelesaikan masalah jika akhirnya hanya satu stream aplikasi yang terlihat.

Timing dan cross-layer RTT juga relevan. Proxy menggeser sesi transport dan aplikasi terhadap satu sama lain. Perbedaan waktu itu bisa terukur, baik klien dekat maupun jauh dari proxy. Ini bukan sesuatu yang bisa dibereskan dengan mengganti header.

Kesimpulannya sederhana: yang menentukan bukan label protokol, tetapi perilaku keseluruhan setup.

Shadowsocks bukan VPN klasik

Shadowsocks sering dimasukkan ke kategori VPN. Dalam bahasa sehari-hari itu bisa dimengerti, tetapi secara teknis kurang tepat.

Shadowsocks adalah proxy terenkripsi yang longgar terinspirasi SOCKS5. Klien lokal menyediakan proxy untuk aplikasi, mengenkripsi traffic, lalu mengirimkannya ke server Shadowsocks jarak jauh. Server mendekripsi permintaan, terhubung ke tujuan sebenarnya, dan mengembalikan respons lewat jalur terenkripsi.

Ini lebih ramping daripada VPN penuh. Shadowsocks tidak otomatis memasukkan seluruh sistem operasi ke dalam tunnel. Ia lebih seperti alat untuk mengirim traffic tertentu melalui jalur lain. Dengan klien dan komponen tambahan, perilakunya bisa dibuat hampir seperti VPN, tetapi ide dasarnya tetap proxy, bukan site-to-site VPN.

Bagi administrator, ini penting:

• Shadowsocks tidak menggantikan site-to-site IPsec yang rapi.
• Shadowsocks bukan perlindungan ajaib dari semua deteksi.
• Shadowsocks berguna ketika diperlukan proxy terenkripsi yang sederhana dan cepat dari jaringan restriktif.

Secara teknis, Shadowsocks berkembang. Setup lama dengan stream cipher tidak lagi layak menjadi acuan. Deployment modern berada di dunia AEAD, dan Shadowsocks 2022 menambah basis kunci simetris pre-shared, derivasi berbasis BLAKE3, replay protection, dan koreksi lain. Namun spesifikasinya tidak memberi Forward Secrecy. Jika kunci bocor, rotasi yang bersih wajib dilakukan.

shadowsocks-rust adalah implementasi modern yang juga bisa dijalankan dengan Docker. Di sisi server ada ssserver, di sisi klien sslocal. Dibutuhkan secret yang dibuat benar, port yang bisa dijangkau, cipher terbaru, dan keputusan jelas tentang TCP, UDP, atau keduanya.

Mengapa Xray-core berbeda kategori

Xray-core bukan sekadar “Shadowsocks yang lebih baru”. Ia lebih seperti framework untuk skenario proxy dan tunnel.

Xray dapat menggabungkan protokol inbound dan outbound seperti VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS, dan HTTP. Di atasnya ada transport seperti RAW, WebSocket, gRPC, XHTTP, atau Hysteria, lalu TLS, REALITY, atau XTLS Vision. VMess masih muncul di setup lama, tetapi untuk deployment baru lebih bersifat legacy; pada Xray modern, VLESS biasanya menjadi pusatnya.

Shadowsocks adalah obeng cepat. Xray adalah kotak alat. Ia bisa membuat setup sederhana, tetapi juga rantai yang menerima traffic lewat klien lokal SOCKS atau TUN, mengirimnya via VLESS dengan REALITY ke server, lalu keluar ke Internet melalui outbound freedom.

VLESS bukan kamuflase itu sendiri. Ia protokol proxy ringan dengan autentikasi UUID. Kerahasiaan dan kamuflase datang dari lapisan transport dan security di bawahnya, seperti TLS, REALITY, atau XTLS Vision.

REALITY menarik karena tidak sekadar melakukan “TLS lagi”. Dari luar, server meminjam handshake TLS dari situs HTTPS pihak ketiga yang nyata. Bagi pengamat, itu tampak seperti sertifikat nyata dari situs nyata, bukan sertifikat proxy buatan sendiri. Hanya klien yang sah, dengan material kunci yang dikonfigurasi, mengenali server Xray miliknya.

Ini terutama menyasar TLS fingerprint sisi server dan active probing. uTLS membantu sisi klien dengan meniru Client Hello browser. Tetapi Xray bukan jubah tembus pandang: timing, ukuran paket, ALPN, perilaku server, dan pola TLS bertingkat masih bisa menjadi sinyal. XTLS Vision dan XHTTP adalah komponen menarik, bukan jaminan. Sedikit padding tidak banyak membantu jika pola dasar traffic tetap terlihat.

Pendekatan berbasis UDP seperti Hysteria atau QUIC bisa cepat, tetapi di jaringan restriktif sering dibatasi atau diblokir lebih mudah daripada TCP/443 keluar. Karena itu Xray menuntut disiplin: pin versi, uji perubahan, baca release notes, dan jangan menyalin rekomendasi forum secara buta.

Kebingungan fork dan nama

Saat mulai mencari, kita cepat menemukan blog lama, fork GitHub, dan klien yang setengah terawat. Itu berasal dari sejarah alat-alat ini.

Shadowsocks adalah protokol sekaligus ekosistem dengan beberapa implementasi. shadowsocks-rust sekarang pilihan alami untuk server modern. Implementasi lama seperti shadowsocks-libev masih dikenal, tetapi tergantung status proyeknya lebih tepat dianggap legacy atau berfokus pada bugfix.

ShadowsocksR adalah fork dengan ide obfuscation tambahan. SSR masih muncul di banyak panduan lama. Saya akan berhati-hati hari ini: bukan karena semua instalasi lama buruk, tetapi karena klien, server, kripto, update, dan komunitas harus dicek dengan serius.

Xray-core berasal dari lingkungan V2Ray, tetapi berkembang sendiri. Tutorial V2Ray lama tidak boleh langsung diterapkan ke Xray. Konsepnya mirip, tetapi konfigurasi, fitur, dan rekomendasi berubah.

V2Fly masih relevan sebagai proyek komunitas yang lebih konservatif. Xray-core lebih agresif pada fitur seperti REALITY, XTLS Vision, dan XHTTP. Ada juga sing-box sebagai platform universal modern. Artikel ini fokus pada Xray, tetapi di lab saya juga akan melihat sing-box.

Saran praktis saya:

• Untuk setup baru yang sederhana: Shadowsocks dengan implementasi terbaru.
• Untuk jaringan lebih sulit: Xray-core dengan desain bersih dan modern.
• Untuk panduan SSR atau V2Ray lama: cek status proyek dan keamanan dulu.
• Untuk pelanggan produksi: jangan menyalin setup tanpa memahami sendiri.

Apa yang dibutuhkan di kedua sisi

Setup minimal selalu punya dua sisi.

Di sisi jauh, diperlukan server di luar jaringan restriktif: VPS, server sendiri, atau infrastruktur terkontrol di wilayah yang bisa dijangkau pelanggan. Server ini harus di-hardening, di-patch, dipantau, dan didokumentasikan. Instance murah yang dilupakan adalah risiko jangka panjang.

Di sisi klien, diperlukan program yang sesuai. Untuk Shadowsocks biasanya klien SOCKS lokal atau aplikasi yang mengatur proxy sistem. Untuk Xray bisa berupa klien Xray, mode TUN, setup router, atau aplikasi yang mengimpor profil.

Di antara keduanya diperlukan:

• tujuan yang jelas
• autentikasi yang bersih
• versi software terbaru
• resolusi DNS yang terkontrol
• logging tanpa data pelanggan yang tidak perlu
• monitoring keterjangkauan
• rencana rotasi server, port, dan secret
• pemeriksaan legal dan kontraktual

Poin terakhir penting. Di beberapa negara, menggunakan alat seperti ini bisa bermasalah secara hukum. Dalam konteks perusahaan, juga harus jelas apakah ini untuk sistem sendiri, jaringan pelanggan, atau akses Internet umum karyawan.

DNS sering diremehkan. Jika browser atau sistem masih melakukan resolusi domain melalui provider lokal, tunnel hanya membantu setengah. Konten mungkin lewat proxy, tetapi query DNS tetap mengungkap tujuan. Karena itu jalur DNS, IPv6, dan perilaku saat tunnel putus harus diuji.

Logging juga sensitif. Untuk troubleshooting kita ingin tahu tunnel hidup; untuk privasi kita ingin menyimpan sesedikit mungkin. Setup yang baik mengumpulkan status teknis, latensi, error rate, dan volume, bukan daftar koneksi lengkap. Debug log, TLS keylog, dan access log tanpa masking tidak pantas tinggal di produksi.

Monitoring harus memeriksa jalur uji nyata, DNS yang benar, blokir per wilayah, dan perbedaan tampilan dari negara terdampak, bukan hanya apakah container berjalan.

Cara saya menggolongkannya secara operasional

Bagi saya, Shadowsocks atau Xray bukan pengganti arsitektur firewall, Zero Trust, MFA, atau segmentasi. Ini alat transport untuk kasus khusus.

Pendekatan perusahaan yang masuk akal:

1. Coba dulu SSL VPN, IPsec, atau WireGuard.
2. Jika diblokir, ukur DNS, port, protokol, IP server, TLS fingerprint, dan throttling UDP.
3. Uji transport alternatif seperti Shadowsocks atau Xray-core.
4. Gunakan tunnel hanya untuk tujuan yang diperlukan.
5. Filter di sisi server layanan internal yang boleh dicapai.
6. Bangun monitoring agar blokir tidak baru diketahui dari pelanggan.
7. Siapkan fallback: exit kedua, provider lain, wilayah lain, protokol lain.
8. Pisahkan secret dan profil per lokasi atau pengguna.
9. Buat log dan metrik yang cukup untuk operasi tanpa jejak berlebihan.

Ketika pelanggan kehilangan akses, “yang penting jalan lagi” memang menggoda. Tetapi setelah itu harus dibereskan dan didokumentasikan. Jika tidak, workaround sementara menjadi jalur produksi tak terlihat.

Mengapa blokade sering mengejar

Pihak lawan terus menyesuaikan deteksi.

Jika banyak orang memakai Docker Compose yang sama, port yang sama, TLS fingerprint yang sama, strategi domain yang sama, dan provider VPS yang sama, polanya akan terlihat. Yang diblokir bukan “Xray” atau “Shadowsocks” secara abstrak, tetapi pola konkret: handshake, ukuran paket, range IP, klien umum, fallback buruk, atau respons error mencolok.

Kamuflase bukan hanya fitur tool. Kamuflase adalah operasi: tool yang sama dengan domain, provider, profil, dan pola traffic berbeda bisa terlihat sangat berbeda.

Itulah alasan saya berhati-hati dengan klaim proyek. Jika sebuah tool mengaku tidak terdeteksi, itu klaim proyek. Jika paper menunjukkan sebuah ciri terdeteksi di jaringan nyata, bobotnya berbeda. Praktik membutuhkan keduanya: inovasi proyek dan ketenangan riset.

Penilaian saya

Shadowsocks masuk akal ketika dibutuhkan proxy terenkripsi yang ramping, cepat, dan relatif sederhana: tes awal, akses sementara, atau lingkungan tanpa deteksi sangat agresif.

Xray-core masuk akal ketika jaringan lebih sulit, beberapa transport dibutuhkan, atau kita ingin memakai VLESS, REALITY, WebSocket, gRPC, atau XHTTP. Tetapi ia menuntut pemahaman lebih dan lebih mudah salah konfigurasi.

Untuk pelanggan, saya tidak akan menjual keduanya sebagai “pengganti VPN”. Saya akan menyebutnya jalur transport alternatif untuk akses yang sah. Itu kurang spektakuler, tetapi lebih jujur.

Perbedaan terpenting bukan Shadowsocks melawan Xray, tetapi apakah saya memahami masalah yang saya selesaikan. Untuk remote access normal, gunakan VPN normal. Untuk deteksi protokol oleh negara atau provider, bicarakan keterlihatan, fingerprint, dan strategi operasi. Jika tidak bisa menjelaskannya dengan bersih, jangan jalankan untuk pelanggan produksi.

Kesimpulan

Shadowsocks dan Xray-core berasal dari dunia di mana koneksi jaringan tidak hanya “berjalan” atau “tidak berjalan”. Kadang koneksi diklasifikasikan, diperlambat, diuji aktif, atau diblokir. Siapa pun yang melayani pelanggan internasional akhirnya bertemu realitas ini.

Topik ini menarik karena membuat jaringan sangat konkret: enkripsi, pola, fingerprint, routing, DNS, operasi, hukum, tanggung jawab, dan fakta bahwa tunnel yang berjalan tidak otomatis desain yang baik.

Langkah saya berikutnya jelas: saya ingin mencoba Shadowsocks dan Xray-core di lab kecil. Bukan untuk melewati sensor secara buta, tetapi untuk memahami mengapa VPN klasik kadang terlihat dan alternatif mana yang bisa dioperasikan secara serius.

Sampai jumpa lagi,
Joe

FAQ