استكشاف أخطاء النطاق وSSL وإصلاحها
أصلح مشكلات التحقق من النطاق المخصص وDNS والتوجيه وعمليات إعادة التوجيه وHTTPS من خلال فحوصات مستهدفة.
استخدم هذا الدليل عندما لا يصبح النطاق المخصص جاهزًا، أو يفتح موقع الويب الخطأ، أو يعيد التوجيه بشكل غير صحيح، أو يعرض خطأ في HTTPS/الأمان.
ابدأ من هنا
الإعدادات → النطاقات → إدارة → حالة النطاق → حدّد المرحلة التي فشلت → أعد التحقق
حدّد مشكلتك أولًا
استخدم جدول الأعراض قبل تغيير DNS. ابدأ بالقسم الذي يطابق ما تراه، وأجرِ تغييرًا واحدًا مستهدفًا، ثم أعد التحقق من حالة النطاق واسم المضيف في المتصفح.
| ما الذي تراه | انتقل إلى |
|---|---|
| يتعذر على Atoms التحقق من النطاق، أو يبدو أن سجلًا مطلوبًا مفقود | مشكلات التحقق وسجلات DNS |
| يفتح النطاق موقع ويب قديمًا أو خاطئًا | التوجيه، أو السجلات المتعارضة، أو Cloudflare، أو ربط المشروع |
| يعمل التغيير على بعض الشبكات دون غيرها | انتشار DNS والتخزين المؤقت المحلي |
| يفشل HTTPS أو يعرض المتصفح تحذيرًا بشأن الشهادة | مشكلات SSL / HTTPS |
| يفتح النطاق مشروع Atoms خاطئًا | سلوك المشروع الخاطئ |
| يتصرف النطاق الجذر وwww بشكل مختلف | استكشاف أخطاء الجذر / www وإصلاحها |
| يعيد النطاق التوجيه إلى عنوان خاطئ أو يدخل في حلقة | استكشاف أخطاء إعادة التوجيه وإصلاحها |
| تفشل عدة نطاقات Atoms غير مرتبطة في الوقت نفسه | توقّف عن تغيير DNS وتواصل مع دعم Atoms |
مهم
استخدم دائمًا قيم DNS المعروضة حاليًا داخل Atoms للنطاق الذي تستكشف مشكلته. لا تنسخ عنوان IP أو قيمة تحقق أو هدف DNS من نطاق آخر أو لقطة شاشة قديمة أو دليل أقدم.
مكان التحقق من النطاق
مرجع سريع: مصطلحات قد تراها أثناء استخدام هذا الدليل
لا تحتاج إلى فهم DNS داخليًا لاستخدام خطوات استكشاف الأخطاء وإصلاحها. هذه التعريفات موجودة فقط عندما يكون المصطلح غير مألوف.
| المصطلح | ما معناه |
|---|---|
| DNS | الإعدادات التي تخبر الإنترنت إلى أين يجب أن يوجّه نطاقك الزوار وما الخدمات عبر الإنترنت التي يستخدمها. |
| Authoritative DNS / nameservers | خدمة DNS التي تتحكم فعليًا في الإعدادات المباشرة لنطاقك. إذا غيّرت DNS في مكان آخر، فلن تؤثر هذه التغييرات في النطاق. |
| A / AAAA / CNAME | سجلات تخبر المتصفحات أين تجد موقع الويب الخاص بك. يمكن أن تؤدي السجلات القديمة أو المتعارضة إلى إرسال الزوار إلى الموقع الخطأ. |
| TXT | سجل DNS نصي يُستخدم غالبًا لإثبات أنك تتحكم في نطاق ما. قد يطلب منك Atoms إضافة واحد أثناء إعداد النطاق. |
| DNS propagation / TTL | الوقت الذي يستغرقه تغيير DNS ليظهر في كل مكان. خلال هذه الفترة، قد يستمر بعض الأشخاص في رؤية النتيجة القديمة. |
| CAA | قاعدة DNS اختيارية تتحكم في الشركات المسموح لها بإصدار شهادة الأمان اللازمة لـ HTTPS على نطاقك. |
| Cloudflare proxy | إعداد في Cloudflare يمرر حركة مرور موقع الويب عبر Cloudflare قبل أن تصل إلى موقعك. قد يؤثر ذلك في كيفية توجيه النطاق أو التحقق منه. |
قبل أن تغيّر أي شيء
• سجّل حالة النطاق الدقيقة وأي رسالة خطأ معروضة في Atoms.
• غيّر إعداد DNS أو توجيه واحدًا فقط في كل مرة حتى تتمكن من معرفة أي تغيير أثّر في النتيجة.
• سجّل القيمة السابقة قبل تعديل سجل DNS إنتاجي.
• لا تحذف السجلات لمجرد أنك لا تتعرف عليها. قد تدعم سجلات MX وسجلات TXT المتعلقة بالبريد والنطاقات الفرعية غير المرتبطة البريد الإلكتروني أو خدمات أخرى.
• لا تغيّر خوادم الأسماء فقط لإصلاح مشكلة تحقق واحدة ما لم تكن هناك عملية ترحيل DNS منفصلة مقصودة ومؤكدة.
• إذا أدى تغيير أثناء استكشاف الأخطاء وإصلاحها إلى تعطيل موقع ويب يعمل أو البريد الإلكتروني أو خدمة أخرى، فاستعد فقط آخر تغيير تسبب في التراجع.
مشكلات التحقق وسجلات DNS
استخدم هذا القسم عندما يتعذر على Atoms التحقق من النطاق، أو يبدو أن سجلًا مطلوبًا مفقود أو غير صحيح، أو عندما عدّلت DNS لكن حالة النطاق لم تتغير.
تحقق من مصدر DNS أولًا
• افتح النطاق في Atoms وقارن كل سجل مطلوب بما هو منشور علنًا لاسم المضيف نفسه.
• تحقق من خوادم الأسماء authoritative الخاصة بالنطاق وتأكد من أنك تعدّل DNS لدى المزوّد الذي يقدّم تلك الخوادم. إذا كانت خوادم الأسماء تشير إلى Cloudflare، فقد لا تكون التغييرات التي تُجرى فقط في لوحة DNS الخاصة بمسجّل النطاق authoritative.
• لكل سجل مطلوب، أكّد نوع السجل واسم المضيف/الاسم والهدف أو القيمة، وأن السجل موجود فعلًا لدى المزوّد authoritative.
• يجب أن تتطابق قيمة التحقق تمامًا مع القيمة المعروضة حاليًا بواسطة Atoms ويجب أن تكون مرئية في بحث DNS عام.
أصلح عدم التطابق فقط، ثم أعد التحقق
• أنشئ سجلًا مفقودًا أو صحّح فقط الحقل الذي لا يتطابق.
• إذا تمت إضافة السجل لدى مزوّد DNS خاطئ، فأضفه لدى المزوّد authoritative بدلًا من ذلك.
• لا تستبدل قيمة Atoms الحالية بعنوان أو قيمة تحقق من مشروع آخر أو نطاق آخر أو لقطة شاشة قديمة أو مقالة أقدم في مركز المساعدة.
• بعد أن يصبح التغيير عامًا، ارجع إلى النطاقات → إدارة، وأعد التحقق من حالة النطاق، ثم اختبر اسم المضيف في المتصفح.
احمِ الخدمات غير المرتبطة
إذا أدى تغيير DNS إلى تعطيل البريد الإلكتروني أو خدمة خارجية أخرى، فاستعد فقط سجل MX أو TXT أو التحقق أو النطاق الفرعي غير المرتبط الذي تم تغييره عن طريق الخطأ. ثم واصل استكشاف الأخطاء وإصلاحها سجلًا واحدًا في كل مرة.
التوجيه والمحتوى القديم والسجلات المتعارضة وCloudflare
استخدم هذا القسم عندما يفتح اسم المضيف موقع ويب قديمًا، أو يصل إلى وجهة خاطئة، أو يحتوي على عدة سجلات توجيه لاسم المضيف نفسه.
تحقق من سجلات A وAAAA وCNAME لاسم المضيف المحدد
• ابحث عن سجلات من مزوّد استضافة سابق، أو وجهة IPv6 AAAA قديمة، أو CNAME بالإضافة إلى سجل وجهة آخر لاسم المضيف نفسه، أو سجلات مكررة ترسل حركة المرور إلى خدمات مختلفة.
• أزل فقط سجل توجيه موقع ويب تأكدت من أنه يتعارض مع إعداد Atoms الحالي. لا تحذف السجلات غير المعروفة كخطوة تنظيف.
• إذا كان DNS يشير بالفعل إلى الوجهة المقصودة لكن المحتوى القديم ما زال يظهر، فاختبر نافذة خاصة/تصفح خفي، أو متصفحًا أو جهازًا آخر، وشبكة أخرى قبل تغيير DNS مرة أخرى.
حالة Cloudflare proxy
• سجلات التحقق TXT هي DNS فقط؛ وليست سجلات وكيل ويب.
• بالنسبة إلى سجلات A أو CNAME، غيّر Proxy Status فقط عندما تتطلب واجهة Atoms أو دعم Atoms ذلك تحديدًا. لا تبدّل السجلات بين Proxied وDNS only كخطوة روتينية في استكشاف الأخطاء وإصلاحها.
• إذا طلب منك Atoms أو الدعم تغيير حالة الوكيل، فغيّر فقط سجل التوجيه المسمى، وانتظر حتى تصبح استجابة DNS الجديدة مرئية، ثم أعد اختبار النطاق وHTTPS.
انتشار DNS والتخزين المؤقت المحلي
إذا كان DNS authoritative صحيحًا بالفعل لكن الشبكات أو الأجهزة المختلفة ما زالت تعرض نتائج مختلفة، فعادةً ما تكون المشكلة المتبقية هي التخزين المؤقت وليس خطأ إعداد جديد.
• قارن نتيجة DNS authoritative مع واحد أو أكثر من محللات DNS العامة، وإذا كان ذلك مفيدًا، مع شبكة أخرى مثل بيانات الهاتف المحمول.
• إذا كان DNS authoritative خاطئًا، فصحّح سجل المصدر. وإذا كان DNS authoritative صحيحًا لكن المحللات الأخرى ما زالت تعيد القيمة السابقة، فتجنب تعديل السجل بشكل متكرر.
• قد تستغرق تغييرات DNS ما يصل إلى 48 ساعة لتصبح مرئية عالميًا، رغم أنها تظهر عادةً في وقت أقرب.
• إذا كان متصفح أو جهاز واحد فقط يعرض النتيجة الخاطئة بينما DNS وAtoms صحيحان في أماكن أخرى، فامسح أو تجاوز ذاكرة التخزين المؤقت المحلية لذلك المتصفح/الشبكة. لا تغيّر DNS بسبب مشكلة تخزين مؤقت خاصة بجهاز معين.
• أعد التحقق لاحقًا وابحث عن تقارب المحللات العامة على القيمة المقصودة نفسها.
مشكلات SSL / HTTPS
استخدم هذا القسم عندما يبدو DNS صحيحًا لكن يتعذر إصدار HTTPS، أو يعرض المتصفح تحذيرًا بشأن الشهادة، أو كان HTTPS يعمل سابقًا ثم فشل الآن.
تحقق من الإعدادات المحيطة بالشهادة
• سجّل خطأ المتصفح الدقيق واسم المضيف الدقيق الذي يتم فتحه.
• أكّد توجيه DNS وانتشاره وحالة Cloudflare proxy وما إذا كانت الشهادة تبدو تابعة لاسم مضيف مختلف.
• تحقق مما إذا كان أي شيء قد تغيّر مؤخرًا في DNS أو خوادم الأسماء أو إعدادات Cloudflare proxy أو سجلات CAA أو ربط المشروع/النطاق.
• تحقق من سجلات CAA على اسم المضيف المتأثر والنطاق الأب إذا كانت هناك سياسة شهادة مقيّدة محتملة.
تنبيه بشأن CAA
لا ينشر Atoms جهة إصدار الشهادات التي يجب على المستخدمين إضافتها إلى سجلات CAA. لا تخمّن جهة إصدار شهادات Atoms ولا تضف قيمة CAA عشوائية. إذا كانت سياسة CAA مقيّدة قد تمنع الإصدار، فتواصل مع دعم Atoms قبل تغيير CAA.
أصلح وتحقق
• صحّح فقط مشكلة مؤكدة تتعلق بـ DNS أو الوكيل أو CAA أو اسم المضيف أو ربط المشروع.
• لا تتجاوز تحذيرات شهادة المتصفح كحل عادي.
• إذا كان DNS العام صحيحًا ولا يوجد إعداد يتحكم فيه المستخدم يفسر الفشل، فتوقف عن تغيير DNS وتواصل مع دعم Atoms بشأن توفير الشهادة أو تجديدها.
• لا تستبدل DNS الصحيح بخلاف ذلك فقط لفرض تجديد الشهادة ما لم يطلب Atoms منك ذلك تحديدًا.
• أعد التحقق بفتح اسم المضيف الدقيق باستخدام https:// والتأكد من تحميل المشروع المقصود دون تحذير شهادة.
الجذر وwww وعمليات إعادة التوجيه وسلوك المشروع الخاطئ
يجدر التحقق من هذه المشكلات هنا لأنها قد تبدو كإخفاقات DNS أو SSL حتى عندما يكون الاتصال الأساسي يعمل بالفعل.
يعمل الجذر لكن www لا يعمل — أو العكس
• تعامل مع example.com وwww.example.com على أنهما اسما مضيف منفصلان. اختبر كليهما عبر HTTPS.
• تحقق من نتيجة DNS وحالة نطاق Atoms لاسم المضيف الذي يفشل.
• لا تفترض أنه يجب ببساطة نسخ قيم النطاق الجذر إلى www.
إذا كان اسم المضيف لا يزال بحاجة إلى الاتصال أو إعادة التهيئة، فاتبع خطوات الإعداد في Connect and Manage Domains بدلًا من تكرار إجراء التهيئة هنا.
تنتقل عمليات إعادة التوجيه إلى العنوان الخاطئ أو تدخل في حلقة
• أكّد العنوان الذي تتوقع أن ينتهي عنده الزوار واختبر إعادة التوجيه في جلسة متصفح جديدة/خاصة.
• تحقق مما إذا كان نظام آخر ينفذ أيضًا عمليات إعادة توجيه، مثل إعادة التوجيه من المسجّل، أو قواعد إعادة التوجيه في Cloudflare، أو وكيل/CDN آخر، أو منصة الاستضافة السابقة.
• غيّر فقط طبقة إعادة التوجيه المتعارضة المؤكدة. تجنب تغيير عدة أنظمة إعادة توجيه في الوقت نفسه.
• إذا تسبب تغيير ما في إنشاء حلقة إعادة توجيه أو إرسال الزوار إلى الوجهة الخاطئة، فاستعد إعداد إعادة التوجيه السابق الذي كان يعمل قبل اختبار طبقة أخرى.
لتغيير العنوان المتصل الأساسي، استخدم الإجراء الموجود في Connect and Manage Domains.
يفتح النطاق مشروع Atoms خاطئًا
• إذا كان DNS يصل بالفعل إلى Atoms بشكل صحيح، فتعامل مع المشكلة على أنها مشكلة ربط مشروع/نطاق بدلًا من تغيير DNS بشكل متكرر.
• أكّد أي مشروع أو مساحة عمل تعرض حاليًا ربط النطاق.
• بعد تصحيح الربط، أعد التحقق من أن اسم المضيف يفتح المشروع المقصود وأن HTTPS ما زال يعمل.
للتبديل أو الفصل أو إعادة الاتصال أو نقل نطاق بين المشاريع، اتبع Connect and Manage Domains. إذا كان الربط الحالي يخص مشروعًا/مساحة عمل/حسابًا غير قابل للوصول أو محذوفًا، فتواصل مع دعم Atoms بدلًا من إجراء تغييرات إضافية على DNS.
متى يجب التوقف عن تغيير DNS والتواصل مع دعم Atoms
قم بالتصعيد بدلًا من الاستمرار في تعديل DNS عندما تشير الأدلة إلى وجود مشكلة في حالة Atoms أو الشهادة أو الربط.
• تم تأكيد صحة DNS لكن حالة نطاق Atoms لا تتعافى.
• يفشل توفير الشهادة أو تجديدها رغم أن DNS العام والإعدادات التي يتحكم فيها المستخدم صحيحة.
• النطاق مرتبط بمشروع/مساحة عمل/حساب غير قابل للوصول أو محذوف، أو يفشل إجراء إدارة النطاق ذي الصلة.
• تفشل عدة نطاقات Atoms غير مرتبطة في الوقت نفسه ولم تتغير سجلات DNS الخاصة بها مؤخرًا.
• يؤثر تغيير أثناء استكشاف الأخطاء وإصلاحها في خدمة أخرى ولا يمكنك تحديد التراجع الصحيح بأمان.
ملاحظة حول حالة الخدمة
لا توجد حاليًا صفحة عامة مؤكدة تعمل لحالة خدمة Atoms. إذا فشلت عدة نطاقات غير مرتبطة في الوقت نفسه، فتجنب تعديل DNS الصحيح بخلاف ذلك وتواصل مع دعم Atoms.
جهّز هذه الأدلة قبل التصعيد
• اسم المضيف المتأثر ومشروع Atoms/مساحة العمل المقصودان.
• حالة النطاق الدقيقة أو رسالة الخطأ المعروضة حاليًا.
• نتائج DNS authoritative الحالية والقيم التي يطلبها Atoms حاليًا.
• خطأ HTTPS/الشهادة الدقيق في المتصفح، إن وُجد.
• آخر تغيير تم إجراؤه وما إذا كانت استعادته أعادت السلوك السابق.
إعادة التحقق النهائية
بعد أي إصلاح، ارجع إلى النطاقات → إدارة وأعد التحقق من حالة النطاق. ثم أكّد النتيجة في المتصفح.
• اسم المضيف المقصود متصل ويصل إلى مشروع Atoms المقصود.
• يعمل HTTPS دون تحذير شهادة.
• يتصرف الجذر وwww كما هو مقصود.
• تنتهي عمليات إعادة التوجيه عند العنوان المقصود.
• ما زال البريد الإلكتروني والخدمات الأخرى غير المرتبطة تعمل بعد تغييرات DNS.
النتيجة الكاملة
حالة نطاق صحيحة + موقع ويب صحيح + HTTPS + اسم مضيف صحيح + عمليات إعادة توجيه متوقعة
الأسئلة الشائعة
لماذا يعرض نطاقي المخصص DNS_PROBE_FINISHED_NXDOMAIN؟
إذا كان متصفحك يعرض DNS_PROBE_FINISHED_NXDOMAIN، فهذا يعني أن الطلب لم يصل إلى منصتنا بعد. يُرجى التحقق من:
- أن نطاقك لم تنتهِ صلاحيته.
- أن خوادم الأسماء تشير بشكل صحيح.
- أن سجلات A/CNAME/TXT المطلوبة مُعدّة كما تحددها المنصة.
المعلومات المطلوبة لاستكشاف الأخطاء وإصلاحها:
- اسم النطاق الكامل
- المسجّل / مزوّد DNS
- لقطة شاشة كاملة للشاشة لسجلات DNS الحالية
- وقت آخر تعديل
- نتائج الاختبار لكل من apex وwww كلٌّ على حدة
سنتحقق من انتشار DNS وربط المنصة بمجرد تأكيد السجلات.
لماذا يتصرف النطاق الجذر والنطاق الفرعي www بشكل مختلف؟
النطاق الجذر والنطاق الفرعي www هما اسما مضيف منفصلان، لذلك قد يعمل أحدهما بينما يكون الآخر غير مُعد.
- اختر اسم المضيف الذي يجب أن يكون أساسيًا وما إذا كان يجب أن يعيد الآخر التوجيه إليه.
- في إعدادات النطاق في Atoms، أكّد أن كلا اسمي المضيف مضافان أو أن إعادة التوجيه المقصودة مُعدّة.
- لدى مزوّد DNS الخاص بك، قارن كل اسم مضيف بالسجل الدقيق الذي يطلبه Atoms حاليًا. أزل سجلًا متعارضًا فقط بعد التأكد من أنه لا تستخدمه خدمة أخرى.
- انتظر تحديثات DNS والشهادة، ثم اختبر كلا عنواني HTTPS في نافذة تصفح خفي.
إذا استمر الاختلاف بينهما، فتواصل مع الدعم مع تزويدهم بكلا الرابطين، واسم المضيف الأساسي المطلوب، ولقطة شاشة لإعدادات النطاق، ولقطة شاشة لـ DNS، والخطأ من كل عنوان، ووقت آخر تغيير.
سجلات DNS الخاصة بي صحيحة، لكن نطاقي المخصص ما زال لا يعمل. لماذا؟
- لا تفصل ربط النطاق بشكل متكرر ولا تحذف السجلات؛ فقد يؤدي ذلك إلى إعادة بدء التحقق أو عمل الشهادة.
- أكّد مزوّد DNS authoritative وقارن نتيجة A أو CNAME أو TXT المباشرة بالقيمة الدقيقة المعروضة في Atoms. تحقق من وجود سجلات مكررة أو متعارضة.
- أكّد أن النطاق ما زال مرتبطًا بالمشروع الصحيح وأن عنوان URL الإنتاج الخاص بالمنصة يعمل.
- إذا تغيّرت السجلات مؤخرًا، فانتظر TTL المنشور وإصدار الشهادة قبل الاختبار مرة أخرى.
إذا كان النطاق ما زال يعرض 404 أو تحذير شهادة أو مسارًا غير متصل، فتواصل مع الدعم مع تزويدهم باسم النطاق الكامل، وصفحة إعدادات النطاق، ولقطة شاشة لـ DNS، ووقت آخر تغيير وإعادة تحقق، وعنوان URL الإنتاج الخاص بالمنصة، والخطأ الكامل.
لماذا ما زال نطاقي المخصص يعرض محتوى قديمًا بعد أن نشرت إصدارًا جديدًا؟
- افتح Publish وأكّد أن أحدث إصدار قد تم نشره وأن الحالة حالية.
- قارن عنوان URL الإنتاج الخاص بالمنصة بالنطاق المخصص.
- أجرِ تحديثًا قسريًا للنطاق المخصص واختبره في نافذة تصفح خفي.
- إذا كان عنوان URL الخاص بالمنصة حاليًا لكن النطاق المخصص قديمًا، فأكّد أن النطاق ما زال يشير إلى هدف Atoms الحالي. إذا كنت تستخدم وكيلًا أو CDN، فحدّث ذاكرة التخزين المؤقت الخاصة به وفقًا لإرشادات ذلك المزوّد.
لا تغيّر سجلات DNS ما لم تكن مختلفة عن متطلبات Atoms الحالية. إذا استمرت المشكلة، فتواصل مع الدعم مع تزويدهم بكلا الرابطين، ولقطات شاشة للمقارنة، والإصدار الحالي، ووقت النشر، ومزوّد DNS أو الوكيل، والمسارات المتأثرة.