لماذا عنوان IP المجرد يُشكّل مشكلة
عنوان مثل 203.0.113.10 يعمل، لكنه يخلق ثلاثة عقبات فور محاولة المضي قُدُمًا.
أولًا، TLS مستحيل على IP مجرد. ترفض Let's Encrypt وسائر جهات إصدار الشهادات إصدار شهادة لعنوان IP عام. بلا شهادة، يعرض متصفحك «غير آمن» ولا يجد الـreverse proxy شيئًا ليُنهيه من جهة HTTPS.
ثانيًا، الـIP غير مستقر بطبيعته. إذا أعدت تثبيت VPS أو انتقلت إلى خطة أعلى أو غيّرت مركز البيانات، يتغيّر الـIP. كل إعداداتك — DNS الداخلي، ملفات إعداد التطبيق، أوامر SSH في مدير كلمات المرور — تصبح خاطئة فجأة.
ثالثًا، الـreverse proxy يحتاج إلى اسم مضيف. يعتمد Nginx وCaddy على قيمة الترويسة Host: لتوجيه الطلبات إلى الخدمة الصحيحة. على IP مجرد، يكون هذا الحقل هو الـIP نفسه، مما يُعقّد استضافة خدمات متعددة على نفس الخادم.
حالات يكون فيها العنوان المؤقت (بلا نطاق خاص) هو الحل الصحيح
- تختبر أداةً تستضيفها بنفسك قبل أن تقرر إبقاء الـVPS.
- تنتظر اكتمال نقل نطاق (من 5 إلى 7 أيام لدى بعض المسجّلين).
- تبني بيئة تجريبية داخلية لن يصل إليها أحد من خارج الفريق.
- تبني نموذج API أو webhook وتحتاج إلى عنوان HTTPS يمكن الوصول إليه من الخارج.
- عميلك لم يُعطك نطاقه بعد، لكن الـsprint يبدأ غدًا.
- تستكشف نطاقًا فرعيًا لمشروع جانبي قبل تقرير ما إذا كان يستحق نطاقًا خاصًا.
- تُعدّ الـDNS العكسي (PTR) لخادم البريد وتحتاج إلى FQDN متسق الآن.
- تصل إلى VPS من شبكة تحجب الاتصالات المباشرة بعنوان IP (بعض جدران الحماية تُرشّح الوجهات غير الحاملة لـSNI).
المتطلبات المشتركة للخيارات الثلاثة
قبل الاختيار، تأكد من توفّر:
VPS نشط يمكن الوصول إليه عبر SSH. يجب أن يستجيب الأمر ssh root@<ip-vps>. إذا سُلِّم VPS للتو، انتظر بضع دقائق حتى تنتهي الصورة من النشر الكامل.
الوصول إلى وحدة تحكّم الإدارة (منطقة عميل ServOrbit للخيار 1، والمتصفح للخيارين 2 و3).
معرفة أساسية بالـDNS: أن تعرف أن سجل A يُشير باسم إلى عنوان IP، وأن TTL مرتفعًا يُبطئ الانتشار. للخيارين 2 و3، لا يُشترط شيء آخر من جهة الخادم — تتكفّل الخدمات بالباقي.
الخيار 1 — النطاق الفرعي من ServOrbit: العنوان الفوري
يتلقى كل خادم VPS من ServOrbit عند التسليم اسم مضيف بصيغة vps-xxxxxxx.servorbit-dns.com. يُسنَد تلقائيًا، يُشير إلى IP خادمك، ويبقى صالحًا حتى لو تغيّر هذا الـIP بعد إعادة التثبيت. هذا هو الحل بلا احتكاك: لا حساب خارجي، ولا عميل لتثبيته، ولا cron لإعداده.
تفعيل النطاق الفرعي من ServOrbit واستخدامه
ابحث عن عنوانك في منطقة العميل
سجّل الدخول، افتح VPS ← إدارة. يعرض كتلة الوصول عنوانك vps-xxxxxxx.servorbit-dns.com بدلًا من الـIP. زرّ ينسخ أمر SSH الكامل — ssh [email protected].
استبدل الـIP بهذا الاسم في كل مكان
في إعداد تطبيقك وعميل SSH وسكريبتات النشر: استبدل الـIP بالنطاق الفرعي. يبقى العنوان صالحًا بعد إعادة تثبيت قد تُغيّر الـIP.
انشر تطبيقًا بـHTTPS دون كتابة سطر إعداد واحد
في VPS ← إدارة ← التطبيقات، اختر قالبك وحدد النطاق الفرعي المجاني عوضًا عن إدخال نطاق. يُعدّ المثبِّت الـreverse proxy (Caddy أو Nginx Proxy Manager حسب القالب)، ويطلب شهادة Let's Encrypt ويُعطيك عنوانًا مثل my-app.vps-xxxxxxx.servorbit-dns.com، جاهزًا عبر HTTPS في دقائق.
اضبط الـDNS العكسي (PTR) بنقرة واحدة
إذا كنت تستضيف خادم بريد، اذهب إلى الشبكة والأمان ← DNS العكسي، أدخل vps-xxxxxxx.servorbit-dns.com وأكّد. بما أن هذا الاسم يُشير فعلًا إلى IP خادمك، يصبح PTR «مؤكَّدًا» فورًا — الشرط اللازم حتى لا تُصنّف خوادم البريد المستقبِلة رسائلك ضمن الرسائل المزعجة.
اربط نطاقك حين تصبح جاهزًا
عندما تشتري نطاقًا أو تنقله، اربطه بالـVPS من منطقة العميل. يبقى النطاق الفرعي servorbit-dns.com نشطًا بالتوازي خلال الانتقال — لا ينكسر أي رابط قائم، ولا شيء تعيد إعداده.
الخيار 2 — DNS ديناميكي مجاني (Afraid.org وdeSEC وnsupdate.info)
إذا أردت اسمًا أكثر تخصيصًا، أو كنت تدير عدة VPS عند مزودين مختلفين، فإن خدمات DNS الديناميكي المجانية بديل جدي. تتيح لك Afraid.org اختيار نطاق فرعي تحت خمسين نطاقًا عامًا تقريبًا (mooo.com وmyftp.org…). تتيح لك deSEC إحضار نطاقك الخاص وتُدير الـDNS نيابةً عنك مجانًا عبر API للتحديثات. تتبع nsupdate.info المبدأ ذاته بواجهة أبسط.
الآلية واحدة للثلاثة: عميل DDNS يعمل على VPS يكتشف تغيّرات الـIP ويُحدّث سجل A عبر API الخدمة. النتيجة: نطاقك الفرعي يتتبّع الـIP، حتى لو تغيّر.
إعداد DNS ديناميكي (مثال مع deSEC)
أنشئ حسابًا ونطاقًا فرعيًا على desec.io
على desec.io، أنشئ حسابًا ثم أضف نطاقًا فرعيًا (مثال: myvps.dedyn.io). تُنشئ deSEC رمز وصول API — انسخه.
ثبّت ddclient على خادمك
على Debian/Ubuntu: apt install ddclient. خلال التثبيت، اختر أي بروتوكول أو أجب بحرية — ستستبدل الإعداد على أي حال.
اعدّ /etc/ddclient.conf
عدّل الملف بواسطة رمزك ونطاقك الفرعي. توفّر deSEC توثيقًا مباشرًا على موقعها لكتلة الإعداد الدقيقة وفق إصدار ddclient لديك.
ابدأ الخدمة وتحقق من الانتشار
شغّل systemctl enable --now ddclient، ثم انتظر دقيقة إلى دقيقتين. تحقق من الحلّ بـ dig myvps.dedyn.io A من جهاز خارجي. إذا طابق الـIP المُعاد IP خادمك، فقد اكتملت العملية.
احصل على شهادة TLS مع Caddy أو Certbot
مع Caddy (apt install caddy)، يكفي ملف Caddyfile مبسّط: myvps.dedyn.io { reverse_proxy localhost:3000 }. يتفاوض Caddy على شهادة Let's Encrypt بنفسه. مع Certbot، شغّل certbot certonly --standalone -d myvps.dedyn.io.
الخيار 3 — نفق التطوير (Cloudflare Tunnel أو ngrok)
الأنفاق العكسية هي الطريقة الأسرع لكشف خدمة على VPS خلف NAT دون فتح منافذ أو إعداد DNS. يُنشئ Cloudflare Tunnel (cloudflared) نفقًا مشفّرًا بين VPS وحافة Cloudflare، تعرض خدمتك على نطاق فرعي trycloudflare.com (وضع مؤقت، دون حساب) أو على نطاقك الخاص إذا كان لديك واحد في Cloudflare. يعمل ngrok بالمبدأ ذاته ويُسند عنوانًا عشوائيًا يتجدد عند كل بدء (حساب مجاني) أو عنوانًا ثابتًا (حساب مدفوع).
هذه الأدوات مثالية لعرض نموذج، اختبار webhook لـStripe أو GitHub، أو دعم عميل عن بُعد دون تعديل جدار الحماية. لا تُعوّض البنية التحتية الدائمة: الكمون الإضافي وحدود النطاق الترددي للخطط المجانية تُبقيها في نطاق التطوير والاختبار.
كشف خدمة في 3 دقائق مع Cloudflare Tunnel (الوضع المؤقت)
ثبّت cloudflared على خادمك
حمّل الملف الثنائي من github.com/cloudflare/cloudflared/releases واجعله قابلًا للتنفيذ: chmod +x cloudflared && mv cloudflared /usr/local/bin/.
ابدأ نفقًا مؤقتًا نحو خدمتك
إذا كان تطبيقك يستمع على المنفذ 8080: cloudflared tunnel --url http://localhost:8080. يعرض Cloudflare عنوانًا بصيغة *.trycloudflare.com — شاركه. ينتهي حين تُغلق العملية.
لنفق دائم، أنشئ حسابًا ونفقًا باسم
سجّل الدخول بـ cloudflared tunnel login، أنشئ نفقًا (cloudflared tunnel create my-tunnel)، اعدّ ملف YAML وسجّل الخدمة (cloudflared service install). يُعاد تشغيل النفق مع الـVPS.
متى تنتقل إلى نطاق حقيقي
هذه الخيارات الثلاثة حلول بداية أو تطوير. انتقل إلى نطاق باسمك حين تتحقق إحدى هذه الشروط.
TLS الإنتاج. تُصدر Let's Encrypt الشهادات لأسماء النطاقات المسجّلة؛ على نطاق فرعي تابع لطرف ثالث، أنت تعتمد على بنيته التحتية وسياسة الاحتفاظ لديه.
تهيئة محركات البحث. مقال مدونة أو صفحة هبوط أو متجر إلكتروني لا يبني أي سلطة نطاق على نطاق فرعي لطرف ثالث. سيُفهرَس محتواك، لكن إشارة الثقة تذهب للنطاق الأب لا لك.
ثقة العميل. مشاركة عنوان myapp.vps-xxxxxxx.servorbit-dns.com أو myapplication.trycloudflare.com مع عميل نهائي تخلق احتكاكًا غير ضروري. نطاق خاص بك هو إشارة احترافية لا يمكن شراؤها لاحقًا.
على ServOrbit، تسجيل نطاق أو نقله وربطه بالـVPS يستغرق بضع نقرات من منطقة العميل — والنطاق الفرعي المجاني يبقى متاحًا بالتوازي طوال فترة الانتقال.
الأخطاء الأربعة الأكثر شيوعًا
الـDNS لم ينتشر بعد. قد يستغرق انتشار سجل A من ثوانٍ (TTL منخفض) حتى 48 ساعة (TTL موروث من مسجّل قديم). تحقق بـ dig +short your-subdomain-name A من جهاز خارجي — نظامك التشغيلي يُخزّن الإجابات مؤقتًا. ينتشر النطاق الفرعي من ServOrbit فور التسليم: إذا لم يستجب dig، تحقق من غياب خطأ إملائي في العنوان.
رُفض TLS على IP مجرد. إذا أعطى Certbot أو Caddy خطأً مثل «Domain not found» أو «Invalid domain»، فأنت حاولت إصدار شهادة لعنوان IP. استبدل الـIP باسم المضيف في إعداد الـreverse proxy وأعِد المحاولة.
النطاق الفرعي من ServOrbit غير مُسنَد. إذا لم يُحَلّ vps-xxxxxxx.servorbit-dns.com، افتح منطقة العميل وتحقق من أن الـVPS في حالة نشط (ليس في مرحلة التثبيت). على VPS تُسلَّم للتو، انتظر دقيقتين إلى ثلاث حتى ينتشر إسناد الـDNS.
نفق Cloudflare يُغلق. في الوضع المؤقت (--url)، يعيش النفق بقدر بقاء العملية. إذا انقطع اتصال SSH، اختفى النفق. لنفق ثابت، اعدّه كخدمة systemd (cloudflared service install) أو استخدم screen / tmux لبقاء العملية بعد قطع الاتصال.
خلاصة: اختيار الخيار الصحيح
النطاق الفرعي من ServOrbit هو الخيار الافتراضي إذا كان VPS لديك عند ServOrbit: لا إعداد، HTTPS تلقائي عبر المثبّت، DNS عكسي مُضمَّن. يغطي 90% من حالات البداية.
DNS الديناميكي (deSEC وAfraid.org) يستحق العناء إذا كنت تدير عدة VPS عند مزودين مختلفين، أو تريد اسمًا أكثر دلالة، أو لديك نطاق تريد تفويضه دون دفع رسوم DNS إضافية.
النفق (Cloudflare Tunnel وngrok) هو الإجابة حين تكون السرعة هي الأولوية: نموذج تعرضه خلال ساعة، webhook لاختباره، عرض تجريبي مفاجئ لعميل. العمر القصير ميزة لا عيب.
حين يكتسب مشروعك زخمًا، سجّل نطاقك واربطه بالـVPS — هذه هي الخطوة الطبيعية التالية.