فحص متقدم لتسريب IP و DNS: تأكد من أمان شبكتك وفك حظر المكالمات

جاري تحليل مستوى التخفي لشبكتك... سيتم توجيهك تلقائياً بمجرد اكتمال الفحص.
حالة حزمة بروتوكولات الشبكة ?
IPv4 ?
في انتظار البدء
IPv4 DNS ?
في انتظار البدء
IPv6 ?
في انتظار البدء
IPv6 DNS ?
في انتظار البدء
البروتوكول ذو الأولوية ?
في انتظار البدء
نوع NAT ?
في انتظار البدء
زمن الانتقال إلى الوكيل
في انتظار البدء
تذبذب الشبكة
في انتظار البدء
تسريب WebRTC
في انتظار البدء
تسريب خوادم DNS ?
في انتظار البدء
حالة وكيل الشبكة (البروكسي)
في انتظار البدء
النفق المقسم
في انتظار البدء
مستوى إخفاء الهوية والتخفي
في انتظار البدء
عناوين خروج الـ IP المكتشفة عنوان IP العام الذي تراه الخوادم الخارجية
جاري الفحص...
عناوين خوادم DNS المكتشفة الموقع الجغرافي لخوادم تحليل أسماء النطاقات
View Full DNS Health Check →
جاري الفحص...
اختبار زمن استجابة الشبكة (Ping) والسرعة حركة البيانات المقدرة:10 MB
في انتظار بدء الاختبار...
التنزيل
--
Mbps
الرفع
--
Mbps
زمن الاستجابة
--
ms
انقر على فئة حركة البيانات لبدء اختبار السرعة:
جاري اختبار الاتصال بزمن الاستجابة (Ping)...

الأسئلة الشائعة حول فحص الـ IP والشبكة

تعرف على الفرق الجوهري بين عناوين مراكز البيانات والخطوط السكنية، وآليات تقييم المخاطر، وأسباب تسريب DNS و WebRTC.

يعتقد العديد من المستخدمين أن شراء "بروكسي سكني" سيخفيهم تماماً كمستخدم منزلي عادي. ومع ذلك، تنظر محركات تقييم المخاطر الحديثة إلى ما هو أبعد بكثير من علامات التصنيف الثابتة في قواعد بيانات GeoIP (مثل IP2Location أو MaxMind). حتى عندما يُدرج عنوان IP لمنفذ الخروج كعنوان ISP/سكني، فإن بوابة البروكسي لإعادة التوجيه تعمل دائماً تقريباً على خادم Linux سحابي، مما يُحدث تناقضات صارخة عبر الطبقات: أولاً، توقيعات حزمة بروتوكول النقل: يرسل خادم الخروج ترتيب خيارات TCP القياسي لنظام Linux (MSS, SACK_PERM, TS, NOP, WS) أثناء مصافحة SYN الأولية بدلاً من خيارات Windows أو Apple. ثانياً، تباين MTU للمسار: عادة ما تُظهر اتصالات PPPoE السكنية قيمة MTU تبلغ 1492 (أو 1400–1430 على شبكات الجوال)، بينما شبكة الإيثرنت النقية في مراكز البيانات هي 1500 القياسية (MSS=1460). عندما يكتشف نظام مكافحة الاحتيال عنوان IP سكنياً مصحوباً بقيمة MTU لمركز بيانات وحزمة TCP لنظام Linux، فإنه يصنف الاتصال على أنه بروكسي مؤتمت.

💡 اختبر اتصالك عبر فحص مجهولية البروكسي لمعرفة أين تنتهي حزمة TCP الخاصة بك.

لا يوجد ارتباط مادي ثابت بين عنوان IP وموقع جغرافي فيزيائي. تعتمد نتائج الموقع على قاعدة بيانات GeoIP التجارية التي يستخدمها كل موقع ودورة تحديثها: أولاً، تختلف مصادر قواعد البيانات ونماذج القياس عن بُعد — حيث يزن المزودون (مثل MaxMind و IP2Location و DB-IP) إعلانات BGP وسجلات whois ومسابير زمن انتقال الشبكة بشكل مختلف، مع فترات تحديث تتراوح من أيام إلى شهور. ثانياً، توجيه Anycast وتوصيل حافة CDN: يعلن مزودون مثل Cloudflare عن نفس كتلة IP من مئات مراكز البيانات العالمية، مما يوجه حزمتك إلى أقرب نقطة تواجد عند الحافة. ثالثاً، إعادة تعيين عناوين IP عبر الحدود: عندما يعيد مزود استضافة تخصيص كتلة IP مسجلة في بلد ما إلى خوادم في بلد آخر، تبلغ قواعد البيانات القديمة عن الأصل التاريخي. تجمع أداتنا بين عمليات التحقق المتبادلة لقواعد البيانات المتعددة وحساب تأخير سرعة الضوء المادي RTT لتأكيد المناطق المادية الفعلية.

