ما هو تسريب WebRTC؟ كيف تختبره وتصلحه (دليل 2026)

تشغّل الـ VPN، تضيء العلامة الخضراء الصغيرة "متصل"، وتفترض أن عنوان IP الحقيقي مخفيّ. غالباً لا يكون كذلك. تسريب WebRTC هو قناة جانبية خفية موجودة في كل متصفح حديث، ويمكنها كشف عنوان IP الفعلي الذي خصصه لك مزوّد الخدمة — وأحياناً عنوان شبكتك المحلية — لأي موقع يرغب في طلبه. يحدث ذلك بمعزل عن نفق الـ VPN، ولهذا يفاجئ الكثيرين.

يشرح هذا الدليل ما هو تسريب WebRTC فعلاً، وكيف تختبره في أقل من دقيقة، والحل الدقيق لكروم وفايرفوكس وبريف وسفاري في 2026. ستتعلّم أيضاً أمرين ليسا تسريباً لكن يُخلط بينهما وبين التسريب كل يوم: عناوين .local الخاصة بـ mDNS، وعناوين الشبكة المحلية على المتصفحات الحديثة.

ما هو تسريب WebRTC؟

WebRTC (التواصل الفوري عبر الويب) هو واجهة برمجية في المتصفح تشغّل مكالمات الفيديو والدردشة الصوتية ومشاركة الشاشة ونقل الملفات المباشر بين الأجهزة — كل ذلك داخل المتصفح بلا أي إضافة. تستخدمها Google Meet وDiscord على الويب ومكالمات WhatsApp Web وZoom في المتصفح ومعظم نوافذ دردشة الدعم.

لبناء اتصال مباشر بين جهازين، يحتاج WebRTC إلى معرفة عناوين IP الخاصة بك. ويفعل ذلك بالاستعلام من خوادم STUN — وهي خوادم عامة على الإنترنت تُرجع لك العنوان الذي تراه واردًا منه. وهنا المشكلة: تخرج استعلامات STUN عبر بروتوكول UDP، وتتجاوز افتراضياً أي بروكسي SOCKS أو HTTP مُعدّ في متصفحك. هذا يعني أن رد STUN قد يكشف عنوان IP العام الحقيقي حتى بينما يُفترض أن نفق الـ VPN يحميك.

يحدث تسريب WebRTC عندما يشغّل موقع بضعة أسطر من كود WebRTC بلغة JavaScript، فيجمع العناوين التي اكتشفها متصفحك ويرسلها إلى خادمه الخاص. لا ترى أي نافذة طلب إذن. ولا يصلك أي تحذير. يعرف الموقع ببساطة عنوانك الحقيقي بينما تظن أنك مجهول الهوية.

كيف أختبر تسريب WebRTC؟

يستغرق اختبار تسريب WebRTC نحو 30 ثانية. لا يوجد برنامج للتثبيت. يعمل الاختبار داخل متصفحك ويستخدم واجهة WebRTC نفسها التي قد يستخدمها موقع خبيث — لذا فما يراه الاختبار هو بالضبط ما يستطيع أي موقع رؤيته.

استخدم اختبار تسريب WebRTC المجاني على هذا الموقع. وإليك الخطوات:

1. اتصل بالـ VPN أولاً. تأكد من أن لوحة تحكم الـ VPN تعرض الدولة والخادم اللذين اخترتهما.
2. افتح صفحة اختبار تسريب WebRTC في المتصفح نفسه الذي تستخدمه عادةً.
3. اضغط بدء الفحص. تستعلم الصفحة من خوادم STUN العامة لجوجل وتسرد كل عنوان IP يُرجعه متصفحك.
4. قارن صفوف عنوان IP العام مع لوحة تحكم الـ VPN. يجب أن تتطابق جميعها مع عنوان خروج الـ VPN، لا مع عنوان مزوّد خدمتك الحقيقي.
5. كرّر الاختبار مع فصل الـ VPN. يمنحك ذلك خط أساس — تلك هي العناوين التي يكشفها WebRTC حين لا تكون محمياً.

