شرح XRay core: المحرك خلف VPN المقاوم للرقابة

الناس يستمرون في تسمية XRay بروتوكول VPN. ليس كذلك. XRay منصة proxy. فكّر فيه مثل nginx، لكن بدلاً من توجيه طلبات HTTP لخوادم خلفية، يوجّه اتصالات شبكة كاملة عبر أنفاق مشفرة باستخدام أي بروتوكول تريد.

VLESS بروتوكول. Reality طبقة مصادقة. WireGuard بروتوكول. XRay هو الشيء الذي يشغّل VLESS وReality على جانب الخادم. الحصول على هذا التمييز بشكل صحيح يهم إذا أردت فهم لماذا يعمل نظام مقاومة الرقابة البيئي بالطريقة التي يعمل بها.

من أين أتى XRay

القصة تبدأ مع V2Ray، مشروع أُنشِئ حوالي 2015 من قبل شخص يستخدم اسم "Victoria Raymond" المستعار. V2Ray قدّم بروتوكول VMess وبنية معيارية حيث تستطيع تبديل النقل (TCP، WebSocket، gRPC) باستقلالية عن بروتوكول proxy نفسه. كانت فكرة جيدة وكسبت زخماً سريعاً، خاصة في الصين حيث احتاج الناس لأدوات تستطيع البقاء أمام الجدار الناري الكبير.

بحلول 2020، مبتكر V2Ray الأصلي هدأ. مجتمع V2Fly صان fork اسمه v2fly-core. مطور معروف بـ RPRX ساهم بـ XTLS، تحسين أداء يسمح لحركة proxy بتخطّي طبقات تشفير TLS الزائدة. كانت مساهمة تقنية مهمة.

ثم أصبحت الأمور فوضوية.

في نوفمبر 2020، كود XTLS من RPRX أُزِيل من v2ray-core بسبب نزاع ترخيص. التفاصيل معقدة وسياسية بعض الشيء، لكن النتيجة كانت نظيفة: RPRX عمل fork لـ v2fly-core (من commit 9a03cc5) وأنشأ xray-core. كسر نظيف.

XRay تحرك أسرع بعد الانقسام. RPRX شحن XTLS Vision، ثم Reality، ثم XHTTP. المشروع يجلس حالياً على 35,900+ نجمة GitHub مقابل ~22,000 لـ V2Ray. المجتمع صوّت بـ commits. معظم التطوير النشط في فضاء proxy مكافحة الرقابة الآن يحدث في xray-core أو مشاريع مبنية عليه.

ماذا يفعل XRay فعلاً

XRay هو ثنائي Go. تطعمه تكوين JSON يعرّف inbounds (مستمعات) وoutbounds (وجهات)، ويوكّل الحركة بينها. هذا هو النموذج كاملاً.

القوة في ما تستطيع جمعه. XRay يدعم بروتوكولات proxy متعددة:

• VLESS، الذي خفيف الوزن بدون عبء تشفير (يعتمد على طبقة النقل لذلك)
• VMess، بروتوكول V2Ray الأصلي مع تشفير AES-128-GCM (مصادقة MD5 أُزِيلت مؤخراً)
• Trojan، الذي يحاكي حركة HTTPS باستخدام مصادقة قائمة على كلمة مرور
• Shadowsocks-2022، إعادة الكتابة الحديثة بشيفرات AEAD-2022

كل من هذه يستطيع العمل فوق أي من نقل XRay:

• TCP خام
• mKCP (قائم على UDP، مثل KCP لكن معدّل)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (نقل HTTP المتعدد الإرسال الخاص بـ XRay، مُضاف في 2025)

لذا تستطيع تشغيل VLESS فوق WebSocket خلف CDN، أو Trojan فوق gRPC عبر Cloudflare، أو VLESS فوق TCP خام مع مصادقة Reality. البروتوكول والنقل مستقلان. اخلط وطابق بناءً على ما تسمح به بيئة شبكتك.

XRay له أيضاً محرك توجيه. تستطيع كتابة قواعد ترسل حركة لنطاقات معينة عبر outbound واحد، تحجب الإعلانات عبر آخر، وتوجّه كل شيء آخر عبر proxy. هو أقرب إلى مكدس شبكة قابل للبرمجة من نفق بسيط.

XTLS ولماذا يهم الأداء

إعدادات proxy القياسية لها مشكلة. عندما تزور https://example.com عبر proxy، تشفير TLS يحدث مرتين: مرة بين متصفحك وexample.com (TLS داخلي)، ومرة بين عميلك وخادم proxy (TLS خارجي). أنت تشفّر بيانات مشفرة بالفعل. هذا CPU مهدور وزمن استجابة مضاف.

