بروتوكول VLESS: دليل تجاوز الرقابة باستخدام VPN V2Ray وخادم Xray

بعد مرور نحو خمس سنوات على ظهوره في مستودع تطوير غير معروف على منصة GitHub، أصبح بروتوكول VLESS بهدوء البروتوكول الافتراضي الذي تستخدمه الخوادم الوكيلة في روسيا وإيران والصين. والأسباب غير جذابة، فهو صغير الحجم، ولا يقوم بتشفير أي بيانات بنفسه، كما أنه البروتوكول الوحيد واسع الانتشار الذي لم تتمكن أنظمة فحص الحزم العميق (DPI) الحكومية الكبرى من التغلب عليه بشكل حاسم حتى منتصف عام 2026.

يشرح هذا الدليل ماهية بروتوكول VLESS كبروتوكول خفيف الوزن، وكيفية عمله داخليًا، وما يعمل عليه (Xray، XTLS، REALITY)، ومقارنته ببروتوكولات VMess وTrojan وShadowsocks وWireGuard وبروتوكولات VPN التقليدية مثل OpenVPN، وكيف يبدو إعداد VLESS VPN عمليًا. إنه شرح تقني، وليس دليلًا تفصيليًا للتكوين. إذا انتهيت من قراءته وما زلت ترغب في نسخ أوامر الخادم ولصقها، فإن وثائق المشروع على xtls.github.io هي الخطوة التالية المناسبة.

ما هو VLESS ولماذا قام مجتمع V2Ray بتطويره؟

VLESS، اختصارًا لـ "VMess Less"، هو بروتوكول وكيل خفيف الوزن عديم الحالة تم تقديمه في عام 2020 من قبل المطور المعروف باسم RPRX، الذي احتفظ بمستودع حاضنة في RPRX/v2ray-vless منذ عام 2019. تم تصميمه كعملية تجريد متعمدة لبروتوكول VMess الأصلي، V2Ray، الذي أصبح معقدًا للغاية بحلول أواخر العقد الأول من القرن الحادي والعشرين بسبب آليات التشفير والحماية من إعادة التشغيل ومزامنة الساعة الخاصة به.

يوجد VLESS اليوم بشكل أساسي في قاعدتي بيانات. تحتوي قاعدة البيانات الأصلية v2fly/v2ray-core على VLESS لضمان التوافق. أما نسخة XTLS/Xray-core، التي يتولى RPRX صيانتها أيضًا، فهي النسخة الأكثر تطورًا: إذ حصدت 38,600 نجمة على GitHub ونحو 5,400 نسخة فرعية حتى مايو 2026، مقابل 33,900 نجمة على v2fly/v2ray-core. تُوفر Xray الميزات الأساسية، وتحديدًا التحكم في تدفق XTLS Vision ونقل REALITY، وهي ميزات غير متوفرة في v2fly.

كيف يعمل بروتوكول VLESS: مُعرّف فريد عالمي (UUID)، بدون تشفير، بروتوكول أمان طبقة النقل (TLS) خارجي

بروتوكول VLESS السلكي قصير بما يكفي لوصفه في فقرة. يفتح العميل اتصالاً، ويرسل ترويسة. تحتوي الترويسة على بايت الإصدار، ومعرّف فريد عالمي (UUID) للمستخدم (16 بايت)، ومؤشر طول لحقل الإضافات الاختيارية، والإضافات نفسها، وأمر (بايت واحد) (TCP أو UDP)، ومنفذ الوجهة، وبايت نوع العنوان، والعنوان. يصل حجم كل اتصال إلى ما بين 25 و50 بايت. أما OpenVPN فيتجاوز حجم كل حزمة بيانات 100 بايت.

لا يقوم بروتوكول VLESS بتشفير رأس الطلب بأي شكل من الأشكال. يشترط البروتوكول صراحةً تحديد `encryption: "none"` في إعدادات JSON الخاصة به، وتنص وثائق v2fly على أنه لا يمكن ترك هذا الحقل فارغًا، بل يجب أن يُكتب فيه "none" بوضوح، لتذكير المشغلين بأن البروتوكول يُفوّض جميع إجراءات السرية إلى بروتوكول النقل المستخدم. عمليًا، يكون بروتوكول النقل هذا في أغلب الأحيان هو TLS 1.3.

