دليل Cloudflare DNS: من شراء النطاق إلى تشغيل الموقع

يمكنك نقل إدارة DNS إلى Cloudflare وإبقاء الموقع على استضافته الحالية. أما نقل الموقع نفسه فهو قرار مستقل. فهم هذا الفرق يسهّل بقية الإعداد.

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

نعتمد الإعداد المعتاد لموقع على الإنترنت، مع قسم مختصر لطرق إعداد DNS الأخرى في نهاية الدليل.

إذا عدت إلى المقال لإنجاز مهمة محددة، يمكنك الانتقال مباشرة إلى:

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

من يجيب عن الاستعلامات الخاصة بنطاقك؟

مسجّل النطاق هو الجهة التي تشتري منها النطاق وتجدّد اشتراكه لديها. وفي إعداداته تحدّد خوادم الأسماء المسؤولة عن سجلات النطاق، وتسمّى خوادم الأسماء الموثوقة، أو authoritative nameservers. أما الاستضافة فهي المكان الذي يعمل فيه الموقع. وقد تتولى ثلاث شركات مختلفة هذه المهام.

عندما يحتاج المتصفح إلى عنوان الموقع، يستعين بخادم لحل أسماء النطاقات يسمّى DNS resolver. قد يجد الإجابة محفوظة لديه، أو يبحث عنها عبر تسلسل خوادم DNS حتى يصل إلى الخوادم المسؤولة عن النطاق. يشرح دليل Cloudflare لعمل DNS هذه الخطوات بالتفصيل.

في مثال www.example.com، يدلّ خادم الجذر على خوادم .com، وهذه تدلّ على خوادم example.com التي تجيب عن الاسم www. خادم حل الأسماء هو الذي يتابع البحث؛ المتصفح لا يسأل كل هذه الخوادم بنفسه. وإذا وُجدت إجابة محفوظة، فقد يختصر البحث كثيرًا من هذه الخطوات.

كيف يجد خادم حل الأسماء الإجابة؟

مثال لاستعلام بلا إجابة مخزّنة: المتصفح يسأل خادم حل الأسماء، وهو يتولى الخطوات التالية.

1. 01 · Rootخادم الجذريدلّ خادم حل الأسماء على خوادم نطاق ‎.com.
2. 02 · .comخادم النطاق الأعلىيدلّه على خوادم الأسماء المعيّنة لـexample.com.
3. 03 · Cloudflareالخادم الموثوق للنطاقيجيب عن سجل الاسم المطلوب. وقد يستلزم CNAME استعلامات إضافية.
4. 04 · Resolverالإجابة تعود إلى المتصفحيحفظ خادم حل الأسماء الإجابة وفق TTL. ثم يبدأ المتصفح اتصال الويب.

تؤدي Cloudflare دورين مختلفين هنا. خدمة 1.1.1.1 تحلّ الأسماء لمن يستخدمها، أما خوادم DNS الموثوقة فتجيب عن النطاقات التي تدير Cloudflare سجلاتها. ضبط جهازك ليستخدم 1.1.1.1 لا ينقل إدارة نطاقك إلى Cloudflare ولا يفعّل السحابة البرتقالية.

تسمّى مجموعة السجلات التي تديرها للنطاق منطقة DNS، أو zone. يمثّل example.com جذر هذه المنطقة، ويسمّى apex، بينما www.example.com نطاق فرعي. أما /articles في عنوان الصفحة فهو مسار يعالجه التطبيق عبر HTTP؛ لا يختار DNS المقال الذي سيظهر للقارئ.

لنجرّب ذلك على هذا الموقع. إذا كانت أداة dig مثبتة لديك، نفّذ:

dig +short NS omaralbeik.com

عند الفحص في 17 أيلول 2026، كانت النتيجة:

alan.ns.cloudflare.com.
demi.ns.cloudflare.com.

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

لماذا قد تشتري النطاق من Cloudflare؟

