Atoms
Domains & SSL

استكشاف أخطاء النطاق و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 المتعلقة بالبريد والنطاقات الفرعية غير المرتبطة البريد الإلكتروني أو خدمات أخرى.

• لا تغيّر nameservers فقط لإصلاح مشكلة تحقق واحدة ما لم تكن هناك عملية ترحيل DNS منفصلة مقصودة ومؤكدة.

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

مشكلات التحقق وسجلات DNS

استخدم هذا القسم عندما يتعذر على Atoms التحقق من النطاق، أو يبدو أن سجلًا مطلوبًا مفقود أو غير صحيح، أو عندما عدّلت DNS لكن حالة النطاق لم تتغير.

تحقق من مصدر DNS أولاً

• افتح النطاق في Atoms وقارن كل سجل مطلوب بما هو منشور علنًا لاسم المضيف نفسه.

• تحقق من nameservers المعتمدة للنطاق وتأكد من أنك تعدّل DNS لدى المزوّد الذي يخدم تلك nameservers. إذا كانت nameservers تشير إلى Cloudflare، فقد لا تكون التغييرات التي أُجريت فقط في لوحة DNS الخاصة بالمسجّل معتمدة.

• لكل سجل مطلوب، أكّد نوع السجل واسم المضيف/الاسم والهدف أو القيمة، وأن السجل موجود فعليًا لدى المزوّد المعتمد.

• يجب أن تتطابق قيمة التحقق تمامًا مع القيمة المعروضة حاليًا بواسطة Atoms ويجب أن تكون مرئية في بحث DNS عام.

أصلِح عدم التطابق فقط، ثم أعد الفحص

• أنشئ سجلًا مفقودًا أو صحّح فقط الحقل الذي لا يتطابق.

• إذا تمت إضافة السجل لدى مزوّد DNS خاطئ، فأضفه لدى المزوّد المعتمد بدلًا من ذلك.

• لا تستبدل قيمة Atoms الحالية بعنوان أو قيمة تحقق من مشروع آخر أو نطاق آخر أو لقطة شاشة قديمة أو مقالة أقدم في مركز المساعدة.

• بعد أن يصبح التغيير عامًا، ارجع إلى النطاقات → إدارة، وأعد فحص حالة النطاق، ثم اختبر اسم المضيف في المتصفح.

احمِ الخدمات غير المرتبطة

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

التوجيه والمحتوى القديم والسجلات المتعارضة وCloudflare

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

تحقق من سجلات A وAAAA وCNAME لاسم المضيف الدقيق

• ابحث عن سجلات من مزوّد استضافة سابق، أو وجهة IPv6 AAAA قديمة، أو CNAME بالإضافة إلى سجل وجهة آخر لاسم المضيف نفسه، أو سجلات مكررة ترسل الحركة إلى خدمات مختلفة.

• أزل فقط سجل توجيه موقع ويب تأكدت من أنه يتعارض مع إعداد Atoms الحالي. لا تحذف السجلات غير المعروفة كخطوة تنظيف.

• إذا كان DNS يشير بالفعل إلى الوجهة المقصودة لكن المحتوى القديم يظهر، فاختبر نافذة خاصة/تصفح خفي، أو متصفحًا أو جهازًا آخر، وشبكة أخرى قبل تغيير DNS مرة أخرى.

حالة وكيل Cloudflare

• سجلات التحقق TXT هي DNS فقط؛ وليست سجلات وكيل ويب.

• بالنسبة إلى سجلات A أو CNAME، غيّر Proxy Status فقط عندما تتطلب واجهة Atoms أو دعم Atoms ذلك تحديدًا. لا تبدّل السجلات بين Proxied وDNS only كخطوة روتينية في استكشاف الأخطاء وإصلاحها.

• إذا طلب منك Atoms أو الدعم تغيير حالة الوكيل، فغيّر فقط سجل التوجيه المذكور، وانتظر حتى تصبح استجابة DNS الجديدة مرئية، ثم أعد اختبار النطاق وHTTPS.

انتشار DNS والتخزين المؤقت المحلي

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

• قارن نتيجة DNS المعتمد مع واحد أو أكثر من محللات DNS العامة، وإذا كان ذلك مفيدًا، مع شبكة أخرى مثل بيانات الهاتف المحمول.

• إذا كان DNS المعتمد خاطئًا، فصحّح سجل المصدر. وإذا كان DNS المعتمد صحيحًا لكن المحللات الأخرى لا تزال تُرجع القيمة السابقة، فتجنب تعديل السجل بشكل متكرر.

• قد تستغرق تغييرات DNS ما يصل إلى 48 ساعة لتصبح مرئية عالميًا، رغم أنها تظهر عادةً في وقت أقرب.

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

