VLESS مقابل WireGuard: حين تلتقي السرعة بمقاومة الرقابة
WireGuard على الأرجح أفضل بروتوكول VPN صُمِّم على الإطلاق للشبكات غير المقيّدة. VLESS Reality على الأرجح أفضل بروتوكول للشبكات حيث يحاول أحد بنشاط إيقافك. هذه مشاكل مختلفة، والبروتوكولات التي تحلها لا تشبه بعضها أبداً.
معظم مقالات المقارنة تختار فائزاً. لن نفعل، لأن الإجابة تعتمد على أين أنت وكيف تبدو الشبكة بينك وبين الخادم. نشحن كلا البروتوكولين في Fexyn ونبدّل تلقائياً بينهما لهذا السبب. (لنظرة أعلى مستوى عن ما هو بروتوكول VPN فعلاً، ابدأ هناك.)
إليك ما يهم فعلاً عند الاختيار بينهما.
WireGuard: لماذا أصبح الافتراضي
WireGuard كسب سمعته. البروتوكول كله حوالي 4,000 سطر من كود kernel. للمقارنة، OpenVPN يزيد عن 100,000 سطر. تطبيقات IPsec تعمل أطول. قواعد كود أصغر تعني أماكن أقل لاختباء البقات، الذي يهم بشكل هائل لبرنامج حرج أمنياً.
الخيارات التشفيرية رأي وثابتة: ChaCha20-Poly1305 للتشفير المتماثل، Curve25519 لتبادل المفاتيح، BLAKE2s للتجزئة. لا يوجد تفاوض cipher، لا مصفوفة تكوين، لا قائمة "اختر خوارزميتك المفضلة". هذا قرار تصميمي مقصود من Jason Donenfeld، ويلغي فئة كاملة من هجمات downgrade التي تبتلي البروتوكولات بـ cipher suites قابلة للتكوين.
الأداء يتبع من المعمارية. WireGuard يعمل على مستوى kernel (أو في userspace عبر boringtun)، معالجاً الحزم بأقل تبديل سياق. نقل UDP يتجنب مشكلة head-of-line blocking في TCP كلياً. على اتصال 500 Mbps فايبر، WireGuard يقدّم باستمرار حوالي 480 Mbps في اختبارنا. هذا 96% من الإنتاجية الأساسية. بالكاد تدفع ضريبة للتشفير.
تأسيس الاتصال سريع أيضاً. handshake WireGuard هو دورة واحدة: المُبدِئ يرسل رسالة مشفرة، المُستجِيب يرسل واحدة للخلف، والنفق حي. في تطبيق Fexyn على Windows، تسلسل الاتصال الكامل من "المستخدم ينقر اتصال" إلى "الحركة تتدفق عبر النفق" متوسطه حوالي 611 مللي ثانية. معظم ذلك الوقت يُقضى في إعداد محول TUN وتكوين routes، لا في انتظار البروتوكول نفسه.
لغالبية المستخدمين على غالبية الشبكات، WireGuard هو الخيار الصحيح. سريع، بسيط، وله سنوات من تصلب الإنتاج عبر Linux وWindows وmacOS وiOS وAndroid.
مشكلة 148-بايت
WireGuard لديه ضعف لا يستطيع أي قدر من الهندسة الذكية إصلاحه، لأنه نتيجة مباشرة لفلسفة تصميم البروتوكول.
كل رسالة بدء handshake في WireGuard تماماً 148 بايت طولاً. البايت الأول 0x01 (نوع الرسالة 1: بدء handshake). الثلاث بايتات التالية 0x00 0x00 0x00 (محجوز، دائماً صفر). يتبع ذلك فهرس مرسل 4 بايت ثم مفتاح Curve25519 ephemeral عام 32 بايت غير مشفر.
هذه البنية لا تتغير أبداً. لا تستطيع التغير؛ مواصفة البروتوكول تتطلبها.
أنظمة فحص الحزم العميق تستغل هذا. منطق الكشف بسيط بشكل محرج. إليك ما يفحصه nDPI، مكتبة DPI مفتوحة المصدر يستخدمها بائعو معدات الشبكة عالمياً، فعلياً:
if (message_type == 1 && packet_length == 148)
→ classify as WireGuard
هذا كل شيء. شرط واحد. handshake 148 بايت بـ 0x01 0x00 0x00 0x00 رائدة بصمة فريدة لا ينتجها أي بروتوكول آخر. لا تحتاج لتعلّم آلي أو تحليل إحصائي. طالب شبكات في السنة الأولى يستطيع كتابة هذا الفلتر.
TSPU الروسي (Technical Systems for Countering Threats) كان يحجب WireGuard بدقة قريبة من 100% منذ منتصف 2024. ليس خنق، ليس تدهور. حجب. حزم UDP التي تحمل handshakes WireGuard تختفي ببساطة. الجدار الناري الكبير الصيني يفعل نفس الشيء. إيران تحجبه. أي حكومة تشغّل معدات DPI حديثة تستطيع إضافة WireGuard إلى قائمة الحجب في فترة بعد ظهر.
مشروع WireGuard على علم بهذا. ليس بقاً. البروتوكول صُمِّم للسرعة والبساطة، ليس للتخفي. جعل handshake متغير الطول أو إضافة حشو سيعقّد البروتوكول وينتهك مبدأ التصميم الأساسي للحد الأدنى من التعقيد. هذه مقايضات معقولة لنموذج التهديد الذي يستهدفه WireGuard. تعني فقط أن WireGuard هو الأداة الخاطئة إذا كنت على شبكة حيث أحد يفحص الحركة بنشاط.
AmneziaWG: إصلاح جزئي
AmneziaWG 2.0 يحاول معالجة مشكلة البصمة بإضافة حشو عشوائي إلى حزم WireGuard، باستخدام headers ديناميكية، وحقن حزم قمامة. يجعل الكشف أصعب فعلاً. لكنه لا يزال يعمل ضمن إطار WireGuard القائم على UDP، مما يعني أن الرقباء يستطيعون تطبيق التحليل الإحصائي على توزيع حجم الحزم وفترات التوقيت وخصائص الإنتروبيا. حركة UDP التي لا تطابق أي بروتوكول معروف مريبة افتراضياً في البيئات المراقَبة بشدة.
AmneziaWG خطوة للأمام. ليس حلاً للمشكلة الأساسية.
VLESS Reality: الاختباء على مرأى من الجميع
VLESS يأخذ النهج المعاكس لـ WireGuard في كل تقريباً. حيث WireGuard بروتوكول VPN مبني لغرض بشكل سلكي فريد، VLESS بروتوكول proxy يفوّض تشفيره كلياً لـ TLS 1.3. header VLESS نفسه يضيف فقط 25 إلى 50 بايت من العبء، يحتوي على بايت إصدار، UUID للمصادقة، ومعلومات توجيه.
البروتوكول يعمل فقط داخل اتصال TLS. اخلع TLS وVLESS لا تشفير له، لا حماية تكامل، لا شيء. هذه التبعية على TLS كثيراً ما تُنتقَد كضعف. هي في الواقع مصدر أعظم قوة لـ VLESS.
VLESS Reality مع تدفق Vision يمتد البروتوكول الأساسي بنظام تمويه يجعل الاتصال غير قابل للتمييز فعلاً عن حركة HTTPS العادية. عندما تتصل بخادم Fexyn باستخدام Reality+Vision، الخادم ينفّذ TLS handshake حقيقي مع موقع فعلي، مثل www.microsoft.com، ويعيد توجيه شهادة ذلك الموقع الشرعية إلى عميلك. عميلك يستخدم مكتبة uTLS لإنتاج رسالة ClientHello متطابقة بايت-بايت مع ما سيرسله Chrome أو Firefox.
إذا فحص رقيب الخادم، يُعاد توجيهه إلى microsoft.com الحقيقي. شهادة حقيقية. محتوى حقيقي. headers HTTP حقيقية. لا توجد محاكاة. الخادم يعمل كـ reverse proxy شفاف للاتصالات غير المصادقة وكنفق VLESS للمصادقة.
النتيجة أنه لا نظام DPI سلبي يستطيع تمييز جلسة VLESS Reality عن شخص يتصفح موقع Microsoft. الفحص النشط يفشل أيضاً لأن المسبار يستلم استجابات أصيلة من موقع أصيل. الكشف سيتطلب من الرقيب التمييز بين "مستخدم يزور microsoft.com" و"خادم Reality يوكّل إلى microsoft.com"، اللذان من منظور الشبكة هما نفس الشيء.
هذا يعمل في روسيا. يعمل في الصين. يعمل في إيران. ليس نظرياً. الآن، في الإنتاج، لمستخدمين حقيقيين.
ما يتنازل عنه VLESS
VLESS Reality ليس مجانياً. تتداول أشياء للحصول على ذلك الإخفاء.
التكلفة الأكبر هي TCP. VLESS يعمل فوق TCP (عبر TLS)، مما يعني أنه يرث مشكلة head-of-line blocking في TCP. إذا فُقدت حزمة واحدة، كل حزمة لاحقة في ذلك دفق TCP تنتظر إعادة الإرسال. WireGuard يتجنب هذا بالعمل على UDP. على اتصالات ذات فقد، النوع الذي تحصل عليه على Wi-Fi مزدحم أو شبكات موبايل بتغطية متقطعة، الفرق قابل للقياس. VLESS أيضاً TCP-only، فترة. XHTTP (خيار نقل أحدث في Xray-core) يضيف multiplexing لكنه لا يغيّر قيد TCP الأساسي. للألعاب أو الصوت في الزمن الحقيقي، حيث زمن الاستجابة يهم أكثر من الموثوقية، نقل UDP في WireGuard أفضل ملاءمة.
مسار الاتصال أكثر تعقيداً أيضاً. جلسة VLESS Reality تتضمن TLS 1.3 handshake (1-RTT أو 0-RTT)، تفاوض بروتوكول VLESS، وربما إعداد محول TUN مع توجيه tun2socks. أجزاء متحركة أكثر من handshake دورة واحدة في WireGuard. على جانب الخادم، Reality يحتفظ باتصال TLS بوجهة التمويه ويدير منطق proxy للاتصالات غير المصادقة. هذا يكلف ذاكرة وCPU أكثر لكل عميل من معالجة حزم WireGuard في kernel-space. على المقياس، الفرق يتراكم لمشغلي الخوادم.
ثم هناك القابلية للتدقيق. 4,000 سطر من كود WireGuard تم التحقق منها رسمياً وتدقيقها على نطاق واسع. Xray-core قاعدة كود Go كبيرة بمساحة سطح أكبر بكثير. بروتوكول VLESS الأساسي بسيط، لكن التطبيق المحيط (Reality، بصمة uTLS، أوضاع نقل متعددة) لم يتلقَ نفس مستوى المراجعة الأمنية المستقلة.
هذه تكاليف حقيقية. مقبولة عندما يكون البديل حجب اتصالك. ليست تكاليف ينبغي أن تدفعها عندما لا تضطر.
وجهاً لوجه: أرقام أداء Fexyn
اختبرنا كلا البروتوكولين على نفس الأجهزة، نفس الخادم، نفس ظروف الشبكة. Windows 11، 500 Mbps فايبر، الاتصال بخادمنا في فرانكفورت. هذه الأرقام تأتي من قياسات مرجعية تلقائية، لا تشغيلات مختارة بعناية.
| المقياس | WireGuard | VLESS Reality |
|---|---|---|
| وقت الاتصال البارد | ~611 ms | ~627 ms |
| وقت إعادة الاتصال الدافئ | غير متاح | ~42 ms |
| وقت قطع الاتصال | ~108 ms | ~100 ms |
| الإنتاجية (أساس 500 Mbps) | ~480 Mbps (96%) | أقل (عبء TCP) |
| النقل | UDP | TCP (TLS 1.3) |
| دورات handshake | دورة واحدة | 1-RTT TLS + header VLESS |
| قابل للكشف بـ DPI | نعم، بساطة | لا، مع Reality |
| عبء البروتوكول لكل حزمة | ~32 بايت (Poly1305 tag + counter) | 25-50 بايت (VLESS) + record TLS |
أوقات الاتصال أقرب مما يتوقع معظم الناس. الفرق 16 مللي ثانية بين 611 ms و627 ms لاتصال بارد ليس شيئاً قد يدركه المستخدم. معظم ذلك الوقت في كلا الحالتين هو إعداد المحول، تكوين route، والتحقق، ليس زمن استجابة على مستوى البروتوكول.
VLESS له ميزة مثيرة على إعادات الاتصال الدافئة. لأن Xray-core يمكن إبقاؤه يعمل كعملية مستمرة بين الاتصالات، إعادة اتصال (تبديل خوادم أو التعافي من تغيير شبكة) تتطلب فقط إعادة تأسيس جلسة TLS. هذا يأخذ حوالي 42 مللي ثانية في اختبارنا. إعادات اتصال WireGuard أيضاً سريعة، لكن دورة تفكيك المحول وإعادة إنشائه الكاملة في تطبيقنا على Windows لا يوجد لديها نفس تحسين المسار الدافئ.
حيث يتقدم WireGuard بوضوح هو الإنتاجية. نقل UDP مع معالجة حزم على مستوى kernel (أو userspace عالي الأداء) يعطي WireGuard ميزة قابلة للقياس، خاصة على الاتصالات عالية النطاق الترددي. الفجوة تتسع على شبكات ذات فقد حيث سلوك إعادة الإرسال في TCP يضيف ارتفاعات في زمن الاستجابة.
متى تستخدم أيهما
هذا أبسط مما قد يوحي به باقي المقال.
استخدم WireGuard إذا كنت على شبكة حيث حركة VPN ليست محجوبة أو مخنوقة. إنترنت المنزل في معظم البلدان الغربية، شبكات المكاتب التي تسمح باستخدام VPN، شبكات الموبايل في البلدان بدون رقابة نشطة. WireGuard يعطيك أفضل إنتاجية، أقل زمن استجابة، وأبسط نموذج اتصال. هو الافتراضي الصحيح.
استخدم VLESS Reality إذا كنت على شبكة تحجب أو تتدهور بروتوكولات VPN. شبكات الجامعة التي تحجب WireGuard. جدران الشركات النارية التي تسمح فقط بـ HTTPS على المنفذ 443. Wi-Fi العام مع قيود قائمة على DPI. وبوضوح، أي مكان في روسيا، الصين، إيران، أو بلدان أخرى ذات رقابة إنترنت نشطة. VLESS Reality هو البروتوكول الإنتاجي الوحيد الذي اختبرنا أنه يمر من خلال كل هذه بموثوقية.
استخدم الدوران التلقائي إذا كنت تسافر بين كلا البيئتين أو إذا لست متأكداً مما تسمح به شبكتك. هذا وضع Fexyn الافتراضي: جرّب WireGuard أولاً للسرعة، ارجع إلى VLESS Reality إذا فشل WireGuard، ثم ارجع إلى OpenVPN كملاذ أخير. التبديل يحدث تلقائياً دون إسقاط حماية kill switch خاصتك.
لماذا يشحن Fexyn كليهما
معظم مزودي VPN يشحنون بروتوكولاً واحداً وربما يعرضون OpenVPN كاحتياطي قديم. NordLynx من NordVPN هو WireGuard مع طبقة NAT (انظر Fexyn مقابل NordVPN للتفصيل الكامل). Lightway من ExpressVPN بروتوكول مخصص لا يزال قابلاً للكشف بـ DPI. لا أي من مزودي VPN الغربيين الكبار يشحن VLESS Reality لأنه يأتي من نظام XRay/V2Ray البيئي، الذي هو في الأساس صيني-اللغة ويتطلب معرفة عميقة بقاعدة كود لا يوجد لها مواصفات رسمية.
نعتقد أن VPN ينبغي أن يعمل في كل مكان. على Wi-Fi المنزل حيث لا شيء يحجبك، نعم. أيضاً على شبكة الفندق في موسكو التي تشغّل TSPU. على حرم الجامعة الذي يسمح فقط بـ HTTPS. على Wi-Fi المقهى الذي يحجب UDP كلياً.
هذا يتطلب بروتوكولات متعددة بخصائص مختلفة. WireGuard للسرعة عندما لا شيء في الطريق. VLESS Reality للإخفاء عندما يوجد شيء. OpenVPN للشبكات النادرة حيث لا أي منهما يعمل لكن حركة VPN قائمة على TLS قديم لا تزال مسموحة.
محرك دوران البروتوكول في Fexyn يجرّبها بالترتيب بناءً على إعداد وضع الاتصال. "Speed first" يبدأ بـ WireGuard. "Stealth first" يبدأ بـ VLESS Reality. في كلا الحالتين، تنتهي متصلاً. اختيار البروتوكول تلقائي، kill switch يبقى نشطاً خلال الدوران، والمستخدم لا يحتاج لفهم أي من الفروق الموصوفة في هذا المقال.
يحتاجون فقط لأن يعمل إنترنتهم. حتى عندما يحاول أحد التأكد أنه لا يعمل.
تستطيع تجربة كلا البروتوكولين اليوم بـ اشتراك Fexyn.