يُعدّ هذا الخيار التصميمي مصدر جميع الخصائص المميزة لبروتوكول VLESS. فمن خلال عدم تشغيل طبقة تشفير خاصة به، يتجنب VLESS نمط الفشل الذي قضى على بروتوكول VMess في الشبكات الخاضعة للرقابة. وتُنتج طبقة تشفير ثانية داخل نفق TLS خارجي ما يُطلق عليه باحثو تحليل حركة البيانات أنماط "TLS-in-TLS". وكانت أنظمة فحص الحزم العميق الحكومية، المُدرّبة على رصد هذا الشكل المزدوج تحديدًا، السبب الرئيسي وراء تجاوز معدلات اكتشاف VMess نسبة 80% على جدار الحماية الصيني العظيم بحلول سبتمبر 2025. وبما أن VLESS لا يحمل سوى بيانات المصادقة وبيانات التوجيه الوصفية، فإنه يبدو أقرب بكثير إلى محادثة TLS عادية، مما يُفشل نوع بصمة البروتوكول التي تعتمد عليها أنظمة فحص الحزم العميق.

أما الإغفال المتعمد الآخر فهو خاصية الاحتفاظ بالحالة. يعتمد بروتوكول VMess على تزامن الساعات بين العميل والخادم، مع استخدام الطوابع الزمنية للحزم لمنع هجمات إعادة الإرسال. وقد نتج عن ذلك سنوات من حالات فشل الاتصال المُربكة كلما انحرفت ساعة الهاتف، أو كان جهاز الكمبيوتر المحمول يعمل بنظام تشغيل مزدوج، أو كان الخادم في منطقة زمنية خاطئة. أما بروتوكول VLESS فهو عديم الحالة. يُعدّ مُعرّف UUID هو آلية المصادقة بأكملها. إذا تطابق مُعرّف UUID، يتم السماح بالاتصال؛ وإذا لم يتطابق، يتم رفضه من البايت الأول. لا شيء يعتمد على الوقت.

تُعدّ مُعرّفات UUID في VLESS مُعرّفات قياسية وفقًا لمعيار RFC-4122. يُنشئها الأمر `xray uuid`، كما يُمكن استخدام أي مُولّد UUID قياسي. تُقبل سلاسل نصية مُخصصة يصل طولها إلى 30 بايت، ويتم ربطها بمعرّفات UUID من خلال ما يُسمى في الوثائق "معيار ربط UUID في VLESS". تلتزم معظم الإعدادات بمعرّفات UUID المتعارف عليها، لأن عملية الربط لا تُغيّر شيئًا عمليًا.

توجد خيارات النقل ضمن البروتوكول: يدعم كل من TCP (مع أو بدون TLS)، وmKCP، وWebSocket، وgRPC، وQUIC. كل منها يُشكّل حركة البيانات بشكل مختلف. يسمح WebSocket لـ VLESS بالعمل خلف عملية مصافحة ترقية HTTP/1.1 عادية والتوجيه عبر شبكات توصيل المحتوى (CDN) مثل Cloudflare. يعتمد gRPC على تقنية تعدد الإرسال في HTTP/2. ينقل QUIC كل شيء داخل جلسة TLS 1.3 خارجية قائمة على UDP. لا يهم البروتوكول على أي بروتوكول نقل يعمل. هذا الفصل هو ما يجعله قابلاً للنقل.

الأشعة السينية، والواقع، وXTLS: المكدس الذي يعمل عليه VLESS فعليًا

في الواقع، لا أحد يركض عارياً في سباق VLESS. الأجزاء المثيرة للاهتمام هي ما يدور حوله.

يُعدّ Xray-core بيئة التشغيل المهيمنة. وهو نسخة معدلة من V2Ray-core بدأها RPRX ومساهمو XTLS بعد انقسام المجتمع، ويحتوي على تقنيتين يعتمد عليهما VLESS في أعمال تجاوز الرقابة الجادة: XTLS Vision وREALITY.

تُعدّ XTLS Vision (المُحددة كـ `flow: "xtls-rprx-vision"` في الإعدادات) آلية حشو تُطبّق على بيانات TLS 1.3. تكمن المشكلة التي تحلّها في دقة تفاصيلها. إذ تتميز سجلات TLS 1.3 بتوقيعات طول مُتوقعة عند نقلها لبيانات تطبيقات داخلية ذات أشكال ثابتة، ما يُؤدي إلى تسريب معلومات حول البيانات المُمرّرة عبر النفق. تُضيف Vision بايتات الحشو خلال مرحلة المصافحة الأولية. وبمجرد إنشاء الاتصال، تنتقل إلى نسخ المقابس مباشرةً. في نظام Linux، تستخدم استدعاء النظام `splice()` لإعادة توجيه حزم TCP في النواة دون نسخها عبر مساحة المستخدم. والنتيجة هي معدل نقل بيانات قريب من معدل نقل البيانات الذي يُوفّره اتصال TCP غير مُوجّه، مع تقليل تسريب توقيع الطول.