XTLS Vision يصلح هذا. عندما يكشف XRay أن الاتصال الداخلي هو TLS 1.3 بالفعل، يتوقف عن تشفير الحمولة على طبقة proxy بعد اكتمال handshake. TLS الداخلي يقدّم السرية. الطبقة الخارجية تحتاج فقط للتعامل مع التفاوض الأولي.

XTLS splice يذهب أبعد على Linux. يستخدم استدعاء نظام splice() في kernel لإعادة توجيه بيانات TCP مباشرة بين واصفات الملفات دون نسخها عبر ذاكرة userspace كلياً. البيانات تتحرك من socket الشبكة إلى socket النفق كلياً في فضاء kernel. عملية Go الخاصة بـ XRay بالكاد تلمسها.

النتيجة: إنتاجية proxy ضمن نسبة قليلة من اتصال مباشر. على خادم بوصلة 1 Gbps، XTLS splice يستطيع إشباعها. proxies مزدوجة التشفير التقليدية تعلو بكثير تحت ذلك.

هذا سبب أن VLESS مع Reality يؤدي بشكل أفضل بكثير من أدوات التحايل الأقدم. البروتوكول خفيف، النقل فعّال، وXTLS يلغي ضريبة التشفير الزائد.

النظام البيئي حول XRay

XRay هو المحرك. نظام بيئي كامل من الأدوات نما حوله.

لوحات إدارة الخادم مثل 3X-UI تعطيك واجهة ويب لتكوين inbounds XRay، إدارة حسابات المستخدمين، ومراقبة النطاق الترددي. هي شائعة لخوادم proxy الشخصية لأنها تزيل الحاجة لتحرير تكوينات JSON يدوياً. إذا رأيت لقطات شاشة لإعداد proxy لشخص ما برسوم بيانية لطيفة وقوائم مستخدمين، على الأرجح هي 3X-UI أو fork منها.

عملاء سطح المكتب مثل V2RayN (Windows) وV2RayA (Linux) يلفون xray-core بـ GUI. يقرأون روابط الاشتراك، يديرون قوائم الخوادم، ويتعاملون مع قواعد التوجيه. معظم المستخدمين في البلدان المراقَبة يتفاعلون مع XRay عبر أحد هؤلاء العملاء، ليس الثنائي الخام.

sing-box هو المثير للاهتمام. هو منصة proxy أحدث مكتوبة من الصفر من قبل مطور SagerNet. يدعم كل بروتوكولات XRay (VLESS، VMess، Trojan، Shadowsocks) بالإضافة إلى Hysteria2 وTUIC وآخرين. الأهم، يُجمَّع إلى مكتبة موبايل عبر gomobile. هذا ما يجعل VLESS Reality ممكناً على الهواتف. لا تستطيع بشكل معقول تشغيل xray-core على iOS أو Android، لكن تستطيع تضمين libbox من sing-box في تطبيق أصلي.

النظام البيئي ينقسم تقريباً على هذه الخطوط: xray-core يهيمن على الخوادم، V2RayN/V2RayA على أجهزة سطح المكتب، وsing-box على الموبايل. كلها تتحدث نفس البروتوكولات.

كيف يستخدم Fexyn XRay

نشغّل xray-core على خوادم VPN. كل خادم له مدخل VLESS Reality على المنفذ 443 (TCP مع مصادقة Reality) ومدخل XHTTP على المنفذ 8444 (لبيئات حيث TCP الخام إلى المنفذ 443 مفلتر لكن نقل قائم على HTTP يمر).

على الخادم، Fexyn Agent يدير عملية xray-core، يتعامل مع دوران المفاتيح، ويزوّد UUIDs لكل مستخدم. عندما تتصل بـ VLESS محدداً، الوكيل يولّد اعتمادياتك والعميل يستلم تكويناً يشير إلى الخادم الصحيح بمفاتيح Reality الصحيحة.

جانب العميل حيث تصبح الأمور مثيرة. على Windows، لا نستخدم xray-core على الإطلاق. بدلاً من ذلك، نُنشئ محول Wintun TUN ونشغّل tun2socks لتوجيه كل حركة النظام إلى proxy SOCKS5 يقدّمه xray-core. في الواقع، نشغّل xray-core مُعرَّى في وضع SOCKS proxy، وtun2socks يلتقط الحزم من واجهة TUN، يعيد بناء جلسات TCP/UDP، ويعيد توجيهها عبر ذلك SOCKS proxy. نظام التشغيل يرى محول شبكة عادي. كل الحركة تذهب عبره. لا حاجة لتكوين proxy على مستوى التطبيق.

على Android وiOS، نستخدم sing-box المُجمَّع كمكتبة أصلية. يتعامل مع نفس بروتوكول VLESS Reality لكن يعمل داخل إطار VPN لنظام التشغيل (VpnService في Android، NEPacketTunnelProvider في iOS). sing-box كان الخيار الصحيح هنا لأن xray-core لا يبني بشكل نظيف لمنصات الموبايل، وlibbox من sing-box صُمِّم لهذا الاستخدام بالضبط.

