2026 میں جدید VLESS اسٹیک

Contents
2026 تک VLESS ایک ہلکا پھلکا، stateless پراکسی پروٹوکول ہے، لیکن «VLESS میں انکرپشن نہیں» اب مکمل بیان نہیں رہا۔ Xray-core اب اختیاری VLESS Encryption فراہم کرتا ہے۔ تعیناتیاں اپنے خطرے کے ماڈل کے مطابق VLESS کو TLS، REALITY، XTLS Vision، XHTTP اور XUDP کے ساتھ بھی جوڑ سکتی ہیں۔ یہ تہیں مختلف مسائل حل کرتی ہیں اور انہیں ایک ہی پروٹوکول میں گڈمڈ نہیں کرنا چاہیے۔
شواہد کی پالیسی: یہ گائیڈ Project X، Xray-core، sing-box اور AnyTLS کے بنیادی ذرائع استعمال کرتی ہے۔ GitHub کی pull requests اور مباحثے نگرانوں کے ڈیزائن اور نفاذ کو دستاویزی شکل دیتے ہیں؛ یہ آزادانہ سکیورٹی آڈٹ نہیں ہیں۔ SingLink کے حوالے ڈھانچے کے موازنے ہیں، یہ دعویٰ نہیں کہ SingLinkVPN ان پروجیکٹس کو نافذ کرتا ہے۔
1. جدید VLESS اسٹیک ایک نظر میں
- VLESS: شناخت، کمانڈ اور منزل کی ایک ہلکی پھلکی تہہ۔
- VLESS Encryption: موجودہ Xray-core میں payload کے تحفظ کی ایک اختیاری مقامی تہہ۔
- TLS 1.3 / REALITY: بیرونی ٹرانسپورٹ سکیورٹی، تصدیق اور نیٹ ورک پر ظاہری شکل۔
- XTLS Vision: فلو کنٹرول اور ڈیٹا کے راستے کی بہتری، کوئی الگ cipher نہیں۔
- RAW / XHTTP / gRPC / WebSocket: وہ ٹرانسپورٹس جو پراکسی ڈیٹا لے جاتے ہیں۔
- XUDP: Xray ماحولیاتی نظام میں UDP پیکٹ انکوڈنگ کا ایک آپشن۔
- XMUX اور دیگر MUX نظام: بنیادی کنکشنز کو مشترکہ طور پر استعمال کرنے کے طریقے۔
- Padding / FinalMask / Browser Dialer: لمبائی، وقت، بیرونی ٹرانسپورٹ کے رویے یا براؤزر نیٹ ورکنگ کے ٹولز۔
لہٰذا ایک کنکشن کو یوں ماڈل کیا جا سکتا ہے: ایپلیکیشن ٹریفک ← VLESS شناخت اور منزل ← پروٹوکول یا بیرونی سکیورٹی ← Vision فلو کنٹرول ← RAW یا XHTTP جیسا ٹرانسپورٹ ← TCP یا UDP۔ ہر ڈیزائن میں ہر ماڈیول نہ ضروری ہوتا ہے اور نہ مطابقت رکھتا ہے۔
2. VLESS کا بنیادی پروٹوکول کیا کرتا ہے
Project X کی دستاویزات VLESS کو ایک ہلکا پھلکا، stateless ٹرانسپورٹ پروٹوکول قرار دیتی ہیں جو سسٹم کے وقت پر منحصر نہیں اور تصدیق کے لیے UUID یا میپ شدہ ID استعمال کرتا ہے۔ عوامی Xray-core انکوڈنگ کا نفاذ ورژن، user ID، addons، کمانڈ، منزل کا پورٹ، ایڈریس اور اس کے بعد آنے والا ڈیٹا دکھاتا ہے۔
عملی طور پر بنیادی تہہ ان سوالوں کا جواب دیتی ہے: کلائنٹ کون ہے، کون سا کنکشن مانگا جا رہا ہے، اور اسے کہاں جانا ہے؟ اسمارٹ روٹنگ، نوڈ کا لوڈ، پلان کا استحقاق اور خودکار دوبارہ کنکشن عموماً اوپر کی پروڈکٹ اور کنٹرول تہوں کا کام ہیں۔
روایتی کنفیگریشنز میں عموماً `encryption: "none"` استعمال ہوتا ہے۔ Project X کی موجودہ رہنمائی کے مطابق بیرونی ٹرانسپورٹ سکیورٹی لازمی ہے، الا یہ کہ دوسرا فریق اور لنک قابلِ اعتماد نجی انفراسٹرکچر ہوں، یا VLESS Encryption فعال ہو۔
3. VLESS Encryption کیا بدلتا ہے
VLESS Encryption تحفظ کی ایک اختیاری مقامی تہہ ہے جو 2025 میں Xray-core میں شامل کی گئی۔ ضم شدہ PR #5067 اور موجودہ کنفیگریشن دستاویزات `mlkem768x25519plus` ہینڈ شیک، `native`، `xorpub` اور `random` ظاہری شکلیں، `1rtt` اور `0rtt` سیشن رویہ، اور متغیر padding بیان کرتی ہیں۔
شائع شدہ ڈیزائن اہداف
- ML-KEM-768 اور X25519 کے امتزاج سے سیشن کیز اخذ کرنا؛
- بیرونی TLS کے بغیر VLESS payloads کا تحفظ؛
- بعد کی 0-RTT بحالی کے لیے tickets اور replay کا خطرہ کم کرنے کے لیے مختصر مدت کی حالت استعمال کرنا؛
- مقررہ لمبائی یا public-key کی ظاہری شکل بدلنے کے لیے متغیر padding اور اختیاری XOR موڈز استعمال کرنا۔
یہ نگرانوں کے ڈیزائن اور نفاذ کے دعوے ہیں۔ ہمیں کوئی ایسا آزادانہ کرپٹوگرافک آڈٹ نہیں ملا جو ہر خصوصیت کا احاطہ کرے، اس لیے یہ گائیڈ اس ڈیزائن کو «replay سے مکمل محفوظ» یا «مطلقاً کوانٹم محفوظ» نہیں کہتی۔
یہ خود بخود کس چیز کی جگہ نہیں لیتا
VLESS Encryption پروٹوکول کے payload کا تحفظ کرتا ہے۔ یہ خود بخود عام 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، کلائنٹ fingerprint، ٹرانسپورٹ اور تعیناتی کے معیار پر منحصر ہیں؛ یہ ہر درجہ بندی کرنے والے نظام سے پوشیدہ رہنے کی ضمانت نہیں دے سکتا۔
5. XTLS Vision انکرپشن پروٹوکول نہیں
VLESS/Vision کی دستاویزات Vision کو فلو کنٹرول کے زمرے میں رکھتی ہیں۔ معاون حالات میں یہ اندرونی TLS ٹریفک کو پہچان کر اضافی انکرپشن یا نقل کو کم کر سکتا ہے۔ مطابقت رکھنے والے Linux اور TCP راستوں پر core، `splice` آزما سکتا ہے تاکہ kernel ڈیٹا براہِ راست منتقل کرے۔
درست تقسیم یہ ہے: 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 ہیڈر padding، اپ لوڈ/ڈاؤن لوڈ کے الگ راستے اور XMUX بھی استعمال کر سکتا ہے۔ یہ کسی مخصوص CDN کے ذریعے کام کرتا ہے یا نہیں، یہ موڈ، HTTP ورژن، ریورس پراکسی کے رویے اور فراہم کنندہ کی کنفیگریشن پر منحصر ہے۔
7. XMUX، عمومی ملٹی پلیکسنگ اور head-of-line blocking
XMUX، XHTTP میں بیک وقت کنکشنز، بنیادی کنکشنز کی تعداد، دوبارہ استعمال، مدت اور keepalive کا انتظام کرتا ہے۔ اس کا مقصد ہمیشہ ٹھیک ایک کنکشن رکھنا نہیں؛ یہ ہینڈ شیک کی لاگت، بیک وقت کنکشنز اور طویل کنکشن کے انداز میں توازن رکھتا ہے۔
sing-box کی multiplex دستاویزات smux، yamux اور h2mux بھی درج کرتی ہیں۔ ملٹی پلیکسنگ ہینڈ شیکس کم کر سکتی ہے، لیکن کسی بنیادی TCP کنکشن پر پیکٹ لاس یا رکاوٹ کئی streams کو متاثر کر سکتی ہے۔ HTTP/3، TCP کی سطح پر streams کے درمیان head-of-line blocking سے بچتا ہے، جبکہ ایک انفرادی QUIC stream پھر بھی پیکٹ لاس کی بحالی کا انتظار کر سکتا ہے۔
8. XUDP، UDP انکوڈنگ کا ایک آپشن ہے
sing-box کی VLESS دستاویزات `xudp` کو `packetaddr` اور اضافی انکوڈنگ بند کرنے کے ساتھ ساتھ پیکٹ انکوڈنگ کے ایک آپشن کے طور پر درج کرتی ہیں۔ اس سے یہ محدود نتیجہ نکلتا ہے کہ اس ماحولیاتی نظام میں XUDP، UDP کو لے جاتا ہے؛ یہ کوئی مکمل، ورژن شدہ پیکٹ specification نہیں۔
سیشن، ایڈریس، حدود اور منتقلی کے تفصیلی رویے کی تصدیق core کے عین ورژن اور کوڈ سے کرنی چاہیے۔ یہ گائیڈ جان بوجھ کر اندازے سے اخذ کردہ framing تفصیلات کو عالمگیر معیار کے طور پر پیش کرنے سے گریز کرتی ہے۔
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، paths یا پروٹوکول ٹریفک کو Nginx، Caddy یا کسی عام ویب سائٹ کی طرف کیسے بھیجا جا سکتا ہے، تاکہ ایک ہی داخلی راستہ پراکسی اور عام سروسز دونوں کی میزبانی کر سکے۔
Fallback ہر ناکام تصدیقی کوشش کا جواب ایک واضح خرابی سے دینے سے بچا سکتا ہے۔ یہ فعال جانچ (active probing) سے مکمل تحفظ نہیں؛ پہچانے جانے کا امکان اب بھی TLS، ٹرانسپورٹ، جوابات، وقت اور سرور کنفیگریشن پر منحصر ہے۔
11. AnyTLS ایک موازنہ ہے، VLESS کا جزو نہیں
AnyTLS پروٹوکول کی دستاویز یہ ترتیب بیان کرتی ہے: TCP ← TLS ← `SHA-256(password)` تصدیق ← ایک سیشن ← متعدد streams۔ فریمز میں Command، Stream ID، Data Length اور Data ہوتے ہیں، اور SYN، PSH، FIN، settings، padding، heartbeat اور ورژن 2 کی SYNACK کمانڈز ہیں۔
اس کا سیشن ماڈل، متعدد streams، متحرک padding اور صحت کی جانچ ایک مفید موازنہ فراہم کرتے ہیں۔ AnyTLS ایک الگ پروٹوکول ہے؛ VLESS کو یہ فیچرز خود بخود وراثت میں نہیں ملتے۔
12. عام امتزاج اور ان کی حدود
- VLESS + REALITY + Vision + RAW: براہِ راست کارکردگی اور TLS طرز کی بیرونی ظاہری شکل پر مرکوز؛ CDN پر انحصار نہیں۔
- VLESS + TLS/REALITY + XHTTP: HTTP کے ذریعے ترسیل، ریورس پراکسیز اور مشروط CDN مطابقت پر مرکوز۔
- VLESS Encryption + Vision: relay یا غیر معیاری بیرونی سکیورٹی والی صورتوں کے لیے پروٹوکول payload کا تحفظ کرتا ہے، عام HTTPS ظاہری شکل کے بغیر۔
- VLESS + TLS + XHTTP + Browser Dialer: زیادہ آپریشنل لاگت کے ساتھ حقیقی براؤزر کا نیٹ ورک اسٹیک استعمال کرتا ہے۔
- AnyTLS + TLS: ایک الگ session/stream اور padding ڈیزائن، VLESS اسٹیک نہیں۔
کوئی کنفیگریشن کارکردگی، مطابقت، دیکھ بھال میں آسانی، ظاہری شکل اور سکیورٹی سب میں بیک وقت ہمیشہ بہترین نہیں ہوتی۔ انتخاب کا آغاز خطرے کے ماڈل، نیٹ ورک راستے، CDN یا پراکسی کی پابندیوں، کلائنٹ پلیٹ فارمز اور مشاہدے کی ضروریات سے ہونا چاہیے۔
13. SingLink کی تحقیق کے لیے اس کا کیا مطلب ہے
VLESS اور AnyTLS کا عوامی مواد شناخت، کلید کے تبادلے، سیشنز، streams، UDP، padding، ملٹی پلیکسنگ، بحالی اور ورژن کی گفت و شنید پر تحقیق میں مددگار ہو سکتا ہے۔ یہ مضمون یہ ثابت نہیں کرتا کہ SingLink 2.0 کی بنیاد VLESS، REALITY، XHTTP یا AnyTLS پر ہے۔
SingLinkVPN کو شائع شدہ رویے، تحقیقی سمتوں اور غیر ظاہر شدہ نفاذ کو الگ الگ رکھنا جاری رکھنا چاہیے۔ اس وقت شائع شدہ دائرے کے لیے SingLinkVPN اوپن سورس منصوبہ دیکھیں۔
14. اکثر پوچھے جانے والے سوالات (FAQ)
کیا VLESS بذاتِ خود ٹریفک انکرپٹ کرتا ہے?
روایتی `encryption: "none"` پروٹوکول payload کا تحفظ نہیں کرتا اور اس کے لیے قابلِ اعتماد نجی انفراسٹرکچر یا بیرونی سکیورٹی درکار ہے۔ موجودہ Xray-core میں VLESS Encryption فعال کیا جا سکتا ہے، اس لیے جواب نفاذ اور کنفیگریشن پر منحصر ہے۔
کیا VLESS Encryption، TLS یا REALITY کی جگہ لے سکتا ہے?
مساوی متبادل کے طور پر نہیں۔ VLESS Encryption، VLESS payloads کا تحفظ کرتا ہے لیکن خود بخود معیاری HTTPS سرٹیفکیٹ، ہینڈ شیک یا ویب سائٹ کی ظاہری شکل فراہم نہیں کرتا۔
کیا XTLS Vision انکرپشن کرتا ہے?
نہیں۔ XTLS Vision بنیادی طور پر فلو کنٹرول اور ڈیٹا کے راستے کی بہتری فراہم کرتا ہے۔
XHTTP کے تین موڈز میں سے انتخاب کیسے کریں?
packet-up مطابقت پر زور دیتا ہے، stream-up اسٹریمنگ کی سمتوں کو الگ کرتا ہے، اور stream-one ایک دو طرفہ stream استعمال کرتا ہے۔ ہر ایک کو اصل درمیانی راستے کے ساتھ آزمانا ضروری ہے۔
XUDP عام UDP پراکسی سے کیسے مختلف ہے?
XUDP، Xray ماحولیاتی نظام میں UDP انکوڈنگ کا ایک آپشن ہے۔ اس کا عین رویہ core اور ورژن پر منحصر ہے اور صرف نام سے اس کا اندازہ نہیں لگانا چاہیے۔
کیا SingLink 2.0 کی بنیاد VLESS یا AnyTLS پر ہے?
اس تعلق کو ثابت کرنے کے لیے کافی عوامی شواہد موجود نہیں۔ یہ مضمون ایک تکنیکی موازنہ ہے، نفاذ کا انکشاف نہیں۔
15. اختتامیہ اور ذرائع کی تاریخ
جدید VLESS ایک قابلِ ترکیب اسٹیک ہے: VLESS شناخت اور منزل لے جاتا ہے، VLESS Encryption پروٹوکول کی سطح پر اختیاری تحفظ شامل کرتا ہے، TLS یا REALITY بیرونی سکیورٹی فراہم کرتے ہیں، Vision بہاؤ کو بہتر بناتا ہے، XHTTP اور XUDP ٹریفک لے جاتے ہیں، اور ملٹی پلیکسنگ یا padding کنکشن کے رویے کو مزید بدلتے ہیں۔
اصل اشاعت کی تاریخ: 20 مئی 2026۔ تکنیکی ذرائع کا جائزہ: 28 جولائی 2026۔ یہ پروجیکٹس بدلتے رہتے ہیں؛ تعیناتی سے پہلے عین ورژن کی دستاویزات، تبدیلی لاگ اور مطابقت کی تصدیق کریں۔