إذا كنت تنوي استخدام Cloudflare لإدارة DNS، فمن المنطقي أن تنظر في خدمة تسجيل النطاقات لديها أيضًا. ما يجعلها خيارًا جيدًا هو بساطة أمور ستعود إليها سنوات: التجديد وإدارة النطاق وربطه بخدماتك.

تتقاضى Cloudflare Registrar رسوم الجهة المشغّلة لامتداد النطاق، مثل .com، ورسوم ICANN دون هامش ربح إضافي، في التسجيل والتجديد. لذلك قارن سعر التجديد أيضًا عند المفاضلة بين الشركات، لا عرض السنة الأولى فقط. والبيع بالتكلفة لا يعني ثبات السعر إلى الأبد؛ فقد تتغير رسوم الجهة المشغّلة للامتداد. كما لا يعني أنه أقل من كل عرض ترويجي لدى الشركات الأخرى.

وتوجد أسباب عملية أخرى لاختيارها:

• إدارة التسجيل وDNS في حساب واحد تقلّل التنقل بين لوحات التحكم عند ربط خدمة جديدة.
• تكامل DNSSEC مع المسجّل يختصر نقل بيانات DS يدويًا بين شركتين.
• تُحجب بيانات الاتصال الشخصية من بيانات التسجيل العامة حين تسمح قواعد سجلّ النطاق بذلك. لا يعني هذا إخفاء الهوية بالكامل؛ ما زالت Cloudflare تحتاج إلى بيانات تسجيل صحيحة، وتبقى بعض الحقول متاحة للجميع.

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

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

شراء نطاق جديد

افتح Domain Registration → Register Domains وابحث عن الاسم. راجع مدة التسجيل وشروط التجديد، وأدخل بيانات اتصال صحيحة وتحقق من المبلغ قبل إتمام الشراء. بعد ذلك أكمل التحقق من البريد، وراجع التجديد التلقائي ووسيلة الدفع. يوضح دليل التسجيل الخطوات الحالية؛ والتجديد التلقائي مفعّل افتراضيًا.

تكون خوادم أسماء Cloudflare معيّنة للنطاق الجديد بالفعل. يبقى عليك ربط الموقع والبريد؛ شراء الاسم وحده لا ينشر تطبيقًا ولا ينشئ صندوق بريد.

نقل تسجيل نطاق موجود

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

طريقان إلى إدارة النطاق على Cloudflare

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

1. A · Registrarنطاق جديد من Cloudflareاختر الاسم وراجع التجديد، ثم أكمل التسجيل وتحقق من البريد. تكون خوادم Cloudflare معيّنة للنطاق.
2. B · Existing domainنطاق مسجّل لدى جهة أخرىانسخ السجلات وراجع DNSSEC، ثم غيّر خوادم الأسماء لدى المسجّل وانتظر تفعيل النطاق.
3. A + Bاربط الخدمات وافحصهااضبط الموقع والبريد وDNSSEC. نقل تسجيل النطاق الموجود إلى Cloudflare يظل قرارًا مستقلًا.

ماذا تغيّر السحابة البرتقالية؟

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

بعد معرفة العنوان، إلى أين يتصل المتصفح؟

DNS onlyموقع على استضافة خارجية

1. المتصفح
2. ←خادم الموقع

Proxiedموقع على استضافة خارجية

1. المتصفح
2. ←Cloudflare
3. ←خادم الموقع

Worker + Custom Domainتطبيق يعمل على Cloudflare

1. المتصفح
2. ←Cloudflare
3. ←Worker

يسبق DNS هذه الاتصالات. في المسار الثالث، يعمل الـWorker داخل Cloudflare.

تفعيل السحابة البرتقالية لا يعني تخزين كل استجابة مؤقتًا. فشبكة CDN التقليدية لدى Cloudflare لا تخزّن HTML أو JSON افتراضيًا. أما Workers والملفات الثابتة فلها آلياتها في تقديم المحتوى، وسنعود إليها في جزء الاستضافة.