يُعدّ مشروع REALITY، الذي أُطلق عام 2023 ويُدار على github.com/XTLS/REALITY، أكثر جذرية. فخادم VLESS+TLS القياسي يُقدّم شهادة TLS خاصة به، ما يعني امتلاكه نطاقًا، وتشغيله لبرنامج Certbot، وكشفه عن بصمة شهادة يُمكن لنظام فحص الحزم العميق (DPI) ربطها باستخدام الوكيل. أما REALITY فيتخلى عن هذه الفكرة تمامًا. فبدلًا من تشغيل بروتوكول TLS الخاص به، يُحاكي الخادم عملية المصافحة لموقع ويب حقيقي تابع لجهة خارجية. ويختار المُشغّل النطاق المستهدف: `microsoft.com`، `apple.com`، أو أي نطاق آخر. ويستخدم الخادم تقنية SNI المُزيّفة وتبادل مفاتيح X25519. وتُكمل الأجهزة العميلة التي تعرف مفتاح REALITY العام الصحيح عملية مصافحة TLS 1.3 حقيقية مع سلسلة الشهادات المُنتحلة، تمامًا كما يُصافح المتصفح خادم ويب حقيقي، ثم يتم توجيهها إلى نفق VLESS. أما العملاء الذين لا يفعلون ذلك، بما في ذلك أنظمة فحص الحزم العميق، فيرون ما يبدو وكأنه اتصال طبيعي بالموقع المنتحل، بما في ذلك الشهادة الحقيقية.

إن الجمع بين VLESS كبروتوكول داخلي، وXTLS Vision لتسوية التوقيع الطولي، وREALITY لإخفاء المصافحة هو ما يقصده الناس عندما يقولون "VLESS+REALITY" أو "VLESS+Vision+REALITY". إنه التكوين الذي، اعتبارًا من منتصف عام 2026، لا يزال يعمل في بيئات لا يعمل فيها أي شيء آخر تقريبًا.

VLESS ضد VMess ضد Trojan ضد Shadowsocks ضد WireGuard

نطاق البروتوكولات المحيطة بـ VLESS محدود، والاختلافات بينها جوهرية. تجدون أدناه النسخة المختصرة، أما النسخة المطولة فهي الجدول.

يُعدّ VMess سلفًا لـ VLESS، وهو مزود بتشفير AEAD خاص به، وحماية من إعادة الإرسال، وإصدارات تعتمد على alterId. في الشبكات غير الخاضعة للرقابة، تُؤثر هذه الميزات سلبًا على الإنتاجية بنسبة ضئيلة دون أي فائدة تُذكر. أما في الشبكات الخاضعة للرقابة، فيُمكن اكتشاف نمط التشفير داخل TLS، وتشير بيانات قياس جدار الحماية الصيني العظيم (GFW) إلى أن نسبة اكتشافه تبلغ حوالي 80% منذ سبتمبر 2025.

يُعدّ برنامج Trojan تصميمًا مشابهًا من فريق مختلف. وهو أبسط من VLESS: كلمة مرور بدلًا من مُعرّف فريد عالمي (UUID)، ولا يحتوي على حقل إضافات، ويستخدم بروتوكول TLS خارجيًا. لسنوات، شكّلت هذه البساطة ميزةً قويةً له؛ إلا أن تحديث جدار الحماية الصيني العظيم (GFW) في أغسطس 2025 غيّر ذلك، وأصبح Trojan الآن يُكتشف بنسبة 90% تقريبًا.

ينتمي Shadowsocks إلى عائلة مختلفة تمامًا. فهو تشفير AEAD متناظر بدون واجهة TLS، مصمم ليبدو كبايتات عشوائية بدلًا من HTTPS. وقد نجح هذا النهج حتى بدأ جدار الحماية الصيني (GFW) بتصنيف حركة المرور المشفرة بالكامل على أنها مشبوهة افتراضيًا؛ وتعتمد عمليات نشر Shadowsocks الحديثة على إضافات النقل (v2ray-plugin، cloak) التي تغلف التشفير بـ TLS أو HTTP، مما يعيد بناء بنية VLESS فعليًا من الاتجاه المعاكس.