• أعد الفحص لاحقًا وابحث عن تقارب المحللات العامة على القيمة المقصودة نفسها.

مشكلات SSL / HTTPS

استخدم هذا القسم عندما يبدو DNS صحيحًا لكن يتعذر إصدار HTTPS، أو يعرض المتصفح تحذيرًا بشأن الشهادة، أو كان HTTPS يعمل سابقًا ثم فشل الآن.

تحقق من الإعدادات المحيطة بالشهادة

• سجّل خطأ المتصفح الدقيق واسم المضيف الدقيق الذي يتم فتحه.

• أكّد توجيه DNS وانتشاره وحالة وكيل Cloudflare وما إذا كانت الشهادة تبدو تابعة لاسم مضيف مختلف.

• تحقق مما إذا كان أي شيء قد تغيّر مؤخرًا في DNS أو nameservers أو إعدادات وكيل Cloudflare أو سجلات 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.

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

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

• أكّد العنوان الذي تتوقع أن ينتهي إليه الزوار واختبر إعادة التوجيه في جلسة متصفح جديدة/خاصة.

• تحقق مما إذا كان نظام آخر ينفذ أيضًا عمليات إعادة توجيه، مثل إعادة التوجيه لدى المسجّل أو قواعد إعادة التوجيه في Cloudflare أو وكيل/CDN آخر أو منصة الاستضافة السابقة.

• غيّر فقط طبقة إعادة التوجيه المتعارضة المؤكدة. تجنب تغيير عدة أنظمة إعادة توجيه في الوقت نفسه.

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

لتغيير العنوان المتصل الأساسي، استخدم الإجراء الموجود في ربط النطاقات وإدارتها.

يفتح النطاق مشروع Atoms خاطئًا

• إذا كان DNS يصل بالفعل إلى Atoms بشكل صحيح، فتعامل مع المشكلة على أنها مشكلة ربط مشروع/نطاق بدلًا من تغيير DNS بشكل متكرر.

• أكّد أي مشروع أو مساحة عمل تعرض حاليًا ربط النطاق.

• بعد تصحيح الربط، أعد التحقق من أن اسم المضيف يفتح المشروع المقصود وأن HTTPS لا يزال يعمل.

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

متى يجب التوقف عن تغيير DNS والتواصل مع دعم Atoms

قم بالتصعيد بدلًا من الاستمرار في تعديل DNS عندما تشير الأدلة إلى مشكلة في حالة Atoms أو الشهادة أو الربط من جهة Atoms.

• تم التأكد من صحة DNS لكن حالة نطاق Atoms لا تتعافى.

• يفشل توفير الشهادة أو تجديدها رغم أن DNS العام والإعدادات التي يتحكم فيها المستخدم صحيحة.

• النطاق مرتبط بمشروع/مساحة عمل/حساب غير قابل للوصول أو محذوف، أو يفشل إجراء إدارة النطاق ذي الصلة.

• تفشل عدة نطاقات Atoms غير مرتبطة في الوقت نفسه ولم تتغير سجلات DNS الخاصة بها مؤخرًا.

• يؤثر تغيير أثناء استكشاف الأخطاء وإصلاحها في خدمة أخرى ولا يمكنك تحديد التراجع الصحيح بأمان.

ملاحظة حول حالة الخدمة

لا توجد حاليًا صفحة عامة مؤكدة تعمل لحالة خدمة Atoms. إذا فشلت عدة نطاقات غير مرتبطة في الوقت نفسه، فتجنب تعديل DNS الصحيح بخلاف ذلك وتواصل مع دعم Atoms.

جهّز هذه الأدلة قبل التصعيد

• اسم المضيف المتأثر ومشروع/مساحة العمل المقصودان في Atoms.

• حالة النطاق الدقيقة أو رسالة الخطأ المعروضة حاليًا.

• نتائج DNS المعتمدة الحالية والقيم التي يطلبها Atoms حاليًا.

• خطأ HTTPS/الشهادة الدقيق في المتصفح، إن وجد.

• آخر تغيير تم إجراؤه وما إذا كانت استعادته قد أعادت السلوك السابق.

إعادة الفحص النهائية

بعد أي إصلاح، ارجع إلى النطاقات → إدارة وأعد فحص حالة النطاق. ثم أكّد النتيجة في المتصفح.

• اسم المضيف المقصود متصل ويصل إلى مشروع Atoms المقصود.

• يعمل HTTPS دون تحذير بشأن الشهادة.

• يتصرف الجذر وwww كما هو مقصود.

• تنتهي عمليات إعادة التوجيه عند العنوان المقصود.