كذلك، لا يحوّل هذا الخيار Cloudflare إلى وسيط لكل أنواع الاتصال. اترك سجلات خوادم البريد وسجلات إثبات ملكية النطاق للخدمات الخارجية على DNS-only، واتبع تعليمات مزوّد الخدمة. توضح وثائق حدود البروكسي ما يمكن تمريره عبره. يمكن تفعيل البروكسي لسجلات A وAAAA وCNAME المستخدمة للاتصالات المدعومة، أما MX وTXT فليست لها وظيفة مماثلة. السحابة الرمادية هي الاختيار الصحيح لبعض الخدمات.

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

افهم السجل قبل تعديله

لكل نوع من السجلات وظيفة. هذه أكثر الأنواع التي ستصادفها، ويمكن الرجوع إلى مرجع السجلات للتفاصيل:

لإضافة سجل، افتح DNS → Records → Add record في إعدادات النطاق. اختر النوع والاسم والقيمة، ثم حالة البروكسي وTTL حين تتاحان. ويتيح محرّر السجلات إضافة تعليق. اكتب اسم الخدمة التي طلبت السجل لتعرف سبب وجوده لاحقًا.

قراءة نموذج إضافة سجل

مثال توضيحي لخادم خارجي. العنوان ‎192.0.2.10 محجوز للتوثيق ولا يشغّل موقعًا حقيقيًا.

1. Type · Aنوع الإجابةربط اسم بعنوان IPv4. استخدم AAAA لعنوان IPv6.
2. Name · @الاسم الذي تضبطهيعني example.com في هذه المنطقة. أما www فيعني www.example.com.
3. Content · 192.0.2.10الوجهةاستبدله بعنوان الخادم الذي تعطيك إياه شركة الاستضافة.
4. Proxy · Proxied / TTL · Autoمسار الاتصال ومدة الحفظالسحابة البرتقالية تمرّر الويب عبر Cloudflare؛ وTTL تخص حفظ إجابة DNS.

لنفترض أن شركة الاستضافة طلبت سجل CNAME للاسم www.example.com يشير إلى project.host.example. تكتب اسم المضيف وحده في قيمة السجل، دون https:// أو مسار صفحة. وعليك أيضًا إضافة www.example.com إلى إعدادات النطاقات في الاستضافة؛ فسجل DNS لا يضبط التطبيق الذي سيستقبل الطلب.

ولا يعيد CNAME توجيه المتصفح إلى عنوان آخر. إذا ربطت www بالنطاق الرئيسي بهذه الطريقة، يبقى www ظاهرًا في شريط العنوان. لتوجيه الزوار إلى عنوان واحد تختاره، تحتاج إلى إعادة توجيه HTTP في الاستضافة أو في Cloudflare.

أما الرمز @ في لوحة التحكم فيشير إلى النطاق الأساسي، مثل example.com. وتتيح Cloudflare استخدام CNAME عند هذا الاسم بفضل CNAME flattening: تبحث عن عناوين IP للاسم المستهدف وتعيدها في الإجابة. لذلك لا يمكنك دائمًا استنتاج نوع السجل الذي أضفته من العنوان الذي يعيده dig.

لا تضف CNAME إلى جانب سجل A أو AAAA للاسم العادي نفسه؛ ترفض Cloudflare هذا التعارض بين السجلات. أما A وAAAA فيمكن أن يجتمعا لأن كلًا منهما يجيب عن نوع مختلف من العناوين. أضف AAAA لخادم الاستضافة فقط إذا كان يخدم الموقع عبر IPv6. مع DNS-only، قد يرسل سجل AAAA قديم زوار IPv6 إلى الاستضافة السابقة، رغم نجاح اختبارك عبر IPv4. أما مع البروكسي، فيمكن لـCloudflare توفير عناوين IPv6 للزوار حتى لو كان خادمك يستخدم IPv4؛ فلا تحتاج إلى إضافة AAAA للخادم لهذا الغرض.