يختلف بروتوكول WireGuard تمامًا عن بروتوكول VLESS+XTLS، فهو بروتوكول VPN يعمل على مستوى نواة النظام، وليس بروتوكول وسيط. في الشبكات النظيفة، يكون أسرع بنسبة 2-3% تقريبًا من VLESS+XTLS من حيث معدل نقل البيانات الخام، مع استهلاك أقل بكثير لوحدة المعالجة المركزية، ويظل الخيار الأمثل لحالات الاستخدام العادية التي تتطلب الخصوصية من مزود خدمة الإنترنت. أما في الشبكات الخاضعة للرقابة، فيمكن بسهولة تحديد بايت المصافحة الثابت 0x01، مما يؤدي إلى انخفاض معدل نقل البيانات الفعلي إلى ما يقارب الصفر.

VLESS، والرقابة، والحصار الروسي لهيئة الإذاعة والتلفزيون

لولا قدرة بروتوكول VLESS على تجاوز الرقابة في روسيا والأنظمة المماثلة بكفاءة تفوق أي بروتوكول آخر واسع الانتشار، لكان مجرد هامش في تاريخ برامج البروكسي. ومنذ عام 2024، تسعى أكبر أنظمة فحص الحزم العميق الحكومية في العالم جاهدةً للقضاء عليه. ومنذ ذلك الحين، باتت القضية أشبه بلعبة تصعيد علنية بطيئة.

في روسيا، أفادت هيئة روسكومنادزور بحجب 439 خدمة VPN بحلول يناير 2026. وبلغت ميزانية حجب خدمات VPN الفيدرالية حوالي 60 مليار روبل (حوالي 780 مليون دولار أمريكي) للفترة 2025-2027، مع تخصيص 2.27 مليار روبل أخرى (حوالي 29 مليون دولار أمريكي) تحديدًا لفلترة حركة البيانات باستخدام الذكاء الاصطناعي، وفقًا لتقرير نشرته zona.media في أبريل 2026. وفي 17 فبراير 2026، صعّدت روسكومنادزور إجراءاتها مجددًا، بموجة حجب حادة استهدفت تحديدًا بروتوكول VLESS-over-TCP-with-TLS، كما وثّق ذلك موقعا Mezha وdigirt. وانتقل المستخدمون إلى بروتوكولات REALITY وgRPC وشبكات نقل البيانات (CDN) في غضون ساعات. وبلغ معدل تجاوز الحجب المُبلغ عنه لبروتوكول VLESS+REALITY ضد فحص الحزم العميق الروسي حوالي 99.5% خلال تلك الموجة، وهو رقم يُفترض اعتباره مؤشرًا اتجاهيًا وليس قياسًا دقيقًا.

في الصين، مرّ جدار الحماية العظيم بتسلسل مماثل في عام 2025. انخفضت نسبة اكتشاف برامج التجسس الخبيثة إلى حوالي 90% في أغسطس، وبرنامج VMess إلى حوالي 80% في سبتمبر. وفي حادثة أمنية إلكترونية منفصلة في سبتمبر 2025، كشف تسريب بحجم 600 جيجابايت من متعاقد صيني مع جدار الحماية العظيم، وفقًا لتقرير Cybernews، عن أجزاء من البنية التحتية الداخلية للتصنيف، لكنه لم يُغيّر في حد ذاته من جدوى نشره. وأفادت اختبارات مجتمعية على موقع greatfirewallguide.com عن معدلات تجاوز بلغت 98% لبروتوكول VLESS+REALITY+Vision في أوائل عام 2026.

في إيران، يقوم جدار الحماية التابع لشركة MCI بحظر عناوين بروتوكول الإنترنت الخاصة بشبكة REALITY منذ أبريل 2024 على الأقل، كما هو موثق في مناقشة XTLS/Xray-core رقم 3269. ويفيد المشغلون بأن عنوان IP الذي يحمل حوالي 100 جيجابايت من حركة مرور REALITY يتم حظره عادةً بواسطة Irancell في غضون 48 ساعة، ولهذا السبب أصبح تدوير الخوادم واستخدام شبكة توصيل المحتوى (CDN) ممارسة شائعة هناك.

كيف يبدو إعداد VPN بدون VLS: الخادم، العملاء، الإعدادات

يتكون نشر VLESS العامل من ثلاثة أجزاء: خادم في مكان ما، وعميل على كل جهاز، وسلسلة اتصال تربط بينهما.

