حزمة VLESS الحديثة في 2026

حتى عام 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: خيار لترميز حزم UDP ضمن منظومة Xray.
• XMUX وأنظمة MUX الأخرى: طرق لمشاركة الاتصالات الأساسية.
• Padding / FinalMask / Browser Dialer: أدوات للتحكم في الطول أو التوقيت أو سلوك النقل الخارجي أو شبكات المتصفح.

لذلك يمكن نمذجة الاتصال على النحو التالي: حركة مرور التطبيق ← هوية VLESS والوجهة ← أمان البروتوكول أو الأمان الخارجي ← التحكم في التدفق عبر Vision ← وسيلة نقل مثل RAW أو XHTTP ← TCP أو UDP. وليست كل وحدة ضرورية أو متوافقة في كل تصميم.

2. ما الذي يفعله بروتوكول VLESS الأساسي

تعرّف وثائق Project X بروتوكول VLESS بأنه بروتوكول نقل خفيف وعديم الحالة لا يعتمد على وقت النظام، ويستخدم UUID أو معرّفًا مقابلًا للمصادقة. ويُظهر تنفيذ الترميز العام في Xray-core الإصدار ومعرّف المستخدم والإضافات والأمر ومنفذ الوجهة والعنوان والبيانات التالية.

عمليًا، تجيب الطبقة الأساسية عن الأسئلة التالية: من هو العميل، وما الاتصال المطلوب، وإلى أين يجب أن يذهب؟ أما التوجيه الذكي وحِمل العقد وصلاحيات الخطط وإعادة الاتصال التلقائية فتنتمي عادةً إلى طبقات المنتج والتحكم الأعلى.

تستخدم الإعدادات التقليدية عادةً `encryption: "none"`. وتشترط إرشادات Project X الحالية وجود أمان نقل خارجي، ما لم يكن الطرف المقابل والرابط بنية تحتية خاصة موثوقة، أو ما لم يكن VLESS Encryption مفعّلًا.

3. ما الذي يغيّره VLESS Encryption

VLESS Encryption طبقة حماية أصلية اختيارية دُمجت في Xray-core عام 2025. ويصف طلب السحب المدموج PR #5067 ووثائق الإعدادات الحالية مصافحة `mlkem768x25519plus`، ومظاهر `native` و`xorpub` و`random`، وسلوك الجلسة `1rtt` و`0rtt`، والحشو المتغير.

أهداف التصميم المنشورة

• اشتقاق مفاتيح الجلسة عبر الجمع بين ML-KEM-768 وX25519؛
• حماية حمولات VLESS دون اشتراط TLS خارجي؛
• استخدام تذاكر لاستئناف 0-RTT لاحقًا، وحالة قصيرة الأجل لتقليل خطر إعادة التشغيل؛
• استخدام حشو متغير وأوضاع XOR اختيارية لتغيير المظاهر ذات الطول الثابت أو مظاهر المفتاح العام.

هذه ادعاءات تصميم وتنفيذ صادرة عن المطورين المسؤولين. ولم نعثر على تدقيق تشفيري مستقل يغطي كل خاصية، لذلك لا يصف هذا الدليل التصميم بأنه «محصّن ضد إعادة التشغيل» أو «آمن كميًا بشكل مطلق».

ما الذي لا يحل محله تلقائيًا

يحمي VLESS Encryption حمولة البروتوكول، لكنه لا يُنشئ تلقائيًا سلسلة شهادات HTTPS عادية أو مصافحة موقع ويب أو سلوك HTTP/2 أو HTTP/3 أو توافقًا مع شبكات CDN. ولذلك فهو ليس مكافئًا لـ TLS أو REALITY.

4. TLS 1.3 وREALITY

يوفّر TLS تحققًا موحّدًا من الشهادات وتبادلًا للمفاتيح وسلامةً للبيانات وتشفيرًا للنقل. ويمكن أن يرافق RAW أو XHTTP أو gRPC أو WebSocket؛ ومع ذلك يظل الإصدار المتفاوض عليه وALPN والتحقق من الشهادات معتمدًا على الإعدادات ودعم الطرف المقابل.

تصف وثائق REALITY في Project X طبقة أمان معدّلة على غرار TLS تتضمن إعدادات target وserverNames ومفاتيح X25519 وshortId، إضافةً إلى بيانات تحقق ML-DSA-65 اختيارية. ويمكن أن يرافق REALITY كلًّا من RAW وXHTTP وgRPC.

لا ينبغي اختزال REALITY في عبارة «TLS بلا شهادة». فسلوكه يجمع بين تفويض العميل ومظهر مصافحة خارجي. وتظل النتائج معتمدة على الهدف وبصمة العميل ووسيلة النقل وجودة النشر، ولا يمكنه ضمان الاختفاء عن كل أداة تصنيف.

5. XTLS Vision ليس بروتوكول تشفير