درجة الاحتيال لعنوان IP (أو درجة المخاطر) هي مؤشر رقمي (عادة من 0 إلى 100) تستخدمه محركات تقييم المخاطر لقياس احتمالية أن يكون الاتصال ناشئاً عن نشاط مسيء أو روبوت أو متنكر. تتضمن عوامل التقييم الأساسية: أولاً، السمعة التاريخية وقوائم الإساءة: ما إذا كان عنوان IP قد شارك في حشو بيانات الاعتماد، أو الكشط، أو الرسائل غير المرغوب فيها، أو المسح خلال آخر 24 إلى 72 ساعة. ثانياً، نوع ASN والبنية التحتية: تحمل نطاقات مراكز البيانات (الاستضافة) والبروكسي/VPN العام مخاطر أساسية أعلى من النطاق العريض السكني أو مشغلي شبكات الجوال. ثالثاً، اتساق نقاط النهاية المتعددة والبروتوكول: ما إذا كانت الجلسة تُظهر منافذ خروج منقسمة للمكدس المزدوج (تباعد IPv4 و IPv6)، أو تباعد موقع محلل DNS، أو كشف IP المحلي عبر WebRTC.

💡 استخدم فحص تقسيم المسارات لتحديد تسريبات التوجيه التي قد ترفع درجة المخاطر الخاصة بك.

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

💡 للتحقق من تسريبات Canvas والصوت و WebRTC على مستوى العتاد، تفضل بزيارة فحص بصمة المتصفح.

تشغّل لوحة حزمة الشبكة بالصفحة الرئيسية ثلاثة مسابير مترابطة بالتوازي: مسبار يطلب نطاقاً يحتوي على سجلات A فقط (iptestv4.myipdns.com)، ومسبار يطلب نطاقاً يحتوي على سجلات AAAA فقط (iptestv6.myipdns.com)، والثالث يطلب نطاقاً مزدوج المكدس يحتوي على عائلتي السجلات معاً. المسباران الأولان إجباريان — حيث يُحلل كل اسم مضيف إلى عائلة عناوين واحدة فقط دون ترك خيار لنظامك، مما يلتقط عنوان IP الفعلي لخروجك على IPv4 و IPv6 بشكل مستقل. المسبار الثالث ليس إجبارياً؛ بل يراقب عائلة العناوين التي اختارها نظامك تلقائياً، والتي تظهر في عمود "البروتوكول المفضل": تتحدد هذه النتيجة من خلال سياسة اختيار العناوين لنظام التشغيل والمتصفح (Happy Eyeballs، RFC 8305: عند توفر المكدس المزدوج، جرّب IPv6 أولاً، مع الرجوع إلى IPv4 فقط عند الفشل)، ولا نحددها نحن. وضع المسابير الثلاثة جنباً إلى جنب أمر بالغ الأهمية لأن العديد من عملاء البروكسي و VPN ينشئون نفقاً لـ IPv4 فقط: فإذا كان مخرج IPv4 على ASN الخاص بالبروكسي بينما يظل مخرج IPv6 على مزود الإنترنت المنزلي، ويُظهر البروتوكول المفضل IPv6، فعند زيارة المواقع مزدوجة المكدس لن تمر معظم حركة مرورك عبر النفق مطلقاً — وهذا هو الشكل الأكثر شيوعاً لحالة "تشغيل الـ VPN مع بقاء الهوية الحقيقية مكشوفة"، ولا يصدر عنه أي خطأ على الإطلاق.

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

نحن لا نقرأ إعدادات نظامك المحلي — فالمتصفحات لا تستطيع قراءتها على الإطلاق، وأي صفحة ويب تدعي قراءة ضبط DNS المحلي لديك إنما تخمن فقط. النهج الحقيقي هو الاختبار العكسي: يدير موقعنا خادم DNS موثوقاً (Authoritative)، يولد نطاقاً فرعياً عشوائياً فريداً لكل اختبار (مثل k3f9x2ab.leakv4.myipdns.com) ليقوم متصفحك بتحليله. يظهر اسم المضيف هذا مرة واحدة فقط في التاريخ ولن يوجد في أي ذاكرة تخزين مؤقت، لذا يجب على سلسلة التحليل التكراري الاستعلام من خادمنا الموثوق وصولاً إلى المصدر؛ نحن نسجل من أجرى الاستعلام بالفعل، ثم نعيد هذا العنوان إلى متصفحك. وبالتالي، يعرض عمود "مخرج DNS" عنوان الشبكة الصادر الفعلي لمحللك التكراري، وليس عنوان IP الذي أدخلته في إعدادات نظامك: فإذا قمت بضبط 8.8.8.8، فإن الجهاز الذي يستعلم منا سيكون عقدة خروج محددة في تلك المجموعة، والتي قد تقع في بلد مختلف؛ تعتمد المحللات العامة الكبيرة على Anycast والمجموعات المتعددة، لذا فإن ملاحظة عدة عناوين خروج مختلفة في اختبار واحد أمر طبيعي تماماً. المعيار الحقيقي ليس تطابق العناوين، بل: إذا وقع هذا المخرج داخل شبكة مزود خدمة الإنترنت المنزلي الخاص بك بينما ينتهي مخرج IP على بروكسي — فهذا يشير إلى أن استعلامات DNS فشلت في اتباع النفق.

