Timbunan VLESS Moden pada 2026

Setakat 2026, VLESS masih merupakan protokol proksi yang ringan dan tanpa keadaan (stateless), tetapi “VLESS tiada penyulitan” bukan lagi gambaran yang lengkap. Xray-core kini menawarkan VLESS Encryption sebagai pilihan. Penggunaan sebenar juga boleh menggabungkan VLESS dengan TLS, REALITY, XTLS Vision, XHTTP dan XUDP mengikut model ancaman masing-masing. Lapisan-lapisan ini menyelesaikan masalah yang berbeza dan tidak patut dianggap sebagai satu protokol.

Dasar bukti: Panduan ini menggunakan sumber utama Project X, Xray-core, sing-box dan AnyTLS. Pull request dan perbincangan GitHub mendokumentasikan reka bentuk dan pelaksanaan oleh penyelenggara; ia bukan audit keselamatan bebas. Rujukan kepada SingLink ialah perbandingan seni bina, bukan dakwaan bahawa SingLinkVPN melaksanakan projek-projek ini.

1. Ringkasan timbunan VLESS moden

• VLESS: lapisan ringan untuk identiti, arahan dan destinasi.
• VLESS Encryption: lapisan perlindungan muatan asli pilihan dalam Xray-core semasa.
• TLS 1.3 / REALITY: keselamatan pengangkutan luar, pengesahan dan rupa trafik di rangkaian.
• XTLS Vision: kawalan aliran dan pengoptimuman laluan data, bukan sifer yang berasingan.
• RAW / XHTTP / gRPC / WebSocket: pengangkutan yang membawa data proksi.
• XUDP: pilihan pengekodan paket UDP dalam ekosistem Xray.
• XMUX dan sistem MUX lain: cara berkongsi sambungan asas.
• Padding / FinalMask / Browser Dialer: alat untuk panjang, pemasaan, tingkah laku pengangkutan luar atau rangkaian pelayar.

Oleh itu, satu sambungan boleh dimodelkan sebagai trafik aplikasi → identiti dan destinasi VLESS → keselamatan protokol atau keselamatan luar → kawalan aliran Vision → pengangkutan seperti RAW atau XHTTP → TCP atau UDP. Bukan setiap modul diperlukan atau serasi dalam setiap reka bentuk.

2. Apa yang dilakukan oleh protokol asas VLESS

Dokumentasi Project X mentakrifkan VLESS sebagai protokol pengangkutan yang ringan dan tanpa keadaan, tidak bergantung pada masa sistem, dan menggunakan UUID atau ID yang dipetakan untuk pengesahan. Pelaksanaan pengekodan Xray-core yang terbuka kepada umum menunjukkan versi, ID pengguna, tambahan (addons), arahan, port destinasi, alamat dan data yang menyusul.

Secara praktikal, lapisan asas ini menjawab: Siapakah klien, sambungan apakah yang diminta, dan ke manakah ia patut pergi? Penghalaan pintar, beban nod, hak pelan dan sambung semula automatik biasanya terletak pada lapisan produk dan kawalan yang lebih tinggi.

Konfigurasi tradisional biasanya menggunakan `encryption: "none"`. Panduan Project X semasa mewajibkan keselamatan pengangkutan luar, kecuali jika rakan sambungan dan pautannya ialah infrastruktur persendirian yang dipercayai, atau VLESS Encryption diaktifkan.

3. Apa yang diubah oleh VLESS Encryption

VLESS Encryption ialah lapisan perlindungan asli pilihan yang digabungkan ke dalam Xray-core pada 2025. PR #5067 yang telah digabungkan dan dokumentasi konfigurasi semasa menerangkan jabat tangan `mlkem768x25519plus`, rupa `native`, `xorpub` dan `random`, tingkah laku sesi `1rtt` dan `0rtt`, serta padding berubah-ubah.

Matlamat reka bentuk yang diterbitkan

