طريقة معرفة استضافة أي موقع على الإنترنت بسهولة: دليل فحص عملي 2026

قد تحتاج إلى معرفة استضافة موقع لأنك تخطط للانتقال إلى مزود آخر، أو تقارن عرضين، أو تحقق من سبب بطء متكرر، أو تريد فهم من يشغّل البنية التي تتعامل معها قبل قرار تجاري. السؤال يبدو بسيطًا: «أين يستضاف هذا الموقع؟» لكن الإجابة الصحيحة ليست اسمًا واحدًا يظهر في أداة واحدة. هناك دومين مسجل لدى مسجل، و DNS قد يديره طرف آخر، وشبكة توصيل محتوى تخفي العنوان الأصلي، وخادم قد يكون لدى مزود سحابي أو شركة استضافة أو موزع يعيد البيع.

هذا الدليل يشرح طريقة فحص منظمة تعتمد على معلومات عامة فقط، دون محاولة اختراق أو تجاوز حماية. الهدف ليس الحصول على «الإجابة النهائية» من رقم IP، بل بناء مجموعة أدلة تشرح ما يمكن إثباته وما يبقى احتمالًا. في كثير من المواقع ستصل إلى مزود البنية التحتية بثقة معقولة، وفي مواقع أخرى ستجد أن CDN أو الاستضافة المشتركة تجعل الجزم مستحيلًا من الخارج. معرفة هذا الحد جزء من الإجابة الصحيحة.

ما الذي تبحث عنه بالضبط؟

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

لذلك عندما ترى أن سجلات NS تشير إلى Cloudflare، فهذا يعني عادة أن DNS أو الحماية تمر عبر Cloudflare، ولا يعني بالضرورة أن ملفات الموقع مستضافة هناك. وبالمثل، قد يكون الموقع على منصة مثل WordPress.com أو Shopify أو GitHub Pages، وفي هذه الحالة تكون البنية المدارة هي المستضيف الفعلي حتى لو ظهر دومين مخصص. اكتب أولًا ما تريد إثباته: من يستضيف الملفات؟ من يدير DNS؟ أم من يقدم الحماية والكاش؟ لكل سؤال أدلته المختلفة.

الفحص السريع في ست خطوات

1. ابدأ بسجلات DNS

استخدم أداة استعلام DNS من جهازك أو من خدمة ويب موثوقة. على Linux و macOS يمكنك كتابة dig +short example.com A، ثم dig +short example.com AAAA، و dig +short www.example.com CNAME، و dig +short example.com NS، و dig +short example.com MX. على Windows يمكنك استخدام Resolve-DnsName example.com في PowerShell أو nslookup. لا تكتفِ بنتيجة المتصفح لأن ذاكرة DNS المؤقتة قد تعرض عنوانًا قديمًا أو مختلفًا حسب موقعك.

سجلات A و AAAA تعطيك عنوان IPv4 و IPv6 للخادم الذي يستقبل الطلب، لكن قد يكون عنوان حافة CDN لا عنوان الأصل. سجل CNAME قد يكشف اسمًا مثل متجر مستضاف أو خدمة خارجية، لكن بعض مزودي DNS يستخدمون CNAME Flattening فيحوّلونه إلى عنوان A ويخفي الاسم الأصلي. سجلات NS تدل على مزود DNS، وليست دليل استضافة. سجلات MX تدل على مزود البريد. وجود أكثر من عنوان A أو AAAA أمر طبيعي في المواقع الموزعة، وقد تشير العناوين المختلفة إلى مزودين مختلفين، خصوصًا عند الجمع بين IPv4 و IPv6.

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

2. حوّل عنوان IP إلى شبكة و ASN

بعد الحصول على عنوان IP، ابحث عنه في WHOIS أو RDAP. RDAP هو بروتوكول أحدث ومنظم للاستعلام عن تسجيل عناوين IP والنطاقات، وتوفره عدة سجلات إقليمية. يمكنك تجربة whois على عنوان IP في الطرفية، أو طلب RDAP عبر المتصفح أو curl. ستحصل عادة على اسم الشبكة والمنظمة والبلد ونطاق العنوان. لكن السجل يصف مالك أو مسؤول تخصيص النطاق، وقد يكون مزود سحابة كبيرة أو موزعًا أو شركة اتصالات، وليس بالضرورة الشركة التي باعت الاستضافة لصاحب الموقع.

