19 نوفمبر 2025·7 دقيقة
قائمة فحص استكشاف أخطاء النطاق المخصص لمشاكل DNS وSSL
استخدم قائمة فحص استكشاف أخطاء النطاقات المخصصة هذه لتشخيص مشاكل سجلات DNS وتأخّر الانتشار وتوقيت إصدار SSL، مع خطوات تحقق بسيطة.
استخدم قائمة فحص استكشاف أخطاء النطاقات المخصصة هذه لتشخيص مشاكل سجلات DNS وتأخّر الانتشار وتوقيت إصدار SSL، مع خطوات تحقق بسيطة.
"النطاق المخصص لا يعمل" تعبير شامل لعدد من الأعطال المختلفة. المتصفح يظهر العرض الظاهري، وليس السبب. قبل تغيير أي شيء، حدّد ما الذي تراه بالضبط.
الأعراض الشائعة تتضمن:
معظم الوقت، سبب واحد فقط يكون خاطئًا:
قبل الاستكشاف، تأكد من أن لديك وصولًا لمكانين: حيث تعدّل سجلات DNS (المسجل أو مزود DNS) وحيث تربط النطاق على جانب الاستضافة. على سبيل المثال، إذا كنت توصل تطبيقًا منشورًا على Koder.ai بنطاق مخصص، تحتاج وصول DNS للنطاق وإعدادات النطاق داخل إعدادات الاستضافة أو النشر في التطبيق.
بعض الإصلاحات فورية (مثل تصحيح خطأ مطبعي). والبعض الآخر يستغرق وقتًا. تغييرات DNS قد تستغرق فترة للظهور، وعادةً لن تكتمل SSL حتى يشير DNS بشكل صحيح ويكون النطاق قابلًا للوصول. الهدف هو التوقف عن التخمين والتحقق من كل طبقة بالترتيب.
معظم مشاكل النطاق ترجع إلى عدم تطابق بين (1) اسم المضيف الذي تختبره، (2) المكان الذي يُدار فيه DNS، و(3) ما الذي يشير إليه السجل فعليًا. بمجرد أن تتطابق هذه الثلاثة، تكون SSL عادةً الخطوة الأخيرة.
للنطاقات شكلان شائعان: النطاق الجذري (example.com، ويسمّى أيضًا apex) والنطاقات الفرعية (www.example.com، app.example.com). هما مرتبطان، لكن يمكن أن يكون لهما سجلات DNS مختلفة. لذا من الطبيعي أن يعمل www بينما يفشل apex، أو العكس.
خوادم الأسماء (nameservers) تقرر من يدير منطقة DNS الخاصة بك. إذا اشتريت نطاقًا من شركة لكن خوادم الأسماء تشير إلى شركة أخرى، يجب عليك تعديل DNS حيث تشير خوادم الأسماء. كثير من حالات "عدّلت لكن لم يتغير شيء" تحدث لأن السجلات عُدِّلت في لوحة تحكم خاطئة.
إليك ما تفعله أنواع السجلات الرئيسية:
TTL هو مؤقت "كم من الوقت تُخزّن هذه الإجابة". TTL أقل يعني أن التخزين المؤقت يتحدّث بسرعة أكبر. TTL أعلى يعني أنك قد تنتظر أطول حتى ترى التغيير، ورؤية القيمة القديمة لفترة يمكن أن تكون طبيعية.
عندما يفشل نطاق مخصص، يمكنك عادةً تصنيفه في إحدى أربع فئات: DNS لا يحل الاسم، DNS يحل إلى المكان الخاطئ، SSL غير جاهز، أو يفشل عند بعض الأشخاص بسبب التخزين المؤقت.
استخدم شجرة القرار هذه:
www لكن النطاق الجذري لا يعمل (أو العكس)، فقد قمت بتكوين اسم مضيف واحد فقط، أو لديك قواعد إعادة توجيه متضاربة.تحرّك أسرع بكتابة اسم المضيف الذي يفشل بالضبط (apex مقابل www) ورسالة الخطأ الحرفية. على منصات الاستضافة التي تؤتمت النطاقات والشهادات، الفرق بين "لا يمكن إيجاد المضيف" و"الشهادة معلقة" يخبرك ما إذا كان عليك إصلاح سجلات DNS أم الانتظار حتى تصدر الشهادة بعد ظهور DNS.
تبدأ كثير من مشاكل النطاق بعدم تطابق بسيط: ضبطت DNS لاسم مضيف واحد لكن تختبر اسمًا آخر.
أولًا، دوّن اسم المضيف الذي تريد أن يكون مباشرًا. النطاق الجذري يبدو مثل example.com. النطاق الفرعي يبدو مثل www.example.com أو app.example.com. هذه مدخلات DNS منفصلة، لذا "عمل www" لا يعني أن النطاق الجذري سيعمل.
بعدها، اعثر على الهدف المتوقع من منصتك المستضيفة. بعض المنصات تعطي عنوان IP (لسجل A أو AAAA). أخرى تعطي اسم مضيف هدف (لسجل CNAME). إذا أعطاك المضيف قيمة في شاشة إعداد النطاق، اعتبرها المصدر الموثوق.
قبل تغيير أي شيء، قم بنسخ ما هو مضبوط حاليًا. اجعله بسيطًا:
وتأكد أيضًا أنك تعدّل المنطقة الصحيحة. من السهل تحديث النطاق الخاطئ أو البيئة الخاطئة أو حساب المزود الخطأ.
العديد من المشاكل تكون بسبب نوع السجل الخاطئ لاسم المضيف الذي تحاول توصيله. ابدأ بفصل حالتين: النطاق الجذري (example.com) والنطاق الفرعي (www.example.com). يتصرّفان بشكل مختلف عند كثير من مزودي DNS.
سجل A يشير اسمًا إلى عنوان IPv4. الكثير من الإعدادات تستخدم سجل A للنطاق الجذري لأن بعض المزودين لا يسمحون بـ CNAME في الـ apex. إذا أعطاك المضيف عنوان IP، فسر A عادةً صحيح.
سجل AAAA هو نسخة IPv6. سجل AAAA خاطئ قد يخلق سلوكًا متضاربًا: بعض الزوار يصلون عبر IPv6 والآخرون عبر IPv4. إذا لم يوفر المضيف هدف IPv6، فإن إزالة AAAA غير الصحيحة غالبًا تحل حالات الفشل المتباينة.
سجل CNAME يشير نطاقًا فرعيًا إلى اسم مضيف آخر (يُستخدم كثيرًا لـ www). مفيد عندما يريد المضيف منك استهداف نقطة اسمية قد تتغير خلف الكواليس.
سجل TXT مخصص للتحقق والتحديات (بما في ذلك بعض فحوصات SSL). أخطاء شائعة تتضمن وضع TXT على الاسم الخاطئ (الجذر مقابل _acme-challenge مقابل نطاق فرعي)، إضافة مسافات زائدة، أو لصق قيمة خاطئة.
قبل المتابعة، ابحث عن تعارضات. هذه هي التي تسبب معظم المشاكل:
العديد من حالات "النطاق المخصص لا يعمل" ليست بسبب قيمة السجل على الإطلاق. تحدث لأن السجل أُضيف في المزود الخطأ. إذا كان نطاقك يستخدم خوادم أسماء مزود A، فإن تغيير السجلات في لوحة مزود B لن يفعل شيئًا، حتى لو بدت السجلات صحيحة هناك.
تحقق أي خوادم أسماء يستخدمها نطاقك فعليًا. يمكنك عادةً رؤية ذلك في إعدادات النطاق لدى المسجل تحت "Nameservers". وللتحقق من مصدر ثانٍ، اسأل DNS مباشرة من جهازك:
dig NS example.com
خوادم الأسماء التي يعيدها هذا الأمر هي الخوادم المخوّلة.
فحص سريع للتأكد:
ns1... وns2...، يجب أن تظهر تلك القيم بالضبط عند المسجل.إذا حدّثت السجلات عند المزود الخطأ، سترى غالبًا لوحتين تحكم لا تتطابقان. خوادم الأسماء المخوّلة فقط هي المهمة.
وانتبه أيضًا للتأخيرات بعد تغيير خوادم الأسماء عند المسجل. خلال نافذة الانتقال، قد تبدو النتائج متباينة اعتمادًا من أين تختبر. إذا كانت خوادم الأسماء لا تزال تتغير، أوقف تعديلات السجلات حتى تستقر مجموعة خوادم الأسماء، ثم استمر.
"الانتشار" ليس مفتاحًا واحدًا. هو سلسلة من مخابئ DNS (مزودي خدمة الإنترنت، مشغلي الهاتف، المحللات العامة، وأجهزتك الخاصة) التي تتحدّث بسرعات مختلفة. لهذا السبب يمكن أن يعمل نطاق لزميل بينما يفشل لك.
TTL (المدة الحية) يخبر المخبئات كم من الوقت يمكنها الاحتفاظ بالإجابة. إذا كان TTL القديم ساعة، فقد يستمر بعض الأشخاص في رؤية القيمة القديمة لما يقارب الساعة. خفض TTL يساعد فقط إذا فعلت ذلك قبل إجراء التغيير.
لفصل تأخيرات التخزين المؤقت عن الأخطاء الحقيقية، قم ببعض الفحوصات السريعة:
إذا كان السجل خاطئًا في أي مكان تتحقق منه (IP خاطئ، فقدان www، CNAME قديم)، قم بتصحيح ذلك. إذا بدت السجلات صحيحة في معظم الأماكن لكن شبكة واحدة لا تزال تظهر القيمة القديمة، فعادةً يكون ذلك تأخيرًا في التخزين المؤقت.
شهادات SSL تفشل عادةً لسبب أساسي واحد: مزود الشهادات لا يستطيع التحقق من النطاق حتى يشير DNS إلى المكان الصحيح بشكل ثابت.
التسلسل الطبيعي بسيط:
العوائق الشائعة سهلة الفوت. هدف A أو CNAME خاطئ يوجّه فحوصات التحقق إلى خادم خاطئ. سجل AAAA قديم قد يتجاوز سجل A لبعض الزوار فيؤدي إلى فشل HTTPS عندهم فقط. غياب سجل TXT المطلوب يمكن أن يمنع المنصة من إصدار الشهادة.
استخدم الأعراض لتمييز "قيد الإصدار" عن "مخطئ":
أثناء الانتظار، لا تواصل قلب السجلات. كل تغيير يعيد ضبط الساعة ويمكن أن يخلق عالمًا مقسومًا حيث ترى شبكات مختلفة إجابات مختلفة. اضبط السجلات الصحيحة مرة واحدة، ثم أعد التحقق من الحلول والإصدار حتى تصدر الشهادة.
إذا كنت تستخدم منصة مثل Koder.ai، فالتدفق الأكثر أمانًا هو نفسه: أكد أن DNS يشير إلى الهدف المتوقع، واحذف سجلات AAAA غير الصحيحة إن وُجدت، وأعطِ SSL وقتًا بعد استقرار DNS.
الاستكشاف الجيد مبني على المقارنة: ما تراه مقابل ما تتوقعه. لا تعتمد على "يعمل على هاتفي". استخدم فحوصًا قابلة للتكرار.
استخدم أداة فحص DNS (مثل nslookup أو dig) وتأكد أن القيمة المعادة تطابق ما قصدته (IP لسجل A أو AAAA، اسم مضيف لسجل CNAME، رمز لسجل TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
تحقق من كلا الاسمين الذين قد تستخدمهما: apex (example.com) وwww (www.example.com). شائع أن يكون أحدهما صحيحًا بينما لا يزال الآخر يشير إلى مكان قديم.
افتح كلًا من http:// وhttps:// لكل من apex وwww. تريد دومينًا "رئيسيًا" واضحًا ومسار إعادة توجيه نظيف.
www) وأعد توجيه الآخر إليه.إذا اختلفت النتائج بحسب الشبكة، فأنت على الأرجح ترى تخزينًا مؤقتًا أو انتشارًا. احتفظ بسجل صغير: ما غيّرت، أين غيّرت، الوقت، وما لاحظته.
معظم مشاكل DNS وSSL ليست معجزات. هي أخطاء صغيرة تجعلك تتحقق من الشيء الخاطئ، أو تغيّر الأمور بسرعة بحيث لا تحصل على قراءة واضحة.
الأكثر شيوعًا هو تعديل DNS في مكانين. يحدث هذا غالبًا بعد تبديل خوادم الأسماء: حدّث السجلات عند المسجل، لكن DNS مستضاف في مكان آخر (أو العكس). كل شيء يبدو صحيحًا في لوحة واحدة، ومع ذلك لا يتغير شيء علنيًا.
خطأ كلاسيكي آخر هو محاولة وضع CNAME على النطاق الجذري مع مزود لا يدعم ذلك. قد تحتاج لسجل A، أو سجل من نوع ALIAS أو ANAME إذا وفّره مزود DNS.
IPv6 أيضًا يسبب صداعًا. بقاء سجل AAAA قديم يمكن أن يرسل بعض الزوار للخادم الخطأ بينما يصل الآخرون عبر IPv4 بشكل صحيح.
كن حذرًا مع السجلات "للاحتياط". وجود سجلات A متعددة يمكن أن يتصرف كـ load balancing عرضي إذا كان أحد الأهداف خاطئًا، خاصة عند توجيه نطاق مخصص لتطبيق مستضاف.
قاعدة أخيرة: أوقف إعادة ضبط الساعة.
التغييرات الصغيرة الهادئة تتفوق على التعديلات المستمرة.
تطلق تطبيقًا جديدًا وتُعد كلا من example.com وwww.example.com. بعد دقائق، www.example.com يحمل بشكل جيد، لكن النطاق الجذري يظهر خطأ DNS، أو يحمل موقعًا قديمًا، أو يبقى HTTPS معلقًا. هذا النمط شائع وعادةً ما له سبب بسيط.
ابدأ بالسؤال الممل: هل تعدّل DNS في المكان الصحيح؟ إذا كان نطاقك مسجلاً لدى شركة لكن DNS مستضاف لدى أخرى، يمكنك تعديل السجلات يوميًا ولن يحدث شيء. تحقق من خوادم الأسماء أولًا، ثم افتح لوحة DNS للمزود الذي تشير إليه خوادم الأسماء.
بعدها، قارن الاسمين. www عادةً ما يكون CNAME. النطاق الجذري أصعب: كثير من المزودين لا يسمحون بـ CNAME على الـ apex، لذا غالبًا يحتاج لسجل A إلى عنوان IP، أو سجل ALIAS/ANAME إن وفره المزود.
مسار قرار عملي:
example.com لا يملك سجلًا (أو يشير لمكان آخر)؟ أصلح سجل الجذر.الحالة النهائية الصحيحة مملة: كل من example.com وwww.example.com يوجّهان إلى نفس التطبيق، واحد منهما قياسي (والآخر يعيد التوجيه)، وHTTPS صالح.
عندما يفشل إعداد النطاق، تأتي معظم الإصلاحات من بضعة فحوصات سريعة. نفّذ هذه قبل تغيير أي شيء آخر.
بعد أن يتّضح أن DNS صحيح، تحقق من SSL. كثير من المنصات تصدر الشهادة فقط بعد أن يتم حل نطاقك باستمرار إلى الهدف المتوقع. إذا فحَصت مبكرًا جدًا، قد تظن أن التأخير الطبيعي خطأ حقيقي.
إذا كنت تضيف نطاقًا مخصصًا لتطبيق منشور على Koder.ai، اعتبر شاشة إعداد النطاق مرجعًا لهدف DNS المتوقع، ثم أعد فحص الحالة بعد أن يسمح وقت انتشار DNS.
أسرع طريقة لتجنب تكرار أخطاء DNS وSSL هي الاحتفاظ بمذكرة "إعداد النطاق" قصيرة لكل مشروع. هي دفتر تشغيل قابل لإعادة الاستخدام يمكنك نسخه في الإطلاق التالي.
احتفظ به في مستندات المشروع واملأه قبل لمس DNS:
أثناء الإطلاق، اجعل شخصًا واحدًا مالكًا لـ DNS. الأخطاء تحدث غالبًا عندما يحاول اثنان "الإصلاح" في نفس الوقت (مثلاً أحدهم يغيّر خوادم الأسماء بينما الآخر يحرر السجلات).
على جانب الاستضافة، خطط لعمليات التراجع الآمنة. إذا كانت منصتك تدعم لقطات أو التراجع، التقط لقطة قبل تغيير التوجيه حتى تتمكن من العودة للحالة المعروفة الجيدة بسرعة. إذا بنيت على Koder.ai، يمكنك استخدام وضع التخطيط (Planning Mode) لكتابة خطوات النطاق، تطبيقها بترتيب، والرجوع إذا أثّرت تغييرات على الإنتاج.
إذا أكدت أن DNS صحيح وما زلت ترى أعطالًا، أوقف التخمين وصعّد المشكلة مع دليل:
عند التصعيد، أرفق اسم المضيف، السجلات المتوقعة، نتائج المحللات الحالية، والطوابع الزمنية. هذا يحوّل تبادلًا بطيئًا إلى إصلاح سريع.
عادةً ما يعني ذلك أن طبقة واحدة في السلسلة خاطئة: إما أن DNS لا يحل الاسم، أو يحل إلى الهدف الخاطئ، أو الخادم/المضيف لا يتعرف على اسم المضيف، أو أن HTTPS/SSL لم تصدر بعد. ابدأ بكتابة رسالة الخطأ بالضبط واسم المضيف الذي كتبته (apex مقابل www).
example.com (apex) وwww.example.com هما اسمان مختلفان بسجلات DNS منفصلة. شائع أن يكون لديك CNAME صحيح لـ www بينما لا يوجد سجل A للأpex أو السجل خاطئ أو الإعداد غير مدعوم من مزود DNS.
تحقق من خوادم الأسماء (nameservers) المسجلة لدى المسجل وقارنها بمزود DNS الذي تُجري عليه التعديلات. المزود المدرج في خوادم الأسماء النشطة هو المصدر المخول؛ التعديل في أي لوحة أخرى لن يؤثر على ما يراه الإنترنت العام.
استخدم سجل A عندما يعطيك المضيف عنوان IPv4، وAAAA فقط إذا أعطاك عنوان IPv6، وCNAME عندما يطلب منك المضيف هدفًا اسميًا (شائع لـ www). سجلات TXT تستخدم للتحقق والمهام الخاصة مثل تحديات SSL، ويجب إنشاؤها على الاسم الدقيق الذي يحدده المضيف.
سجل AAAA قديم أو خاطئ يمكن أن يوجّه بعض الزوار عبر IPv6 إلى خادم قديم بينما يذهب الآخرون عبر IPv4 إلى الوجهة الصحيحة، مما يخلق إحساسًا بأن "يعمل عند البعض فقط". إذا لم يقدم مضيفك هدف IPv6، فمحو AAAA غير الصحيح غالبًا ما يحل المشكلة.
عادةً يحدث ذلك لأنك قمت بتكوين اسم مضيف واحد فقط على جهة الاستضافة (فقط apex أو فقط www)، أو لديك قواعد إعادة توجيه متنافسة تؤدي إلى ارتداد بين HTTP وHTTPS أو بين apex وwww. اختر اسمًا قياسيًا واحدًا، قم بتكوين كلا الاسمين، وتأكد من وجود مسار إعادة توجيه واحد واضح.
نعم — الانتظار أحيانًا هو التصرف الصحيح بعد أن تتأكد أن DNS يشير إلى الهدف الصحيح من عدة أماكن. عادةً لن تكتمل إصدار شهادة SSL حتى يحل الاسم بشكل ثابت إلى الوجهة المتوقعة، وتغيير السجلات ذهابًا وإيابًا يعيق العملية.
TTL يحدد مدة احتفاظ المجمّعات بالإجابة، لذا حتى بعد إصلاح السجل قد يستمر بعض الشبكات في تقديم القيمة القديمة حتى انتهاء نافذة TTL. اختبر من شبكتين مختلفتين (مثلاً Wi‑Fi وبيانات الجوال) وتجنب إجراء تغييرات متتابعة سريعة حتى تلاحظ انتشارًا واضحًا.
استخدم فحصًا قابلًا للتكرار مثل dig أو nslookup لتأكد أن إجابات A/AAAA/CNAME/TXT تطابق الهدف المتوقع، ثم اختبر كلًا من http:// وhttps:// لكل من apex وwww. إذا أظهرت شبكة واحدة إجابات DNS مختلفة عن أخرى فاعتبرها تخزينًا مؤقتًا؛ إذا أظهرت كل الشبكات إجابات خاطئة فاعتبرها خطأ في التكوين.
على Koder.ai، اعتبر شاشة إعداد النطاق في التطبيق المصدر الموثوق لهدف DNS المتوقع، ثم اجعل DNS مطابقًا لذلك تمامًا عند المزود المخوّل. بعد تغيير DNS، امنح النظام وقتًا للاستقرار قبل إعادة فحص SSL، واستخدم لقطات/الرجوع إذا كنت تعدّل التوجيه على مشروع حي لتتمكن من العودة للحالة المعروفة الجيدة بسرعة.