الانتقال إلى المحتوى

دليل تغطية المسارات

البروكسي مقابل VPN مقابل WARP: أي مسارات شبكة المتصفح مشمولة فعلا؟

تعمل منتجات التوجيه على طبقات مختلفة. فقد يغير بروكسي المتصفح حركة HTTP إلى المواقع بينما يظل WebRTC أو DNS أو عائلة عناوين أخرى يسلك مسار نظام التشغيل.

إصدار الاختبار 2026.10.01روجعت في المراجع التقني: John Hale

إجابة سريعة

ما الذي يمكن أن تثبته هذه النتيجة

لا ينقل بروكسي HTTP عادة إلا حركة التطبيقات المعدة صراحة لاستخدامه. ويمكن لـ SOCKS5 نقل بروتوكولات أكثر، وقد يدعم تحليل الأسماء عن بعد، لكن سلوك العميل هو ما يحدد ما يمر عبر البروكسي. وتعمل شبكة VPN التي تشمل الجهاز بالكامل أو وضع حركة البيانات في WARP على طبقة مسار الجهاز، ومع ذلك قد تحدث الأنفاق المنقسمة والاستثناءات وأوضاع DNS وسياسات المتصفح مسارات مختلفة يمكن رصدها. لذا ينبغي اختبار كل إشارة قبل تغيير مسار واحد وبعده.

حدود الأدلة

الإشارات التي تفحص، وما لا تثبته

يفصل حكم التسرب الذي يعتمد عليه بين أدلة المتصفح القابلة للرصد والافتراضات المتعلقة بالهوية أو الملكية أو المسار المقصود.

الإشارات التي يفحصها دليل التشخيص هذا
الإشارةالأدلة المتاحةما لا تثبته
حركة HTTP/HTTPS في المتصفحالمسار العام الذي تراه طلبات الصفحات العادية ونقاط الاكتشاف الخاصة بكل عائلة.لا يثبت تغير عنوان الخروج الذي تراه المواقع أن UDP أو DNS أو WebRTC أو التطبيقات الأخرى تستخدم المسار نفسه.
مسار WebRTC/ICEالمرشحات العامة التي تكشفها حزمة الاتصال بين الأقران في المتصفح.لا يصف إعداد بروكسي المتصفح تلقائيا كيفية توجيه مقابس ICE.
مسار DNSالمحللات التكرارية المرصودة عبر استدعاءات مرجعية تحمل رموزا فريدة.لا تكشف جغرافيا المحلل وحدها أي مكون محلي اختاره.
سلوك المسارات المنقسمةالإشارات التي تبقى على خط الأساس المباشر المحفوظ بعد تفعيل بروكسي أو ملف تعريف WARP أو VPN.لا تستطيع الأداة قراءة قواعد التوجيه الاحتكارية أو الاستثناءات أو إعدادات المنتج المشترى.

المنهجية

سير عمل يبدأ بخط الأساس

  1. 1

    بدء دون أي مسار قيد التقييم

    تسجيل أدلة IPv4 وIPv6 وWebRTC والمحللات المباشرة في ملف تعريف المتصفح نفسه. وحفظها كخط أساس قائم على إقرارك.

  2. 2

    تفعيل طبقة توجيه واحدة فقط

    اختبار بروكسي HTTP أو عميل SOCKS5 أو ملف تعريف WARP أو شبكة VPN التي تشمل الجهاز بالكامل كلا على حدة. فتكديس المسارات يصعب تحديد الطبقة التي كشفت إشارة ما.

  3. 3

    مقارنة كل قناة

    فحص طلبات الصفحات العادية وعائلتي IP وأدلة WebRTC المكتملة وملاحظات DNS المرجعية. وتبقى الأدلة المفقودة في حالة «غير متاح».

  4. 4

    فحص الإعدادات قبل الإصلاح

    استخدام وثائق العميل والمزود للتأكد من DNS عن بعد ودعم IPv6 ووضع حركة البيانات واستثناءات النفق المنقسم وسياسة WebRTC في المتصفح.

التفسير

كيف تترجم الأدلة إلى حالة مشروطة

«لا مؤشر» أضيق من «آمن»، و«مراجعة» ليست حكما بالتسرب، و«غير متاح» لا تتحول أبدا إلى نجاح.

لا مؤشر

كل القنوات العامة المقيسة إما تستخدم المسار المقصود أو لا تكشف أي عنوان غير متوقع من خط الأساس.

كانت القنوات المقيسة متسقة في هذا التشغيل؛ وتبقى التطبيقات غير المختبرة وتغييرات المسار المستقبلية خارج النطاق.

مراجعة

يتغير مسار HTTP لكن ملكية DNS/الشبكة ملتبسة، أو لا يمكن ربط إحدى القنوات بالمسار المقصود بثقة.

يلزم التحقق من وضع العميل وسلوك المزود بدلا من اعتبار عدم التطابق الجغرافي دليلا.

تسرب

يكشف WebRTC أو IPv4 أو IPv6 عنوانا يطابق خط الأساس المباشر تماما، بينما يستخدم المسار الظاهر للمتصفح البروكسي أو النفق.

تجاوزت قناة مقيسة واحدة على الأقل المسار المقصود.

غير متاح

تفشل عائلة عناوين أو استدعاء DNS أو عملية جمع مرشحات ICE في تقديم أدلة قابلة للاستخدام.

لا يمكن الحكم على المسار في تلك القناة بالسلامة ولا بالفشل. ينصح بإعادة المحاولة وفحص السياسة أو إمكانية الوصول إلى الخدمة.

استكشاف الأخطاء وإصلاحها

تشخيص المسار قبل تغيير الإعدادات

عنوان خروج بروكسي المتصفح صحيح، لكن WebRTC يطابق خط الأساس المباشر.

التفسير المرجح
البروكسي محصور على مستوى التطبيق، بينما يستخدم ICE مسار مقبس آخر في المتصفح أو نظام التشغيل.
الفحص التالي
تقييد WebRTC،‏ أو استخدام مسار يشمل الجهاز بالكامل، أو تعطيل WebRTC حيث يكون ذلك مناسبا؛ ثم المقارنة بخط الأساس نفسه مجددا.

يغير WARP أو VPN معظم الإشارات، لكن أحد المسارات يبقى مباشرا.

التفسير المرجح
استثناء في النفق المنقسم، أو بديل احتياطي للنطاقات المحلية، أو وضع حركة البيانات، أو فجوة في عائلة العناوين، أو قاعدة توافق في العميل.
الفحص التالي
فحص إعدادات المسار وDNS الرسمية. فوثائق Cloudflare تنص على أن حركة البيانات المستثناة تتجاوز عميلها، وأن لـ DNS ضوابط منفصلة.

يعمل SOCKS5 مع اسم مضيف، لكن DNS يبدو مباشرا.

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

الحدود

ما لا يستطيع هذا الدليل والاختبار ضمانه

  • يصف الجدول نطاقات التوجيه الشائعة، لا ضمانا لكل منتج أو نظام تشغيل أو متصفح أو إضافة أو سياسة مؤسسية.
  • WARP اسم منتج من Cloudflare؛ ويجب التحقق من أوضاعه وسلوك النفق المنقسم فيه وفق العميل المثبت حاليا والوثائق الرسمية.
  • لا تستطيع صفحة ويب عادية فحص جدول التوجيه الكامل لنظام التشغيل أو إعدادات العميل الاحتكارية.
  • قد تنشئ البروكسيات المكدسة والأنفاق والحاويات والأجهزة الافتراضية والمتصفحات البعيدة أكثر من مسارين عامين مشروعين.