الخطوة الأهم هي معرفة ASN، أي رقم النظام المستقل الذي يحدد الشبكة التي يعلن عنها العنوان. يمكن الاستعلام عنه عبر خدمات WHOIS المتخصصة أو قواعد BGP العامة. اسم ASN غالبًا أدق من اسم النطاق التجاري، لأن عنوان IP قد يعاد تخصيصه أو ينتمي إلى مزود بنية تحتية يخدم آلاف العملاء. إذا كان ASN لشركة سحابية معروفة، فاستنتاجك المعقول هو أن الموقع على بنية تلك الشركة أو عبر شريك لها، وليس أن الشركة هي من تقدم الدعم أو الفاتورة لصاحب الموقع.

انتبه إلى أن عنوان IP واحد قد يخدم مواقع كثيرة، خصوصًا في الاستضافة المشتركة. كما أن بعض مزودي الاستضافة يستخدمون نطاقات عناوين مسجلة باسم شركة أم أو موزع إقليمي. وإذا كان الموقع خلف CDN فستحصل على ASN الخاص بشبكة الحافة، مثل شبكة Cloudflare أو Fastly أو Amazon CloudFront أو Akamai، وهذا يخبرك بمن يقدم الحافة لا بمن يشغّل الأصل. لا تحاول استنتاج الأصل من عنوان الحافة ثم فحص منافذ الخادم؛ هذا يتجاوز حدود الفحص السلبي.

3. افحص PTR والعناوين المجاورة بحذر

سجل PTR هو الاسم العكسي المرتبط بعنوان IP. قد يكون اسمًا وصفيًا مثل خادم داخل نطاق مزود، أو اسمًا عامًا لا يفيد. اطلبه بأمر dig -x متبوعًا بالعنوان، أو عبر أداة ويب. وجود اسم نطاق تابع لمزود في PTR إشارة مفيدة، لكنه قد يكون قديمًا أو مضللًا أو متجاهلًا من مزود الخدمة. لا تبنِ حكمك على PTR وحده، ولا تفترض أن كل المواقع على العنوان نفسه تخص الموقع الذي تدرسه.

في الاستضافة المشتركة، قد يكشف فحص المواقع المرتبطة بالعنوان عشرات النطاقات الأخرى. هذا قد يساعد على تمييز نمط الاستضافة، لكنه لا يثبت علاقة ملكية، وقد يعرضك لبيانات لا تحتاجها. الأفضل عدم جمع أسماء نطاقات أخرى بلا سبب، والاكتفاء بعدد صغير للتأكد من طبيعة الخدمة. إذا كانت النتائج متضاربة، فالأرجح أنك أمام بنية موزعة أو CDN أو مزود يعيد استخدام العناوين، وليس أمام لغز يحتاج مزيدًا من التوسع في جمع البيانات.

4. اقرأ رؤوس HTTP والشهادة

استخدم curl -I https://example.com لطلب الرؤوس فقط، أو أدوات المطور في المتصفح. رأس Server قد يعرض nginx أو Apache أو LiteSpeed أو اسم خدمة سحابية، لكنه يمكن تغييره أو حذفه، ولذلك هو قرينة لا إثبات. رأس X-Powered-By يصف تقنية التطبيق مثل PHP أو ASP.NET ولا يحدد المستضيف. رؤوس مثل Via و X-Cache و CF-Ray و X-Amz-Cf-Id و X-Fastly-Request-Id و X-Akamai-Transformed تكشف وجود وسيط أو CDN، وهي مفيدة جدًا في تفسير سبب ظهور عنوان الحافة بدل الأصل.

الشهادة الرقمية يمكن فحصها بأمر openssl s_client متبوعًا باسم المضيف والمنفذ 443، ثم تمرير الناتج إلى openssl x509 لعرض الموضوع والجهة المصدرة والتواريخ. اسم الجهة المصدرة قد يكون Let’s Encrypt أو Google Trust Services أو مزود CDN، وهذا لا يعني أن المستضيف هو نفسه. أما أسماء النطاقات في حقل SAN فتوضح ما تغطيه الشهادة، وقد تكشف نطاقات فرعية أو خدمات مرتبطة، لكنها ليست سجلًا للملكية. لا تعتبر شهادة صالحة دليلًا على أن الموقع آمن أو أنه يستضاف لدى جهة معينة؛ الشهادة تثبت هوية النطاق في لحظة الاتصال فقط.

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

