Stack VLESS Modern di 2026

Per 2026, VLESS tetap merupakan protokol proxy yang ringan dan stateless, tetapi “VLESS tidak punya enkripsi” bukan lagi gambaran yang lengkap. Xray-core kini menyediakan VLESS Encryption yang bersifat opsional. Sebuah deployment juga dapat menggabungkan VLESS dengan TLS, REALITY, XTLS Vision, XHTTP, dan XUDP sesuai model ancamannya. Lapisan-lapisan ini menyelesaikan masalah yang berbeda dan tidak boleh dilebur menjadi satu protokol.

Kebijakan bukti: Panduan ini memakai sumber primer dari Project X, Xray-core, sing-box, dan AnyTLS. Pull request dan diskusi GitHub mendokumentasikan desain dan implementasi dari para maintainer; keduanya bukan audit keamanan independen. Rujukan ke SingLink adalah perbandingan arsitektur, bukan klaim bahwa SingLinkVPN mengimplementasikan proyek-proyek tersebut.

1. Sekilas tentang stack VLESS modern

• VLESS: lapisan ringan untuk identitas, perintah, dan tujuan.
• VLESS Encryption: lapisan perlindungan payload bawaan yang opsional di Xray-core saat ini.
• TLS 1.3 / REALITY: keamanan transport lapisan luar, autentikasi, dan tampilan di jaringan.
• XTLS Vision: kontrol alur dan optimasi jalur data, bukan cipher tersendiri.
• RAW / XHTTP / gRPC / WebSocket: transport yang membawa data proxy.
• XUDP: opsi encoding paket UDP di ekosistem Xray.
• XMUX dan sistem MUX lainnya: cara berbagi koneksi yang mendasarinya.
• Padding / FinalMask / Browser Dialer: alat untuk mengatur panjang, waktu, perilaku transport lapisan luar, atau jaringan melalui browser.

Karena itu, sebuah koneksi dapat dimodelkan sebagai lalu lintas aplikasi → identitas dan tujuan VLESS → protokol atau keamanan lapisan luar → kontrol alur Vision → transport seperti RAW atau XHTTP → TCP atau UDP. Tidak setiap modul dibutuhkan atau kompatibel di setiap desain.

2. Apa yang dilakukan protokol dasar VLESS

Dokumentasi Project X mendefinisikan VLESS sebagai protokol transport yang ringan dan stateless, tidak bergantung pada waktu sistem, dan memakai UUID atau ID yang dipetakan untuk autentikasi. Implementasi encoding Xray-core yang publik menunjukkan versi, ID pengguna, addons, perintah, port tujuan, alamat, dan data yang mengikutinya.

Secara praktis, lapisan dasar ini menjawab: siapa kliennya, koneksi apa yang diminta, dan ke mana koneksi itu harus diarahkan? Perutean pintar, beban node, hak akses paket, dan penyambungan ulang otomatis biasanya berada di lapisan produk dan kontrol yang lebih tinggi.

Konfigurasi tradisional umumnya memakai `encryption: "none"`. Panduan Project X saat ini mewajibkan keamanan transport lapisan luar, kecuali peer dan tautannya merupakan infrastruktur privat tepercaya, atau VLESS Encryption diaktifkan.

3. Apa yang diubah oleh VLESS Encryption

VLESS Encryption adalah lapisan perlindungan bawaan yang opsional dan digabungkan ke Xray-core pada 2025. PR #5067 yang sudah di-merge dan dokumentasi konfigurasi saat ini menjelaskan handshake `mlkem768x25519plus`, tampilan `native`, `xorpub`, dan `random`, perilaku sesi `1rtt` dan `0rtt`, serta padding yang bervariasi.

Tujuan desain yang dipublikasikan

• Menurunkan kunci sesi melalui kombinasi ML-KEM-768 dan X25519;
• melindungi payload VLESS tanpa memerlukan TLS lapisan luar;
• memakai tiket untuk resumption 0-RTT berikutnya dan state berumur pendek guna mengurangi risiko replay;
• memakai padding yang bervariasi dan mode XOR opsional untuk mengubah tampilan panjang tetap atau kunci publik.

Ini adalah klaim desain dan implementasi dari para maintainer. Kami tidak menemukan audit kriptografi independen yang mencakup setiap propertinya, sehingga panduan ini tidak menyebut desain tersebut “kebal replay” atau “sepenuhnya aman terhadap komputer kuantum”.

Apa yang tidak otomatis digantikannya

VLESS Encryption melindungi payload protokol. Fitur ini tidak otomatis menghasilkan rantai sertifikat HTTPS biasa, handshake situs web, perilaku HTTP/2 atau HTTP/3, maupun kompatibilitas CDN. Karena itu, fitur ini tidak setara dengan TLS atau REALITY.

4. TLS 1.3 dan REALITY

TLS menyediakan validasi sertifikat, pertukaran kunci, integritas, dan enkripsi transport yang terstandardisasi. TLS dapat dipakai bersama RAW, XHTTP, gRPC, atau WebSocket; versi yang dinegosiasikan, ALPN, dan pemeriksaan sertifikat tetap bergantung pada konfigurasi dan dukungan peer.

