الموقع لا يفتح؟ طريقة تشخيص DNS وSSL وHTTP قبل تغيير الإعدادات عشوائيًا

عندما الموقع لا يفتح، أسوأ نقطة بداية هي تغيير DNS أو SSL أو إعدادات الخادم كلها في وقت واحد. نفس العرض قد ينتج عن أسباب مختلفة تمامًا: الدومين لا يُحل، الاتصال يصل إلى خادم خاطئ، شهادة HTTPS غير صالحة، الخادم يعيد 500، أو التطبيق نفسه لا يجد الصفحة.

الطريقة الأفضل هي تحديد في أي طبقة يفشل الطلب، ثم إصلاح هذه الطبقة فقط.

ابدأ من السؤال: ما رسالة الخطأ بالضبط؟

هناك فرق كبير بين «Server not found» و«Your connection is not private» و404 و500. الرسالة أو Status Code تقصر مساحة البحث.

1. هل DNS يحل الدومين إلى عنوان صحيح؟

DNS يحول اسم مثل example.com إلى عنوان يستطيع الجهاز الاتصال به. استخدم أداة مثل nslookup أو dig وتأكد أن النتيجة هي الـIP أو الخدمة التي تقصدها.

nslookup example.com

إذا كنت قد غيرت DNS للتو، تذكر أن الـcaches والـTTL قد تجعل بعض الشبكات ترى النتيجة القديمة لفترة. لا تفترض أن كل المستخدمين يشاهدون نفس record في اللحظة نفسها.

2. اختبر HTTP وHTTPS بصورة منفصلة

جرّب معرفة استجابة الخادم بدون الاعتماد على شكل الصفحة داخل المتصفح:

curl -I http://example.com/
curl -I https://example.com/

قد تجد أن HTTP يعمل ويعيد 301 إلى HTTPS، بينما HTTPS نفسه يفشل. هنا المشكلة ليست «الموقع كله»، بل الجزء المتعلق بالاتصال المشفر أو إعداد الـVirtual Host على 443.

3. افحص Redirects

Redirect واحد من HTTP إلى HTTPS طبيعي في كثير من المواقع. المشكلة عندما تدخل في loop أو chain طويلة مثل HTTP → www → HTTPS → مسار آخر.

استخدم:

curl -I -L https://example.com/

وراقب كل Location حتى الوجهة النهائية. بعد migrations راجع أن الروابط القديمة تنتهي مباشرة في البديل الصحيح قدر الإمكان.

4. فرّق بين مشكلة SSL ومشكلة التطبيق

إذا كان المتصفح يحذر أن الشهادة منتهية أو لا تطابق hostname، فإصلاح Controller داخل التطبيق لن يفيد. تحقق من الشهادة والدومينات التي تغطيها وسلسلة الثقة وتاريخ الصلاحية.

ولا تستخدم تعطيل التحقق من الشهادة كحل Production. تجاوز SSL قد يساعد فقط في اختبار تشخيصي محدود عندما تعرف لماذا تفعله.

5. ماذا يعني 404؟

404 يعني أن الطلب وصل إلى جهة استطاعت إعطاء استجابة HTTP، لكنها لم تجد المورد المطلوب. هنا DNS والاتصال الأساسي يعملان غالبًا، لكن عليك تحديد من الذي أعاد 404: Web Server أم Reverse Proxy أم التطبيق.

لو الصفحة الرئيسية تعمل ومسار واحد يفشل، ابدأ بالـrouting وrewrite rules. ولو كل المواقع على الخادم تعيد صفحة 404 افتراضية، راجع Virtual Host والـhost binding.

6. ماذا يعني 403؟

403 تعني أن الخادم فهم الطلب لكنه يرفض السماح به. قد يكون السبب صلاحيات ملفات، WAF، IP rules، Authentication/Authorization، أو قاعدة حماية مخصصة.