5. افهم ما تعنيه علامات CDN

شبكات CDN مثل Cloudflare و Fastly و Amazon CloudFront و Akamai تشغل عناوين IP خاصة بها وتعلن عنها عبر ASN. عندما يظهر عنوان من هذه الشبكات، فأنت ترى نقطة الحافة التي تخدم الزائر، وليس بالضرورة الخادم الذي يخزن قاعدة البيانات أو ملفات ووردبريس. هذا مفيد لمن يريد معرفة من يقدم الحماية والكاش، لكنه لا يجيب عن سؤال «أين أستضيف موقعي؟» إذا كان المقصود هو الخادم الأصلي. بعض المواقع تستخدم CDN مع استضافة خارجية، وبعضها يستخدم خدمات الحافة مع تخزين ثابت، وبعضها يجمع بين عدة مزودين.

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

6. استخدم أدوات التاريخ والسمعة كدليل مساعد

توجد خدمات تحلل بصمة التقنيات أو تحتفظ بسجلات DNS وشهادات قديمة، وأدوات مثل crt.sh تعرض سجلات الشفافية للشهادات، وأدوات مثل Wappalyzer أو BuiltWith تعرض مؤشرات عن المنصات والتقنيات. هذه الأدوات مفيدة لاكتشاف نطاقات فرعية أو تغيرات تاريخية، لكن نتائجها قد تكون قديمة أو ناقصة أو مبنية على تخمين. لا تقدم أداة واحدة كدليل نهائي، خصوصًا إذا كانت تعتمد على بيانات تاريخية أو على بصمات يمكن تغييرها.

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

مثال عملي لقراءة مجموعة أدلة

لنفترض موقعًا توضيحيًا يستخدم نطاقًا محجوزًا وأرقامًا مخصصة للتوثيق، وليس موقعًا حقيقيًا. سجلات NS تشير إلى مزود DNS منفصل. سجل A يعطي عنوانًا في نطاق 203.0.113.0/24 المخصص للأمثلة. استعلام RDAP يظهر شبكة باسم مزود سحابي تجريبي و ASN خيالي. سجل PTR يعيد اسمًا مثل srv-45.provider.example. رؤوس HTTP تعرض Server: nginx ولا تعرض CF-Ray أو X-Amz-Cf-Id. الشهادة صادرة من Let’s Encrypt وتغطي النطاق فقط.

القراءة المنطقية: مزود DNS ليس بالضرورة المستضيف؛ عنوان IP ينتمي إلى شبكة مزود سحابي، وغياب علامات CDN يرجح أن الطلب يصل إلى خادم تابع لتلك الشبكة أو إلى وكيل أمامها. لكننا لا نعرف إن كان الموقع على خادم افتراضي صغير، أو خادم مخصص، أو منصة مُدارة تابعة لموزع. كما لا نعرف من يدفع الفاتورة. النتيجة الصحيحة هي: «البنية التحتية العامة تبدو تابعة للمزود السحابي التجريبي بثقة متوسطة، ولا يمكن تحديد الموزع أو خطة الاستضافة من الخارج». هذا أدق من عبارة «الموقع مستضاف عند فلان» بلا تحفظ.

جدول تفسير الإشارات

أخطاء شائعة تنتج إجابة خاطئة

الخطأ الأول هو اعتبار سجلات NS دليل استضافة. الخطأ الثاني هو اعتبار اسم الشركة في WHOIS هو من باع الخطة لصاحب الموقع. الخطأ الثالث هو تفسير عنوان IP واحد كأنه خادم واحد؛ فالعنوان قد يخدم مئات المواقع. الخطأ الرابع هو الاعتماد على رأس Server أو X-Powered-By وحدهما. الخطأ الخامس هو تجاهل IPv6؛ فقد يشير سجل AAAA إلى مزود مختلف عن IPv4. الخطأ السادس هو اعتبار نتيجة أداة تاريخية حالة راهنة. الخطأ السابع هو محاولة تجاوز CDN لمعرفة الأصل، وهذا ليس ضروريًا ولا مشروعًا في الغالب.

