ربط الدومين بالاستضافة: الدليل الكامل

ماذا يعني «ربط الدومين بالاستضافة» أصلًا؟

كثيرون يشترون نطاقًا من شركة (المُسجّل/Registrar) وخطّة استضافة من شركة أخرى، ثم يتفاجؤون أن كتابة النطاق في المتصفّح لا تفتح الموقع، أو تفتح صفحة افتراضية لا علاقة لها بهم. السبب أن النطاق والاستضافة شيئان منفصلان تمامًا: النطاق مجرّد اسم تملكه، والاستضافة خادم له عنوان IP يعيش عليه موقعك. ما لم تربط الاثنين صراحةً، لا يعرف الإنترنت أين يجد موقعك حين يُطلب اسمك.

الربط ليس عملية «نقل ملفّات»؛ هو ضبط سجلّات DNS بحيث يُترجَم اسم نطاقك إلى عنوان خادم استضافتك. حين يكتب زائر example.com، يبدأ متصفّحه رحلة استعلام عبر نظام أسماء النطاقات حتى يصل إلى السجلّ الذي يقول: «هذا الاسم يشير إلى الخادم رقم كذا». مهمّتك في الربط هي أن تضع هذا السجلّ بشكل صحيح، سواء بتفويض DNS كاملًا للمضيف أو بتعديل سجلّ واحد بنفسك. إن أردت تعميق فهمك للسجلّات نفسها قبل المتابعة، فمقالنا عن شرح سجلّات DNS يشرح كل نوع بالتفصيل.

لتثبيت الصورة الذهنية، تخيّل ثلاثة أطراف: المُسجّل (حيث اشتريت النطاق وتُدار خوادم أسمائه)، ومزوّد DNS (الجهة التي تحتفظ بسجلّاتك الفعلية)، وشركة الاستضافة (الخادم الذي يحمل ملفّات موقعك وله عنوان IP). في كثير من الحالات يكون المُسجّل ومزوّد DNS نفس الشركة، وأحيانًا يكون مزوّد DNS هو شركة الاستضافة. الربط = توجيه السهم من النطاق نحو خادم الاستضافة، والطريقة تعتمد على من تختاره ليدير الـDNS.

الطريقتان: Nameservers مقابل سجلّ A

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

الطريقة الأولى: تغيير خوادم الأسماء (تفويض DNS كاملًا)

في هذه الطريقة تذهب إلى لوحة المُسجّل وتستبدل خوادم الأسماء الافتراضية بخوادم الأسماء التي تعطيك إياها شركة الاستضافة (مثل ns1.wpressly.com وns2.wpressly.com). أثرها أنك تفوّض إدارة DNS بالكامل للمضيف: من الآن فصاعدًا، كل سجلّاتك (A للموقع، MX للبريد، TXT، CNAME…) تُدار من لوحة الاستضافة لا من المسجّل.

هذه الطريقة هي الأبسط والأكثر شيوعًا للمبتدئين، ولها سبب وجيه: حين تربط عبر خوادم الأسماء، تتولّى لوحة الاستضافة (cPanel غالبًا) إنشاء كل السجلّات الضرورية تلقائيًّا — سجلّ A للموقع، وwww، وغالبًا سجلّات البريد. أنت تضبط شيئًا واحدًا (خوادم الأسماء) فيُربط كل شيء دفعة واحدة.

الطريقة الثانية: سجلّ A فقط (توجيه IP)

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

ميزة هذه الطريقة هي الفصل: يمكنك توجيه الموقع لخادم وإبقاء البريد على خدمة أخرى (مثل Google Workspace) دون أن يلمس أحدهما الآخر. كما تتيح لك استخدام مزوّد DNS متقدّم مثل Cloudflare للحماية والـCDN بينما تستضيف الموقع في مكان آخر.

متى تختار كل طريقة؟

القاعدة العملية بسيطة:

• اختر تغيير Nameservers إذا كنت مبتدئًا، وستستضيف الموقع والبريد على نفس شركة الاستضافة، وتريد أبسط مسار «اضبط مرّة وانسَ». هذا هو الخيار الافتراضي لأغلب مواقع ووردبريس على استضافة مشتركة.
• اختر سجلّ A إذا كان بريدك مستضافًا في مكان آخر وتريد ألّا تمسّه، أو إذا كنت تستخدم Cloudflare لإدارة DNS والحماية، أو إذا أردت توجيه الموقع فقط مع إبقاء سجلّات أخرى تحت سيطرتك.

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

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