النتيجة هي نفسها عبر كل المنصات: حركتك تبدو كشخص يتصفح microsoft.com (أو أي SNI يستهدفه تكوين Reality). أنظمة DPI ترى اتصال TLS 1.3 إلى نطاق شرعي. المسبارات النشطة ضد خادمنا يُعاد توجيهها إلى الموقع الحقيقي. مقارنة البروتوكول مع WireGuard تأتي بالضبط لهذا: WireGuard أسرع لكن قابل للبصم بساطة، بينما VLESS Reality يضحي بقليل من الإنتاجية لإخفاء شبه كلي.

XRay مقارنة بأدوات أخرى

فضاء مكافحة الرقابة لديه مشاريع كثيرة. إليك أين يقع XRay.

Shadowsocks كان الأصلي. proxy مشفر بسيط، سريع، وحيد الغرض. إعادة كتابة 2022 (Shadowsocks-2022) أصلحت ضعفاً تشفيرياً قديماً، لكن Shadowsocks لديه مشكلة كشف: GFW يستطيع تعريف أنماط حركته عبر تحليل إحصائي لأطوال الحزم والتوقيت. لا يزال يعمل في بعض المناطق. أقل موثوقية من VLESS Reality في المناطق المراقَبة بشدة.

V2Ray (v2fly-core) هو سلف XRay. لا يزال يُصان، لا يزال يعمل. لكنه يفتقر XTLS Vision وReality وXHTTP. إذا احتجت تلك الميزات، وفي 2026 تحتاجها بالتأكيد تقريباً، تحتاج xray-core.

Trojan-GFW كان ذكياً عند إطلاقه. يموّه حركة proxy كـ HTTPS بتشغيل خادم ويب حقيقي إلى جانب proxy. Reality أخذ هذه الفكرة أبعد بإلغاء الحاجة لامتلاك شهادة TLS حقيقية لنطاق الهدف.

Hysteria 2 يستخدم QUIC (قائم على UDP) مع إخفاء. إنتاجية رائعة، لكن البروتوكولات القائمة على QUIC تحصل على اهتمام أكبر من الرقباء. بعض الشبكات تحجب أو تخنق QUIC كلياً الآن. الأدوات القائمة على TCP مثل VLESS Reality أصعب للحجب الشامل لأنك ستضطر لحجب HTTPS نفسها.

NaiveProxy يستخدم مكدس شبكة Chrome لتوليد حركة متطابقة إحصائياً مع متصفح Chrome حقيقي. صعب جداً للكشف، لكن إعداد جانب العميل أكثر تعقيداً ولا يوجد لديه نفس النظام البيئي للوحات والعملاء.

ميزة XRay ليست أنه يفعل شيئاً واحداً أفضل من كل بديل. الميزة هي أنه منصة. يشغّل بروتوكولات متعددة، يدعم نقل متعدد، له محرك توجيه ناضج، وله أكبر مجتمع نشط. عندما يطوّر GFW طريقة كشف جديدة، xray-core يحصل على مضاد خلال أسابيع. هذه فائدة 35,000+ نجمة وصائن نشط يعامل هذا كسباق تسلح.

إلى أين يتجه

تطوير XRay لم يبطئ. الإصدارات الأخيرة جرّدت كوداً قديماً: مصادقة MD5 في VMess ذهبت، دعم MTProto أُزِيل. قاعدة الكود تصبح أنحف.

ميزتان قادمتان تبرزان. XDRIVE نقل يموّه حركة proxy كعمليات تخزين سحابي. XICMP يستخدم حزم ICMP كطبقة نقل. كلتاهما تجريبيتان، لكنهما تمثلان نفس النمط الذي عرّف تطور XRay: أوجد نوع حركة يسمح به الرقباء، وابنِ نقل حوله.

مخطط الإصدار يخبرك شيئاً عن الوتيرة. XRay يستخدم تنسيق vYY.M.DD. الإصدار v26.2.6 يعني 6 فبراير 2026. الإصدارات متكررة. المشروع يتحرك سريعاً لأنه مضطر. الجدار الناري الكبير لا ينتظر دورات إصدار ربع سنوية.

إذا كنت تبني أي شيء يحتاج للنجاة في شبكة مراقَبة، XRay هو المحرك الذي على الأرجح تريد تشغيله على جانب الخادم. ليس الخيار الوحيد. لكنه الذي له أكثر زخم، أوسع دعم بروتوكول، وأسرع استجابة لتقنيات رقابة جديدة. لهذا اخترناه لـ Fexyn.