شغّل الاختبار في كل متصفح تستخدمه. فالـ VPN الذي ينجح في كروم قد يسرّب في فايرفوكس، لأن المتصفحين ينفّذان WebRTC بطريقتين مختلفتين قليلاً. وشغّله على الهاتف أيضاً — يعمل WebRTC بالطريقة نفسها في كروم لأندرويد وسفاري على iOS.

لماذا يسرّب WebRTC عنواني رغم استخدامي الـ VPN؟

الإجابة المختصرة: يطلق WebRTC طلبات STUN عبر UDP الخام، وكثير من برامج الـ VPN توجّه فقط حركة TCP/HTTP التي يبدأها المتصفح عبر نفقها. أما حزمة UDP الخاصة بـ STUN فتخرج عبر واجهة الشبكة الفيزيائية، وتصل إلى خادم STUN لدى جوجل، فيعود رد STUN حاملاً عنوانك الحقيقي — لأن ذلك الخادم يرى أن الطلب جاء من عنوانك الحقيقي.

يعتمد ما إذا كان الـ VPN سيسرّب على ثلاثة أمور:

• هل يوجّه برنامج الـ VPN حركة UDP؟ خدمات VPN الرخيصة والمجانية تتجاوز توجيه UDP لخفض التكاليف. كل ما هو على شكل TCP يمرّ عبر النفق؛ أما حزم STUN عبر UDP فلا.
• هل يتعامل مع IPv6؟ كثير من خدمات VPN تنفق IPv4 فقط. فإن أعطاك مزوّد خدمتك عنوان IPv6، فإن عنوان v6 يتجاوز النفق بالكامل. هذا هو السبب الأول لشكوى "لديّ VPN لكن عنواني الحقيقي ما زال يتسرّب".
• هل يحجب المزوّد حزم UDP غير الموجّهة عبر البروكسي على مستوى جدار الحماية في النواة؟ الأكثر حرصاً يفعلون ذلك (Mullvad وProtonVPN وNordVPN). فأي شيء يفلت من النفق لا يغادر الجهاز أصلاً.

أفضل VPN لحماية تسريب WebRTC

بناءً على طريقة تعامل كل مزوّد مع WebRTC كما يوثّقها علناً في 2026، هذه هي خدمات VPN التي تجتاز اختبارات التسريب باستمرار وبشكل افتراضي:

• Mullvad — يحجب حزم UDP غير الموجّهة عبر البروكسي على مستوى جدار الحماية. لا يفلت شيء إلا إذا أُدرج صراحةً في القائمة البيضاء.
• ProtonVPN — يتعامل مع IPv6 أصلياً (أو يحجبه بنظافة إن لم يدعمه الخادم). وينفق UDP افتراضياً.
• NordVPN — يختبر صراحةً ضد تسريبات WebRTC كجزء من سلوك مفتاح الإيقاف (kill switch).
• ExpressVPN — يستخدم مفتاح الإيقاف "network lock" لإسقاط أي حركة قد تفلت من النفق، بما في ذلك STUN الخاص بـ WebRTC.

خدمات VPN المجانية، وإضافات VPN في المتصفح، ومعظم خدمات VPN المرفقة مع برامج مكافحة الفيروسات غير موثوقة مع WebRTC. اختبر إعدادك بالتحديد عبر اختبار تسريب WebRTC — ولا تثق بالدعاية التسويقية.

كيف تصلح تسريبات WebRTC في كروم (وإيدج)

لا يحتوي كروم أي زر مدمج لتعطيل WebRTC في 2026. أزالت جوجل خيارات chrome://flags القديمة منذ سنوات. وهذا يترك ثلاثة حلول عملية:

الحل 1: ثبّت إضافة WebRTC Network Limiter الرسمية من جوجل

تنشر جوجل إضافة رسمية لكروم باسم WebRTC Network Limiter على متجر كروم. لا تعطّل WebRTC بالكامل — بل تخبر كروم بأن يستخدم فقط UDP الموجّه عبر البروكسي وألا يرتبط بمسارات غير افتراضية. عملياً، يوقف ذلك معظم التسريبات مع إبقاء مكالمات الفيديو فعّالة.