انقل إدارة DNS إلى Cloudflare

للنطاق المسجّل لدى شركة أخرى، اتبع طريقة الإعداد الكامل. تتوفر خدمة DNS على خطة Free، وتبقى تكلفة تسجيل النطاق وأي منتجات مدفوعة مستقلة عنها.

رتّب العمل على النحو التالي:

1. احتفظ بنسخة من سجلاتك لدى مزوّد DNS الحالي.
2. أضف النطاق الأساسي إلى Cloudflare وقارن السجلات المستوردة بهذه النسخة؛ فقد يفوت الفحص التلقائي بعضها. راجع الموقع والبريد وإثبات الملكية والأسماء الأقل استخدامًا.
3. عالج إعداد DNSSEC الحالي قبل التبديل، كما سنشرح بعد قليل.
4. استبدل خوادم الأسماء لدى المسجّل بالزوج الذي عيّنته Cloudflare لنطاقك. لا تنسخ خوادم موقعي من المثال.
5. أبقِ خدمة DNS القديمة والاستضافة متاحتين خلال الانتقال. تحقق من ظهور حالة Active في Cloudflare، ثم اختبر الخدمات.

إضافة سجلات NS داخل لوحة DNS القديمة لا تغني عن تغيير خوادم الأسماء لدى مسجّل النطاق؛ فالتفويض من المنطقة الأعلى هو الذي يوجّه الاستعلامات إلى المزوّد الجديد.

إذا كان DNSSEC مفعّلًا، اتبع إرشادات نقله قبل التغيير. في الطريقة المعتادة، تحذف سجل DS القديم لدى مسجّل النطاق، وتنتظر انتهاء صلاحية نسخه المخزّنة مؤقتًا، ثم تغيّر خوادم الأسماء. أبقِ توقيع المنطقة القديمة مفعّلًا ما دامت نسخ DS المخزّنة صالحة. وبعد التبديل، انتظر انتهاء TTL لسجلات خوادم الأسماء القديمة قبل تفعيل DNSSEC في Cloudflare ونشر سجل DS الجديد. بذلك تتجنب مقارنة إجابات مزوّد بمفاتيح المزوّد الآخر. تتوقف حماية DNSSEC مؤقتًا خلال هذه الطريقة؛ ويشرح الدليل أيضًا نقلها دون انقطاع التوقيع لدى المزوّدين الذين يدعمون ذلك.

ما الذي تحميه DNSSEC؟

تستخدم DNSSEC التوقيعات وسلسلة ثقة تمر بالنطاق الأعلى للتحقق من مصدر إجابات DNS وسلامتها. لكنها لا تشفّر الاستعلامات ولا تحل محل HTTPS. أما DNS over HTTPS فيشفّر الاتصال بين الجهاز وخادم حل الأسماء.

لمنطقة جديدة، افتح DNS → Settings → DNSSEC واتبع خطوات التفعيل. يربط سجل DS المنطقة الأعلى بمفتاح توقيع DNS لنطاقك. إذا كان المسجّل خارجيًا، فأضف لديه بيانات DS التي تعطيك إياها Cloudflare. أما مع Cloudflare Registrar فيتولى التكامل بين الخدمتين هذه الخطوة. تحقق من الحالة النهائية؛ الضغط على زر التفعيل وحده لا يثبت اكتمال سلسلة الثقة.

وإذا نقلت DNS إلى جهة أخرى لاحقًا، فخطط لنقل DNSSEC معها. سجل DS يشير إلى مفاتيح قديمة قد يعطّل حل الأسماء حتى لو نسخت جميع سجلات A وMX نسخًا صحيحًا.

اربط الاسم بالتطبيق الذي سيستقبل الطلبات

للاستضافة الخارجية، استخدم القيم التي يزوّدك بها المضيف، وتأكد من دعمه للعمل خلف بروكسي Cloudflare. لا تنسخ عنوان IP من موقع آخر؛ فقد يكون العنوان الذي تراه تابعًا لـCloudflare، لا لخادم الموقع.