• لا يزال البريد الإلكتروني والخدمات الأخرى غير المرتبطة تعمل بعد تغييرات DNS.

النتيجة الكاملة

حالة نطاق صحيحة + موقع ويب صحيح + HTTPS + اسم مضيف صحيح + عمليات إعادة توجيه متوقعة

الأسئلة الشائعة

لماذا يعرض نطاقي المخصص DNS_PROBE_FINISHED_NXDOMAIN؟

إذا كان متصفحك يعرض DNS_PROBE_FINISHED_NXDOMAIN، فهذا يعني أن الطلب لم يصل إلى منصتنا بعد. يُرجى التحقق من:

  1. لم تنتهِ صلاحية نطاقك.
  2. تشير nameservers بشكل صحيح.
  3. تم تكوين سجلات A/CNAME/TXT المطلوبة كما تحددها المنصة.

المعلومات المطلوبة لاستكشاف الأخطاء وإصلاحها:

- اسم النطاق الكامل

- المسجّل / مزوّد DNS

- لقطة شاشة بملء الشاشة لسجلات DNS الحالية

- وقت آخر تعديل

- نتائج الاختبار لكل من apex وwww بشكل منفصل

سنتحقق من انتشار DNS وربط المنصة بمجرد تأكيد السجلات.

لماذا يتصرف النطاق الجذر والنطاق الفرعي www بشكل مختلف؟

النطاق الجذر والنطاق الفرعي www هما اسما مضيف منفصلان، لذلك يمكن أن يعمل أحدهما بينما يكون الآخر غير مهيأ.

  1. اختر اسم المضيف الذي يجب أن يكون أساسيًا وما إذا كان يجب أن يعيد الآخر التوجيه إليه.
  2. في إعدادات نطاق Atoms، أكّد أن كلا اسمي المضيف قد تمت إضافتهما أو أن إعادة التوجيه المقصودة مهيأة.
  3. لدى مزوّد DNS الخاص بك، قارن كل اسم مضيف بالسجل الدقيق الذي يطلبه Atoms حاليًا. أزل سجلًا متعارضًا فقط بعد التأكد من أنه غير مستخدم من خدمة أخرى.
  4. انتظر تحديثات DNS والشهادة، ثم اختبر كلا عنواني HTTPS في نافذة التصفح الخفي.

إذا استمر الاختلاف، فتواصل مع الدعم مع كلا الرابطين واسم المضيف الأساسي المطلوب ولقطة شاشة لإعدادات النطاق ولقطة شاشة لـ DNS والخطأ من كل عنوان ووقت آخر تغيير.

سجلات DNS الخاصة بي صحيحة، لكن نطاقي المخصص لا يزال لا يعمل. لماذا؟
  1. لا تفصل ربط النطاق بشكل متكرر ولا تحذف السجلات؛ فقد يؤدي ذلك إلى إعادة بدء التحقق أو أعمال الشهادة.
  2. أكّد مزوّد DNS المعتمد وقارن نتيجة A أو CNAME أو TXT المباشرة بالقيمة الدقيقة المعروضة في Atoms. تحقق من السجلات المكررة أو المتعارضة.
  3. أكّد أن النطاق لا يزال مرتبطًا بالمشروع الصحيح وأن عنوان URL الإنتاج الخاص بالمنصة يعمل.
  4. إذا تغيّرت السجلات مؤخرًا، فانتظر TTL المنشور وإصدار الشهادة قبل الاختبار مرة أخرى.

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

لماذا لا يزال نطاقي المخصص يعرض محتوى قديمًا بعد أن نشرت إصدارًا جديدًا؟
  1. افتح Publish وأكّد أن أحدث إصدار قد تم نشره وأن الحالة حالية.
  2. قارن عنوان URL الإنتاج الخاص بالمنصة بالنطاق المخصص.
  3. نفّذ تحديثًا قسريًا للنطاق المخصص واختبره في نافذة التصفح الخفي.
  4. إذا كان عنوان URL الخاص بالمنصة حاليًا لكن النطاق المخصص قديمًا، فأكّد أن النطاق لا يزال يشير إلى هدف Atoms الحالي. إذا كنت تستخدم وكيلًا أو CDN، فحدّث ذاكرة التخزين المؤقت الخاصة به وفقًا لتعليمات ذلك المزوّد.

لا تغيّر سجلات DNS ما لم تكن تختلف عن متطلبات Atoms الحالية. إذا استمرت المشكلة، فتواصل مع الدعم مع كلا الرابطين ولقطات شاشة للمقارنة والإصدار الحالي ووقت النشر ومزوّد DNS أو الوكيل والمسارات المتأثرة.

هل كانت هذه الصفحة مفيدة؟

مقالات ذات صلة