1. افتح صفحة WebRTC Network Limiter على متجر كروم.
2. اضغط إضافة إلى Chrome. لا يحتاج إلى إعداد — يُطبَّق فوراً.
3. أعد الاختبار عبر اختبار تسريب WebRTC.

الحل 2: استخدم إعداد WebRTC في uBlock Origin

إن كنت تستخدم uBlock Origin أصلاً، فيوجد خيار مدمج يحجب تسريبات العنوان المحلي عبر WebRTC دون إيقاف مكالمات الفيديو:

1. اضغط أيقونة uBlock Origin في شريط الأدوات، ثم أيقونة التروس لفتح اللوحة.
2. انتقل إلى تبويب الإعدادات (يُسمى الخصوصية في بعض الإصدارات).
3. فعّل خيار منع WebRTC من تسريب عناوين IP المحلية.
4. اضغط تطبيق التغييرات.

الحل 3: انتقل إلى VPN مزوّد بحجب تسريب مدمج

الحل الأنظف هو على مستوى النواة: VPN يرفض توجيه أي حزمة UDP خارج نفقه. يمنع ذلك استعلام STUN من الوصول إلى خوادم جوجل أصلاً، فلا يبقى ما يُسرَّب. كل من Mullvad وNordVPN وProtonVPN يفعل ذلك مع تفعيل مفتاح الإيقاف.

الحلول الثلاثة نفسها تعمل في Microsoft Edge — فإيدج مبني على Chromium، لذا منظومة الإضافات والسلوك متطابقان.

كيف تصلح تسريبات WebRTC في فايرفوكس (about:config)

فايرفوكس هو المتصفح الرئيسي الوحيد الذي يمكنك فيه تعطيل WebRTC بالكامل بإعداد واحد — بلا إضافة.

أعد الاختبار عبر اختبار تسريب WebRTC — يجب أن يُبلّغ كل حقل الآن بأن "WebRTC معطّل" أو لا يُرجع أي عناوين.

كيف تصلح تسريبات WebRTC في Brave

Brave هو المتصفح الرئيسي الوحيد الذي يحتوي زر تعطيل تسريب WebRTC في واجهة الإعدادات. لا تحتاج إلى إضافة ولا إلى حيلة about:config.

1. افتح تبويباً جديداً وانتقل إلى brave://settings/privacy.
2. انزل إلى سياسة معالجة IP في WebRTC.
3. غيّر القائمة المنسدلة إلى تعطيل UDP غير الموجّه عبر البروكسي.
4. أغلق Brave وأعد فتحه، ثم أعد الاختبار عبر اختبار تسريب WebRTC.

خيار "تعطيل UDP غير الموجّه عبر البروكسي" هو نقطة التوازن المثالية: يظل WebRTC يعمل للمكالمات الموجّهة عبر بروكسي VPN، لكنه يرفض إرسال استعلامات STUN عبر اتصال UDP مباشر (غير موجّه عبر بروكسي). لا تسريب، والمكالمات تبقى فعّالة.

كيف تصلح تسريبات WebRTC في سفاري (macOS وiOS)

سلوك WebRTC في سفاري أكثر صرامة افتراضياً — فالعناوين المحلية مخفية تلقائياً، والعناوين العامة تمرّ عبر أي بروكسي مُعدّ في النظام. لكن إن أردت طبقة تحكّم إضافية:

سفاري على macOS

1. افتح سفاري، ثم اضغط Safari → الإعدادات → Advanced.
2. فعّل Show features for web developers في الأسفل.
3. سيظهر عنصر قائمة جديد باسم Feature Flags (أو قائمة "Develop").
4. افتحه وابحث عن المدخلات التي تحتوي WebRTC.
5. عطّل الخيارات المتعلقة بمرشّحات mDNS ICE أو واجهات WebRTC القديمة إن أردت تشديد الحماية أكثر. لاحظ أن هذه الأعلام تتغير بين إصدارات سفاري؛ والإعدادات الافتراضية في سفاري 17 فما فوق محترمة للخصوصية لمعظم المستخدمين.

