2026’da Modern VLESS Yığını

2026 itibarıyla VLESS hafif ve durumsuz bir proxy protokolü olmaya devam ediyor, ancak “VLESS’te şifreleme yoktur” ifadesi artık eksiksiz bir tanım değil. Xray-core artık isteğe bağlı VLESS Encryption sunuyor. Kurulumlar, tehdit modeline göre VLESS’i TLS, REALITY, XTLS Vision, XHTTP ve XUDP ile de birleştirebilir. Bu katmanlar farklı sorunları çözer ve tek bir protokol gibi ele alınmamalıdır.

Kanıt politikası: Bu rehber birincil Project X, Xray-core, sing-box ve AnyTLS kaynaklarını kullanır. GitHub çekme istekleri ve tartışmaları, bakımcıların tasarım ve uygulama kararlarını belgeler; bağımsız güvenlik denetimleri değildir. SingLink’e yapılan atıflar mimari karşılaştırmalardır; SingLinkVPN’in bu projeleri uyguladığı iddiası değildir.

1. Bir bakışta modern VLESS yığını

• VLESS: hafif bir kimlik, komut ve hedef katmanı.
• VLESS Encryption: güncel Xray-core’da isteğe bağlı, yerel bir yük koruma katmanı.
• TLS 1.3 / REALITY: dış aktarım güvenliği, kimlik doğrulama ve ağdaki görünüm.
• XTLS Vision: akış denetimi ve veri yolu optimizasyonu; ayrı bir şifreleme algoritması değildir.
• RAW / XHTTP / gRPC / WebSocket: proxy verisini taşıyan aktarım yöntemleri.
• XUDP: Xray ekosisteminde bir UDP paket kodlama seçeneği.
• XMUX ve diğer MUX sistemleri: alttaki bağlantıları paylaşma yöntemleri.
• Padding / FinalMask / Browser Dialer: uzunluk, zamanlama, dış aktarım davranışı veya tarayıcı ağı için araçlar.

Dolayısıyla bir bağlantı şöyle modellenebilir: uygulama trafiği → VLESS kimliği ve hedefi → protokol veya dış güvenlik katmanı → Vision akış denetimi → RAW veya XHTTP gibi bir aktarım → TCP ya da UDP. Her tasarımda her modül gerekli veya birbiriyle uyumlu değildir.

2. VLESS temel protokolü ne yapar

Project X belgeleri VLESS’i, sistem saatine bağlı olmayan ve kimlik doğrulama için bir UUID ya da eşlenmiş kimlik kullanan hafif, durumsuz bir aktarım protokolü olarak tanımlar. Herkese açık Xray-core kodlama uygulaması sürüm, kullanıcı kimliği, eklentiler, komut, hedef port, adres ve ardından gelen verileri gösterir.

Pratikte temel katman şu sorulara yanıt verir: İstemci kim, hangi bağlantı isteniyor ve nereye gitmeli? Akıllı yönlendirme, düğüm yükü, plan hakları ve otomatik yeniden bağlanma normalde daha üstteki ürün ve kontrol katmanlarına aittir.

Geleneksel yapılandırmalarda genellikle `encryption: "none"` kullanılır. Güncel Project X yönergeleri, karşı uç ve bağlantı güvenilir özel altyapı olmadıkça ya da VLESS Encryption etkinleştirilmedikçe dış aktarım güvenliğini zorunlu tutar.

3. VLESS Encryption neyi değiştirir

VLESS Encryption, 2025’te Xray-core’a birleştirilen isteğe bağlı, yerel bir koruma katmanıdır. Birleştirilen PR #5067 ve güncel yapılandırma belgeleri; `mlkem768x25519plus` el sıkışmasını, `native`, `xorpub` ve `random` görünümlerini, `1rtt` ve `0rtt` oturum davranışını ve değişken dolguyu (padding) anlatır.

Yayımlanan tasarım hedefleri