أين تجد خوادم الأسماء أو عنوان IP الاستضافة؟

قبل أن تربط أي شيء، تحتاج المعلومة الصحيحة من جهة الاستضافة: إمّا أسماء خوادم الأسماء (للطريقة الأولى)، أو عنوان IP الخادم (للطريقة الثانية).

لخوادم الأسماء (Nameservers): تجدها عادةً في:

• بريد الترحيب (Welcome Email) الذي وصلك عند شراء الاستضافة — أغلب الشركات تكتبه بوضوح.
• لوحة العميل (Client Area) لدى شركة الاستضافة، تحت تفاصيل الخدمة.
• صفحة المساعدة/المعرفة للشركة (ابحث عن «nameservers»).

لعنوان IP الخادم: تجده في:

• بريد الترحيب أيضًا (Shared IP أو Server IP).
• لوحة cPanel: في الشريط الجانبي تحت «General Information» يظهر «Shared IP Address» أو «Dedicated IP».
• بسؤال الدعم الفني إن لم تجده.

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

خطوات الطريقة الأولى: تغيير خوادم الأسماء

العملية متشابهة لدى كل المسجّلين تقريبًا، مع اختلاف بسيط في مكان الزر. الخطوات العامّة:

1. سجّل دخولك إلى لوحة المُسجّل (حيث اشتريت النطاق، لا حيث اشتريت الاستضافة — إلا إن كانتا الشركة نفسها).
2. افتح قائمة نطاقاتك واختر النطاق المطلوب.
3. ابحث عن قسم «Nameservers» أو «DNS» أو «خوادم الأسماء».
4. اختر «Custom Nameservers» (خوادم مخصّصة) بدل الافتراضية.
5. احذف القيم القديمة وأدخل خوادم استضافتك (عادةً اثنان، أحيانًا أربعة).
6. احفظ. الآن انتظر الانتشار (سنشرحه).

مثال على القيم التي ستُدخلها:

ns1.wpressly.com
ns2.wpressly.com

أين تجد هذا الإعداد عند كبار المسجّلين؟

تختلف التسميات قليلًا. هذا الجدول يختصر المسار عند الأشهر:

بعد الحفظ، تتولّى لوحة الاستضافة (cPanel غالبًا) إنشاء سجلّات A وwww تلقائيًّا حين تضيف النطاق كـ«Addon Domain» أو يكون هو النطاق الأساسي للحساب. تحقّق أن النطاق مضاف فعلًا في لوحة الاستضافة، وإلا ستظهر صفحة المضيف الافتراضية.

خطوات الطريقة الثانية: تعديل سجلّ A

في هذه الطريقة تذهب إلى محرّر DNS عند مزوّدك الحالي (المسجّل أو Cloudflare) وتعدّل سجلّ A. الخطوات:

1. سجّل دخولك إلى مزوّد DNS (المسجّل أو Cloudflare أو أينما تُدار سجلّاتك).
2. افتح محرّر DNS / DNS Management / Advanced DNS.
3. ابحث عن سجلّ A بالاسم @ (يمثّل الجذر). إن وُجد، عدّله؛ وإلا أنشئ جديدًا.
4. ضع عنوان IP خادم الاستضافة في حقل القيمة (Value/Points to).
5. اضبط TTL على قيمة منخفضة (مثل 300 ثانية) أثناء التغيير لتسريع الانتشار.
6. كرّر لـwww (سجلّ A بنفس الـIP، أو CNAME يشير للجذر — التفصيل بعد قليل).
7. احفظ وانتظر الانتشار.

أمثلة لقيم السجلّات التي ستدخلها:

# توجيه الجذر بسجلّ A
Type: A     Name: @      Value: 185.199.108.153     TTL: 300

# توجيه www بسجلّ A أيضًا
Type: A     Name: www    Value: 185.199.108.153     TTL: 300

