2026 में आधुनिक VLESS स्टैक
Contents
2026 तक VLESS एक हल्का, स्टेटलेस प्रॉक्सी प्रोटोकॉल बना हुआ है, लेकिन “VLESS में एन्क्रिप्शन नहीं है” अब पूरा वर्णन नहीं है। Xray-core अब वैकल्पिक VLESS Encryption देता है। डिप्लॉयमेंट अपने थ्रेट मॉडल के अनुसार VLESS को TLS, REALITY, XTLS Vision, XHTTP और XUDP के साथ भी जोड़ सकते हैं। ये लेयर्स अलग-अलग समस्याएं हल करती हैं और इन्हें एक ही प्रोटोकॉल में समेटकर नहीं देखना चाहिए।
सबूत नीति: यह गाइड Project X, Xray-core, sing-box और AnyTLS के प्राथमिक स्रोतों का इस्तेमाल करती है। GitHub पुल रिक्वेस्ट और चर्चाएं मेंटेनर के डिज़ाइन और इम्प्लीमेंटेशन को दर्ज करती हैं; वे स्वतंत्र सुरक्षा ऑडिट नहीं हैं। SingLink के उल्लेख आर्किटेक्चर की तुलना हैं, यह दावा नहीं कि SingLinkVPN इन प्रोजेक्ट्स को लागू करता है।
1. आधुनिक VLESS स्टैक एक नज़र में
- VLESS: पहचान, कमांड और गंतव्य की एक हल्की लेयर।
- VLESS Encryption: मौजूदा Xray-core में पेलोड सुरक्षा की एक वैकल्पिक नेटिव लेयर।
- TLS 1.3 / REALITY: बाहरी ट्रांसपोर्ट सुरक्षा, ऑथेंटिकेशन और नेटवर्क पर दिखावट।
- XTLS Vision: फ़्लो कंट्रोल और डेटा-पथ ऑप्टिमाइज़ेशन, कोई अलग सिफ़र नहीं।
- RAW / XHTTP / gRPC / WebSocket: ट्रांसपोर्ट, जो प्रॉक्सी डेटा ले जाते हैं।
- XUDP: Xray इकोसिस्टम में UDP पैकेट एन्कोडिंग का एक विकल्प।
- XMUX और दूसरे MUX सिस्टम: नीचे के कनेक्शन साझा करने के तरीके।
- Padding / FinalMask / Browser Dialer: लंबाई, टाइमिंग, बाहरी ट्रांसपोर्ट व्यवहार या ब्राउज़र नेटवर्किंग के लिए टूल।
इसलिए एक कनेक्शन को इस तरह मॉडल किया जा सकता है: ऐप्लिकेशन ट्रैफ़िक → VLESS पहचान और गंतव्य → प्रोटोकॉल या बाहरी सुरक्षा → Vision फ़्लो कंट्रोल → RAW या XHTTP जैसा ट्रांसपोर्ट → TCP या UDP। हर डिज़ाइन में हर मॉड्यूल की ज़रूरत नहीं होती, और हर मॉड्यूल हर डिज़ाइन के साथ कम्पैटिबल भी नहीं होता।
2. VLESS का बेस प्रोटोकॉल क्या करता है
Project X दस्तावेज़ VLESS को एक हल्के, स्टेटलेस ट्रांसपोर्ट प्रोटोकॉल के रूप में परिभाषित करते हैं, जो सिस्टम टाइम पर निर्भर नहीं करता और ऑथेंटिकेशन के लिए UUID या मैप की गई ID इस्तेमाल करता है। सार्वजनिक Xray-core एन्कोडिंग इम्प्लीमेंटेशन में वर्ज़न, यूज़र ID, ऐडऑन, कमांड, गंतव्य पोर्ट, पता और उसके बाद का डेटा दिखता है।
व्यवहार में बेस लेयर इन सवालों का जवाब देती है: क्लाइंट कौन है, कौन-सा कनेक्शन मांगा गया है, और उसे कहां जाना है? स्मार्ट रूटिंग, नोड लोड, प्लान के अधिकार और अपने-आप दोबारा कनेक्ट होना आम तौर पर ऊपर की प्रोडक्ट और कंट्रोल लेयर्स का काम है।
पारंपरिक कॉन्फ़िगरेशन में आम तौर पर `encryption: "none"` इस्तेमाल होता है। Project X का मौजूदा मार्गदर्शन बाहरी ट्रांसपोर्ट सुरक्षा को ज़रूरी मानता है, जब तक कि पीयर और लिंक भरोसेमंद निजी इन्फ्रास्ट्रक्चर न हों या VLESS Encryption चालू न हो।
3. VLESS Encryption क्या बदलता है
VLESS Encryption एक वैकल्पिक नेटिव सुरक्षा लेयर है, जिसे 2025 में Xray-core में मर्ज किया गया। मर्ज हुआ PR #5067 और मौजूदा कॉन्फ़िगरेशन दस्तावेज़ `mlkem768x25519plus` हैंडशेक, `native`, `xorpub` और `random` दिखावट, `1rtt` और `0rtt` सत्र व्यवहार, और वेरिएबल पैडिंग का वर्णन करते हैं।
प्रकाशित डिज़ाइन लक्ष्य
- ML-KEM-768 और X25519 के संयोजन से सत्र कुंजियां निकालना;
- बाहरी TLS के बिना VLESS पेलोड की सुरक्षा करना;
- बाद में 0-RTT दोबारा शुरू करने के लिए टिकट और रीप्ले जोखिम घटाने के लिए कम समय तक रहने वाली स्टेट इस्तेमाल करना;
- तय लंबाई या पब्लिक-की की दिखावट बदलने के लिए वेरिएबल पैडिंग और वैकल्पिक XOR मोड इस्तेमाल करना।
ये मेंटेनर के डिज़ाइन और इम्प्लीमेंटेशन के दावे हैं। हमें ऐसा कोई स्वतंत्र क्रिप्टोग्राफ़िक ऑडिट नहीं मिला जो हर गुण को कवर करता हो, इसलिए यह गाइड इस डिज़ाइन को “रीप्ले-प्रूफ़” या “पूरी तरह क्वांटम-सुरक्षित” नहीं कहती।
यह किन चीज़ों की जगह अपने-आप नहीं ले लेता
VLESS Encryption प्रोटोकॉल पेलोड की सुरक्षा करता है। यह अपने-आप कोई सामान्य HTTPS सर्टिफ़िकेट चेन, वेबसाइट हैंडशेक, HTTP/2 या HTTP/3 व्यवहार, या CDN कम्पैटिबिलिटी नहीं बनाता। इसलिए यह TLS या REALITY के बराबर नहीं है।
4. TLS 1.3 और REALITY
TLS मानक सर्टिफ़िकेट वैलिडेशन, की एक्सचेंज, इंटीग्रिटी और ट्रांसपोर्ट एन्क्रिप्शन देता है। यह RAW, XHTTP, gRPC या WebSocket के साथ चल सकता है; तय हुआ वर्ज़न, ALPN और सर्टिफ़िकेट जांच फिर भी कॉन्फ़िगरेशन और पीयर के सपोर्ट पर निर्भर करते हैं।
Project X REALITY दस्तावेज़ एक संशोधित TLS-जैसी सुरक्षा लेयर का वर्णन करते हैं, जिसमें target, serverNames, X25519 कुंजियां और shortId सेटिंग्स होती हैं, साथ में वैकल्पिक ML-DSA-65 वेरिफ़िकेशन डेटा भी। REALITY, RAW, XHTTP और gRPC के साथ चल सकता है।
REALITY को “बिना सर्टिफ़िकेट वाला TLS” कहकर छोटा नहीं करना चाहिए। इसका व्यवहार क्लाइंट ऑथराइज़ेशन को बाहरी हैंडशेक दिखावट के साथ जोड़ता है। नतीजे फिर भी target, क्लाइंट फ़िंगरप्रिंट, ट्रांसपोर्ट और डिप्लॉयमेंट की गुणवत्ता पर निर्भर करते हैं; यह हर क्लासिफ़ायर से अदृश्य रहने की गारंटी नहीं दे सकता।
5. XTLS Vision एन्क्रिप्शन प्रोटोकॉल नहीं है
VLESS/Vision दस्तावेज़ Vision को फ़्लो कंट्रोल की श्रेणी में रखते हैं। सपोर्ट वाली स्थितियों में यह अंदर के TLS ट्रैफ़िक को पहचानकर अतिरिक्त एन्क्रिप्शन या कॉपी कम कर सकता है। कम्पैटिबल Linux और TCP पथों पर कोर `splice` आज़मा सकता है, ताकि कर्नेल डेटा सीधे ट्रांसफ़र करे।
सही बंटवारा यह है: सुरक्षा TLS, REALITY या VLESS Encryption देते हैं; Vision यह ऑप्टिमाइज़ करता है कि सुरक्षित डेटा प्रॉक्सी लेयर से कैसे गुज़रे। हर प्लेटफ़ॉर्म, ट्रांसपोर्ट या ट्रैफ़िक प्रकार splice इस्तेमाल नहीं कर सकता।
6. XHTTP के तीन मोड
मेंटेनर की XHTTP डिज़ाइन चर्चा एक HTTP ट्रांसपोर्ट सिस्टम का वर्णन करती है, जो HTTP/1.1, HTTP/2 और HTTP/3 वातावरण में काम कर सकता है:
- packet-up: कई अपस्ट्रीम POST रिक्वेस्ट और एक लगातार चलने वाला डाउनस्ट्रीम रिस्पॉन्स; बीच के ज़्यादातर सर्वरों और प्रॉक्सी के साथ कम्पैटिबिलिटी के लिए बना।
- stream-up: एक स्ट्रीमिंग अपस्ट्रीम POST और एक अलग स्ट्रीमिंग डाउनस्ट्रीम GET।
- stream-one: एक दोतरफ़ा स्ट्रीमिंग रिक्वेस्ट; परफ़ॉर्मेंस और कम्पैटिबिलिटी बीच के नोड्स पर निर्भर करती है।
XHTTP हेडर पैडिंग, अलग अपलोड/डाउनलोड पथ और XMUX भी इस्तेमाल कर सकता है। यह किसी खास CDN से होकर काम करेगा या नहीं, यह मोड, HTTP वर्ज़न, रिवर्स-प्रॉक्सी व्यवहार और प्रोवाइडर के कॉन्फ़िगरेशन पर निर्भर करता है।
7. XMUX, सामान्य मल्टीप्लेक्सिंग और हेड-ऑफ़-लाइन ब्लॉकिंग
XMUX, XHTTP की कॉन्करेंसी, नीचे के कनेक्शनों की संख्या, दोबारा इस्तेमाल, जीवनकाल और keepalive संभालता है। इसका लक्ष्य हमेशा ठीक एक कनेक्शन पकड़े रखना नहीं है; यह हैंडशेक की लागत, कॉन्करेंसी और लंबे समय तक चलने वाले कनेक्शन पैटर्न के बीच संतुलन बनाता है।
sing-box मल्टीप्लेक्स दस्तावेज़ smux, yamux और h2mux भी सूचीबद्ध करते हैं। मल्टीप्लेक्सिंग हैंडशेक कम कर सकती है, लेकिन नीचे के किसी TCP कनेक्शन पर पैकेट लॉस या रुकावट कई स्ट्रीम्स पर असर डाल सकती है। HTTP/3, TCP स्तर पर स्ट्रीम्स के बीच हेड-ऑफ़-लाइन ब्लॉकिंग से बचता है, फिर भी कोई एक QUIC स्ट्रीम लॉस रिकवरी का इंतज़ार कर सकती है।
8. XUDP, UDP एन्कोडिंग का एक विकल्प है
sing-box VLESS दस्तावेज़ `xudp` को पैकेट एन्कोडिंग विकल्प के रूप में सूचीबद्ध करते हैं, `packetaddr` और अतिरिक्त एन्कोडिंग बंद करने के विकल्प के साथ। इससे सिर्फ़ इतना सीमित निष्कर्ष निकलता है कि इस इकोसिस्टम में XUDP, UDP ले जाता है; यह कोई पूरा, वर्ज़न वाला पैकेट स्पेसिफ़िकेशन नहीं है।
सत्र, पते, सीमाओं और माइग्रेशन का विस्तृत व्यवहार ठीक उसी कोर वर्ज़न और कोड से जांचना चाहिए। यह गाइड जानबूझकर अनुमान से निकाले गए फ़्रेमिंग विवरणों को सार्वभौमिक मानक के रूप में पेश करने से बचती है।
9. Padding, FinalMask, ECH और Browser Dialer
- Padding: लंबाई या टाइमिंग की विशेषताएं बदलता है; यह एन्क्रिप्शन नहीं है।
- FinalMask: इसके कॉन्फ़िगरेशन दस्तावेज़ इसे बाहरी ट्रांसपोर्ट प्रोसेसिंग के चरण में रखते हैं, जिसमें TCP, UDP और QUIC से जुड़ी सेटिंग्स हैं।
- ECH: sing-box TLS दस्तावेज़ में ClientHello के एक हिस्से की सुरक्षा के लिए Encrypted ClientHello कॉन्फ़िगरेशन शामिल है; ECH टनल एन्क्रिप्शन की जगह नहीं लेता।
- Browser Dialer: Project X दस्तावेज़ के अनुसार यह एक असली ब्राउज़र से TLS और HTTP कनेक्शन बनवाता है, जिससे ब्राउज़र जैसा ज़्यादा प्रामाणिक व्यवहार मिलता है, लेकिन डिप्लॉयमेंट और परफ़ॉर्मेंस की सीमाओं की कीमत पर।
10. Fallback क्या कर सकता है और क्या नहीं
Project X Fallback दस्तावेज़ दिखाते हैं कि मेल न खाने वाला SNI, पथ या प्रोटोकॉल ट्रैफ़िक Nginx, Caddy या किसी सामान्य वेबसाइट पर कैसे भेजा जा सकता है, ताकि एक ही एंट्री पॉइंट पर प्रॉक्सी और सामान्य सेवाएं दोनों चल सकें।
Fallback हर असफल ऑथेंटिकेशन प्रयास का जवाब एक ही साफ़ दिखने वाली एरर से देने से बचा सकता है। यह एक्टिव प्रोबिंग से पूरी छूट नहीं है; पहचाने जाने की संभावना फिर भी TLS, ट्रांसपोर्ट, रिस्पॉन्स, टाइमिंग और सर्वर कॉन्फ़िगरेशन पर निर्भर करती है।
11. AnyTLS एक तुलना है, VLESS का हिस्सा नहीं
AnyTLS प्रोटोकॉल दस्तावेज़ यह क्रम बताता है: TCP → TLS → `SHA-256(password)` ऑथेंटिकेशन → एक सत्र → कई स्ट्रीम्स। फ़्रेम में Command, Stream ID, Data Length और Data होते हैं, साथ में SYN, PSH, FIN, settings, padding, heartbeat और version 2 की SYNACK कमांड।
इसका सत्र मॉडल, कई स्ट्रीम्स, डायनामिक पैडिंग और हेल्थ चेक तुलना के लिए उपयोगी हैं। AnyTLS एक अलग प्रोटोकॉल ही है; VLESS ये सुविधाएं अपने-आप नहीं पाता।
12. आम संयोजन और उनकी सीमाएं
- VLESS + REALITY + Vision + RAW: सीधी परफ़ॉर्मेंस और TLS-जैसी बाहरी दिखावट की ओर झुका; CDN पर निर्भरता नहीं।
- VLESS + TLS/REALITY + XHTTP: HTTP के ज़रिए ले जाने, रिवर्स प्रॉक्सी और शर्तों के साथ CDN कम्पैटिबिलिटी की ओर झुका।
- VLESS Encryption + Vision: रिले या गैर-मानक बाहरी सुरक्षा वाले परिदृश्यों में प्रोटोकॉल पेलोड की सुरक्षा करता है, सामान्य HTTPS दिखावट के बिना।
- VLESS + TLS + XHTTP + Browser Dialer: असली ब्राउज़र का नेटवर्क स्टैक इस्तेमाल करता है, ज़्यादा संचालन लागत के साथ।
- AnyTLS + TLS: सत्र/स्ट्रीम और पैडिंग का एक अलग डिज़ाइन, VLESS स्टैक नहीं।
कोई भी कॉन्फ़िगरेशन परफ़ॉर्मेंस, कम्पैटिबिलिटी, रखरखाव, दिखावट और सुरक्षा, सबमें एक साथ हमेशा सबसे अच्छा नहीं होता। चुनाव की शुरुआत थ्रेट मॉडल, नेटवर्क पथ, CDN या प्रॉक्सी की सीमाओं, क्लाइंट प्लेटफ़ॉर्म और निगरानी की ज़रूरतों से होनी चाहिए।
13. SingLink रिसर्च के लिए इसका क्या मतलब है
VLESS और AnyTLS की सार्वजनिक सामग्री पहचान, की एक्सचेंज, सत्र, स्ट्रीम्स, UDP, पैडिंग, मल्टीप्लेक्सिंग, रिकवरी और वर्ज़न नेगोशिएशन पर रिसर्च में मदद कर सकती है। यह लेख यह स्थापित नहीं करता कि SingLink 2.0 VLESS, REALITY, XHTTP या AnyTLS पर आधारित है।
SingLinkVPN को प्रकाशित व्यवहार, रिसर्च की दिशाओं और अप्रकाशित इम्प्लीमेंटेशन को अलग-अलग रखना जारी रखना चाहिए। अभी प्रकाशित दायरे के लिए SingLinkVPN ओपन-सोर्स योजना देखें।
14. अक्सर पूछे जाने वाले प्रश्न (FAQ)
क्या VLESS खुद ट्रैफ़िक एन्क्रिप्ट करता है?
पारंपरिक `encryption: "none"` वाला VLESS प्रोटोकॉल पेलोड की सुरक्षा नहीं करता और उसे भरोसेमंद निजी इन्फ्रास्ट्रक्चर या बाहरी सुरक्षा चाहिए। मौजूदा Xray-core में VLESS Encryption चालू किया जा सकता है, इसलिए जवाब इम्प्लीमेंटेशन और कॉन्फ़िगरेशन पर निर्भर करता है।
क्या VLESS Encryption, TLS या REALITY की जगह ले सकता है?
VLESS Encryption, TLS या REALITY के बराबर विकल्प नहीं है। यह VLESS पेलोड की सुरक्षा करता है, लेकिन अपने-आप मानक HTTPS सर्टिफ़िकेट, हैंडशेक या वेबसाइट जैसी दिखावट नहीं देता।
क्या XTLS Vision एन्क्रिप्शन करता है?
नहीं, XTLS Vision एन्क्रिप्शन नहीं करता। Vision मुख्य रूप से फ़्लो कंट्रोल और डेटा-पथ ऑप्टिमाइज़ेशन देता है।
XHTTP के तीन मोड में से कैसे चुनें?
XHTTP में packet-up कम्पैटिबिलिटी पर ज़ोर देता है, stream-up स्ट्रीमिंग की दिशाओं को अलग करता है, और stream-one एक दोतरफ़ा स्ट्रीम इस्तेमाल करता है। हर मोड को बीच के असली पथ के साथ परखना चाहिए।
XUDP किसी सामान्य UDP प्रॉक्सी से कैसे अलग है?
XUDP, Xray इकोसिस्टम में UDP एन्कोडिंग का एक विकल्प है। इसका सटीक व्यवहार कोर और वर्ज़न पर निर्भर करता है और सिर्फ़ नाम से इसका अनुमान नहीं लगाना चाहिए।
क्या SingLink 2.0, VLESS या AnyTLS पर आधारित है?
SingLink के इस प्रोटोकॉल और VLESS या AnyTLS के बीच ऐसा संबंध स्थापित करने के लिए पर्याप्त सार्वजनिक सबूत नहीं हैं। यह लेख एक तकनीकी तुलना है, इम्प्लीमेंटेशन का खुलासा नहीं।
15. निष्कर्ष और स्रोतों की तारीख
आधुनिक VLESS एक जोड़ने योग्य स्टैक है: VLESS पहचान और गंतव्य ले जाता है, VLESS Encryption प्रोटोकॉल स्तर पर वैकल्पिक सुरक्षा जोड़ता है, TLS या REALITY बाहरी सुरक्षा देते हैं, Vision फ़्लो को ऑप्टिमाइज़ करता है, XHTTP और XUDP ट्रैफ़िक ले जाते हैं, और मल्टीप्लेक्सिंग या पैडिंग कनेक्शन के व्यवहार को और बदलते हैं।
मूल प्रकाशन तिथि: 20 मई 2026। तकनीकी स्रोतों की समीक्षा: 28 जुलाई 2026। ये प्रोजेक्ट लगातार बदल रहे हैं; डिप्लॉयमेंट से पहले ठीक उसी वर्ज़न के दस्तावेज़, बदलाव लॉग और कम्पैटिबिलिटी की पुष्टि करें।
