إعداد نطاق مخصص لتطبيقات الويب: سجلات DNS وSSL وخطة انتقال منخفضة المخاطر

ما الذي يغيّره النطاق المخصص (وما الذي قد يخطئ)\n\nالنطاق المخصص أكثر من مجرد رابط أجمل. بمجرد الانتقال من عنوان منصة (على سبيل المثال، تطبيق بنَيته على Koder.ai تحت نطاق فرعي للمنصة) إلى نطاقك الخاص، المتصفحات والشبكات تتعامل معه كموقع مختلف. هذا يؤثر على التوجيه، الأمان، وكيف تتصرف جلسات المستخدمين.\n\nبمجرد التحويل إلى نطاق مخصص، تتغير بعض الأمور على الفور:\n\n- توجيه DNS: يتوقف المستخدمون عن الذهاب إلى اسم المضيف القديم ويبدأون بالوصول إلى الهدف الذي يشير إليه DNS.\n- TLS/SSL: يجب أن تتطابق الشهادة مع اسم المضيف الجديد/الأسماء، ويجب أن تكون فعالة قبل وصول المستخدمين الحقيقيين.\n- التحويلات (Redirects): تختار ما إذا كان المستخدمون سيهبطون على www أو على النطاق apex، وتحتاج لقواعد متسقة من HTTP إلى HTTPS.\n- الكوكيز والجلسات: الكوكيز مرتبطة بنطاق. كوكي تسجيل الدخول لـ old-platform.example لن تعمل تلقائيًا على app.yourdomain.com.\n- التخزين المؤقت والانتشار: محولات DNS والمتصفحات تخزن النتائج، لذا ليس الجميع يتحول في نفس اللحظة.\n\nالانقطاعات القصيرة عادةً تأتي من التوقيت. قد يبدأ DNS في إرسال الحركة إلى المضيف الجديد قبل أن تكون شهادة SSL جاهزة، مما يؤدي إلى تحذيرات المتصفح. أو العكس: الشهادة جاهزة لكن العديد من المستخدمين ما زالوا يذهبون إلى المكان القديم لأن ذاكرة DNS المؤقتة لم تنتهِ.\n\nالتحويلات قد تكسر عمليات تسجيل الدخول بطرق دقيقة أيضًا. تحويل يغيّر اسم المضيف (من apex إلى www، أو العكس) قد يجعل الكوكيز تذهب، وإذا كانت موفري المصادقة لا تزال تستخدم عنوان النداء القديم فقد تفشل.\n\nخطة انتقال منخفضة المخاطر تعني أنك تخطط للتداخل: أبقِ العنوان القديم يعمل، شغّل النطاق الجديد بالتوازي، غيّر الحركة في لحظة متوقعة، واجعل التراجع بسيطًا عبر تغيير DNS مرة أخرى.\n\n## قرّر نطاقك وأسماء المضيف قبل لمس DNS\n\nقبل أن تغيّر أي شيء، اكتب بالضبط الأسماء التي تريد أن يكتبها المستخدمون، وأي الأسماء يجب أن تعيد التوجيه بهدوء. معظم حالات “لماذا هذا يعمل جزئيًا؟” تأتي من فريق لم يتفق على اسم المضيف الوحيد المرجعي.\n\nابدأ بالاختيار الكبير: apex (example.com) أم www (www.example.com) كالأولي. كلاهما ممكن، لكن اختَر واحدًا واجعل الآخر تحويلًا. هذا مهم لاحقًا للكوكيز أيضًا: الجلسات عادةً تكون أسهل عندما يعيش التطبيق على مضيف واحد متسق.\n\nبعدها قرر أي النطاقات الفرعية تحتاجها الآن، وأيها يمكن تأجيله. نمط شائع هو app.example.com للتطبيق وapi.example.com للواجهات البرمجية، مع إضافة admin.example.com أو assets.example.com لاحقًا. إذا كنت تضبط نطاقًا مخصصًا على منصة مثل Koder.ai، فهذه الخيارات تتطابق مباشرة مع ما ستتحقق منه لشهادة SSL وما ستشير إليه في DNS.\n\n### اعرف من يسيطر فعليًا على DNS\n\nالكثير من الناس يشترون نطاقًا عند مسجل، لكن DNS قد يكون مستضافًا في مكان آخر. تأكد أين تُحرر السجلات اليوم، من له صلاحية، وهل هناك أتمتة تدير التغييرات (IT الشركة، وكالة، أو مزوّد DNS مُدار). إذا لم تستطع الدخول ورؤية السجلات الحالية، توقف وصحح هذا أولًا.\n\nقم أيضًا بتدقيق ما الذي يستخدم النطاق بالفعل. البريد الإلكتروني هو الفخ الكلاسيكي: بإمكانك كسر تسليم البريد بحذف أو استبدال سجلات.\n\nقبل المتابعة، سجّل هذه القرارات كتابةً:\n\n- اسم المضيف الرئيسي (apex أو www) واتجاه إعادة التوجيه\n- النطاقات الفرعية المطلوبة الآن (app، api، admin) مقابل أفكار لاحقة\n- أين يستضاف DNS ومن يمكنه نشر التغييرات\n- السجلات الحرجة الموجودة (MX، SPF، DKIM، DMARC، TXT التحقق)\n- توقعات الكوكيز والمصادقة (مضيف واحد مقابل مشاركة عبر النطاقات الفرعية)\n\nإذا كانت فرق التسويق بالفعل تدير البريد على example.com، احتفظ بسجلات البريد دون تغيير أثناء إضافة ما يحتاجه التطبيق فقط.\n\n## سجلات DNS التي ستستخدمها ولماذا تهم\n\nمعظم المخاطر في نقل نطاق مخصص ليست في التطبيق نفسه. إنها تغيير DNS خاطئ يرسل الحركة إلى اللامكان، يكسر البريد، أو يجعل تحقق SSL يفشل.\n\n### السجلات الأساسية (A، CNAME، وما شابه)\n\nسجل A يشير اسمًا إلى عنوان IP. ببساطة: "أرسل الناس إلى هذا السيرفر." شائع للنطاق apex (example.com) عندما يعطيك المزوّد عنوان IP ثابتًا.\n\nسجل CNAME يشير اسمًا إلى اسم آخر. ببساطة: "عامل هذا الاسم كإسم مستعار لذلك المضيف." شائع لـ www.example.com عند الإشارة إلى اسم مضيف للمنصة.\n\nالعديد من مزودي DNS يقدمون أيضًا ALIAS/ANAME على الـ apex. يتصرف كـ CNAME لكنه يعمل على example.com. إذا دعم مزودك ذلك، فقد يسهل الإدارة لأن الهدف يمكن أن يتحرك دون أن تلمس عناوين IP.\n\nنموذج ذهني بسيط:\n\n- A: name -> IP (مباشر)\n- CNAME: name -> name (مستعار)\n- TXT: name -> نص (إثبات وسياسة)\n- MX: name -> خوادم البريد (لا تلمسها إلا إذا كنت تقصد ذلك)\n\n### سجلات TXT: التحقق، SSL، وأمان البريد\n\nستضيف غالبًا سجلات TXT لفحوص ملكية النطاق (التحقق عن طريق المنصة) ولـ التحقق من إصدار الشهادة (بعض الجهات تصدر الشهادات تتحقق عبر رمز TXT). TXT يُستخدم أيضًا لسياسة البريد مثل SPF. حذف أو استبدال SPF عن طريق الخطأ قد يكسر تسليم البريد.\n\n### TTL: مقبض "سرعة التغيير"\n\nTTL يتحكم في مدة تخزين النتيجة مؤقتًا لدى الأنظمة الأخرى. قبل يوم من التحويل، خفّض TTL على السجلات التي تخطط لتغييرها (عادة 300 إلى 600 ثانية). بعد استقرار كل شيء، ارفعه مرة أخرى لتقليل حمل الاستعلامات.\n\n### تجنّب استبدال السجلات القائمة ووثق عملية التراجع\n\nقبل التحرير، صدّر أو التقط صورة لمنطقة DNS الحالية. اكتب كل سجل ستغيره، القيمة القديمة، القيمة الجديدة، وTTL. إذا حدث خطأ، التراجع هو استعادة القيم السابقة.\n\nهذا مهم جدًا عندما يحتوي نطاقك بالفعل على MX أو DKIM أو سجلات TXT أخرى للبريد.\n\n## إصدار شهادة SSL: التحقق، التوقيت، والتغطية\n\nSSL (رمز القفل) يشفر الحركة بين المتصفح وتطبيقك. المتصفحات الحديثة والعديد من واجهات البرمجة تتوقع HTTPS افتراضيًا. بدونه، قد ترى تحذيرات، طلبات محجوزة، وميزات مثل service workers، الموقع الجغرافي، وبعض تدفقات الدفع قد تتوقف عن العمل.\n\nلإصدار شهادة، يجب أن تتحقق سلطة الشهادات من أنك تملك النطاق. طرق التحقق الشائعة هي التحقق عبر HTTP وTXT في DNS:\n\n- التحقق عبر HTTP يضع ملفًا مؤقتًا أو استجابة في عنوان URL محدد على تطبيقك.\n- التحقق عبر DNS TXT يضيف سجل TXT إلى منطقة DNS الخاصة بك.\n\nالتحقق عبر DNS غالبًا أسهل عندما تستخدم CDN أو عندما لا يكون تطبيقك قابلاً للوصول بعد على النطاق الجديد.\n\nمكان إصدار الشهادة يعتمد على إعدادك. بعض الفرق تصدر الشهادات مباشرة على بنية الاستضافة، وبعضها عند الـ CDN، وبعض المنصات التي تدعم نطاقات مخصصة تتولى الأمر نيابةً عنك (مثلًا، Koder.ai يمكنها إدارة الشهادة أثناء إعداد النطاق). المهم هو معرفة من يملك دورة حياة الشهادة، بما في ذلك التجديدات.\n\n### التوقيت والمحاولات المتكررة\n\nإصدار الشهادة ليس دائمًا فوريًا. انتشار DNS، فحوص التحقق، وحدود المعدل قد تبطئ العملية. خطط لمحاولات متكررة وتجنّب جدولة التحويل في آخر لحظة ممكنة.\n\nخطة توقيت عملية:\n\n- خفّض TTL قبل يوم حتى تطبّق التغييرات أسرع.\n- أضف سجلات التحقق مبكرًا (TXT أو رمز HTTP).\n- انتظر حتى تظهر الشهادة كـ "صدرت" لجميع أسماء المضيفين.\n- فقط حينها وجه الحركة إلى الهدف الجديد.\n\n### التغطية: تأكد من تضمين أسماء المضيف الصحيحة\n\nيجب أن تغطي الشهادة كل اسم سيصل إليه المستخدمون. تحقق من قائمة SAN (Subject Alternative Names). إذا كان تطبيقك متاحًا على كل من example.com وwww.example.com، يجب أن تشمل الشهادة الاثنين.\n\nالوايلدكارد (مثل *.example.com) قد يساعد للعديد من النطاقات الفرعية، لكنه لا يغطي الـ apex (example.com).\n\nمثال ملموس: إذا أصدرت شهادة فقط لـ www.example.com، المستخدمون الذين يكتبون example.com سيواجهون تحذيرات ما لم تقم بإعادة التوجيه على طبقة تمتلك شهادة صالحة لـ example.com أيضًا.\n\n## قواعد إعادة التوجيه: www، apex، HTTP إلى HTTPS، والافتراضات الآمنة\n\nتبدو التحويلات بسيطة، لكن معظم مشاكل النطاقات تظهر هنا: حلقات، محتوى مختلط، والمستخدمون الذين يفقدون تسجيل الدخول لأنهم تقلبوا بين مضيفين.\n\nاختر مضيفًا مرجعيًا واحدًا والتزم به: إما www.example.com أو example.com (apex). يجب أن يعيد كل مدخل آخر التوجيه إلى المضيف المرجعي حتى تظل الكوكيز، الجلسات، وإشارات SEO متسقة.\n\nالافتراضات الآمنة:\n\n- مضيف مرجعي واحد، مع تحويل 301 واحد من المضيف الآخر\n- تحويل 301 من http:// إلى https:// لكل طلب\n- الحفاظ على المسار الكامل وسلسلة الاستعلام أثناء التحويلات (الروابط العميقة يجب أن تستمر في العمل)\n- تحويل واحد فقط (تجنّب السلاسل مثل http -> https -> www)\n\nلـ HTTP إلى HTTPS، تجنّب قواعد تُعيد المستخدمين ذهابًا وإيابًا. أسهل طريقة لمنع الحلقات هي أن يبنى القرار على ما كان الطلب فعليًا. إذا كان تطبيقك خلف بروكسي أو CDN، ضبّطه لاحترام رؤوس forward (مثلاً رأس يُخبر أن المخطط الأصلي كان HTTP). وإلا قد يظن تطبيقك أن كل طلب HTTP ويستمر في إعادة التوجيه إلى الأبد.\n\nخلال الانتقال، أبقِ المسارات القديمة حية. إذا كنت تغيّر المسارات (مثل /login إلى /sign-in)، أضف تحويلات صريحة لتلك المسارات. لا تعتمد على إعادة توجيه شامل إلى الصفحة الرئيسية. هذا يكسر الإشارات المرجعية والروابط المشتركة.\n\nأجّل تفعيل HSTS في البداية. إن فعّلته مبكرًا ولزمك لاحقًا تقديم HTTP للتحقق أو للتحرّي، فقد ترفض المتصفحات الطلبات. انتظر حتى يصبح HTTPS مستقرًا وتأكد من تغطية النطاقات الفرعية.\n\nلاختبار التحويلات بدون التأثير على الجميع، استخدم اسم مضيف اختباري مؤقت، جرّب بعض الروابط العميقة الحقيقية (بما في ذلك صفحات المصادقة)، وشغّل طلب سطر أوامر يظهر كل خطوة تحويل والوجهة النهائية.\n\n## خطة انتقال آمنة خطوة بخطوة (بدون توقف)\n\nانتقال آمن يعتمد أساسًا على التوقيت. تريد أن يكون نطاقك الجديد جاهزًا ومختبَرًا قبل أن يرسل إليه أي مستخدم حقيقي، وتريد تغييرات DNS أن تنتشر بسرعة حتى لا تعطلك فترة انتظار أثناء حادث.\n\n### 1) التحضير والاختبار قبل لمس DNS الإنتاجي\n\nخفّض TTL (للسجلات التي ستغيرها) مسبقًا. افعل ذلك قبل يوم إذا استطعت، ثم انتظر حتى تمر فترة TTL القديمة حتى تلتقط المخابئ القيمة المخفضة.\n\nبعدها أضف النطاق المخصص في مضيفك/المزوِّد وأكمل ما يتطلبه من تحقق. إذا كنت تستخدم منصة مثل Koder.ai، أضف النطاق هناك أولًا حتى تتمكن المنصة من تأكيد الملكية وإعداد التوجيه.\n\nأصدر SSL مبكرًا. قد تستغرق الشهادات دقائق أو أكثر بحسب طريقة التحقق، ولا تريد هذا التأخير أثناء التحويل.\n\nقبل جعل النطاق عامًا، قم باختبار خاص: وصلت إلى نقطة النهاية الجديدة بطريقة لا تعتمد على DNS العام (مثلاً عبر إدخال مضيف مؤقت في جهازك) وتأكد أن الموقع يحمل عبر HTTPS بالشهادة الصحيحة.\n\n### 2) الانتقال بخطوات صغيرة وقابلة للتراجع\n\nاستخدم نهجًا مرحليًا حتى تتمكن من الإيقاف بسرعة إذا بدا شيء خاطئ:\n\n- خفّض TTL مقدمًا، ثم انتظر حتى يمرّ زمن TTL القديم بالكامل.\n- أكمل التحقق من النطاق في مضيفك وتأكد أن النطاق يشير للتطبيق داخليًا بشكل صحيح.\n- تأكد أن SSL مفعل لكل اسم مضيف ستخدمه (apex و/أو www) قبل تبديل المستخدمين.\n- غيّر DNS بطريقة مضبوطة: ابدأ بنطاق فرعي، منطقة صغيرة، أو شريحة مستخدم محدودة إن أمكن.\n- أبقِ النطاق القديم على الإنترنت ويعيد التوجيه بينما تراقب معدلات الحركة والأخطاء حتى تستقر.

