كيف تربط نطاقًا مخصصًا بتطبيقك أو موقعك

لربط نطاق مخصص، تشتري النطاق من جهة تسجيل، ثم تضيف سجل DNS يوجّهه إلى مضيفك، وغالبًا سجل CNAME لنطاق فرعي مثل www أو app، أو سجل A (أو سجل ALIAS/مسطّح) للنطاق الجذر. ثم يتحقق مضيفك من النطاق ويصدر شهادة HTTPS. وعادةً يستغرق ذلك دقائق، وقد يطول أحيانًا. وأغلب المشكلات تأتي من خطأ مطبعي في السجل، أو نوع سجل خاطئ، أو وكيل (proxy) يقع أمام المضيف.

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

المكونات المعنية

كثيرًا ما تكون جهة التسجيل ومزود DNS الشركة نفسها، لكن ليس بالضرورة. الأهم هو: أين تعدّل DNS لهذا النطاق؟ هناك ستضيف السجلات.

الخطوة 1: اشترِ نطاقًا

نصائح للاختيار والشراء:

• اجعله قصيرًا وسهل التهجئة بصوت عالٍ. إذا احتجت إلى شرح تهجئته، فاختر غيره.
• .com هو الامتداد الذي يخمّنه الناس افتراضيًا، لكن امتدادات الدول والامتدادات الأحدث (.io، و.app، و.co.uk) مقبولة إذا كانت تناسب جمهورك.
• تحقق من سعر التجديد، لا من سعر السنة الأولى فقط. فالخصومات التعريفية شائعة، وقد تكون أسعار التجديد أعلى.
• فعّل التجديد التلقائي واحتفظ ببطاقة الدفع سارية. فالنطاق المنتهي يعطّل موقعك وبريدك، وقد يشتريه شخص آخر بعد فترة السماح.
• استخدم حماية WHOIS إذا كانت متاحة، حتى لا تُنشر بياناتك الشخصية.
• اشترِه في حساب تتحكم فيه، لا في حساب مستقل أو وكالة.

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

الخطوة 2: قرر العنوان

النطاق الفرعي مقابل النطاق الجذر

• النطاق الجذر (apex): example.com
• النطاق الفرعي: www.example.com، وapp.example.com

إعداد شائع هو موقع تسويقي على example.com أو www.example.com، والمنتج على app.example.com. أما لموقع واحد، فاختر بين www والنطاق الجذر.

لا يسمح معيار DNS بسجل CNAME في جذر النطاق، لأن الجذر يجب أن يحتوي على سجلات أخرى (مثل سجلات خوادم الأسماء). ويتجاوز كثير من مزودي DNS ذلك بنوع سجل خاص، يُسمّى ALIAS أو ANAME أو تسطيح CNAME حسب المزود، ويتصرف كـ CNAME على الجذر. فإذا لم يدعمه مزودك، فالطريقة الموثوقة هي: اعرض الموقع على www، وأعدّ إعادة توجيه من الجذر إلى www عند مزود DNS أو جهة التسجيل.

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

الخطوة 3: أضف سجلات DNS

يخبرك مضيفك بالضبط بما تضيفه. وسيبدو كأحد هذه السجلات:

كيف تملأ النموذج في معظم مزودي DNS:

• الاسم / المضيف: الجزء الفرعي فقط، أي www لا www.example.com. بعض المزودين يضيفون النطاق تلقائيًا، فكتابته كاملة تنتج www.example.com.example.com. استخدم @ للجذر إذا كان مزودك يعتمد هذا الاصطلاح.
• القيمة / الهدف: الصق بالضبط ما يعرضه مضيفك. النقطة الأخيرة مقبولة إذا كان مزودك يضيفها.
• TTL: القيمة الافتراضية مناسبة. فقيمة أقل (مثل 5 دقائق) تجعل التغييرات المستقبلية تسري أسرع.
• الوكيل (Proxy): إذا كان مزود DNS لديك يستطيع توجيه الحركة عبر وكيل (مثل السحابة البرتقالية في Cloudflare)، فاتبع تعليمات مضيفك. وكثير من المضيفين يحتاجون إلى إعداد «DNS فقط» حتى يتمكنوا من إصدار الشهادة.

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

تغيير خوادم الأسماء مقابل إضافة السجلات

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

الخطوة 4: تحقق واحصل على HTTPS

بعد وضع السجل، عُد إلى مضيفك واضغط زر التحقق. يتحقق المضيف من DNS، ثم يطلب شهادة، وعادةً من جهة إصدار شهادات مجانية مثل Let's Encrypt، ويبدأ بعرض موقعك عبر HTTPS.

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

بعد أن يعمل HTTPS، تأكد من أن http:// يحوّل إلى https://. وأغلب المضيفين يفعلون ذلك تلقائيًا.

الخطوة 5: اختبره

• يحمّل https://www.example.com موقعك مع أيقونة القفل
• الصيغة الأخرى (الجذر أو www) تحوّل إلى عنوانك الرئيسي
• http:// يحوّل إلى https://
• تسجيل الدخول وOAuth وإعادة توجيه الدفع تعمل على النطاق الجديد (غالبًا ما تملك قوائم عناوين مسموحًا بها ما زالت تشير إلى العنوان القديم)
• البريد الإلكتروني على نطاقك ما زال يصل
• الروابط في الرسائل التي يرسلها تطبيقك تستخدم النطاق الجديد

البند الرابع يوقع كثيرين في الخطأ: تسجيل الدخول عبر Google، وwebhooks الخاصة بـ Stripe، وروابط إعادة تعيين كلمة المرور، كلها مُعدّة بعناوين محددة. أضف النطاق الجديد حيثما ظهر عنوانك القديم. وراجع كيف تضيف تسجيل الدخول إلى تطبيقك لجانب OAuth.

استكشاف الأخطاء وإصلاحها

تعرض أداة بحث DNS مجانية عبر الإنترنت، أو الأمر dig www.example.com في الطرفية، ما يراه العالم حاليًا لسجلك، وهذا مفيد لتعرف هل المشكلة في DNS أم في المضيف.

ربط نطاق مخصص في Mythex

النطاقات المخصصة ميزة في خطة Pro على Mythex. أما الخطط المجانية فتنشر إلى عنوان yourname.mythex.app. وفي خطة Pro يمكنك:

• شراء نطاق داخل Mythex من Domains في الإعدادات، أو من Publish ← Custom domain في مشروع منشور. يسجّل Mythex النطاق ويعدّ DNS؛ ويُفوتر التسجيل بشكل منفصل عن خطة Pro، والتجديد التلقائي مفعّل افتراضيًا.
• ربط نطاق تملكه بالفعل. انشر المشروع، واختر Connect، وأدخل اسم المضيف (مثلًا app.example.com)، ثم أضف سجل CNAME عند مزود DNS الخاص بك يشير إلى الهدف الذي يعرضه Mythex (yourslug.mythex.ai). واضغط Verify. تُصدر شهادة HTTPS تلقائيًا.

إذا كان DNS لديك على Cloudflare، فاجعل سجل CNAME على DNS only (السحابة الرمادية)، لا مُوكَّلًا (proxied). وبالنسبة إلى النطاق الجذر، توصي الوثائق باستخدام www أو app، وإعادة التوجيه من الجذر عند مزود DNS إذا كان لا يدعم ALIAS أو التسطيح.

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

الأسئلة