لا تعالجها بتحويلها إلى 200 فقط. راجع logs وحدد أي طبقة اتخذت قرار المنع.

7. ماذا يعني 500؟

500 يشير إلى خطأ داخلي أثناء معالجة الطلب. افتح application logs وweb server logs في توقيت الطلب نفسه. ابحث عن exception أو dependency فاشلة أو اتصال قاعدة بيانات أو config مفقود.

رسالة «Internal Server Error» في المتصفح ليست التشخيص؛ هي فقط بداية الانتقال إلى السجلات.

8. جرّب الـIP بحذر

فتح IP في المتصفح لا يثبت دائمًا أن الموقع صحيح، لأن خادمًا واحدًا قد يستضيف عدة مواقع ويعتمد على Host header لتحديد أي Virtual Host يجب استخدامه.

في الاختبارات المتقدمة يمكن إرسال hostname المقصود إلى IP محدد بدل تغيير DNS العام. هذا يفيد في التحقق من خادم جديد قبل cutover، لكن يجب تنفيذ الاختبار مع فهم SSL وSNI والـHost routing.

9. راجع CDN أو Reverse Proxy

إذا كان الموقع خلف Cloudflare أو CDN أو Load Balancer، توجد طبقة إضافية بين المستخدم وorigin. اسأل: هل الخطأ صادر من الـedge أم من الخادم الأصلي؟ هل الـorigin متاح مباشرة؟ هل الـproxy يرسل Host وscheme الصحيحين؟

تغيير إعدادات التطبيق لن يحل قاعدة WAF تمنع الطلب قبل وصوله أصلًا.

10. افحص من خارج شبكتك

كون الموقع يعمل من جهازك لا يعني أنه يعمل للجميع. جرب شبكة أخرى عند الحاجة، وقارن DNS والاستجابة. أحيانًا تكون المشكلة local DNS cache أو hosts file أو VPN أو firewall داخلي.

ترتيب تشخيص يوفر الوقت

1. سجل URL ورسالة الخطأ والوقت.
2. تحقق من DNS.
3. اختبر الاتصال وHTTP status.
4. افحص HTTPS والشهادة.
5. تتبع Redirects.
6. حدد هل الرد من proxy أم web server أم التطبيق.
7. راجع logs في الطبقة المشتبه بها.
8. غيّر إعدادًا واحدًا فقط ثم أعد الاختبار.

بعد إصلاح المشكلة

لا تكتفِ بأن الصفحة «فتحت». اختبر أهم المسارات، assets، النماذج، redirects، وHTTP/HTTPS. لو كانت المشكلة أثناء إطلاق أو نقل موقع، راجع أيضًا canonical وSitemap حتى لا يعمل الموقع للمستخدم بينما تظل إشارات SEO على البيئة القديمة.

يمكنك مراجعة Checklist إنشاء وإطلاق موقع، وكذلك دليل تشخيص عدم ظهور الموقع في Google إذا كانت المشكلة بعد الإصلاح مرتبطة بالفهرسة.

أخطاء تشخيص شائعة

• مسح DNS وتغييره قبل التأكد من record الحالي.
• استخدام -k ثم اعتبار SSL سليمًا.
• إعادة تشغيل كل الخدمات بدل قراءة logs.
• اختبار الصفحة الرئيسية فقط.
• اعتبار 404 وDNS failure المشكلة نفسها.
• تغيير أكثر من إعداد في نفس الوقت ثم عدم معرفة أي تغيير حل المشكلة.

الخلاصة

عندما لا يفتح الموقع، حوّل المشكلة من «الموقع واقع» إلى سؤال محدد: هل الفشل في DNS، الاتصال، SSL، الـproxy، خادم الويب أم التطبيق؟ كل طبقة لها اختبار بسيط وإشارة مختلفة. التشخيص بهذا الترتيب أسرع وأكثر أمانًا من تغيير الإعدادات عشوائيًا حتى تختفي الرسالة.