قد تعطيك شركة الاستضافة عنوان IPv4 للنطاق الأساسي، وتطلب ربط www به. تضيف حينها سجل A للاسم @ وسجل CNAME للاسم www، وتعرّف الاستضافة بالاسمين. اختر العنوان الذي تريد ظهوره للزوار، واضبط إعادة التوجيه في الاستضافة أو باستخدام Redirect Rules. ولكي تطبّق Cloudflare قاعدة إعادة توجيه، يجب أن يصل اتصال الاسم المصدر إلى البروكسي لديها. اختبر الاسمين عبر HTTPS؛ إذ ينبغي أن تتوافق سجلات DNS والشهادات وإعادة التوجيه.

أما التطبيق الذي يعمل على Workers، فيمكن ربطه مباشرة باسم مضيف عبر Custom Domain. بعد تفعيل النطاق على Cloudflare وإنشاء Worker، افتح إعدادات الـWorker واتبع Settings → Domains & Routes → Add → Custom Domain. تنشئ Cloudflare سجل DNS والشهادة. وإذا وُجد سجل CNAME بالاسم نفسه، فعليك معالجة هذا التعارض أولًا؛ تحقق مما يخدمه السجل قبل استبداله.

يطابق Custom Domain اسم المضيف كما هو. فربط example.com لا يشمل www.example.com تلقائيًا؛ اضبط الاسمين إذا أردت أن يعمل كلاهما. ويختلف هذا عن Worker Route الذي يمكنه تشغيل كود أمام خادم موقع موجود. سنحتاج إلى هذا الفرق في الجزء التالي.

وفي حالة خادم خارجي خلف البروكسي، يتكوّن اتصال HTTPS من مرحلتين: من المتصفح إلى Cloudflare، ثم منها إلى الخادم. استخدم Full (strict) مع شهادة غير منتهية تطابق اسم المضيف، صادرة عن جهة موثوقة لدى المتصفحات أو عن Cloudflare Origin CA. أما مع DNS-only، فيتصل المتصفح بالخادم مباشرة ويحتاج إلى شهادة يثق بها؛ شهادات Cloudflare Origin CA لا تفي بهذا الشرط.

وتغطي شهادة Universal SSL المعتادة في إعداد المنطقة الكامل النطاق الأساسي والنطاقات الفرعية من المستوى الأول. لا تفترض أنها تشمل api.staging.example.com أيضًا؛ فقد يعمل DNS لهذا الاسم بلا مشكلة، بينما تحتاج شهادته إلى تغطية إضافية.

حافظ على عمل البريد أيضا

يمكن أن يكون الموقع والبريد لدى مزوّدين مختلفين. احتفظ بسجلات البريد التي يطلبها مزوّدك حين تنقل DNS.

تحدّد سجلات MX خوادم الاستقبال، وتُفضّل القيم الأصغر في حقل الأولوية. وإذا كان MX يشير إلى mail.example.com، فذلك الاسم يحتاج إلى سجل عنوان بدوره، ويجب إبقاء سجل خادم البريد على DNS-only؛ فبروكسي الويب المعتاد لدى Cloudflare لا يمرّر SMTP.

أما إرسال الرسائل، فتتعلق به ثلاثة إعدادات ستراها كثيرًا:

• SPF يستخدم سجل TXT لتحديد خوادم الإرسال المسموح لها باستخدام نطاق المرسِل في اتصال SMTP. قد يختلف هذا النطاق عن الظاهر في حقل From. يحدّد مزوّدك موضع السجل، سواء عند @ أو نطاق فرعي.
• DKIM ينشر البيانات التي يستخدمها المستقبِل للتحقق من توقيع الرسالة. يزوّدك مزوّد البريد غالبًا بسجل TXT أو CNAME تحت اسم مثل selector._domainkey.
• DMARC يستخدم سجل TXT عند _dmarc لطلب تقارير وتحديد طريقة التعامل مع البريد الذي يحمل نطاقك في حقل From. يتطلب اجتياز DMARC نجاح SPF أو DKIM مع توافق نطاقه مع نطاق From؛ لا يُشترط نجاح كليهما.