• Oturum anahtarlarını ML-KEM-768 ve X25519 birleşimiyle türetmek;
• VLESS yüklerini dış TLS gerektirmeden korumak;
• sonraki 0-RTT devam ettirmeleri için bilet (ticket) ve tekrar oynatma riskini azaltmak için kısa ömürlü durum kullanmak;
• sabit uzunluk veya açık anahtar görünümlerini değiştirmek için değişken dolgu ve isteğe bağlı XOR modlarını kullanmak.

Bunlar bakımcıların tasarım ve uygulama iddialarıdır. Her özelliği kapsayan bağımsız bir kriptografik denetim bulamadık; bu nedenle bu rehber tasarımı “tekrar oynatmaya karşı tamamen korumalı” veya “kesinlikle kuantuma dayanıklı” olarak nitelendirmez.

Neyin yerini kendiliğinden almaz

VLESS Encryption protokol yükünü korur. Sıradan bir HTTPS sertifika zinciri, web sitesi el sıkışması, HTTP/2 veya HTTP/3 davranışı ya da CDN uyumluluğunu kendiliğinden oluşturmaz. Bu nedenle TLS veya REALITY’nin eşdeğeri değildir.

4. TLS 1.3 ve REALITY

TLS standartlaştırılmış sertifika doğrulaması, anahtar değişimi, bütünlük ve aktarım şifrelemesi sağlar. RAW, XHTTP, gRPC veya WebSocket ile birlikte kullanılabilir; anlaşılan sürüm, ALPN ve sertifika denetimleri yine de yapılandırmaya ve karşı ucun desteğine bağlıdır.

Project X REALITY belgeleri, target, serverNames, X25519 anahtarları ve shortId ayarlarına ek olarak isteğe bağlı ML-DSA-65 doğrulama verisi içeren, değiştirilmiş TLS tarzı bir güvenlik katmanını anlatır. REALITY; RAW, XHTTP ve gRPC ile birlikte kullanılabilir.

REALITY, “sertifikasız TLS” diye basitleştirilmemelidir. Davranışı, istemci yetkilendirmesini harici bir el sıkışma görünümüyle birleştirir. Sonuçlar yine de hedefe, istemci parmak izine, aktarım yöntemine ve kurulum kalitesine bağlıdır; her sınıflandırıcıya karşı görünmezliği garanti edemez.

5. XTLS Vision bir şifreleme protokolü değildir

VLESS/Vision belgeleri Vision’ı akış denetimi olarak sınıflandırır. Desteklenen koşullarda iç TLS trafiğini tanıyabilir ve fazladan şifrelemeyi veya kopyalamayı azaltabilir. Uyumlu Linux ve TCP yollarında çekirdek, verinin doğrudan çekirdek (kernel) tarafından aktarılması için `splice` deneyebilir.

Doğru iş bölümü şöyledir: güvenliği TLS, REALITY veya VLESS Encryption sağlar; Vision ise korunan verinin proxy katmanında nasıl ilerlediğini optimize eder. Her platform, aktarım yöntemi veya trafik türü splice kullanamaz.

6. Üç XHTTP modu

Bakımcıların XHTTP tasarım tartışması, HTTP/1.1, HTTP/2 ve HTTP/3 ortamlarında çalışabilen bir HTTP aktarım sistemini anlatır:

• packet-up: süren bir aşağı akış yanıtıyla birlikte birden fazla yukarı akış POST isteği; aracı sunucularla geniş uyumluluk için tasarlanmıştır.
• stream-up: akış hâlinde bir yukarı akış POST ve ayrı, akış hâlinde bir aşağı akış GET.
• stream-one: tek bir çift yönlü akış isteği; performans ve uyumluluk aracı sunuculara bağlıdır.

XHTTP ayrıca başlık dolgusu, ayrılmış yükleme/indirme yolları ve XMUX kullanabilir. Belirli bir CDN üzerinden çalışıp çalışmayacağı; moda, HTTP sürümüne, ters proxy davranışına ve sağlayıcı yapılandırmasına bağlıdır.

7. XMUX, genel çoğullama ve satır başı engellemesi

XMUX; XHTTP eşzamanlılığını, alttaki bağlantı sayılarını, yeniden kullanımı, ömrü ve keepalive’ı yönetir. Amacı tam olarak tek bir bağlantıyı sonsuza dek açık tutmak değildir; el sıkışma maliyetini, eşzamanlılığı ve uzun ömürlü bağlantı kalıplarını dengeler.