جانب الخادم بسيط للغاية. أي خادم افتراضي خاص (VPS) رخيص سيفي بالغرض: Hetzner، Vultr، OVH، أي خادم يوفر عنوان IPv4 عامًا. ثبّت Xray-core من ملفات المشروع الثنائية أو من مدير الحزم، ثم أنشئ مُعرّفًا فريدًا عالميًا (UUID) باستخدام الأمر `xray uuid`، وأنشئ زوج مفاتيح X25519 للواقع باستخدام الأمر `xray x25519`، واختر هدفًا للانتحال (موقع HTTPS حقيقي يدعم TLS 1.3 وHTTP/2)، واكتب ملف تكوين خادم JSON يرتبط بالمنفذ 443. إجمالي وقت الإعداد، بعد تجربته مرة واحدة: حوالي عشر دقائق. توفر لوحات تحكم الويب مثل 3X-UI وHiddify-Manager نفس التكوين في واجهة متصفح للمشغلين الذين يفضلون عدم تعديل JSON. تتوفر أيضًا أجهزة مُدارة. يعرض سوق AWS صورة خادم Xray VLESS VPN بسعر 0.063 دولارًا أمريكيًا في الساعة على خادم t3.micro، مع فترة تجريبية مجانية لمدة 5 أيام.

من جانب المستخدم، يتسم النظام البيئي بالتشتت ولكنه موثوق. يُعدّ كل من v2rayN وNekoray من أبرز عملاء Windows. بينما يدعم كل من v2rayNG وNekoBox وHiddify نظام Android. كما يعمل Hiddify على أنظمة macOS وLinux. أما على نظام iOS، حيث تُصعّب سياسة متجر تطبيقات Apple الأمور، فيُعدّ Streisand الخيار المجاني، بينما يُعتبر Shadowrocket أو V2Box الخيارين المدفوعين. جميع هذه البرامج تدعم VLESS، ومعظمها يدعم REALITY. عادةً ما يتم استيراد الإعدادات عبر مخطط URI `vless://`، وهو عنوان URL واحد يحتوي على UUID والعنوان والمنفذ وبروتوكول النقل ومعلمات REALITY، أو يتم مسحه ضوئيًا كرمز QR من لوحة تحكم الخادم.

الأداء والمخاطر ومتى لا تكون تقنية VLESS هي الأداة المناسبة

الأداء أولاً. تُظهر معايير الأداء المجتمعية أن VLESS يتفوق على VMess بنسبة تتراوح بين 15 و25% تقريبًا في الإنتاجية على نفس بروتوكول النقل، ويعود ذلك في الغالب إلى قصر حجم رأس VLESS وعدم وجود عملية تشفير داخلية. مع تقنية XTLS Vision وتحسين وصلات Linux، يقترب تطبيق VLESS المُحسَّن من إنتاجية TCP الأصلية، ولا يحده سوى عرض نطاق VPS وزمن الاستجابة للخادم. يبقى WireGuard أسرع بنسبة 2-3% على الشبكات غير الخاضعة للرقابة، حيث لا تُمثل عملية المصافحة عائقًا.

المخاطر حقيقية. بروتوكول VLESS محايد ومفتوح المصدر، لكن الوضع القانوني لاستخدامه لتجاوز الرقابة الحكومية يختلف اختلافًا كبيرًا باختلاف الأنظمة القضائية. يُجرّم القانون الاتحادي الروسي بشأن أدوات التحايل الترويجَ لإعدادات التشغيل بدلًا من الاستخدام الشخصي؛ أما الموقف التنظيمي في الصين فهو أكثر صرامة وتعسفًا؛ وتُلاحق إيران قضائيًا مُشغّلي مجموعات البروكسي الكبيرة. غالبًا ما تحظر شبكات الشركات جميع حركة مرور البروكسي وشبكات VPN بشكل قاطع. ينبغي على المستخدمين في هذه البيئات معرفة القواعد التي يعملون بموجبها قبل إعداد أي شيء. تطبيقات VPN المجانية التي تأتي مع اشتراكات VLESS مُحمّلة مسبقًا تنتمي إلى فئة تنظيمية منفصلة في بعض الأنظمة القضائية، وقد تخضع لتدقيق مختلف.

أخيرًا، نقطة أقل إثارة للجدل. إذا لم تكن متصلًا بشبكة خاضعة للرقابة، فإن استخدام VLESS يُعدّ مبالغة. للحفاظ على خصوصيتك بشكل طبيعي من مزود خدمة الإنترنت عبر اتصال آمن، يُعدّ WireGuard أو إعداد OpenVPN حديث أسرع وأبسط، كما أنه مدعوم من جميع مزودي خدمات VPN التجارية. VLESS+REALITY أداة لحل مشكلة محددة، واللجوء إليها عندما تكون المشكلة مختلفة تمامًا يُؤدي غالبًا إلى تعقيد الأمور.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.