استخدم قيم مزوّدك الفعلية. لا تنسخ سياسة بريد من موقع آخر، ولا تضف سياسة SPF مستقلة لكل خدمة إرسال؛ إذ يسمح SPF بسجل سياسة واحد لكل اسم. اجمع الجهات المصرّح لها وفق تعليمات مزوّديك، واحصر خدمات الإرسال المشروعة قبل تطبيق سياسة DMARC صارمة.

أما CNAME الذي تستخدمه خدمة لإثبات الملكية، فاتركه عادة على DNS-only. أوقف flattening الاختياري للسجل وخيار تطبيقه على جميع سجلات CNAME. فقد تحتاج الخدمة إلى رؤية CNAME نفسه، لا عنوان IP الناتج عن تتبّعه. يشرح دليل مشكلات التحقق لماذا قد تفشل هذه الخطوة رغم أن القيمة التي أدخلتها تبدو صحيحة.

إضافة السجلات لا تنشئ صندوق بريد. خدمة Cloudflare Email Routing وبريد التطبيق خدمات مستقلة، وسنتناولها في الجزء الخاص بالبريد.

لماذا لا يظهر تعديل DNS فورا؟

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

لماذا قد تبقى الإجابة القديمة؟

مثال مبسّط لسجل DNS-only ومدّة حفظ قديمة تبلغ ساعة. الأوقات للتوضيح.

1. 12:00 · TTL 3600حفظ الإجابة القديمةيحتفظ خادم حل الأسماء بالعنوان لمدة تصل إلى ساعة.
2. 12:10 · TTL 300تعديل العنوان وخفض TTLتعرض الخوادم الموثوقة القيمة الجديدة. النسخة القديمة لا تتلقى إشعارًا بالتعديل.
3. 13:00انتهاء مدة الإجابة القديمةيعيد خادم حل الأسماء الاستعلام عند الحاجة، فيحصل على القيمة الجديدة.

إذا كنت تخطط لتغيير عنوان سجل على DNS-only، فخفّض TTL مسبقًا وانتظر مرور المدة القديمة، ثم غيّر الوجهة. وأبقِ الوجهتين تعملان خلال الانتقال إن أمكن. أما السجلات المفعّل عليها البروكسي فتستخدم Auto TTL، وقيمتها حاليًا 300 ثانية. وهذا ليس ضمانًا بأن كل جهاز سيرى التغيير خلال خمس دقائق؛ فللتفويض والتخزين المحلي مدد أخرى.

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

افحص DNS، ثم استجابة الموقع

لنعد إلى هذا الموقع ونطلب عناوينه:

dig +short A omaralbeik.com
dig +short AAAA omaralbeik.com

في فحص 17 أيلول نفسه، أعاد استعلام A العنوانين 188.114.96.0 و188.114.97.0. هذه نتيجة فحص، وليست قيمًا تنسخها إلى إعداداتك. يوضح DNS أين يمكن بدء الاتصال، لكنه لا يكشف اسم الـWorker الذي يشغّل موقعي، ولا كيف يعالج التطبيق المسارين /en و/ar.

لفحص استجابة HTTP، اطلب ترويساتها:

curl -I https://omaralbeik.com/en

وجود server: cloudflare وترويسة cf-ray يدل على أن Cloudflare عالجت الطلب، لكنه لا يثبت أن الاستجابة جاءت من التخزين المؤقت. اقرأ رمز الحالة أيضًا؛ فإعادة التوجيه استجابة HTTP صحيحة، لكن الصفحة المطلوبة تقع عند العنوان المذكور في ترويسة location.