Dokumentasi REALITY dari Project X menjelaskan lapisan keamanan bergaya TLS yang dimodifikasi, dengan pengaturan target, serverNames, kunci X25519, dan shortId, ditambah data verifikasi ML-DSA-65 yang opsional. REALITY dapat dipakai bersama RAW, XHTTP, dan gRPC.

REALITY tidak boleh disederhanakan menjadi “TLS tanpa sertifikat”. Perilakunya memadukan otorisasi klien dengan tampilan handshake eksternal. Hasilnya tetap bergantung pada target, fingerprint klien, transport, dan kualitas deployment; REALITY tidak bisa menjamin tak terdeteksi oleh setiap pengklasifikasi.

5. XTLS Vision bukan protokol enkripsi

Dokumentasi VLESS/Vision menggolongkan Vision sebagai kontrol alur. Dalam kondisi yang didukung, Vision dapat mengenali lalu lintas TLS di dalamnya dan mengurangi enkripsi atau penyalinan tambahan. Pada jalur Linux dan TCP yang kompatibel, core dapat mencoba `splice` agar kernel memindahkan data secara langsung.

Pembagian yang akurat adalah: TLS, REALITY, atau VLESS Encryption menyediakan keamanan; Vision mengoptimalkan cara data yang terlindungi bergerak melalui lapisan proxy. Tidak setiap platform, transport, atau jenis lalu lintas bisa memakai splice.

6. Tiga mode XHTTP

Diskusi desain XHTTP dari maintainer menjelaskan sistem transport HTTP yang dapat beroperasi di lingkungan HTTP/1.1, HTTP/2, dan HTTP/3:

• packet-up: beberapa request POST ke hulu dengan respons hilir yang terus berlanjut; dirancang untuk kompatibilitas luas dengan perantara.
• stream-up: POST streaming ke hulu dan GET streaming terpisah ke hilir.
• stream-one: satu request streaming dua arah; performa dan kompatibilitasnya bergantung pada perantara.

XHTTP juga dapat memakai padding header, jalur unggah/unduh yang terpisah, dan XMUX. Apakah XHTTP berfungsi melalui CDN tertentu bergantung pada mode, versi HTTP, perilaku reverse proxy, dan konfigurasi penyedia.

7. XMUX, multiplexing umum, dan head-of-line blocking

XMUX mengelola konkurensi XHTTP, jumlah koneksi yang mendasarinya, pemakaian ulang, masa hidup, dan keepalive. Tujuannya bukan mempertahankan tepat satu koneksi selamanya; XMUX menyeimbangkan biaya handshake, konkurensi, dan pola koneksi berumur panjang.

Dokumentasi multiplex sing-box juga mencantumkan smux, yamux, dan h2mux. Multiplexing dapat mengurangi jumlah handshake, tetapi packet loss atau blocking pada satu koneksi TCP yang mendasarinya dapat memengaruhi beberapa stream sekaligus. HTTP/3 menghindari head-of-line blocking antar-stream di tingkat TCP, meski satu stream QUIC tetap bisa menunggu pemulihan packet loss.

8. XUDP adalah opsi encoding UDP

Dokumentasi VLESS sing-box mencantumkan `xudp` sebagai opsi encoding paket, bersama `packetaddr` dan opsi menonaktifkan encoding tambahan. Hal ini mendukung kesimpulan terbatas bahwa XUDP membawa UDP di ekosistem ini; XUDP bukan spesifikasi paket yang lengkap dan berversi.

Perilaku detail mengenai sesi, alamat, batas, dan migrasi perlu diverifikasi terhadap versi core dan kode yang persis. Panduan ini sengaja tidak menyajikan detail framing hasil inferensi sebagai standar universal.

9. Padding, FinalMask, ECH, dan Browser Dialer

• Padding: mengubah karakteristik panjang atau waktu; padding bukan enkripsi.
• FinalMask: dokumentasi konfigurasinya menempatkannya di tahap pemrosesan transport lapisan luar dengan pengaturan terkait TCP, UDP, dan QUIC.
• ECH: dokumentasi TLS sing-box menyertakan konfigurasi Encrypted ClientHello untuk melindungi sebagian ClientHello; ECH tidak menggantikan enkripsi tunnel.
• Browser Dialer: dokumentasi Project X memungkinkan browser sungguhan membangun koneksi TLS dan HTTP, sehingga perilakunya lebih mirip browser asli dengan konsekuensi keterbatasan deployment dan performa.

10. Apa yang bisa dan tidak bisa dilakukan Fallback

Dokumentasi Fallback dari Project X menunjukkan bagaimana SNI, path, atau lalu lintas protokol yang tidak cocok dapat diteruskan ke Nginx, Caddy, atau situs web biasa, sehingga satu titik masuk bisa melayani proxy sekaligus layanan biasa.