⚠ يمكن لهذه المنهجية فقط مراقبة من استعلم من خادمنا الموثوق الخاص بنا؛ ولا يمكننا ولا نرى أي نطاقات أخرى تقوم بتحليلها. وهناك أيضاً نقطة عمياء معروفة: إذا كان البروكسي الخاص بك يعترض أيضاً استعلامات DNS، فإن ما نلاحظه هو محلل موفر البروكسي — مما يؤكد عدم وجود تسريب إلى مزود الإنترنت المحلي لديك، ومع ذلك يظل سجل استعلامات DNS مرئياً لموفر البروكسي الخاص بك؛ وهذا اعتبار منفصل يتجاوز ما تكتشفه هذه الأداة.

عبر WebRTC، يتم إرسال مسابير فردية إلى خوادم STUN متعددة لجمع مرشحي srflx العائدين — أي عنوان IP والمنفذ العام الذي يلاحظه الخادم البعيد بالفعل بعد ترجمة NAT. هناك معيار حاسم واحد فقط: يتم تجميع المرشحين حسب عنوان IP العام المترجم؛ فإذا ظهر منفذان مميزان أو أكثر تحت نفس عنوان IP، فإنه يُصنف كـ NAT متماثل (Symmetric NAT) (حيث يخصص منفذاً معيناً جديداً لكل وجهة مختلفة)؛ وإلا، فإنه يُصنف كـ NAT مخروطي (Cone NAT) (حيث يعين باستمرار نفس المنفذ الداخلي إلى نفس المنفذ الخارجي). تم إدخال تجميع المرشحين قبل مقارنة المنافذ عمداً: في بيئات البروكسي ذات المسارات المنقسمة، قد توجه خوادم STUN المختلفة عبر مخارج مختلفة، مما يجعل المنافذ تتباعد طبيعياً؛ ومع ذلك، ينبع هذا التباعد من اختلافات المسار وليس من سلوك NAT، وكان حذف التجميع سيؤدي إلى تشخيص خاطئ لجميع هذه الإعدادات كـ Symmetric. أما عرض "غير معروف" فله سببان: أولاً، الفشل في استقبال أي مرشح srflx خلال مهلة 4 ثوانٍ (WebRTC معطل في المتصفح، أو محظور بواسطة الإضافات، أو أن حزم UDP الصادرة مفلترة)؛ ثانياً، استلام مرشح واحد فقط لا يتطابق عنوان IP العام الخاص به مع IP الدخول المستخدم للوصول إلى هذا الموقع، مما يجعل من المستحيل التمييز بين إلغاء تكرار المرشحات في المتصفح وبين انقسامات توجيه حركة المرور، لذلك نعرض عمداً غير معروف.

⚠ توضيح أمين: نحن نميز فقط بين Cone NAT و Symmetric NAT، ولا نصنف تصنيفاً فرعياً إلى Full Cone أو Restricted Cone أو Port-Restricted Cone. يتطلب نموذج المستويات الأربعة RFC 3489 التحكم الفعال في مجموعات منافذ المصدر والوجهات المستهدفة عبر مسابير متكررة، ولا يوفر WebRTC في المتصفحات مثل هذا التحكم منخفض المستوى؛ وعندما تبلغ أدوات الويب عن إحدى الفئات الأربع، فإنها عادة ما تعيد تسمية هاتين النتيجتين فقط.

يتكون الفحص في الصفحة الرئيسية من عدة مجموعات من الطلبات: الاتصال بعدة نطاقات فرعية لهذا الموقع لجمع بصمات حزمة البروتوكولات عبر IPv4 و IPv6 وإصدارات HTTP المختلفة؛ والاستعلام من عدة خدمات خارجية للبحث عن عناوين IP وكذلك WebRTC لمعرفة ما إذا كانت الوجهات المختلفة ترى نفس المخرج؛ وترجمة نطاقات فرعية عشوائية لمعرفة الجهة التي تترجم طلبات DNS الخاصة بك؛ وإرسال مجسات إلى خوادمنا في مناطق أخرى للتحقق المتبادل من عدة مواقع؛ وقياس زمن الانتقال إلى عدة مواقع شهيرة.

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