كيف يجعل VLESS Reality حركة VPN غير مرئية للرقابة

كل بروتوكول VPN له بصمة. handshake البدء في WireGuard دائماً 148 بايت بالضبط ببنية ثابتة. القناة التحكمية لـ OpenVPN لها أنماط توقيت واضحة تحت التحليل. حتى Shadowsocks، المصمم خصيصاً لمقاومة الرقابة، ينتج حركة بإنتروبيا عالية قابلة للقياس يمكن لأنظمة DPI أن تعلّمها كـ "ليست HTTPS عادي".

التشفير يحمي المحتوى. لا يفعل شيئاً لإخفاء أنك تستخدم VPN.

VLESS Reality، الصادر في Xray-core v1.8.0 في بداية 2023، يأخذ نهجاً مختلفاً تماماً. بدلاً من تشفير الحركة وأمل ألا يستطيع الرقباء التعرف على الغلاف، يجعل اتصالات VPN تبدو متطابقة مع تصفح HTTPS عادي. ليست مشابهة. متطابقة. شهادة TLS التي يقدمها اتصالك حقيقية، صادرة عن سلطة شهادات حقيقية، لموقع حقيقي.

إليك كيف يعمل ذلك، لماذا يصعب حجبه، وما الذي تتنازل عنه للحصول عليه.

مشكلة الكشف

نظام deep packet inspection لا يحتاج لفك تشفير حركتك ليعرف أي بروتوكول تشغّل. يحتاج فقط للتعرف على الأنماط.

WireGuard هو أسهل مثال. رسالة handshake البدء تبدأ بحقل نوع 1-بايت، 3 بايت من الأصفار المحجوزة، فهرس مرسل 4-بايت، ثم مفتاح ephemeral غير مشفر 32-بايت. هذه البنية لا تتغير أبداً. TSPU الروسي (Technical Systems for Countering Threats) يستطيع كشف WireGuard بدقة قريبة من 100% بمطابقة هذا النمط على الحزمة الأولى.

OpenVPN أصعب قليلاً للكشف لكن ليس بكثير. handshake TLS له توقيت مميز وقناته التحكمية تستخدم تنسيق framing معروف. الجدار الناري الكبير في الصين كان يحجبه بشكل موثوق منذ سنوات.

المشكلة الأصعب هي تحليل الإنتروبيا. الحركة المشفرة بالكامل (بايتات عشوائية بلا بنية معروفة) تبدو فعلاً مريبة. حركة HTTPS العادية لها ملف إحصائي محدد: TLS handshake بسلاسل شهادات قابلة للتنبؤ، يتبعها بيانات تطبيق مشفرة بأحجام records مميزة. اتصال Shadowsocks هو دفق من بايتات عالية الإنتروبيا من الحزمة الأولى. لمصنّف إحصائي، هذا الفرق واضح.

هذا هو التحدي الأساسي. التشفير يجعل بياناتك غير قابلة للقراءة، لكن الحركة نفسها لا تزال لها شكل. الرقباء لا يحتاجون لقراءة بياناتك. يحتاجون فقط للتعرف على ذلك الشكل.

لماذا يفشل الإخفاء التقليدي

قبل وجود Reality، جرّب مجتمع مقاومة الرقابة عدة نهج إخفاء حركة لهذه المشكلة.

obfs4 يلف الحركة في طبقة مصممة لتبدو كضوضاء عشوائية. عملت لفترة. ثم نشرت الصين وإيران مصنّفات تعلّم التدفقات عالية الإنتروبيا التي لا تطابق أي بروتوكول معروف. إذا لم تبدُ الحركة كـ HTTP أو HTTPS أو DNS أو بروتوكول شائع آخر، تُحجَب أو تُخنَق. الضوضاء العشوائية مميزة جداً عندما يكون كل شيء حولها منظماً.

Shadowsocks كان لديه نفس مشكلة الإنتروبيا. متغيرات AEAD حسّنت الأمور، لكن المشكلة الأساسية بقيت: الحركة لا تبدو مثل أي شيء شرعي. أنظمة DPI الصينية بدأت تحجب اتصالات Shadowsocks بكشف غياب TLS handshake قياسي مقترن بحمولات عالية الإنتروبيا.

Domain fronting (إرسال حركة إلى نطاق عبر CDN يوجّهها إلى آخر) عمل جيداً حتى أغلقته Google وAmazon وCloudflare بين 2018 و2020. اعتمد على تسامح مزودي CDN مع الممارسة. توقفوا.

Trojan كان تحسيناً. يحاكي HTTPS بأداء TLS handshake فعلي وخدمة موقع حقيقي للاتصالات غير المصرح بها. لكن Trojan يستخدم شهادة TLS مُكوَّنة ذاتياً، مما يعني أن سلسلة الشهادات مختلفة عما يقدمه موقع حقيقي. أي مسبار نشط يقارن شهادة خادمك بسجلات شفافية الشهادات يستطيع رصد التناقض.