Fallback dapat menghindari respons berupa satu galat yang mencolok terhadap setiap upaya autentikasi yang gagal. Fallback bukan kekebalan terhadap active probing; mudah tidaknya dikenali tetap bergantung pada TLS, transport, respons, waktu, dan konfigurasi server.

11. AnyTLS adalah pembanding, bukan komponen VLESS

Dokumen protokol AnyTLS menjelaskan alur TCP → TLS → autentikasi `SHA-256(password)` → sesi → banyak stream. Frame berisi Command, Stream ID, Data Length, dan Data, dengan perintah SYN, PSH, FIN, settings, padding, heartbeat, dan SYNACK versi 2.

Model sesi, banyak stream, padding dinamis, dan pemeriksaan kesehatannya menjadi bahan perbandingan yang berguna. AnyTLS tetap merupakan protokol terpisah; VLESS tidak otomatis mewarisi fitur-fitur ini.

12. Kombinasi umum dan batasannya

• VLESS + REALITY + Vision + RAW: berorientasi pada performa langsung dan tampilan luar bergaya TLS; tidak bergantung pada CDN.
• VLESS + TLS/REALITY + XHTTP: berorientasi pada pengangkutan lewat HTTP, reverse proxy, dan kompatibilitas CDN bersyarat.
• VLESS Encryption + Vision: melindungi payload protokol untuk skenario relay atau keamanan lapisan luar yang tidak standar, tanpa tampilan HTTPS biasa.
• VLESS + TLS + XHTTP + Browser Dialer: memakai stack jaringan browser sungguhan dengan biaya operasional yang lebih tinggi.
• AnyTLS + TLS: desain sesi/stream dan padding tersendiri, bukan stack VLESS.

Tidak ada konfigurasi yang selalu terbaik untuk performa, kompatibilitas, kemudahan pemeliharaan, tampilan, dan keamanan sekaligus. Pemilihan sebaiknya dimulai dari model ancaman, jalur jaringan, batasan CDN atau proxy, platform klien, dan kebutuhan observabilitas.

13. Artinya bagi riset SingLink

Materi publik tentang VLESS dan AnyTLS dapat menjadi masukan bagi riset tentang identitas, pertukaran kunci, sesi, stream, UDP, padding, multiplexing, pemulihan, dan negosiasi versi. Artikel ini tidak menyatakan bahwa SingLink 2.0 berbasis VLESS, REALITY, XHTTP, atau AnyTLS.

SingLinkVPN perlu terus memisahkan perilaku yang sudah dipublikasikan, arah riset, dan implementasi yang belum diungkapkan. Lihat rencana open source SingLinkVPN untuk cakupan yang saat ini sudah dipublikasikan.

14. Pertanyaan yang sering diajukan (FAQ)

Apakah VLESS mengenkripsi lalu lintas dengan sendirinya?

VLESS dengan konfigurasi tradisional `encryption: "none"` tidak melindungi payload protokol dan memerlukan infrastruktur privat tepercaya atau keamanan lapisan luar. Xray-core saat ini dapat mengaktifkan VLESS Encryption, jadi jawabannya bergantung pada implementasi dan konfigurasi.

Bisakah VLESS Encryption menggantikan TLS atau REALITY?

VLESS Encryption tidak setara dengan keduanya. Fitur ini melindungi payload VLESS, tetapi tidak otomatis menyediakan sertifikat HTTPS standar, handshake, atau tampilan situs web.

Apakah XTLS Vision melakukan enkripsi?

Tidak. XTLS Vision terutama menyediakan kontrol alur dan optimasi jalur data.

Bagaimana cara memilih di antara tiga mode XHTTP?

Di antara tiga mode XHTTP, packet-up mengutamakan kompatibilitas, stream-up memisahkan arah streaming, dan stream-one memakai satu stream dua arah. Setiap mode harus diuji pada jalur perantara yang sebenarnya.

Apa bedanya XUDP dengan proxy UDP biasa?

XUDP adalah opsi encoding UDP di ekosistem Xray. Perilaku persisnya bergantung pada core dan versinya, dan tidak boleh disimpulkan dari namanya saja.

Apakah SingLink 2.0 berbasis VLESS atau AnyTLS?

Belum ada cukup bukti publik untuk menyatakan hubungan tersebut. Artikel ini adalah perbandingan teknis, bukan pengungkapan implementasi.

15. Kesimpulan dan tanggal sumber

VLESS modern adalah stack yang dapat disusun: VLESS membawa identitas dan tujuan, VLESS Encryption menambahkan perlindungan opsional di lapisan protokol, TLS atau REALITY menyediakan keamanan lapisan luar, Vision mengoptimalkan alur, XHTTP dan XUDP membawa lalu lintas, sementara multiplexing atau padding mengubah perilaku koneksi lebih jauh.

Tanggal terbit asli: 20 Mei 2026. Sumber teknis ditinjau: 28 Juli 2026. Proyek-proyek ini terus berubah; verifikasi dokumentasi, changelog, dan kompatibilitas versi yang persis sebelum deployment.