sing-box çoğullama belgeleri ayrıca smux, yamux ve h2mux’u listeler. Çoğullama el sıkışmalarını azaltabilir, ancak alttaki bir TCP bağlantısındaki kayıp veya engelleme birkaç akışı etkileyebilir. HTTP/3, TCP düzeyindeki akışlar arası satır başı engellemesini (head-of-line blocking) önler; yine de tek bir QUIC akışı kayıp kurtarmayı beklemek zorunda kalabilir.

8. XUDP bir UDP kodlama seçeneğidir

sing-box VLESS belgeleri `xudp`’yi, `packetaddr` ve ek kodlamayı devre dışı bırakma seçenekleriyle birlikte bir paket kodlama seçeneği olarak listeler. Bu, XUDP’nin bu ekosistemde UDP taşıdığı yönündeki sınırlı sonucu destekler; eksiksiz, sürümlenmiş bir paket spesifikasyonu değildir.

Ayrıntılı oturum, adres, sınır ve geçiş davranışları tam çekirdek sürümüne ve koda göre doğrulanmalıdır. Bu rehber, çıkarıma dayalı çerçeveleme ayrıntılarını evrensel bir standart gibi sunmaktan bilinçli olarak kaçınır.

9. Padding, FinalMask, ECH ve Browser Dialer

• Padding: uzunluk veya zamanlama özelliklerini değiştirir; şifreleme değildir.
• FinalMask: yapılandırma belgeleri onu TCP, UDP ve QUIC ile ilgili ayarlarla birlikte dış aktarım işleme aşamasına yerleştirir.
• ECH: sing-box TLS belgeleri, ClientHello’nun bir kısmını korumak için Encrypted ClientHello yapılandırmasını içerir; ECH tünel şifrelemesinin yerini almaz.
• Browser Dialer: Project X belgelerine göre gerçek bir tarayıcının TLS ve HTTP bağlantılarını kurmasını sağlar; daha gerçekçi tarayıcı davranışı kazandırır, ancak kurulum ve performans kısıtlamaları getirir.

10. Fallback’in yapabildikleri ve yapamadıkları

Project X Fallback belgeleri, eşleşmeyen SNI, yol veya protokol trafiğinin Nginx’e, Caddy’ye ya da normal bir web sitesine nasıl yönlendirilebileceğini gösterir; böylece tek bir giriş noktası hem proxy hem sıradan hizmetleri barındırabilir.

Fallback, her başarısız kimlik doğrulama denemesine tek ve belirgin bir hatayla yanıt vermekten kaçınmayı sağlayabilir. Aktif yoklamaya (active probing) karşı bağışıklık değildir; tanınabilirlik yine TLS’e, aktarım yöntemine, yanıtlara, zamanlamaya ve sunucu yapılandırmasına bağlıdır.

11. AnyTLS bir VLESS bileşeni değil, bir karşılaştırma noktasıdır

AnyTLS protokol belgesi şu akışı anlatır: TCP → TLS → `SHA-256(password)` kimlik doğrulaması → bir oturum → birden fazla akış. Çerçeveler Command, Stream ID, Data Length ve Data alanlarını içerir; SYN, PSH, FIN, settings, padding, heartbeat ve 2. sürüm SYNACK komutları bulunur.

Oturum modeli, çoklu akışları, dinamik dolgusu ve sağlık kontrolleri onu faydalı bir karşılaştırma noktası yapar. AnyTLS ayrı bir protokol olmaya devam eder; VLESS bu özellikleri kendiliğinden devralmaz.

12. Yaygın birleşimler ve sınırları