النمط عبر كل هذه الأدوات: تحاول تقريب الحركة العادية دون أن تكون فعلاً حركة عادية. مع تحليل كافٍ، التقريب ينهار دائماً.

RPRX (مبتكر مشروع XTLS) لخّص المشكلة بوضوح: رقابة SNI whitelist جعلت كل أدوات التحايل القائمة على TLS قبل Reality غير متاحة في مناطق معينة بين عشية وضحاها. إذا قرر رقيب السماح فقط بالاتصالات لخوادم TLS معروفة وشرعية، أي أداة تستخدم شهادتها الخاصة ميتة.

كيف يعمل Reality فعلياً

Reality لا يقرّب TLS handshake. ينفّذ واحداً حقيقياً.

إليك تدفق الاتصال، خطوة بخطوة:

الخطوة 1: العميل يرسل ClientHello. عميلك يبدأ TLS 1.3 handshake. حقل Server Name Indication (SNI) يحتوي اسم مضيف لموقع حقيقي وشائع، مثل www.microsoft.com. العميل يستخدم مكتبة uTLS لنسخ بصمة TLS الدقيقة لمتصفح حقيقي (Chrome 120، Firefox، Safari، أيّاً كان ما تكوّنه). ClientHello متطابق بايت-بايت مع ما سيرسله ذلك المتصفح.

الخطوة 2: الخادم يستلم ClientHello. خادم Reality يفحص shortId المُشارَك مسبقاً ويتحقق من العميل باستخدام تبادل مفاتيح X25519. هذه المصادقة تحدث داخل حقول معتمة لأي مراقب، مخفية في امتداد key share في TLS handshake.

الخطوة 3: الخادم يتصل بموقع التمويه الحقيقي. خادم Reality يفتح اتصاله الخاص بـ TLS مع www.microsoft.com الفعلي (أو أي نطاق كوّنته كهدف تمويه). ينفّذ TLS handshake شرعي مع خوادم Microsoft.

الخطوة 4: الخادم يعيد توجيه الشهادة الحقيقية. سلسلة الشهادات التي تعيدها Microsoft تُمرَّر إلى عميلك. هذه شهادة حقيقية، موقّعة من CA حقيقية، لنطاق حقيقي. لا شيء للكشف لأنه لا شيء مزيف.

الخطوة 5: العملاء المصادقون يحصلون على نفق. إذا اجتاز العميل shortId ومصادقة X25519 في الخطوة 2، الخادم يؤسس نفق VLESS. حركة VPN تتدفق داخل ما يبدو كجلسة HTTPS عادية مع microsoft.com.

الخطوة 6: الاتصالات غير المصادقة تُعاد توجيهها. إذا اتصل أحد (مسبار رقيب نشط، باحث، أي شخص) بدون اعتماديات صالحة، الخادم يوكّل اتصالهم بشفافية إلى microsoft.com الحقيقي. يرون محتوى حقيقياً. headers حقيقية. سلوك حقيقي. لا شيء يميّز الخادم عن reverse proxy شرعي.

هذا هو الفرق الجوهري عن كل نهج سابق. الشهادة حقيقية. الموقع خلفها حقيقي. بصمة TLS تطابق متصفحاً حقيقياً. لا توجد كذبة قابلة للكشف في السلسلة كاملةً.

مقاومة الفحص النشط

الرقباء لا يحلّلون الحركة بشكل سلبي فقط. يفحصون الخوادم المريبة بنشاط.

الجدار الناري الكبير الصيني يفعل هذا منذ 2012 على الأقل. عندما يكشف اتصالاً قد يكون proxy، يعيد تشغيل handshake العميل أو يرسل مسباره الخاص للخادم. إذا استجاب الخادم بطريقة تختلف عن خدمة شرعية، يُحجَب.

هكذا يتم كشف خوادم Trojan في النهاية. مسبار يتصل، لا يصادق، والخادم يعيد صفحة ويب عامة. لكن شهادة TLS لا تطابق ما تقول سجلات شفافية الشهادات إن النطاق ينبغي أن يحمله. أو headers استجابة HTTP مختلفة بشكل خفي عن نشر حقيقي لذلك البرنامج. تناقضات صغيرة، لكن كافية.

Reality يهزم الفحص النشط تماماً. عندما يتصل مسبار بخادم Reality بدون اعتماديات صالحة، يُعاد توجيهه إلى موقع التمويه الحقيقي. الاستجابة ليست محاكاة. هي microsoft.com، تُقدَّم عبر proxy شفاف. نفس الشهادة. نفس headers. نفس السلوك. نفس المحتوى.