• Menerbitkan kunci sesi melalui gabungan ML-KEM-768 dan X25519;
• melindungi muatan VLESS tanpa memerlukan TLS luar;
• menggunakan tiket untuk penyambungan semula 0-RTT kemudian dan keadaan jangka pendek untuk mengurangkan risiko serangan main semula;
• menggunakan padding berubah-ubah dan mod XOR pilihan untuk mengubah rupa panjang tetap atau kunci awam.

Ini ialah dakwaan reka bentuk dan pelaksanaan oleh penyelenggara. Kami tidak menemui audit kriptografi bebas yang merangkumi setiap sifat, jadi panduan ini tidak menyifatkan reka bentuk itu sebagai “kalis main semula” atau “selamat kuantum sepenuhnya.”

Apa yang tidak digantikannya secara automatik

VLESS Encryption melindungi muatan protokol. Ia tidak secara automatik mewujudkan rantaian sijil HTTPS biasa, jabat tangan laman web, tingkah laku HTTP/2 atau HTTP/3, atau keserasian CDN. Oleh itu, ia tidak setara dengan TLS atau REALITY.

4. TLS 1.3 dan REALITY

TLS menyediakan pengesahan sijil yang standard, pertukaran kunci, integriti dan penyulitan pengangkutan. Ia boleh digunakan bersama RAW, XHTTP, gRPC atau WebSocket; versi yang dirundingkan, ALPN dan semakan sijil masih bergantung pada konfigurasi dan sokongan rakan sambungan.

Dokumentasi REALITY Project X menerangkan lapisan keselamatan gaya TLS yang diubah suai dengan tetapan target, serverNames, kunci X25519 dan shortId, serta data pengesahan ML-DSA-65 pilihan. REALITY boleh digunakan bersama RAW, XHTTP dan gRPC.

REALITY tidak patut diringkaskan sebagai “TLS tanpa sijil.” Tingkah lakunya menggabungkan kebenaran klien dengan rupa jabat tangan luaran. Hasilnya masih bergantung pada sasaran, cap jari klien, pengangkutan dan kualiti penggunaan; ia tidak dapat menjamin tidak dikesan oleh setiap pengelas.

5. XTLS Vision bukan protokol penyulitan

Dokumentasi VLESS/Vision mengklasifikasikan Vision sebagai kawalan aliran. Dalam keadaan yang disokong, ia boleh mengenal pasti trafik TLS dalaman dan mengurangkan penyulitan atau penyalinan tambahan. Pada laluan Linux dan TCP yang serasi, teras boleh mencuba `splice` supaya kernel memindahkan data secara terus.

Pembahagian yang tepat ialah: TLS, REALITY atau VLESS Encryption menyediakan keselamatan; Vision mengoptimumkan cara data yang dilindungi bergerak melalui lapisan proksi. Bukan setiap platform, pengangkutan atau jenis trafik boleh menggunakan splice.

6. Tiga mod XHTTP

Perbincangan reka bentuk XHTTP oleh penyelenggara menerangkan sistem pengangkutan HTTP yang boleh beroperasi dalam persekitaran HTTP/1.1, HTTP/2 dan HTTP/3:

• packet-up: beberapa permintaan POST huluan dengan satu respons hiliran yang berterusan; direka untuk keserasian luas dengan perantara.
• stream-up: satu POST huluan secara penstriman dan satu GET hiliran penstriman yang berasingan.
• stream-one: satu permintaan penstriman dua hala; prestasi dan keserasian bergantung pada perantara.

XHTTP juga boleh menggunakan padding pengepala, laluan muat naik/muat turun yang berasingan dan XMUX. Sama ada ia berfungsi melalui CDN tertentu bergantung pada mod, versi HTTP, tingkah laku proksi songsang dan konfigurasi penyedia.

7. XMUX, pemultipleksan umum dan sekatan kepala barisan