• VLESS + REALITY + Vision + RAW: doğrudan performansa ve TLS tarzı bir dış görünüme yöneliktir; CDN bağımlılığı yoktur.
• VLESS + TLS/REALITY + XHTTP: HTTP üzerinden taşımaya, ters proxy’lere ve koşullu CDN uyumluluğuna yöneliktir.
• VLESS Encryption + Vision: aktarma (relay) veya standart dışı dış güvenlik senaryolarında, sıradan bir HTTPS görünümü olmadan protokol yükünü korur.
• VLESS + TLS + XHTTP + Browser Dialer: gerçek bir tarayıcı ağ yığını kullanır; işletim maliyeti daha yüksektir.
• AnyTLS + TLS: ayrı bir oturum/akış ve dolgu tasarımıdır; bir VLESS yığını değildir.

Hiçbir yapılandırma performans, uyumluluk, bakım kolaylığı, görünüm ve güvenlik açısından aynı anda her zaman en iyisi değildir. Seçim; bir tehdit modeli, ağ yolu, CDN veya proxy kısıtlamaları, istemci platformları ve gözlemlenebilirlik gereksinimleriyle başlamalıdır.

13. Bunun SingLink araştırmaları için anlamı

Herkese açık VLESS ve AnyTLS materyalleri kimlik, anahtar değişimi, oturumlar, akışlar, UDP, dolgu, çoğullama, kurtarma ve sürüm anlaşması üzerine yapılan araştırmalara ışık tutabilir. Bu makale, SingLink 2.0’ın VLESS, REALITY, XHTTP veya AnyTLS tabanlı olduğunu ortaya koymaz.

SingLinkVPN, yayımlanmış davranışı, araştırma yönlerini ve açıklanmamış uygulamayı birbirinden ayırmayı sürdürmelidir. Şu anda yayımlanan kapsam için SingLinkVPN açık kaynak planına bakın.

14. Sıkça sorulan sorular (FAQ)

VLESS trafiği kendi başına şifreler mi?

Geleneksel `encryption: "none"` ayarıyla VLESS protokol yükünü korumaz ve güvenilir özel altyapı ya da dış güvenlik katmanı gerektirir. Güncel Xray-core VLESS Encryption’ı etkinleştirebildiği için yanıt, uygulamaya ve yapılandırmaya bağlıdır.

VLESS Encryption, TLS veya REALITY’nin yerini alabilir mi?

VLESS Encryption, TLS veya REALITY’nin eşdeğeri değildir. VLESS yüklerini korur, ancak standart bir HTTPS sertifikası, el sıkışması veya web sitesi görünümünü kendiliğinden sağlamaz.

XTLS Vision şifreleme yapar mı?

Hayır, XTLS Vision şifreleme yapmaz. Vision esas olarak akış denetimi ve veri yolu optimizasyonu sağlar.

Üç XHTTP modu arasında nasıl seçim yapılmalı?

packet-up uyumluluğu öne çıkarır, stream-up akış yönlerini ayırır, stream-one ise tek bir çift yönlü akış kullanır. Her biri, gerçek aracı sunucu yolu üzerinde test edilmelidir.

XUDP, genel bir UDP proxy’sinden nasıl farklıdır?

XUDP, Xray ekosisteminde bir UDP kodlama seçeneğidir. Tam davranışı çekirdeğe ve sürüme bağlıdır; yalnızca adından yola çıkılarak tahmin edilmemelidir.

SingLink 2.0, VLESS veya AnyTLS tabanlı mı?

Bu ilişkiyi kurmaya yetecek kamuya açık kanıt bulunmuyor. Bu makale bir uygulama açıklaması değil, teknik bir karşılaştırmadır.

15. Sonuç ve kaynak tarihi

Modern VLESS, birleştirilebilir bir yığındır: VLESS kimliği ve hedefi taşır, VLESS Encryption isteğe bağlı protokol katmanı koruması ekler, TLS veya REALITY dış güvenliği sağlar, Vision akışı optimize eder, XHTTP ve XUDP trafiği taşır; çoğullama veya dolgu ise bağlantı davranışını ayrıca değiştirir.

İlk yayın tarihi: 20 Mayıs 2026. Teknik kaynakların incelenme tarihi: 28 Temmuz 2026. Bu projeler değişmeye devam ediyor; kurulumdan önce kullandığınız tam sürümün belgelerini, değişiklik günlüğünü ve uyumluluğunu doğrulayın.