سيحتاج رقيب للتمييز بين "مستخدم يزور microsoft.com" و"خادم Reality يوكّل إلى microsoft.com". من الخارج، هذان متطابقان. جلسة TLS تبدو نفسها. استجابات HTTP نفسها. عنوان IP هو الشيء الوحيد المختلف، وعنوان IP يستضيف reverse proxy إلى microsoft.com ليس مريباً بطبيعته.

تدفق Vision وTLS-in-TLS

هناك متجه كشف أدق يعالجه Reality أيضاً. عندما تشغّل VPN داخل نفق TLS، حركة VPN المشفرة تحتوي handshakes TLS خاصة بها (كل موقع HTTPS تزوره يولّد واحداً). هذا يُنشئ نمط TLS-in-TLS: records TLS تحتوي ما هو واضح أنه records TLS أكثر، مرئي عبر تحليل الحركة حتى لو كان المحتوى مشفراً.

تدفق XTLS Vision (xtls-rprx-vision) يلغي هذا. بدلاً من التشفير المزدوج لحركة TLS، Vision يكشف عندما تكون الحمولة الداخلية محمية بـ TLS بالفعل ويمررها بأقل التفاف. طبقة TLS الخارجية تتعامل مع المصادقة والتأطير؛ بيانات TLS الداخلية تتدفق دون تشفير زائد.

ورقة USENIX أكدت أن Vision حقق أهداف تصميمه. نمط حركة اتصال VLESS+Vision لا يمكن تمييزه إحصائياً عن اتصال HTTPS مباشر بموقع التمويه.

هذا مهم لأن تحليل الحركة (النظر إلى أحجام الحزم والتوقيت والأنماط دون فك تشفير شيء) هو الهجوم الأكثر معقولية المتبقي ضد Reality. Vision يسد تلك الفجوة.

ما يجعله صعب الحجب

لحجب VLESS Reality، سيحتاج رقيب لفعل أحد ما يلي:

حجب نطاق التمويه كلياً. إذا كان Reality مكوّناً لانتحال microsoft.com، سيحتاج الرقيب لحجب microsoft.com. أو google.com. أو أي نطاق آخر يختاره المشغلون. حجب خدمات السحابة والإنتاجية الكبرى له تكاليف اقتصادية ضخمة. الصين قبلت تلك التكلفة لبعض الخدمات، لكن حتى الصين لم تحجب microsoft.com.

كشف مصادقة X25519 في TLS handshake. هذه المعلومات محمولة في امتداد key share، الذي مشفر في TLS 1.3. دون كسر TLS handshake نفسه، المصادقة غير مرئية.

التعرف على خوادم Reality حسب سمعة IP. هذا في الواقع أكثر النهج فعالية وجده الرقباء. TSPU الروسي بدأ يعلّم عناوين IP لـ VPS التي تستقبل اتصالات تطابق أنماطاً سلوكية معينة: اتصالات من IPs سكنية إلى IPs VPS تُوكّل أيضاً إلى مواقع معروفة. هذا ليس كشف Reality نفسه. إنه كشف أنماط البنية التحتية حوله. معدل الكشف لـ VLESS Reality المكوّن بشكل صحيح لا يزال أقل من 5% بناءً على تقارير المجتمع من فبراير 2026.

تحليل توقيت الحركة. حركة VPN لها خصائص توقيت مختلفة عن تصفح ويب عادي. مستخدم يبث فيديو عبر Reality يولّد تدفقات مستدامة وعالية الإنتاجية لا تطابق أنماط تصفح HTTPS النموذجية إلى microsoft.com. هذا ضعف حقيقي، رغم أنه يتطلب تحليلاً متطوراً وينتج إيجابيات كاذبة كثيرة.