# أو توجيه www كـ CNAME يتبع الجذر (بديل أنيق)
Type: CNAME Name: www    Value: example.com.        TTL: 300

ملاحظة: في الطريقة الثانية لا تلمس سجلّات MX إطلاقًا، فيبقى بريدك يعمل كما هو — وهذه ميزتها الكبرى.

توجيه الجذر (@) و www: A أم CNAME؟

من أكثر مواضع الالتباس. نطاقك له شكلان يجب أن يعملا معًا: الجذر example.com (يُكتب في لوحة DNS بالرمز @)، والنسخة بـwww أي www.example.com. الهدف أن يفتح كلاهما الموقع نفسه.

القاعدة الحاسمة: لا يمكن وضع CNAME على الجذر (@) بسبب قيد تقني في بروتوكول DNS (الجذر يحمل سجلّات SOA وNS إلزاميًّا، وقاعدة DNS تمنع مزج CNAME معها). لذا الجذر دائمًا سجلّ A يشير إلى IP. أمّا www فهو نطاق فرعي عادي، فتختار:

• سجلّ A لـwww بنفس IP الجذر (الأبسط والأوضح).
• أو CNAME لـwww يشير إلى الجذر example.com. — ميزته أنك إن غيّرت IP الجذر لاحقًا، يتبعه www تلقائيًّا دون تعديل ثانٍ.

ماذا لو أعطتك الاستضافة اسمًا بدل عنوان IP للجذر (كما في بعض خدمات النشر السحابية)؟ هنا لا يصلح A ولا يُسمح CNAME على الجذر، فتستخدم سجلّ ALIAS/ANAME إن دعمه مزوّدك (CNAME مسطّح). فصّلنا هذا في شرح سجلّات DNS.

نصيحة عملية: لا تكتفِ بأحدهما. اضبط الجذر وwww معًا، ثم قرّر أيّهما «الرسمي» (canonical) ووجّه الآخر إليه بإعادة توجيه 301 من إعدادات الموقع، حتى لا يُفهرس عنوانان مكرّران.

أنواع السجلّات التي قد تحتاجها

عند الربط ستتعامل غالبًا مع هذه السجلّات. فهم دور كلٍّ يجنّبك أخطاء شائعة:

لاحظ أن سجلّ AAAA اختياري لكنه مفيد إن كان خادمك يدعم IPv6؛ يتعايش مع A دون مشكلة. أمّا MX وSPF فهما قلب البريد، وسنعود إليهما في قسم التحذير الخاص بالبريد.

TTL ومدّة الانتشار: لماذا لا يفتح الموقع فورًا؟

بعد حفظ التغيير، لا تتوقّع أن يفتح الموقع لحظيًّا للجميع. السبب هو انتشار DNS (Propagation): التغيير يُسجَّل عند خادمك المختصّ فورًا، لكن آلاف المحلِّلات حول العالم ما تزال تحمل النسخة القديمة في ذاكرتها المؤقّتة حتى ينتهي الـTTL الذي خزّنتها به.

الـTTL (Time To Live) قيمة بالثواني تحدّد كم تحتفظ المحلِّلات بنسخة السجلّ قبل أن تسأل عن نسخة جديدة. كلّما قلّ TTL، انتشر التغيير أسرع (لكن بزيادة عدد الاستعلامات).

تختلف مدّة الانتشار الفعلية حسب نوع التغيير:

كيف تسرّع الانتشار؟

الحيلة الذهبية: خفّض الـTTL قبل التغيير بيوم على الأقل. إن كان TTL الحالي 86400 (يوم)، فخفّضه إلى 300 وانتظر يومًا كاملًا حتى ينتشر هذا التخفيض نفسه. عندها، حين تنفّذ التغيير الفعلي، سينتشر خلال 5 دقائق لأن المحلِّلات لم تعد تخزّن السجلّ طويلًا. بعد استقرار الموقع، أعِد TTL لقيمة أعلى.

تذكّر أن تغيير Nameservers يأخذ وقتًا أطول من تعديل سجلّ A، لأنه يمرّ عبر طبقة الـTLD (سجلّات NS عند المسجّل) التي لها TTL مرتفع لا تتحكّم به أنت. تحلّ بالصبر هنا — قد يصل لـ24–48 ساعة في أسوأ الحالات.