الخطأ الثامن هو خلط الاستضافة بالمنصة. موقع على Shopify أو Wix أو GitHub Pages قد لا يظهر له خادم تقليدي بالمعنى الذي تتوقعه، لأن المنصة تدير البنية بالكامل. الخطأ التاسع هو الظن بأن الشهادة المجانية تعني استضافة رديئة؛ مصدر الشهادة لا يقيس جودة الاستضافة. الخطأ العاشر هو نشر نتيجة قاطعة دون ذكر تاريخ الفحص ودرجة الثقة، ثم تفاجأ بعد أشهر بأن المزود تغير أو أن النطاق انتقل.

حدود قانونية وأخلاقية مهمة

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

إذا كنت تعمل في تدقيق أمني أو تحقيق قانوني، فالمسار الصحيح هو موافقة واضحة ونطاق مكتوب وأدوات مصرح بها، وليس الاعتماد على حيل تجاوز الحماية. وإذا كانت النتيجة مطلوبة في تقرير للعميل، فاذكر المنهج والتاريخ والمصادر ودرجة الثقة، وافصل بين «مزود الحافة» و«مزود الاستضافة الأصلية» و«مسجل النطاق». هذا الفصل يحمي التقرير من استنتاجات لا يقبلها التدقيق.

خطة عشر دقائق قابلة للتكرار

أسئلة سريعة

س: هل يمكن معرفة الاستضافة من عنوان IP فقط؟ ج: نعم أحيانًا إذا كان العنوان ينتمي إلى مزود استضافة واضح وغير مخفي خلف CDN، لكن النتيجة قد تكون مزود البنية التحتية لا الشركة التي تبيع الخطة. اعتمد على ASN والسجل والرؤوس معًا. س: لماذا يظهر Cloudflare في كل شيء؟ ج: لأن Cloudflare قد تدير DNS وتقدم حماية وكاشًا، وقد تظهر سجلاتها وعناوينها ورؤوسها حتى لو كان الخادم الأصلي عند مزود آخر. س: هل NS تكفي؟ ج: لا، هي تدل على مدير DNS فقط. س: هل يمكن معرفة الأصل خلف CDN؟ ج: ليس بشكل موثوق من المعلومات العامة، ومحاولة تجاوز الحماية ليست طريقة مقبولة.

س: ماذا لو كان الموقع على استضافة مشتركة؟ ج: قد ترى عنوان IP واحدًا لعشرات المواقع، و PTR عامًا، ورؤوسًا متشابهة؛ هذا طبيعي ولا يعني أن كل المواقع مملوكة لجهة واحدة. س: هل أدوات مثل BuiltWith دقيقة؟ ج: تعطي مؤشرات مفيدة لكنها قد تعتمد على تاريخ قديم أو بصمات قابلة للتغيير، فلا تعتبرها حكمًا نهائيًا. س: كيف أوثق النتيجة؟ ج: دوّن الأمر أو الأداة والنتيجة والتاريخ ومستوى الثقة، واحتفظ بفرق واضح بين ما ثبت وما استنتجته.

خلاصة

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

لمزيد من السياق يمكن مراجعة دليل موقع إيجي تاج عن الفرق بين بطء DNS وبطء الاستضافة: https://egytag.com/ar/articles/dns-latency-vs-hosting-slow-website، ومقارنة الاستضافة المشتركة و VPS: https://egytag.com/ar/articles/استضافة-مشتركة-أم-vps-كيف-تختار-لموقعك، وطريقة قراءة ASN و ISP معًا: https://egytag.com/ar/articles/قراءة-asn-وisp-وgeo-معا-لتقييم-جودة-مسار-البروكسي. هذه روابط داخلية لموضوعات مكملة، وليست مصادر لإثبات حالة موقع بعينه.

مراجع تقنية عامة: RFC 9110 لمعنى رسائل HTTP، و RFC 9499 لمصطلحات DNS، و RFC 9082 و RFC 9083 لبروتوكول RDAP، و RFC 8446 لبروتوكول TLS 1.3. يمكن العثور عليها في https://www.rfc-editor.org/. هذه المواصفات تشرح السلوك المعياري، ولا تثبت أن موقعًا محددًا يستخدم مزودًا محددًا في تاريخ معين.