إيران تحقق في حجب Reality (نوقش في GitHub issue #3269 على مستودع Xray-core). حتى الآن، لم تُنشَر طريقة كشف موثوقة. نهج روسيا في تسجيل سمعة IP هو الأكثر نجاحاً، لكنه يلتقط نسبة صغيرة من الاتصالات ويتطلب ضبطاً يدوياً مستمراً.

المقايضات

نشغّل VLESS Reality في الإنتاج في Fexyn، إلى جانب WireGuard وOpenVPN. لن نتظاهر أنه غداء مجاني. هناك تكاليف حقيقية.

زمن الاستجابة. اتصال Reality يضيف حوالي 100ms من زمن الاستجابة مقارنةً بـ WireGuard. TLS handshake الإضافي مع موقع التمويه، مصادقة X25519، وطبقة التوكيل كلها تأخذ وقتاً. للتصفح العام، هذا بالكاد ملحوظ. للألعاب أو الصوت في الزمن الحقيقي، ستشعر به.

عبء TCP. VLESS Reality يعمل فوق TCP. WireGuard يعمل فوق UDP. TCP له head-of-line blocking: إذا فُقدت حزمة واحدة، كل شيء خلفها ينتظر. على الشبكات ذات الفقد (اتصالات الموبايل، Wi-Fi مزدحم)، يعني هذا توقفات دورية تتجنبها بروتوكولات قائمة على UDP. وضع نقل XHTTP يساعد عبر multiplexing، لكن قيد TCP الأساسي يبقى.

تعقيد التكوين. WireGuard يحتاج زوج مفاتيح ونقطة نهاية. Reality يحتاج نطاق تمويه، shortId، زوج مفاتيح X25519، اختيار بصمة uTLS، تكوين نقل، واختباراً دقيقاً للتأكد من أن موقع التمويه يعمل بشكل صحيح. نتعامل مع هذا تلقائياً في Fexyn (العميل يستلم تكويناً كاملاً من API)، لكن المستضيفين الذاتيين لديهم المزيد لإدارته.

صعوبة التصحيح. عندما يفشل اتصال WireGuard، أنماط الفشل واضحة: مفتاح خاطئ، نقطة نهاية خاطئة، منفذ محجوب. عندما يفشل اتصال Reality، يمكن أن يكون نطاق التمويه، shortId، زوج المفاتيح، بصمة uTLS، طبقة النقل، موقع التمويه غير قابل للوصول من الخادم، أو نصف دزينة من الأشياء الأخرى. أمضينا وقتاً تصحيحياً كبيراً على اتصالات Reality تبيّن أنها مشاكل نطاق تمويه.

ليست كل نطاقات التمويه تعمل بنفس الجودة. موقع التمويه يحتاج لدعم TLS 1.3، أن تكون لديه شهادة تتسلسل إلى CA موثوقة، وأن يكون قابلاً للوصول من خادمك. بعض النطاقات تعمل بشكل مثالي. أخرى لها خصوصيات تسبب فشلاً خفياً. اختبرنا بشكل مكثف واستقررنا على مجموعة من أهداف تمويه موثوقة، لكن هذا تطلب عمل تجربة وخطأ حقيقي.

معدلات الكشف في العالم الحقيقي

استناداً إلى تقارير المجتمع واختباراتنا الخاصة:

البلد	WireGuard	OpenVPN	VLESS Reality
روسيا (TSPU)	محجوب فوراً	محجوب/مخنوق	~95% نجاح
الصين (GFW)	محجوب	محجوب	يعمل، حجوبات IP دورية
إيران	محجوب	متقطع	يعمل، تحت بحث نشط
تركمانستان	محجوب	محجوب	بيانات محدودة، أُبلِغ أنه يعمل

معدل فشل ~5% في روسيا يأتي بشكل أساسي من تسجيل سمعة IP، ليس كشف البروتوكول. استخدام نطاقات IP تبدو سكنية أو مزودي سحابة ليسوا في القوائم السوداء يقرّب معدل النجاح من 100%.

في الصين، التهديد الرئيسي هو الحجب القائم على IP بدلاً من كشف البروتوكول. GFW يحتفظ بقوائم نطاقات IP لـ VPS معروفة ويحجبها دورياً. اتصالات Reality من IPs نظيفة تعمل باستمرار.

متى تستخدمه

إذا كنت في بلد بدون رقابة نشطة، WireGuard هو الخيار الأفضل. أسرع، أبسط، ويستخدم UDP. لا يوجد سبب لقبول مقايضات Reality إذا لم يحاول أحد حجب اتصالك.

إذا كنت في أو تسافر إلى بلد ذي DPI نشط (روسيا، الصين، إيران، الإمارات، كثير من البلدان الأخرى)، VLESS Reality مع تدفق Vision هو البروتوكول الذي يعمل فعلياً. WireGuard سيُحجَب قبل أن تنهي handshake.

Fexyn يدعم كليهما، مع دوران بروتوكول تلقائي يبدّل إلى VLESS Reality عندما يُحجَب WireGuard. تحصل على سرعة WireGuard عندما يكون متاحاً ومقاومة Reality للرقابة عند الحاجة.

إذا أردت فهم المزيد عن بروتوكول VLESS نفسه (منفصلاً عن نقل Reality)، كتبنا تفصيلاً لـ VLESS يغطي بنية البروتوكول وكيف يقارن بالبدائل.

جرّب Fexyn مجاناً لمدة 7 أيام — Stealth (VLESS Reality مع تدفق Vision) مُضمَّن في كل خطة. الناشطون ومنظمو الحركات قد يرغبون في صفحة VPN للناشطين لتأطير نموذج التهديد.