تصنّف وثائق VLESS/Vision بروتوكول Vision على أنه أداة للتحكم في التدفق. ففي الظروف المدعومة يمكنه التعرف على حركة TLS الداخلية وتقليل التشفير أو النسخ الإضافي. وعلى مسارات Linux وTCP المتوافقة، قد تحاول النواة استخدام `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 أيضًا استخدام حشو الترويسات، وفصل مساري الرفع والتنزيل، وXMUX. ويعتمد عمله عبر شبكة CDN معينة على الوضع وإصدار HTTP وسلوك الوكيل العكسي وإعدادات المزوّد.

7. XMUX وتعدد الإرسال العام وحجب رأس الطابور

يدير XMUX تزامن XHTTP، وعدد الاتصالات الأساسية، وإعادة استخدامها، ومدة بقائها، والإبقاء عليها حية. وليس هدفه الإبقاء على اتصال واحد بالضبط إلى الأبد، بل الموازنة بين كلفة المصافحة والتزامن وأنماط الاتصالات طويلة الأمد.

تذكر وثائق تعدد الإرسال في sing-box أيضًا smux وyamux وh2mux. يمكن لتعدد الإرسال تقليل المصافحات، لكن الفقد أو الحجب على اتصال TCP أساسي قد يؤثر في عدة تدفقات. ويتجنب HTTP/3 حجب رأس الطابور بين التدفقات على مستوى TCP، بينما قد يظل تدفق QUIC منفرد ينتظر التعافي من الفقد.

8. XUDP خيار لترميز UDP

تذكر وثائق VLESS في sing-box الخيار `xudp` بوصفه خيارًا لترميز الحزم، إلى جانب `packetaddr` وتعطيل الترميز الإضافي. وهذا يدعم الاستنتاج المحدود بأن XUDP ينقل UDP ضمن هذه المنظومة؛ لكنه ليس مواصفة حزم كاملة وذات إصدارات.

ينبغي التحقق من السلوك التفصيلي للجلسة والعنوان والحدود والانتقال مقابل إصدار النواة والكود المحددين. ويتجنب هذا الدليل عمدًا تقديم تفاصيل التأطير المستنتجة على أنها معيار عام.

9. Padding وFinalMask وECH وBrowser Dialer

• Padding: يغيّر خصائص الطول أو التوقيت؛ وهو ليس تشفيرًا.
• FinalMask: تضعه وثائق إعداداته في مرحلة معالجة النقل الخارجي مع إعدادات متعلقة بـ TCP وUDP وQUIC.
• ECH: تتضمن وثائق TLS في sing-box إعدادات Encrypted ClientHello لحماية جزء من ClientHello؛ ولا يحل ECH محل تشفير النفق.
• Browser Dialer: تتيح وثائق Project X لمتصفح حقيقي إنشاء اتصالات TLS وHTTP، فيكتسب سلوك متصفح أكثر أصالة مقابل قيود في النشر والأداء.

10. ما يستطيعه Fallback وما لا يستطيعه

تُظهر وثائق Fallback في Project X كيف يمكن تمرير حركة SNI أو المسارات أو البروتوكولات غير المطابقة إلى Nginx أو Caddy أو موقع ويب عادي، بما يتيح لنقطة دخول واحدة استضافة البروكسي والخدمات العادية معًا.

يمكن لـ Fallback تجنّب الرد على كل محاولة مصادقة فاشلة بخطأ واحد واضح. لكنه لا يمنح حصانة من الفحص النشط؛ إذ تظل إمكانية التعرف معتمدة على TLS ووسيلة النقل والاستجابات والتوقيت وإعدادات الخادم.

11. AnyTLS للمقارنة، وليس مكوّنًا من VLESS

تصف وثيقة بروتوكول AnyTLS المسار TCP ← TLS ← مصادقة `SHA-256(password)` ← جلسة ← تدفقات متعددة. وتحتوي الإطارات على Command وStream ID وData Length وData، مع أوامر SYN وPSH وFIN والإعدادات والحشو ونبضات القلب وأمر SYNACK في الإصدار 2.

يجعل نموذج الجلسة فيه والتدفقات المتعددة والحشو الديناميكي وفحوص السلامة منه مادة مفيدة للمقارنة. ويبقى 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"` لا يحمي حمولة البروتوكول، ويتطلب بنية تحتية خاصة موثوقة أو أمانًا خارجيًا. أما Xray-core الحالي فيمكنه تفعيل VLESS Encryption، لذا تعتمد الإجابة على التنفيذ والإعدادات.

هل يمكن أن يحل VLESS Encryption محل TLS أو REALITY?

ليس بوصفه بديلًا مكافئًا. فهو يحمي حمولات VLESS، لكنه لا يوفّر تلقائيًا شهادة HTTPS قياسية أو مصافحة أو مظهر موقع ويب.

هل يقوم XTLS Vision بالتشفير?

لا. يوفّر Vision أساسًا التحكم في التدفق وتحسين مسار البيانات.

كيف يُختار بين أوضاع XHTTP الثلاثة?

يركّز packet-up على التوافق، ويفصل stream-up بين اتجاهي التدفق، ويستخدم stream-one تدفقًا واحدًا ثنائي الاتجاه. ويجب اختبار كل منها على مسار الوسطاء الفعلي.

ما الفرق بين XUDP وبروكسي UDP عام?

XUDP خيار لترميز UDP ضمن منظومة Xray. ويعتمد سلوكه الدقيق على النواة والإصدار، ولا ينبغي استنتاجه من الاسم وحده.

هل SingLink 2.0 مبني على VLESS أو AnyTLS?

لا توجد أدلة علنية كافية لإثبات هذه العلاقة. هذا المقال مقارنة تقنية، وليس إفصاحًا عن التنفيذ.

15. الخلاصة وتاريخ المصادر

VLESS الحديث حزمة قابلة للتركيب: يحمل VLESS الهوية والوجهة، ويضيف VLESS Encryption حماية اختيارية على مستوى البروتوكول، ويوفّر TLS أو REALITY الأمان الخارجي، ويحسّن Vision التدفق، وينقل XHTTP وXUDP حركة المرور، بينما يغيّر تعدد الإرسال أو الحشو سلوك الاتصال أكثر.

تاريخ النشر الأصلي: 20 مايو 2026. تاريخ مراجعة المصادر التقنية: 28 يوليو 2026. تستمر هذه المشاريع في التغير؛ لذا تحقّق من الوثائق وسجل التغييرات والتوافق الخاصة بالإصدار المحدد قبل النشر.