سفاري على iOS / iPadOS

1. افتح تطبيق الإعدادات في iOS، وانزل إلى Safari.
2. انزل إلى Advanced → Experimental Features.
3. ابحث عن مدخلات WebRTC وعطّلها إن أردت تعطيل سلوكيات محددة.

على iOS، يقوم الـ VPN نفسه بالعبء الأكبر. فبخلاف خدمات VPN على سطح المكتب، يجبر iOS كل الحركة (بما فيها UDP) على المرور عبر ملف تعريف الـ VPN المُعدّ عند اتصاله — لذا فتسريبات VPN على iOS أندر منها على سطح المكتب، لكنها ليست مستحيلة.

هل ينبغي أن تعطّل WebRTC بالكامل؟

غالباً، لا. التعطيل الكامل لـ WebRTC أداة فجّة — يوقف التسريب لكنه يوقف أيضاً كل تطبيق يعتمد على WebRTC في متصفحك.

بالنسبة لمعظم الناس، الخطوة الصحيحة ليست التعطيل الكامل — بل إما اختيار VPN يحجب تسريبات WebRTC على مستوى الشبكة، أو تفعيل وضع "تعطيل UDP غير الموجّه عبر البروكسي" في Brave الذي يبقي WebRTC قابلاً للاستخدام مع جعله آمناً من التسريب.

إن كنت صحفياً أو ناشطاً أو باحثاً أمنياً أو أي شخص يشمل نموذج تهديده كشف هويته عبر صفحة ويب، فالتعطيل الكامل هو القرار الصحيح. تقبّل تعطّل مكالمات الفيديو واستخدم التطبيقات المثبَّتة لها. أما المستخدم العادي المهتم بالخصوصية، فمزيج VPN جيد مع Brave توازن أفضل.

ما هو mDNS ولماذا يظهر اختبار التسريب عنوان .local؟

إن شغّلت اختبار تسريب WebRTC على كروم في 2026 ورأيت صف عنوان محلي غريب مثل a1b2c3d4-5678-90ab-cdef-1234567890ab.local، فلم تتعرّض للاختراق. هذا هو mDNS (نظام أسماء النطاقات متعدد البث) — وهو إجراء خصوصية أضافه كروم في الإصدار 76 (الصادر في أغسطس 2019) واستخدمه كل متصفح مبني على Chromium منذ ذلك الحين.

إليك ما يحدث فعلاً:

• قبل mDNS، كان كروم يكشف عنوان شبكتك المحلية الحقيقي (مثلاً 192.168.1.42) لأي موقع يستخدم WebRTC. وكان يمكن استغلال ذلك لرسم خريطة شبكتك أو استهداف ثغرات الراوتر.
• مع mDNS، يولّد كروم اسماً عشوائياً مشفّراً ينتهي بـ .local ويكشفه بدلاً من العنوان المحلي الحقيقي.
• التشفير فريد لكل جلسة متصفح، ولا يمكن عكسه إلى عنوان IP حقيقي، ولا يعني شيئاً خارج شبكتك المحلية.

لذا فرؤية عنوان .local في اختبار التسريب تعني أن الحماية تعمل، لا أنه تسريب. التسريب الحقيقي هو أن ترى عنوان 192.168.x.x الفعلي بدلاً منه.

شاهد: شرح تسريب WebRTC في 3 دقائق

إن كنت تفضّل شرحاً مرئياً، يغطي هذا الفيديو القصير طريقة تعطيل WebRTC في فايرفوكس وأسلوب الإضافة في كروم:

الأسئلة الشائعة — إجابات سريعة

هل يوقف وضع التصفح المتخفي تسريبات WebRTC؟

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

هل تستطيع المواقع رؤية عنوان IP المحلي عبر WebRTC؟

في كروم وإيدج وBrave وفايرفوكس الحديثة — لا. تُخفى عناوين الشبكة المحلية خلف تشفيرات mDNS (أسماء .local) إلا إذا مُنح الموقع إذن الكاميرا أو الميكروفون. أما المتصفحات القديمة (ما قبل 2019) وبعض المتصفحات المقيّدة في الشركات بلا mDNS فلا تزال قد تكشف عناوين 192.168.x.x الخام.