التحقّق: dig و nslookup وأدوات الانتشار

لا تحكم على نجاح الربط من «هل يفتح الموقع عندي؟»، لأن جهازك قد يخدم نسخة مخزّنة محلّيًّا. استخدم أدوات تستعلم مباشرة من الخوادم.

أمثلة عملية للتحقّق من سجلّ A وخوادم الأسماء:

# تأكيد عنوان IP الذي يشير إليه الجذر
dig example.com A +short

# تأكيد www
dig www.example.com +short

# عرض خوادم الأسماء الحالية للنطاق
dig example.com NS +short

# الاستعلام من محلِّل عام لتجاوز ذاكرة جهازك المحلّية
dig @1.1.1.1 example.com A +short

# نفس الفكرة على ويندوز
nslookup example.com
nslookup -type=NS example.com
nslookup example.com 1.1.1.1

للتأكّد أن العنوان يستجيب بعد توجيه A، يمكن استخدام ping (لكن انتبه: بعض الخوادم تعطّل ردّ ping لأسباب أمنية، فعدم الاستجابة لا يعني بالضرورة خطأً):

# هل يستجيب العنوان؟ يظهر الـIP الذي يُحَل إليه الاسم
ping example.com

لفحص الانتشار عالميًّا، استخدم فاحصًا أونلاين من نوع «whatsmydns» يستعلم من عشرات المواقع حول العالم في آن واحد. إن ظهرت القيمة الجديدة في بعض المواقع والقديمة في أخرى، فالانتشار جارٍ ولم يكتمل — انتظر بقدر TTL القديم. ولتجاوز ذاكرة جهازك، استعلم من محلِّل عام مباشرة كما في المثال أعلاه بـ@1.1.1.1.

نصيحة: إن كان الموقع لا يفتح عندك فقط بينما يظهر سليمًا في الفاحص الأونلاين، فالمشكلة في ذاكرة جهازك. امسح DNS Cache المحلّي: على ويندوز ipconfig /flushdns، وعلى ماك sudo dscacheutil -flushcache.

تحذير حاسم: سجلّات البريد MX عند تغيير Nameservers

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

السيناريو الخطير الشائع: لديك بريد على Google Workspace أو Microsoft 365، وموقعك على استضافة منفصلة. تغيّر Nameservers لتربط الموقع، فتفقد سجلّات MX الخاصّة بمزوّد بريدك، ويتوقّف البريد دون إنذار.

مثال لسجلّات MX يجب إعادة إدخالها لو كان بريدك على مزوّد خارجي:

# سجلّات MX نموذجية (القيم الفعلية من مزوّد بريدك)
Type: MX   Name: @   Priority: 1    Value: aspmx.l.google.com.
Type: MX   Name: @   Priority: 5    Value: alt1.aspmx.l.google.com.
Type: MX   Name: @   Priority: 10   Value: alt2.aspmx.l.google.com.

# ولا تنسَ SPF داخل TXT
Type: TXT  Name: @   Value: "v=spf1 include:_spf.google.com ~all"

خلاصة التحذير: قبل تغيير Nameservers، صوّر/انسخ كل سجلّاتك الحالية (خصوصًا MX وTXT) من لوحة DNS القديمة، ثم أعِد إدخالها في اللوحة الجديدة فور التبديل. وإن كان همّك الوحيد هو ربط الموقع وبريدك في مكان آخر، ففكّر جدّيًّا في الطريقة الثانية (سجلّ A) التي لا تلمس البريد أصلًا.

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

إصدار SSL بعد نجاح الربط