XMUX mengurus keserentakan XHTTP, bilangan sambungan asas, penggunaan semula, jangka hayat dan keepalive. Matlamatnya bukan untuk mengekalkan tepat satu sambungan selama-lamanya; ia mengimbangi kos jabat tangan, keserentakan dan corak sambungan jangka panjang.

Dokumentasi pemultipleksan sing-box juga menyenaraikan smux, yamux dan h2mux. Pemultipleksan boleh mengurangkan jabat tangan, tetapi kehilangan paket atau sekatan pada satu sambungan TCP asas boleh menjejaskan beberapa strim. HTTP/3 mengelakkan sekatan kepala barisan rentas strim di peringkat TCP, namun satu strim QUIC individu masih mungkin menunggu pemulihan kehilangan paket.

8. XUDP ialah pilihan pengekodan UDP

Dokumentasi VLESS sing-box menyenaraikan `xudp` sebagai pilihan pengekodan paket, bersama `packetaddr` dan pilihan untuk melumpuhkan pengekodan tambahan. Ini menyokong kesimpulan terhad bahawa XUDP membawa UDP dalam ekosistem ini; ia bukan spesifikasi paket yang lengkap dan berversi.

Butiran tingkah laku sesi, alamat, sempadan dan migrasi patut disahkan berdasarkan versi teras dan kod yang tepat. Panduan ini sengaja tidak mempersembahkan butiran pembingkaian yang disimpulkan sebagai standard sejagat.

9. Padding, FinalMask, ECH dan Browser Dialer

• Padding: mengubah ciri panjang atau pemasaan; ia bukan penyulitan.
• FinalMask: dokumentasi konfigurasinya meletakkannya pada peringkat pemprosesan pengangkutan luar dengan tetapan berkaitan TCP, UDP dan QUIC.
• ECH: dokumentasi TLS sing-box merangkumi konfigurasi Encrypted ClientHello untuk melindungi sebahagian ClientHello; ECH tidak menggantikan penyulitan terowong.
• Browser Dialer: dokumentasi Project X membolehkan pelayar sebenar mewujudkan sambungan TLS dan HTTP, memberikan tingkah laku pelayar yang lebih tulen dengan kekangan penggunaan dan prestasi.

10. Apa yang boleh dan tidak boleh dilakukan oleh Fallback

Dokumentasi Fallback Project X menunjukkan cara SNI, laluan atau trafik protokol yang tidak sepadan boleh dimajukan ke Nginx, Caddy atau laman web biasa, membolehkan satu titik masuk menempatkan perkhidmatan proksi dan perkhidmatan biasa.

Fallback boleh mengelakkan setiap percubaan pengesahan yang gagal daripada dibalas dengan satu ralat yang jelas. Ia bukan kekebalan daripada penyiasatan aktif (active probing); kebolehcaman masih bergantung pada TLS, pengangkutan, respons, pemasaan dan konfigurasi pelayan.

11. AnyTLS ialah perbandingan, bukan komponen VLESS

Dokumen protokol AnyTLS menerangkan TCP → TLS → pengesahan `SHA-256(password)` → sesi → berbilang strim. Bingkai mengandungi Command, Stream ID, Data Length dan Data, dengan arahan SYN, PSH, FIN, settings, padding, heartbeat dan SYNACK versi 2.

Model sesi, berbilang strim, padding dinamik dan semakan kesihatannya menjadikannya perbandingan yang berguna. AnyTLS kekal sebagai protokol yang berasingan; VLESS tidak mewarisi ciri-ciri ini secara automatik.

12. Gabungan lazim dan batasannya