هل يوقف تعطيل IPv6 تسريبات WebRTC؟

جزئياً. إن كان الـ VPN ينفق IPv4 فقط، فإن تعطيل IPv6 في إعدادات شبكة نظام التشغيل يمنع WebRTC من الإبلاغ عن عنوان IPv6 الحقيقي. لكنه لا يصلح تسريب IPv4، وقد يعطّل بعض التطبيقات الحديثة التي تتوقع اتصال v6. الحل الأفضل هو VPN يتعامل مع IPv6 أصلياً أو يحجبه على مستوى جدار الحماية.

هل توقف إضافة المتصفح كل تسريبات WebRTC فعلاً؟

بالنسبة لتسريب العنوان المحلي، نعم — فخيار uBlock Origin وإضافة Network Limiter من جوجل كلاهما يمنعان تعداد العناوين المحلية. أما تسريب العنوان العام (مشكلة الخصوصية الحقيقية)، فالإضافات أقل موثوقية من حل على مستوى الشبكة من الـ VPN. أعد الاختبار دائماً بعد تثبيت أي إضافة.

اختباري يُظهر "عنوان الـ VPN" في حقل العام — هل هذا آمن؟

نعم. إن تطابق عنوان IP العام المعروض في اختبار تسريب WebRTC مع ما تقوله لوحة تحكم الـ VPN، فإن WebRTC يمرّ عبر النفق بشكل صحيح ولا يحدث أي تسريب. هذه هي النتيجة الجيدة المتوقعة.

أشغّل الاختبار فلا يُظهر أي شيء على الإطلاق — هل هذا جيد؟

إن أرجع الفحص صفر عناوين (أو ذكر صراحةً "WebRTC معطّل")، فأنت إما عطّلت WebRTC في فايرفوكس، أو هناك إضافة مثل WebRTC Control تحجب الواجهة بالكامل. هذه أكثر الحالات خصوصيةً على الإطلاق — لكن تذكّر فقط أنها ستعطّل أي تطبيق مكالمات فيديو في المتصفح تعتمد عليه.

هل يوقف حاجب بصمة المتصفح مثل Canvas Defender تسريبات WebRTC؟

لا. حاجبات البصمة تستهدف canvas وWebGL وتعداد الخطوط. أما WebRTC فهو واجهة منفصلة ويحتاج إلى حلّه الخاص (إضافة Network Limiter، أو خيار uBlock، أو about:config في فايرفوكس، أو سياسة معالجة IP في WebRTC ببريف).

أدوات وأدلة ذات صلة

• اختبار تسريب WebRTC — فحص مجاني عبر المتصفح لتسريبات IPv4 وIPv6 والعناوين المحلية.
• فاحص زمن الاستجابة (Latency) — بقية مركز تشخيص الشبكة لدينا لقياس تأخير لوحة المفاتيح والماوس والاتصال.
• اختبار الكاميرا واختبار الميكروفون — تستخدمان واجهتي getUserMedia / WebRTC نفسيهما للتأكد من عمل الكاميرا والميكروفون قبل أي مكالمة.
• اختبار السماعات ومكبر الصوت — مبني أيضاً على منظومة WebRTC الصوتية في المتصفح.
• مولّد كلمات المرور الآمن — كل التوليد يحدث محلياً؛ لا يُرسَل شيء إلى أي خادم.
• دليل فاحص زمن الاستجابة — كيف تقيس تأخير لوحة المفاتيح والماوس وتقلّله.
• كيف تختبر الميكروفون أونلاين — مقال شقيق عن اختبار الميكروفون بتقنية WebRTC.
• دليل اختبار الكاميرا — تحقّق من عمل كاميرتك قبل المكالمات.

شغّل الاختبار الآن: افحص متصفحك بحثاً عن تسريبات WebRTC — يستغرق 30 ثانية، بلا تسجيل.