\nإذا لم تستطع عمل canary حقيقي على مستوى DNS، يمكنك على الأقل المرحلة عبر تغيير اسم مضيف واحد أولًا (مثلاً ) وترك الـ apex حتى تكتسب ثقة.\n\n### 3) خطط التراجع بينما أنت هادئ\n\nاكتب بالضبط ما ستسترجعه (أي السجلات، أي القيم)، ومن سينفّذ ذلك. التراجع عادةً يعني إعادة DNS إلى ما كان عليه.\n\nتأكد أن الإعداد القديم لا يزال صالحًا (بما في ذلك SSL على النطاق القديم) حتى يتمكن المستخدمون من العودة بسلاسة بينما تصلح المسار الجديد.\n\n## تجنّب كوكيز مكسورة، جلسات، والمصادقة بعد الانتقال\n\nتغيير النطاق ليس مجرد تغيير DNS. لكثير من التطبيقات، "البقاء مسجلاً" يعتمد على كوكيز يربطها المتصفح باسم مضيف محدد. إذا انتقلت من مضيف لآخر، قد يتوقف المتصفح عن إرسال الكوكيز القديمة، ويبدو لتطبيقك أن الجميع قد تم تسجيل خروجهم.\n\nإعدادات الكوكيز عادة ما تكون السبب:\n\n- يحدد أي أسماء تستقبل الكوكي. كوكي معين لـ لن يُرسل إلى . كوكي معين لـ يمكن أن يعمل عبر و.\n- يحدّ من أين يُرسل الكوكي. إن كان ضيقًا جدًا (مثل ) قد لا تراه واجهة الويب.\n- يجعل الكوكي يُرسل فقط عبر HTTPS. بعد الانتقال إلى HTTPS فقط، أي طلب HTTP لن يتضمنه.\n- يؤثر على التحويلات عبر المواقع والتضمين. غالبًا كافٍ، لكن بعض SSO أو تحويلات الدفع قد تحتاج مع .\n\nلتقليل المخاطر، خطط لفترة انتقال قصيرة حيث يعمل كلا النطاقين. أبقِ المضيف القديم يجيب ويعيد التوجيه بحذر، لكن اسمح بتحديث الجلسات على النطاق الجديد. إن أمكن، استخدم مخزن جلسات مشترك حتى يمكن التعرف على المستخدم سواء ضرب أيًا من النطاقين.\n\nإذا كنت تستخدم SSO أو OAuth، حدِّث الإعدادات قبل التحويل: عناوين callback، origins المسموح بها، وأي قوائم سماح لعنوان إعادة التوجيه. وإلا قد تنجح المصادقة لدى موفر الهوية لكن تفشل عند العودة إلى التطبيق.\n\nاختبر التدفقات التي عادةً تكسر أولًا: التسجيل (وتأكيد البريد)، تسجيل الدخول/الخروج، إعادة تعيين كلمة المرور، صفحة إرجاع الدفع، والجلسات المتعددة في تبويبات مختلفة.\n\nمثال: إذا كنت تحول إلى ، تأكد من أن الكوكيز مضبوطة على (أو استخدام مضيف واحد ثابت). وإلا قد يتقلب المستخدمون بين المضيفين ويفقدون جلستهم.\n\n## أخطاء شائعة تسبب انقطاعات أو سلوك غريب\n\nمعظم مشاكل النطاق ليست "مشكلة إنترنت غامضة". إنها عدم تطابق بسيط بين DNS والشهادات وقواعد التحويل يظهر فقط بعد وصول المستخدمين الحقيقيين.\n\nفخ سهل هو النطاق apex (). العديد من مزودي DNS لا يسمحون بـ CNAME حقيقي على الـ apex. إن أشرت الـ apex إلى CNAME على أي حال، فقد يفشل بصمت، يحل بنهج غير متسق، أو يتعطل فقط على بعض الشبكات. استخدم ما يدعمه مزود DNS (غالبًا سجل A/AAAA، أو سجل ALIAS/ANAME).\n\nسبب شائع آخر لتعطل الخدمة هو أن تقوم بتبديل DNS قبل أن تكون SSL جاهزة على النقطة الجديدة. يصل المستخدمون، يُحمّل التطبيق، ثم يحجبه المتصفح لأن الشهادة مفقودة أو تغطي أسماء مضيفين جزئية فقط. عمليًا، تريد عادةً أن تغطي الشهادة كلًا من و حتى لو كنت ستعيد التوجيه لأحدهما.\n\nأخطاء شائعة تخلق انقطاعًا أو سلوكًا غريبًا:\n\n- تغيير DNS بدون خفض TTL مسبقًا، ثم انتظار ساعات لانقضاء الإجابات القديمة\n- إبقاء قواعد تحويل تخلق حلقات ( إلى apex ثم apex إلى )، أو إجبار HTTP في مكان وHTTPS في مكان آخر\n- شحن محتوى مختلط عن طريق ترميز روابط أصول بـ ، مما يثير تحذيرات المتصفح ويكسر ميزات\n- نسيان سجلات DNS غير الويب، خاصة MX وTXT، مما يكسر البريد والتحقق من النطاق\n- اختبار متصفح واحد وفقدان خصائص مخبأ HSTS أو خصائص الكوكيز التي سيواجهها الآخرون\n\nفحص سريع للسلامة: افتح كلا المضيفين ( وapex) عبر HTTPS، سجّل الدخول، حدّث الصفحة، وتأكد أن شريط العنوان لا يرجع إلى HTTP أبدًا.\n\nإذا كنت تفعل هذا على منصة مثل Koder.ai، تأكد أن النطاقات المخصصة متصلة وأن SSL صدر قبل لمس DNS الإنتاجي، واحتفظ بخيار تراجع جاهز حتى لا يظل تحويل أو تغيير سجل خاطئ لفترة طويلة.\n\n## قائمة فحص سريعة قبل، أثناء، وبعد التحويل\n\nانتقال هادئ هو في الغالب عمل تحضيري. الهدف بسيط: يجب أن يستمر المستخدمون في تسجيل الدخول، تظل الكوكيز تعمل، ويكون بإمكانك التراجع سريعًا إذا بدا شيء خاطئ.\n\n### قبل التحويل\n\nقم بهذه الخطوات بينما الحركة لا تزال تذهب للنطاق القديم. امنح نفسك يومًا إن أمكن حتى تستقر تغييرات DNS. \n- خفّض TTL لسجلاتك التي ستغيرها واكتب القيم الحالية لتستعيدها سريعًا.\n- وثق كل اسم مضيف ستخدمه (apex، ، api، إلخ) واختر طريقة التحقق للشهادة (DNS أو HTTP).\n- حضّر قواعد التحويل واختبرها في بيئة staging: HTTP إلى HTTPS، إلى apex (أو العكس)، ومضيف مرجعي واحد.\n- حدّث إعدادات المصادقة التي تعتمد على عناوين URL دقيقة: عناوين callback في OAuth، origins المسموح بها، إعدادات دومين الكوكيز، وأي إعدادات SSO.\n- قرّر من سيراقب ماذا أثناء التحويل (السجلات، فحوص التوفر، صندوق الدعم) وحدد نافذة تغيير قصيرة.