إذا عدّلت سجلًا ولم ترَ النتيجة المتوقعة، قارن إجابة خادم يحلّ الأسماء بإجابة أحد خوادم النطاق الموثوقة. باستخدام إعدادات موقعي وقت الكتابة:

dig @1.1.1.1 omaralbeik.com A +noall +answer
dig @alan.ns.cloudflare.com omaralbeik.com A +noall +answer

عند فحص نطاقك، استبدل الاسم وأحد خوادمه المعيّنة له بالقيم المناسبة. العدد الذي يسبق IN A هو مدة TTL بالثواني. وقد تختلف عناوين Cloudflare بين إجابتين صحيحتين لسجل مفعّل عليه البروكسي، فلا تعتبر اختلاف IP وحده دليلًا على قدم الإجابة. ولأن DNS لا يكشف تغيير الخادم خلف البروكسي، راجع الوجهة في لوحة التحكم واختبر استجابة HTTP أيضًا.

وإذا لم يطبع +short شيئًا، أعد الاستعلام دونه لترى تفاصيل الاستجابة. غياب الناتج وحده لا يحدّد السبب؛ فقد لا يوجد سجل من النوع المطلوب، أو قد تكون هناك حالة مثل NXDOMAIN أو SERVFAIL. أما إذا نجح استعلام DNS وفشل HTTPS، فانتقل إلى فحص الشهادات والتوجيه والتطبيق.

ابدأ الفحص مما تراه

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

dig +trace omaralbeik.com

يتابع هذا الأمر الإحالات بين الخوادم بدل الاعتماد على خادم حل الأسماء المعتاد. وقد يفشل في شبكة تمنع استعلامات DNS المباشرة؛ فلا تعتبر فشله وحده دليلًا على تعطل الموقع.

سجلات النجمة وتفويض النطاقات والإعدادات الأخرى

سجلات النجمة، أو wildcards، مثل *.example.com، توفّر إجابات لأسماء فرعية غير مطابقة لسجلات محددة. لا تحلّ محل سجل النطاق الأساسي، وقد يمنع وجود اسم أو تفويض تطبيق سجل النجمة. تعرض أمثلة Cloudflare الحالات الأقل وضوحًا، ومنها الأسماء الأعمق. قواعد wildcard في DNS تختلف عن نطاق تغطية الشهادة؛ لا تستنتج إحداهما من الأخرى.

تفويض نطاق فرعي يعني إسناد DNS لفرع مثل team.example.com إلى مزوّد آخر. تضيف سجلات NS التي يحدّدها المزوّد للاسم team في المنطقة الأم، ثم تدير سجلات الفرع لديه. يختلف هذا عن إضافة سجل A لنطاق فرعي داخل منطقتك. اتبع دليل التفويض إذا أردت تفعيل DNSSEC لذلك الفرع أيضًا.

الإعداد الجزئي وDNS الثانوي مناسبان لمؤسسات لديها متطلبات قائمة. يتيح إعداد CNAME الجزئي للمناطق المؤهلة على خطتي Business وEnterprise الاحتفاظ بمزوّد DNS آخر وتمرير أسماء مختارة عبر بروكسي Cloudflare. وتتيح عمليات نقل المناطق على Enterprise ترتيبات DNS أساسية أو ثانوية. هذه طرق إعداد بديلة، وليست خطوات إضافية مطلوبة لتشغيل موقع عادي.

اجعل الإعداد سهل الصيانة

قبل تعديل كبير، صدّر المنطقة من DNS → Records → Import and Export. يتضمن ملف تصدير المنطقة السجلات ووسومًا خاصة بـCloudflare. دوّن بصورة مستقلة الإعدادات التي لا تندرج تحت DNS، مثل إعادة التوجيه وTLS ونطاقات Workers؛ فملف المنطقة ليس نسخة احتياطية من الحساب كله.

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

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

في الجزء التالي ننظر إلى ما يجري داخل الـWorker بعد وصول الطلب إليه.

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