• VLESS + REALITY + Vision + RAW: berorientasikan prestasi langsung dan rupa luar gaya TLS; tidak bergantung pada CDN.
• VLESS + TLS/REALITY + XHTTP: berorientasikan pembawaan HTTP, proksi songsang dan keserasian CDN bersyarat.
• VLESS Encryption + Vision: melindungi muatan protokol untuk senario geganti atau keselamatan luar bukan standard, tanpa rupa HTTPS biasa.
• VLESS + TLS + XHTTP + Browser Dialer: menggunakan timbunan rangkaian pelayar sebenar dengan kos operasi yang lebih tinggi.
• AnyTLS + TLS: reka bentuk sesi/strim dan padding yang berasingan, bukan timbunan VLESS.

Tiada konfigurasi yang sentiasa terbaik dari segi prestasi, keserasian, kebolehselenggaraan, rupa dan keselamatan sekali gus. Pemilihan patut bermula dengan model ancaman, laluan rangkaian, kekangan CDN atau proksi, platform klien dan keperluan kebolehcerapan.

13. Maksudnya bagi penyelidikan SingLink

Bahan VLESS dan AnyTLS yang terbuka kepada umum boleh menjadi rujukan bagi penyelidikan tentang identiti, pertukaran kunci, sesi, strim, UDP, padding, pemultipleksan, pemulihan dan rundingan versi. Artikel ini tidak membuktikan bahawa SingLink 2.0 berasaskan VLESS, REALITY, XHTTP atau AnyTLS.

SingLinkVPN patut terus mengasingkan tingkah laku yang telah diterbitkan, hala tuju penyelidikan dan pelaksanaan yang tidak didedahkan. Lihat pelan sumber terbuka SingLinkVPN untuk skop yang telah diterbitkan setakat ini.

14. Soalan lazim (FAQ)

Adakah VLESS menyulitkan trafik dengan sendirinya?

VLESS dengan tetapan tradisional `encryption: "none"` tidak melindungi muatan protokol dan memerlukan infrastruktur persendirian yang dipercayai atau keselamatan luar. Xray-core semasa boleh mengaktifkan VLESS Encryption, jadi jawapannya bergantung pada pelaksanaan dan konfigurasi.

Bolehkah VLESS Encryption menggantikan TLS atau REALITY?

VLESS Encryption tidak setara dengan TLS atau REALITY. Ia melindungi muatan VLESS tetapi tidak secara automatik menyediakan sijil HTTPS standard, jabat tangan atau rupa laman web.

Adakah XTLS Vision melakukan penyulitan?

Tidak. XTLS Vision terutamanya menyediakan kawalan aliran dan pengoptimuman laluan data.

Bagaimanakah tiga mod XHTTP patut dipilih?

Dalam XHTTP, packet-up mengutamakan keserasian, stream-up mengasingkan arah penstriman, dan stream-one menggunakan satu strim dua hala. Setiap mod mesti diuji pada laluan perantara yang sebenar.

Apakah perbezaan XUDP dengan proksi UDP generik?

XUDP ialah pilihan pengekodan UDP dalam ekosistem Xray. Tingkah laku tepatnya bergantung pada teras dan versi, dan tidak patut disimpulkan daripada namanya sahaja.

Adakah SingLink 2.0 berasaskan VLESS atau AnyTLS?

Tiada bukti umum yang mencukupi untuk mengesahkan bahawa protokol SingLink berasaskan VLESS atau AnyTLS. Artikel ini ialah perbandingan teknikal, bukan pendedahan pelaksanaan.

15. Kesimpulan dan tarikh sumber

VLESS moden ialah timbunan yang boleh digubah: VLESS membawa identiti dan destinasi, VLESS Encryption menambah perlindungan pilihan di lapisan protokol, TLS atau REALITY menyediakan keselamatan luar, Vision mengoptimumkan aliran, XHTTP dan XUDP membawa trafik, manakala pemultipleksan atau padding terus mengubah tingkah laku sambungan.

Tarikh penerbitan asal: 20 Mei 2026. Sumber teknikal disemak: 28 Julai 2026. Projek-projek ini terus berubah; sahkan dokumentasi, log perubahan dan keserasian versi yang tepat sebelum penggunaan.