شهادة SSL (التي تفعّل HTTPS والقفل الأخضر) لا تُصدر بنجاح إلا بعد أن يشير نطاقك فعلًا إلى الخادم. السبب أن أغلب الشهادات المجّانية (Let's Encrypt) تتحقّق من ملكيتك للنطاق بطلب ملف من الخادم الذي يشير إليه الاسم (تحقّق HTTP-01). إن لم يكن الربط مكتملًا ومنتشرًا، يفشل التحقّق وتظهر أخطاء.

الترتيب الصحيح:

1. اربط النطاق (NS أو A) وانتظر اكتمال الانتشار.
2. تأكّد أن http://example.com وhttp://www.example.com يفتحان موقعك (لا صفحة المضيف الافتراضية).
3. أصدر الشهادة من لوحة الاستضافة (AutoSSL في cPanel غالبًا يفعل ذلك تلقائيًّا خلال ساعات، أو يدويًّا عبر Let's Encrypt).
4. فعّل إعادة التوجيه من HTTP إلى HTTPS.

إن ظهر خطأ «الشهادة لا تطابق النطاق» أو «NET::ERR_CERT_COMMON_NAME_INVALID»، فالسبب غالبًا أن الشهادة صدرت قبل اكتمال الربط، أو أنك تصدر شهادة لـexample.com دون تضمين www (أو العكس). أعِد الإصدار بعد التأكّد من أن الاسمين يشيران للخادم. للتفاصيل الكاملة راجع دليلنا المخصّص لذلك. وتذكّر أن سجلّ CAA (إن وُجد) قد يمنع جهة إصدار معيّنة؛ تأكّد أنه يسمح لجهة شهادتك.

النطاقات الفرعية (Subdomains)

ربط نطاق فرعي مثل blog.example.com أو app.example.com يتبع نفس المنطق، لكنه أبسط: النطاق الفرعي مجرّد سجلّ DNS إضافي تحت نطاقك، لا يحتاج شراءً منفصلًا. تنشئه بإضافة:

• سجلّ A للنطاق الفرعي إن عرفت عنوان IP خادمه.
• سجلّ CNAME إن كان يتبع اسمًا خارجيًّا (خدمة سحابية، متجر طرف ثالث).

# نطاق فرعي على خادم خاص (تعرف IP)
Type: A      Name: blog    Value: 185.199.108.153    TTL: 3600

# نطاق فرعي يتبع خدمة خارجية باسم
Type: CNAME  Name: shop    Value: mystore.myshopify.com.   TTL: 3600

انتبه أن النطاق الفرعي قد يحتاج شهادة SSL خاصّة به (أو شهادة wildcard تغطّي *.example.com). وإن كنت تستخدم الطريقة الأولى (Nameservers)، تضيف هذه السجلّات في لوحة الاستضافة؛ وإن كنت تستخدم سجلّ A، تضيفها عند مزوّد DNS الحالي.

الفرق بين A و CNAME للـwww في سطر

سؤال متكرّر يستحقّ تلخيصًا حاسمًا:

كلاهما صحيح وظيفيًّا. أغلب المحترفين يفضّلون CNAME لـwww (يتبع الجذر) لتقليل نقاط التعديل المستقبلية، مع A على الجذر دائمًا.

استكشاف الأخطاء وحلّها (Troubleshooting)

أكثر المشاكل بعد الربط لها أسباب معروفة. هذا الجدول يربط العَرَض بالسبب بالحلّ مباشرة:

تشخيص سريع بالأوامر حين «لا يفتح الموقع»:

# 1) إلى أي IP يشير الاسم الآن؟
dig example.com A +short

# 2) قارن بالـIP الذي أعطتك إياه الاستضافة. مختلف؟ التغيير لم ينتشر بعد.

# 3) ما خوادم الأسماء الحالية؟ هل هي خوادم استضافتك فعلًا؟
dig example.com NS +short

# 4) تجاوز ذاكرة جهازك للتأكّد من القيمة الفعلية في الإنترنت
dig @8.8.8.8 example.com A +short

أخطاء شائعة ونصائح خبير

أخطاء يقع فيها كثيرون عند الربط، تجنّبها مسبقًا:

• خلط الطريقتين: ضبط خوادم الأسماء على الاستضافة، ثم تعديل سجلّ A عند المسجّل — الأخير مُتجاهَل لأن DNS صار يُدار عند المضيف. اختر طريقة واحدة.
• نسيان سجلّات MX بعد تغيير Nameservers، فيتوقّف البريد. انسخها قبل التبديل.
• توجيه الجذر فقط ونسيان www (أو العكس)، فيشتكي نصف الزوّار أن الموقع لا يفتح.
• محاولة وضع CNAME على الجذر (@) — ممنوع تقنيًّا؛ استخدم A أو ALIAS.
• الحكم على الانتشار من جهازك المحمّل بذاكرة قديمة، بدل فاحص أونلاين أو @1.1.1.1.
• إصدار SSL قبل اكتمال الربط، فيفشل التحقّق وتظهر أخطاء شهادة.
• ترك TTL مرتفعًا قبل نقل مخطّط له، فيتأخّر الانتشار ساعات بلا داعٍ.
• استخدام IP خاطئ أو خوادم أسماء من مثال عام لا من شركتك بالذات.

نصائح خبير تختصر عليك الطريق:

• خفّض TTL قبل النقل بيوم إلى 300 ثانية، ثم نفّذ، ثم أعِده لقيمة أعلى.
• انسخ كامل منطقة DNS القديمة (لقطة شاشة + ملف) قبل أي تغيير جذري، فهي شبكة أمانك.
• حافظ على الموقع القديم يعمل أثناء فترة الانتشار إن كنت تنقل من خادم لآخر، حتى لا يرى أحد موقعًا معطّلًا. تعلّم كيف تنقل دون انقطاع في دليل الترحيل المخصّص.
• اختبر من شبكة مختلفة (بيانات الجوّال مثلًا) لتتجاوز ذاكرة شبكتك المنزلية وتتأكّد أن الانتشار وصل فعلًا.
• إن كان بريدك حسّاسًا، فضّل سجلّ A على تغيير Nameservers لتعزل الموقع عن البريد تمامًا.

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

ملخّص عملي خطوة بخطوة

لتثبيت كل ما سبق في مسار واحد قابل للتنفيذ:

1. قرّر الطريقة: Nameservers (موقع + بريد على نفس المضيف، الأبسط) أم سجلّ A (فصل الخدمات، بريد في مكان آخر).
2. اجمع المعلومة: خوادم الأسماء أو عنوان IP من بريد الترحيب/لوحة الاستضافة.
3. خفّض TTL قبل التغيير بيوم (للطريقة الثانية تحديدًا).
4. نفّذ: غيّر Nameservers عند المسجّل، أو عدّل سجلّ A لـ@ وwww عند مزوّد DNS.
5. احفظ سجلّات MX إن غيّرت Nameservers وبريدك خارجي.
6. انتظر الانتشار وتحقّق بـdig/nslookup وفاحص أونلاين.
7. أصدر SSL بعد اكتمال الربط، ووجّه HTTP إلى HTTPS.
8. أعِد TTL لقيمة أعلى بعد الاستقرار.

سجّل نطاقك وأدِر DNS بسهولة

خدمة الدومينات من wpressly: تسجيل وإدارة سجلّات DNS بواجهة عربية واضحة ودعم يساعدك على ضبط كل سجلّ بثقة.

احجز نطاقك الآن

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

ما الفرق بين تغيير Nameservers وتعديل سجلّ A لربط الدومين؟ تغيير Nameservers يفوّض إدارة DNS بالكامل لشركة الاستضافة، فتُدار كل سجلّاتك (الموقع والبريد) من لوحتها — وهو الأبسط للمبتدئين. أمّا تعديل سجلّ A فيوجّه الموقع فقط إلى عنوان IP الخادم مع إبقاء بقيّة السجلّات (خصوصًا البريد) كما هي عند مزوّدك الحالي. اختر الأول لموقع وبريد على نفس المضيف، والثاني لفصل الخدمات.

كم يستغرق ربط الدومين بالاستضافة حتى يعمل؟ تعديل سجلّ A بـTTL منخفض ينتشر خلال دقائق إلى ساعة. تغيير Nameservers أبطأ وقد يصل إلى 24–48 ساعة لأنه يمرّ عبر طبقة الـTLD التي لها TTL مرتفع. لتسريع الأمر، خفّض TTL إلى 300 ثانية قبل التغيير بيوم، وتحقّق من الانتشار بـdig أو فاحص أونلاين بدل الاعتماد على جهازك.

لماذا يظهر لي الموقع القديم أو صفحة المضيف الافتراضية بعد الربط؟ إن ظهر الموقع القديم، فالمحلِّلات ما زالت تحمل IP القديم — انتظر الانتشار وامسح DNS Cache المحلّي. وإن ظهرت صفحة المضيف الافتراضية، فالنطاق غالبًا غير مضاف داخل لوحة الاستضافة (cPanel) رغم صحّة الربط؛ أضِفه كنطاق أساسي أو Addon Domain فتُنشأ سجلّاته تلقائيًّا.

هل سيتوقّف بريدي عند ربط الدومين بالاستضافة؟ يتوقّف فقط إذا غيّرت Nameservers وكان بريدك مستضافًا في مكان آخر (مثل Google Workspace) ولم تُعِد إدخال سجلّات MX في اللوحة الجديدة. لتجنّب ذلك، انسخ سجلّات MX قبل التبديل وأعِد إدخالها فورًا، أو استخدم طريقة سجلّ A التي لا تلمس البريد إطلاقًا.

ما عنوان IP الذي أضعه في سجلّ A؟ عنوان IP خادم استضافتك، وتجده في بريد الترحيب الذي وصلك عند الشراء، أو في لوحة cPanel تحت «General Information» باسم «Shared IP Address»، أو بسؤال الدعم الفني. لا تستخدم عنوانًا من مثال عام على الإنترنت؛ كل خادم له عنوانه الخاص.

هل أحتاج توجيه www بشكل منفصل عن الجذر؟ نعم. الجذر (example.com) وwww.example.com اسمان منفصلان في DNS. اضبط سجلّ A على الجذر (@)، واضبط www بسجلّ A بنفس الـIP أو بـCNAME يشير إلى الجذر. إن نسيت أحدهما، سيفتح نصف الزوّار الموقع والآخرون لا.

لماذا لا يمكنني وضع CNAME على جذر النطاق؟ لأن الجذر يحمل إلزاميًّا سجلّات SOA وNS، وقاعدة DNS تمنع مزج CNAME مع أي سجلّ آخر لنفس الاسم. لذا الجذر دائمًا سجلّ A يشير إلى IP. إن أعطتك الاستضافة اسمًا لا عنوانًا، استخدم سجلّ ALIAS/ANAME (CNAME مسطّح) إن دعمه مزوّدك.

كيف أتحقّق أن الدومين ارتبط بالاستضافة فعلًا؟ استخدم dig example.com A +short (أو nslookup على ويندوز) وقارن العنوان الظاهر بعنوان خادمك. تحقّق من خوادم الأسماء بـdig example.com NS +short. لتجاوز ذاكرة جهازك، استعلم من محلِّل عام عبر dig @1.1.1.1 example.com. ولفحص الانتشار عالميًّا استخدم فاحص أونلاين متعدّد المواقع.

متى أصدر شهادة SSL بالنسبة للربط؟ بعد اكتمال الربط وانتشاره والتأكّد أن الموقع يفتح على http://. الشهادات المجّانية تتحقّق من ملكيتك بطلب من الخادم الذي يشير إليه الاسم، فإصدارها قبل اكتمال الربط يفشل. أصدرها (أو دع AutoSSL يصدرها) بعد الانتشار، وتأكّد أنها تشمل الجذر وwww معًا.

هل أحتاج إعداد سجلّات للنطاقات الفرعية بشكل منفصل؟ نعم، لكنه بسيط. النطاق الفرعي مثل blog.example.com مجرّد سجلّ إضافي: أضِف سجلّ A إن عرفت IP خادمه، أو CNAME إن كان يتبع خدمة خارجية باسم. أضِفه في لوحة الاستضافة (إن استخدمت Nameservers) أو عند مزوّد DNS (إن استخدمت سجلّ A)، وقد يحتاج شهادة SSL خاصّة أو شهادة wildcard.

هل يمكن استخدام Cloudflare لإدارة DNS مع استضافة في مكان آخر؟ نعم، وهذا من أبرز استخدامات طريقة سجلّ A. تغيّر خوادم أسماء النطاق إلى خوادم Cloudflare (مرّة واحدة)، ثم تدير سجلّات A وMX وغيرها من لوحة Cloudflare التي تشير إلى خادم استضافتك، مع الاستفادة من حمايتها وشبكتها. هكذا تفصل DNS والحماية عن مكان استضافة الموقع.