[الرئيسية](https://servhidden.com/ar) /
[أدلة الاستضافة الخاصة](https://servhidden.com/ar/guides) /
كيفية ترحيل موقع إلى استضافة أوفشور دون توقف






التشغيل


# الانتقال إلى استضافة أوفشور دون توقف



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


[اقرأ الدليل](#guide-body)
[الأسئلة الشائعة](#guide-faq)






## في هذه الصفحة




- [دليل](#guide-body)

- [الأسئلة الشائعة](#guide-faq)

- [أدلة ذات صلة](#guide-related)

- [الصفحات الموصى بها](#guide-cta)






بدون تحقق من الهوية
عملات مشفرة حصراً
بدون سجلات
تجاهل DMCA
صلاحيات Root كاملة
أقراص NVMe SSD





15 دقيقة قراءة
محدّث Aug 2026

في هذه الصفحة

[01ماذا يعني "التوقف الصفري" فعلياً](#ماذا-يعني-التوقف-الصفري-فعليا)
[02خفّض TTL الخاص بـDNS قبل أيام من موعد الانتقال](#خفض-ttl-الخاص-بـdns-قبل-أيام-من-موعد-الانتقال)
[03اجرد ما تنقله فعلياً، لا ما تتذكره](#اجرد-ما-تنقله-فعليا-لا-ما-تتذكره)
[04ابنِ السيرفر الجديد أولاً، وحصّنه قبل أن يحمل أي شيء](#ابن-السيرفر-الجديد-أولا-وحصنه-قبل-أن-يحمل-أي-شيء)
[05انسخ البيانات مرتين: مرور بطيء، ثم مرور سريع](#انسخ-البيانات-مرتين-مرور-بطيء-ثم-مرور-سريع)
[06اختبر السيرفر الجديد قبل أن يعرف DNS بوجوده](#اختبر-السيرفر-الجديد-قبل-أن-يعرف-dns-بوجوده)
[07التحويل، بالترتيب](#التحويل-بالترتيب)
[08ما الذي يخلّفه الترحيل وراءه](#ما-الذي-يخلفه-الترحيل-وراءه)
[09مسألة النطاق: تنقله معك، أم تبدأ من جديد؟](#مسألة-النطاق-تنقله-معك-أم-تبدأ-من-جديد)
[10أخرج المزوّد القديم من الخدمة بالشكل الصحيح](#أخرج-المزود-القديم-من-الخدمة-بالشكل-الصحيح)
[11التسلسل الكامل في صفحة واحدة](#التسلسل-الكامل-في-صفحة-واحدة)
[FAQالأسئلة الشائعة](#guide-faq)
[→الصفحات الموصى بها](#guide-cta)







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

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

## ماذا يعني "التوقف الصفري" فعلياً

العبارة تُستخدم بتساهل، وهذا التساهل هو ما يؤذي الناس. تقديم HTTP من آلتين في آن واحد أمر سهل. الحفاظ على اتساق *الحالة* بينما تعمل آلتان معاً هو الجزء الصعب، وهو الجزء الوحيد الذي يفقد بيانات فعلياً. لذا قبل التخطيط لأي شيء، حدّد أياً من هذه الحالات تُشغّله فعلاً، لأن الإجابة تحدد شكل الليلة بأكملها.

| ما الذي تنقله | الجزء الذي يُسبّب المشكلة فعلياً | ما ينبغي أن تكون عليه الخطة |
| --- | --- | --- |
| موقع ثابت، موقع تعريفي، مخرجات مولَّدة | لا شيء. لا توجد حالة يمكن أن تنقسم | انسخ، تحقّق، حوّل. توقف صفري فعلياً |
| نظام إدارة محتوى بقاعدة بيانات — WordPress، Ghost، منتدى | تعليقات وتسجيلات دخول ومنشورات تصل إلى قاعدتي بيانات في آن واحد | تجميد بوضع القراءة فقط مدته **دقائق**، في أهدأ ساعاتك |
| متجر، أو أي شيء يستقبل طلبات | انقسام صامت بين قاعدتي البيانات يُفقِد طلبات مدفوعة | خذ نافذة الصيانة القصيرة. أرخص من التسوية اللاحقة |
| أي شيء يحتوي مهام cron أو عمليات خلفية | المهمة نفسها تعمل على السيرفرين معاً — رسائل بريد مضاعفة، رسوم مضاعفة | عطّل الجدولة على السيرفر القديم *قبل* أن يبدأ الجديد |
| بريد على النطاق نفسه | سجلات MX تنتهي صلاحيتها من الذاكرة المؤقتة بساعتها الخاصة، بمعزل عن سجل A | انقل البريد في ليلة منفصلة، وأبقِ سجل MX القديم يقبل البريد لمدة أسبوع |

لاحظ أن الصف الأول وحده مجاني فعلاً. في كل مكان آخر، يعني "التوقف الصفري" "تجميد كتابة قصيراً بما يكفي ألا يفتح أحد تذكرة بشأنه". دقيقتان من وضع القراءة فقط عند الساعة 04:00 خطأ مقبول بالتقريب؛ أما ساعتان من كتابة منقسمة بين قاعدتي بيانات فهما عطلة نهاية أسبوع من التسوية. اختر التجميد.

يعمل السيرفران معاً في آن واحد، وDNS هو آخر ما يُنقل — ولهذا لا يترك التحويل الذي يُنفَّذ بالترتيب الصحيح أي نافذة توقف على الإطلاق.

## خفّض TTL الخاص بـDNS قبل أيام من موعد الانتقال

هذه هي الخطوة الوحيدة التي تحتاج وقتاً مسبقاً، ولهذا تأتي أولاً، ولهذا أيضاً يتخطاها الناس. TTL — مدة البقاء — يُخبر كل مُحلل على الإنترنت بالمدة التي يمكنه خلالها تخزين سجلك مؤقتاً قبل أن يسأل من جديد. إذا كان سجل A لديك بقيمة TTL تبلغ 86400، فإن مُحللاً استعلم عنه قبل ساعة سيستمر في تسليم IP القديم لثلاث وعشرين ساعة أخرى، بصرف النظر عمّا تغيّره لدى المسجّل.

التفصيل الحاسم هو أن خفض TTL نفسه خاضع لقيمة TTL القديمة. لا تتعرّف المُحللات على القيمة الجديدة الأقصر إلا عندما تنتهي صلاحية النسخة المخزَّنة مؤقتاً القديمة. لذا اخفض TTL إلى 300 ثانية **قبل التحويل بفترة كاملة على الأقل تعادل TTL القديم** — ومع TTL يبلغ يوماً كاملاً، يعني ذلك فعل هذا قبل 24 إلى 48 ساعة. عندها يتقارب العالم كله مع سجلك الجديد خلال خمس دقائق من التغيير، ويتوقف التحويل عن أن يكون حدثاً مشوّقاً.

أعد TTL إلى قيمة معقولة بعد أيام قليلة من الانتقال. قيمة TTL بـ300 ثانية أداة جيدة لكنها إعداد دائم رديء: فهي تضاعف حجم استعلاماتك وتجعل مزوّد DNS لديك نقطة فشل واحدة أكثر حدة.

## اجرد ما تنقله فعلياً، لا ما تتذكره

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

- **العمل المجدوَل.** crontab -l لكل مستخدم، إضافة إلى مؤقتات systemd. خطافات التجديد والمهام الليلية تختبئ هنا.

- **تعريفات الخدمات.** وحدات systemd المخصصة، والمضيفات الافتراضية لخادم الويب (vhosts)، وتجمّعات PHP-FPM، وأي إعدادات supervisor.

- **الأسرار والبيئة.** ملفات .env، ومفاتيح API، وكلمات مرور قاعدة البيانات، وأملاح التطبيق (salts) — ولاحظ أن هذه يجب تدويرها، لا نسخها فقط.

- **مواد TLS.** الشهادات، والأهم من ذلك، حساب ACME وإعدادات التجديد.

- **هوية البريد.** مفاتيح DKIM الخاصة، وسجلات SPF وDMARC. عدم التطابق هنا لا يتسبب بعطل صاخب؛ بل يرسل بريدك بهدوء إلى مجلد السبام.

- **الوسائط المرفوعة.** غالباً ما تكون خارج جذر الويب، وغالباً ما تكون أكبر ما تملكه.

- **كل ما هو خارجي ويثق بعنوان IP لديك.** قوائم سماح بوابات الدفع، ووجهات webhook، وجدران حماية قاعدة البيانات، وواجهات برمجة تطبيقات خارجية بقيود على IP. هذا هو السبب الأول لظاهرة "الموقع يعمل لكن الدفع معطّل" عند الساعة 03:00.

- **قائمة الحزم.** dpkg --get-selections أو ما يعادلها، حتى تحصل الآلة الجديدة على الإضافات والمكتبات نفسها لا على ما يشبهها فقط.

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

## ابنِ السيرفر الجديد أولاً، وحصّنه قبل أن يحمل أي شيء

اطلب الوجهة مبكراً واتركها تعمل فارغة ليوم أو يومين. لا تكلفة للتداخل الزمني — سيرفر VPS أوفشور صغير يكلّف بضعة دولارات شهرياً — وقيمة كبيرة في ألا تبني تحت ضغط الوقت بينما تنتظرك قاعدة بيانات مُجمَّدة.

طابِق البيئة القديمة عمداً: التوزيعة نفسها بالإصدار الرئيسي نفسه، وإصدار PHP أو Node أو Python الرئيسي نفسه، وإصدار قاعدة البيانات الرئيسي نفسه. إغراء التحديث والتحسين بينما أنت هناك كبير جداً ويجب مقاومته كلياً. إن تعطّل الموقع بعد التحويل، فأنت تريد أن يكون متغيّر واحد بالضبط قد تغيّر. حدّث الحزمة البرمجية بعد أسبوعين، في عصر يوم هادئ، مع الاحتفاظ بالقدرة على التراجع.

حصّنه وهو ما زال فارغاً. SSH بالمفاتيح فقط، وجدار حماية يرفض كل شيء افتراضياً، وتحديثات أمان تلقائية — [قائمة تحصين الساعة الأولى](https://servhidden.com/ar/guides/first-hour-vps-hardening-checklist) هي هذه القائمة بالضبط، وتطبيقها أسهل بكثير على آلة لا يوجد عليها شيء. وإذا كانت البيانات حساسة بما يكفي لتبرير تغيير الولاية القضائية من أجلها، فهذه أيضاً هي اللحظة المناسبة لاتخاذ قرار بشأن [تشفير البيانات الساكنة](https://servhidden.com/ar/guides/full-disk-encryption-on-a-vps)، لأن إضافته لاحقاً تعني ترحيلاً آخر.

## انسخ البيانات مرتين: مرور بطيء، ثم مرور سريع

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

بالنسبة للملفات، يحافظ rsync -aHAX --numeric-ids على الصلاحيات والملكية والروابط الصلبة والسمات الموسّعة؛ وخيار --numeric-ids مهم لأن UIDs نادراً ما تتطابق بين آلتين بُنيتا حديثاً. شغّله مرة مبكراً، ثم مرة أخرى مباشرة قبل التحويل بالمعطيات نفسها — التشغيلة الثانية تنقل الفارق فقط.

تحتاج قواعد البيانات المعاملة ذاتها على مرحلتين لكن بأدوات مختلفة. يمنحك mysqldump --single-transaction أو pg_dump لقطة مبكرة متسقة للبناء والاختبار عليها. عند التحويل، إما أن تأخذ تفريغة ثانية أثناء تجميد الكتابة القصير، أو — بالنسبة لقاعدة بيانات كبيرة يؤلمها حتى التجميد القصير — تُعِدّ السيرفر الجديد كنسخة مطابقة (replica) للقديم قبل أيام، وتتركه يلحق بالتحديثات، ثم ترقّيه. النسخ المطابق يختصر التجميد إلى ثوانٍ. لكنه أيضاً يحوّل ترحيلاً مدته ساعتان إلى مشروع مدته يومان، فاستخدمه فقط عندما يستدعي الحجم ذلك فعلياً.

**اسحب، ولا تدفع، ولا تفعل ذلك أبداً عبر حاسوبك المحمول.** ابدأ النسخ من السيرفر الجديد بحيث يجري النقل مباشرة بين السيرفرين بسرعة مركز البيانات. توجيه غيغابايتات عبر اتصالك المنزلي بطيء، ويضع عنوان IP السكني الخاص بك في سجلات الوصول لكلتا الآلتين — وهو تحديداً الرابط الذي وُجد الترحيل بدافع الخصوصية لتجنّبه. وإذا كان حتى اطّلاع السيرفر القديم على عنوان IP الجديد أمراً غير مقبول، فلا تنسخ مباشرة إطلاقاً: استعِد السيرفر الجديد من [نسختك الاحتياطية المشفّرة خارج الموقع](https://servhidden.com/ar/guides/vps-backup-strategy) بدلاً من ذلك، بحيث لا تتواصل الآلتان أبداً.

## اختبر السيرفر الجديد قبل أن يعرف DNS بوجوده

يمكنك تقديم اسم المضيف الحقيقي من عنوان IP الجديد دون تغيير سجل عام واحد، وينبغي أن تفعل — هذا ما يجعل التحويل بلا أحداث. أضف سطراً إلى ملف /etc/hosts المحلي لديك يوجّه النطاق إلى IP الجديد، أو تجاوز ذلك ودع curl يفعلها لطلب واحد:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

الآن تفقّد الجرد. حمّل الصفحة الرئيسية وثلاث صفحات عميقة. سجّل الدخول. أرسل نموذجاً. ارفع ملفاً. تحقّق من أن اتصال قاعدة البيانات هو الاتصال المحلي الجديد وليس ما زال يشير إلى السيرفر القديم عبر الإنترنت — وهو خطأ يعمل بشكل مثالي إلى أن تُلغي السيرفر القديم. شغّل مهام cron يدوياً واقرأ مخرجاتها. تحقّق من عمليات إعادة التوجيه ومن أن رابطاً غير موجود ما زال يُعيد 404 لا 200.

أصدر شهادة TLS الآن، قبل التحويل، لا بعده. استخدم تحدّي DNS-01 الذي يُثبت التحكم بالنطاق عبر سجل TXT وبالتالي يعمل بينما ما زال سجل A يشير إلى السيرفر القديم. إن انتظرت التحقق عبر HTTP-01 بعد تغيير DNS، فسيحصل كل زائر مبكر على تحذير شهادة خلال هذه الفجوة — انقطاع ذاتي التسبب في النافذة نفسها التي كنت تحاول حمايتها.

## التحويل، بالترتيب

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

- أعلن عن النافذة الزمنية إن كان أحد غيرك يعتمد على الموقع، ثم ضع الموقع القديم في وضع القراءة فقط أو وضع الصيانة.

- **عطّل cron والعمليات الخلفية على السيرفر القديم.** افعل هذا قبل تشغيلها على السيرفر الجديد، لا بعده أبداً.

- شغّل مرور rsync الأخير للفارق والتفريغة النهائية لقاعدة البيانات، ثم استوردها.

- شغّل التطبيق على السيرفر الجديد وأعد تشغيل اختبارات الفحص السريع عبر --resolve، على البيانات النهائية.

- غيّر سجلي A وAAAA إلى IP الجديد. مع TTL بـ300 ثانية، يتبع العالم كله خلال خمس دقائق.

- فعّل cron والعمليات الخلفية على السيرفر الجديد.

- راقب سجلي الوصول لكلا السيرفرين جنباً إلى جنب. تنسحب الزيارات من السيرفر القديم وتظهر على الجديد؛ وحين يهدأ القديم تماماً، يكون التحويل قد اكتمل.

- اترك السيرفر القديم يعمل ويخدم دون أن تلمسه لمدة أسبوع. إنه خطة تراجعك.

الخطوة الثامنة هي التي يتخطاها الناس، وهي أرخص تأمين في القائمة. مقابل ثمن بضعة دولارات تحتفظ بالقدرة على إعادة توجيه DNS للخلف — استعادة خلال خمس دقائق — طوال الوقت اللازم للتأكد.

## ما الذي يخلّفه الترحيل وراءه

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

| ما الذي يوثّق الانتقال | من يستطيع قراءته | ما الذي يمكنك فعله فعلياً |
| --- | --- | --- |
| Passive DNS — سجلات A التاريخية | أي شخص، عبر خدمات أرشيف تجارية | **لا شيء.** عنوان IP القديم مرتبط بالاسم بشكل دائم. تعامل معه وكأنه علني، لأنه كذلك فعلاً |
| سجلات Certificate Transparency | أي شخص، بشكل دائم، قابلة للبحث حسب النطاق | كل شهادة صدرت على الإطلاق مُدرَجة — بما فيها النطاقات الفرعية ذات الطابع الداخلي التي نسيتها. فضّل wildcard على الأسماء الوصفية |
| سجلات حساب المزوّد القديم | المزوّد القديم، وأي جهة يمكنها إجباره على الإفصاح | تفاصيل البطاقة، بريد التسجيل، عناوين IP لتسجيلات الدخول. وجهة بلا KYC تحمي المستقبل، لا الماضي |
| سجل WHOIS التاريخي | أرشيفات WHOIS التجارية | إن كان النطاق قد سُجّل يوماً ببيانات حقيقية، فتلك اللقطة محفوظة. الخصوصية المطبَّقة لاحقاً لا تُلغيها |
| معرّفات التحليلات والإعلانات | مزوّد الخدمة، وأي شخص يقرأ مصدر صفحتك | حمل معرّف التتبع نفسه عبر الموقعين يربطهما بشكل قاطع. أصدر معرّفاً جديداً، أو تخلَّ عنه |
| تفريغات ونسخ احتياطية تُركت على القرص القديم | من يُخصَّص له ذلك التخزين لاحقاً | احذف واكتب فوقها قبل الإلغاء. على التخزين المشترك، افترض أن الحذف مجرد إشارة لا ضمان |
| ترويسات Received: في البريد المُرسَل | كل مستلم، إلى الأبد | لا رجعية هنا. فقط البريد الذي ترسله بعد الانتقال يحمل المسار الجديد |
| اتصالاتك الخاصة أثناء النسخ | مزوّد الإنترنت لديك، وسجلات وصول كلا السيرفرين | هذا وحده تحت سيطرتك الكاملة. لا تلمس أياً من الآلتين أبداً من IP يكشف هويتك |

الخلاصة الصادقة هي أن الترحيل لا يستطيع إعادة كتابة الماضي — بل يستطيع فقط التوقف عن الإضافة إليه. هذا ما زال يستحق الكثير، لكنه يغيّر القرار: إذا كان نموذج التهديد لديك يتطلب ألا يستطيع أي مراقب ربط الموقع الجديد بالقديم، فإن نقل النطاق نفسه إلى مزوّد جديد لا يحقق ذلك، ولن يحققه أي قدر من الحرص أثناء التحويل. تلك الحالة تحتاج اسماً جديداً وبداية نظيفة، وهو ما سنناقشه تالياً. أما إذا كان هدفك بدلاً من ذلك هو التوقف عن توليد سجلات تكشف هويتك ابتداءً من اليوم، ونقل مركز الثقل القانوني إلى ولاية قضائية اخترتها بنفسك، فإن الانتقال يحقق هذا بالضبط. يغطي [دليل الأمن التشغيلي للسيرفر](https://servhidden.com/ar/guides/server-opsec-staying-anonymous) لدينا العادات التي تُبقي الأمر نظيفاً بعد ذلك.

## مسألة النطاق: تنقله معك، أم تبدأ من جديد؟

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

- **احتفظ بالنطاق، وغيّر المسجّل.** منطقي عندما يكون للنطاق قيمة — روابط، ترتيب في نتائج البحث، اسم يكتبه الناس. هذا يُصلح مستقبل سجل WHOIS لا تاريخه، ويُبقي كل إشارة ترتيب سليمة. هذا هو الجواب الصحيح لمعظم المواقع التجارية.

- **احتفظ بالنطاق، ولا تغيّر شيئاً سوى المزوّد.** معقول تماماً عندما يكون دافع انتقالك الولاية القضائية أو زمن التشغيل أو موقف DMCA لا إخفاء الهوية. أبسط انتقال ممكن، وبلا أي مخاطرة على SEO.

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

- **نطاق جديد، وقطيعة نظيفة.** الخيار الوحيد الذي يقطع الصلة فعلياً، ويكلّفك كل ترتيب وكل رابط وارد كان لديك. سجّله بخصوصية منذ البداية، لأن النطاق لا يكون مجهولاً إلا بقدر ما كان تسجيله الأول كذلك. يغطي دليلنا عن [تسجيل نطاق مجهول بعملات رقمية](https://servhidden.com/ar/guides/anonymous-domain-registration-with-crypto) كيفية فعل ذلك بالشكل الصحيح.

اختر بتروٍّ، واختر قبل التحويل لا أثناءه. تغيير رأيك بشأن النطاق بعد انتقال DNS يعني القيام بالجزء الدقيق مرتين.

## أخرج المزوّد القديم من الخدمة بالشكل الصحيح

بعد أسبوع أو أسبوعين من التحويل، حين تصبح سجلات السيرفر الجديد مملة وسجلات القديم فارغة، يحين وقت إغلاق الحساب القديم. افعل ذلك بهذا الترتيب، لأن الاختصار المُغري — الضغط على "إلغاء" — هو ما يترك بياناتك على قرص شخص آخر.

- تأكد من ألا شيء ما زال يشير إلى IP القديم: تحقّق من العناوين المُدرجة يدوياً في webhooks تابعة لجهات خارجية، وقوائم السماح، والمراقبة، وأي سجل DNS نسيته، مثل نطاق فرعي شارد باسم mail أو cpanel.

- دوّر كل سر عاش يوماً على تلك الآلة — كلمات مرور قاعدة البيانات، ومفاتيح API، وأملاح التطبيق، ومفاتيح DKIM، ومفاتيح SSH. لا تنقلها للأمام كما هي.

- أزل مفاتيح SSH العامة الخاصة بك وأي صلاحية دعم فني من السيرفر القديم.

- احذف التطبيق والتفريغات والنسخ الاحتياطية، ثم اكتب فوق المساحة الحرة حتى لا تعطي أي قراءة عابرة للوحدة التخزينية المُعاد تدويرها أي شيء.

- عندها فقط أنهِ الخدمة، وأزل أي وسيلة دفع محفوظة من الحساب القديم.

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

## التسلسل الكامل في صفحة واحدة

إن جرّدت الأمر من التبرير، فترحيل المزوّد تسع خطوات، اثنتان منها فقط لهما إلحاح فعلي:

- **قبل يومين:** اخفض TTL الخاص بـDNS إلى 300 ثانية.

- **قبل يومين:** اطلب سيرفر الوجهة وحصّنه، بمطابقة إصدار الحزمة القديمة إصداراً بإصدار.

- **قبل أيام:** اكتب الجرد — cron، والأسرار، وTLS، ومفاتيح البريد، والوسائط، وقوائم سماح IP، والحزم.

- **قبل أيام:** شغّل أول نسخ كامل للبيانات، من سيرفر إلى سيرفر.

- **قبل النافذة الزمنية:** أصدر الشهادة عبر DNS-01 واختبر كل شيء عبر --resolve.

- **النافذة الزمنية (دقائق):** جمّد الكتابة، عطّل cron القديم، شغّل نسخ الفارق والتفريغة النهائية، شغّل التطبيق الجديد.

- **النافذة الزمنية (ثوانٍ):** غيّر سجل A، ثم فعّل cron على السيرفر الجديد.

- **الأسبوع التالي:** أبقِ السيرفر القديم حياً كخطة تراجع، راقب ملفي السجل كليهما، ثم ارفع TTL من جديد.

- **بعد ذلك:** دوّر الأسرار، وامسح، وألغِ — وتذكّر ما لم يستطع الانتقال محوه.

لا شيء في هذه القائمة صعب. كل خطوة تؤلم هي خطوة نُفِّذت خارج ترتيبها — TTL خُفِّض في ليلة الانتقال، شهادة صدرت بعد تغيير DNS، مهمة cron ظلّت نشطة على آلة لم تعد هي المرجع الرسمي. اضبط التسلسل بشكل صحيح، وسيصبح الجزء الممتع من الترحيل هو اختيار أين تضع السيرفر، لا عملية الانتقال نفسها. إن لم تكن قد حسمت ذلك بعد، فـ[دليل اختيار الولاية القضائية](https://servhidden.com/ar/guides/choosing-an-offshore-jurisdiction) هو نقطة البداية.





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

## أسئلة شائعة حول ترحيل المواقع إلى استضافة أوفشور





### 01
كم من التوقف يجب أن أتوقعه فعلياً؟



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





### 02
كم يستغرق انتشار DNS؟



لا يوجد "انتشار" أصلاً — هذه الكلمة تصف شيئاً لا يحدث فعلياً. المُحلِّلات تخزّن سجلك مؤقتاً فقط للمدة التي حددها TTL، ثم تسأل من جديد عندما تنتهي صلاحيته. إذا كان TTL الفعّال 86400، فسيستمر بعض المُحلِّلات في تقديم IP القديم لـ24 ساعة إضافية. اخفض TTL إلى 300 ثانية قبل التحويل بفترة كاملة على الأقل تعادل TTL القديم، وسيتبع الإنترنت كله تغييرك خلال خمس دقائق.





### 03
هل يجب أن أنقل نطاقي أيضاً؟



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





### 04
هل يمكنني الترحيل دون أن يعرف المزوّد القديم إلى أين انتقلت؟



ليس إذا نسخت مباشرة بين الآلتين — فأحد الطرفين يتصل بالآخر، وتُسجَّل العملية في سجلات الوصول لكليهما. إذا كان هذا الرابط مهماً فعلاً لنموذج التهديد لديك، فلا تنسخ مباشرة بين السيرفرين إطلاقاً: استعِد السيرفر الجديد من نسختك الاحتياطية المشفّرة خارج الموقع، بحيث لا يتبادل المزوّدان أي حزمة بيانات أبداً. وفي كل الأحوال، لا تبدأ النقل أبداً من اتصال يكشف هويتك، وأبقِ وجهتك الجديدة بعيدة عن أي تذكرة دعم تفتحها مع المزوّد القديم.





### 05
هل يجب أن أحدّث نظام التشغيل أو الحزمة البرمجية في الوقت نفسه؟



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





### 06
هل سيضر الترحيل بترتيبي في نتائج البحث؟



ليس بشكل ملموس، طالما بقي النطاق وعناوين URL والمحتوى كما هي — فمحرك بحث Google يفهرس عناوين URL لا عناوين IP، وتغيير المزوّد وحده ليس إشارة ترتيب. حافظ على بنية URL كما هي، وأعِد رموز الحالة نفسها، ولا تجمع بين الانتقال وإعادة تصميم الموقع أو تغيير نظام العناوين. أما إذا كنت تنتقل إلى نطاق جديد بدلاً من ذلك، فتوقّع انخفاضاً مؤقتاً حتى مع إعادة توجيه 301 صحيحة، وافهم أن عمليات إعادة التوجيه هذه تربط الاسمين علنياً أيضاً.





### 07
هل أحتاج إلى إعادة إصدار شهادات TLS؟



نعم — يحتاج السيرفر الجديد شهادته الخاصة ومفتاحه الخاص، ونقل المفتاح القديم كما هو عادة سيئة حتى عندما يعمل تقنياً. أصدرها قبل التحويل باستخدام تحدّي DNS-01 الذي يتحقق عبر سجل TXT وبالتالي ينجح بينما ما زال سجل A يشير إلى السيرفر القديم. انتظار HTTP-01 بعد تغيير DNS يضمن فترة من تحذيرات الشهادة في النافذة نفسها التي كنت تحاول حمايتها.





### 08
متى يكون إلغاء السيرفر القديم آمناً؟



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




أدلة ذات صلة

## واصل القراءة


[### كيف تختار الولاية القضائية للاستضافة الخارجية في 2026

الشراء


إطار قرار عملي لاختيار ولاية قضائية خارجية: قوانين الاحتفاظ بالبيانات، والتعرض لـ MLAT، وموقف DMCA، وسرعة المحاكم والتطبيق الفعلي — دولة بدولة.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/choosing-an-offshore-jurisdiction)
[### VPS مقابل الخادم المخصص لأعباء العمل الحساسة للخصوصية

الشراء


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/vps-vs-dedicated-for-privacy)
[### VPN ذاتي الاستضافة على VPS بدون KYC: WireGuard مقابل OpenVPN

التشغيل


لماذا يتفوق VPN ذاتي الاستضافة على المزودين التجاريين، وكيف يقارن WireGuard وOpenVPN فعلاً من حيث الخصوصية والأداء والمخاطر التشغيلية في 2026.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 مقابل H100 SXM5 للاستدلال على AI (وأين يقع RTX 5090)

الشراء


دليل قرار الشراء: أي GPU من NVIDIA لأعباء عمل LLM الذاتية الاستضافة والصور والفيديو والصوت والضبط الدقيق في 2026. RTX 4090 مقابل RTX 5090 مقابل H100 SXM5 مقابل H100 مزدوج — VRAM والإنتاجية و$/رمز ومتى يتفوق كل منها.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/rtx-4090-vs-h100-for-ai-inference)
[### Windows RDP خارجي لتداول MT4 / MT5 / cTrader في سوق الفوركس

التشغيل


دليل شامل: لماذا Windows RDP لتداول الفوركس، كيفية اختيار ولاية قضائية خارجية منخفضة الزمن، إعداد MT4 / MT5 / cTrader / Expert Advisor، الزمن إلى خوادم الوسيط، ومسار الدفع بلا KYC.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/offshore-windows-rdp-for-forex-trading)
[### استضافة متجاهِلة DMCA: ما الذي تعنيه فعلاً في 2026

الشراء


ما الذي تمنحك إياه استضافة «DMCA متجاهَل» فعلياً، والدول التي تُسندها حقاً، وأحمال العمل التي تحتاج إليها، وفخاخ حقوق النشر التي لا يشملها هذا المصطلح.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/dmca-ignored-hosting-explained)
[### تسجيل نطاق مجهول الهوية بالعملات المشفّرة: خصوصية WHOIS في 2026

الخصوصية


دليل عملي لعام 2026 لتسجيل النطاقات دون الكشف عن هويتك: أنظمة WHOIS حسب نوع النطاق، واختيار المسجّل، وخيارات الدفع بالعملات المشفّرة، والأخطاء التشغيلية التي تُسرّب هويتك على أي حال.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/anonymous-domain-registration-with-crypto)
[### مدفوعات العملات المشفرة للاستضافة: Monero مقابل Bitcoin مقابل USDT

الخصوصية


كيف يؤثر اختيار عملة الدفع على ما يعلمه مضيفك عنك. الخصوصية والرسوم والنهائية والتعرض لتحليل السلاسل لـ XMR وBTC وUSBT — مع توصية واضحة.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### هل الاستضافة الأوفشور مجهولة الهوية حقًا؟ إجابة صادقة

الخصوصية


الاستضافة الأوفشور بدون KYC تزيل الهوية التي يجمعها المستضيف العادي — لكن «المجهولية» تتوقف على طريقة الدفع وسجلات المزوّد وأمنك العملياتي (opsec). إليك ما يمكن تتبعه فعلًا.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/is-offshore-hosting-truly-anonymous)
[### الساعة الأولى من تحصين VPS: قائمة تحقق

التشغيل


قائمة تحقق ملموسة ومرتبة لتأمين VPS جديد في أقل من ساعة: مفاتيح SSH، وجدار حماية، و fail2ban، وتحديثات تلقائية، وتقليص سطح الهجوم الذي يوقف معظم الهجمات الانتهازية.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/first-hour-vps-hardening-checklist)
[### ما هو الاستضافة بدون KYC؟ التعريف، الشرعية، وآلية العمل

الخصوصية


تتيح الاستضافة بدون KYC استئجار خادم دون أي التحقق من الهوية — لا اسم، ولا بريد إلكتروني، ولا وثيقة هوية. إليك ما يعنيه ذلك بالضبط، وكيف يعمل تقنياً، وهل هو قانوني، وكيف تختار مزوداً حقيقياً.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/what-is-no-kyc-hosting)
[### هل الاستضافة الخارجية قانونية؟ الجواب الصريح لعام 2026

الشراء


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/is-offshore-hosting-legal)
[### كيفية الدفع مقابل الاستضافة بـ Monero (XMR) — خطوة بخطوة

الخصوصية


دليل تفصيلي للدفع مقابل VPS أو خادم مخصص باستخدام Monero (XMR): لماذا يُعدّ XMR الخيار الأكثر خصوصية، وكيفية الحصول عليه، وآلية عمل خطوات الدفع — من الفاتورة إلى تشغيل الخادم في دقائق.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/how-to-pay-for-hosting-with-monero)
[### كيفية استضافة موقع ويب بشكل مجهول — دليل عملي لعام 2026

الخصوصية


دليل عملي متعدد الطبقات لاستضافة موقع ويب دون ربطه بأي هوية: الحساب والدفع والنطاق والولاية القضائية واتصالك والمحتوى — كل طبقة مشروحة بالتفصيل.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/how-to-host-a-website-anonymously)
[### كيفية إعداد WireGuard VPN على VPS — دليل خطوة بخطوة

التشغيل


أنشئ VPN خاصًا بك على VPS باستخدام WireGuard: لماذا يتفوق VPN المستضاف ذاتيًا على النظيرات التجارية، والإعداد الكامل من التثبيت حتى الاتصال بالعميل، وكيفية تعزيز الأمان.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### كيفية استضافة LLM ذاتيًا على خادم GPU — دليل 2026

التشغيل


شغِّل نموذج اللغة الكبير الخاص بك على خادم GPU مستأجر: لماذا تتفوق الاستضافة الذاتية على API، وكيف تختار GPU والنموذج المناسبين، وطريقة الإعداد باستخدام Ollama أو vLLM، وتفاصيل التكلفة.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/self-host-an-llm-on-a-gpu-server)
[### الاستضافة المنيعة مقابل الاستضافة الخارجية — ما الفرق بينهما؟

الشراء


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/bulletproof-vs-offshore-hosting)
[### كيفية شراء VPS بواسطة Bitcoin — دليل خطوة بخطوة (2026)

الشراء


دليل شامل للمبتدئين حول شراء VPS باستخدام Bitcoin: الحصول على BTC، واختيار الخطة المناسبة، وسداد الفاتورة، وما ستحصل عليه — خادم جاهز للعمل دون بطاقة ائتمان ودون ربطه بأي اسم.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/how-to-buy-a-vps-with-bitcoin)
[### أفضل الدول لاستضافة الخوادم المتجاهلة لـ DMCA في عام 2026

الشراء


أين تستضيف خوادمك حين تريد الابتعاد عن طائلة إجراءات الإزالة الأمريكية الأسلوب: الولايات القضائية الفعّالة، ومعنى DMCA-ignored حقًا، وكيف تختار.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/best-countries-for-dmca-ignored-hosting)
[### كيفية استضافة خدمة Tor المخفية (موقع .onion) — دليل 2026

التشغيل


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/how-to-host-a-tor-hidden-service)
[### إعداد خادم بريد إلكتروني خارج الحدود — استضافة بريدك الخاص في 2026

التشغيل


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/offshore-mail-server-setup)
[### دليل استضافة عقد العملات المشفرة — تشغيل عقدة بلوكتشين على VPS

التشغيل


كيفية استضافة عقدة بلوكتشين على خادم: لماذا تشغّل عقدتك الخاصة، وكيف تحدد مواصفات الخادم لـ Bitcoin وEthereum وMonero وغيرها، وخطوات الإعداد، وطرق الحفاظ على الخصوصية.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/crypto-node-hosting-guide)
[### استضافة GPU لـ Stable Diffusion — شغّل خادم الصور الخاص بك

التشغيل


شغّل Stable Diffusion على خادم GPU خاص بك: لماذا تستضيف توليد الصور بنفسك، وكيف تختار GPU المناسب، وكيفية الإعداد باستخدام واجهة ويب، وتكلفة ذلك مقارنةً بالخدمات المُدارة.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/gpu-hosting-for-stable-diffusion)
[### OpSec للخادم — الحفاظ على الهوية المجهولة عند تشغيل خادم

الخصوصية


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


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/server-opsec-staying-anonymous)
[### دليل إعداد صندوق البذر — ابنِ صندوق بذرك الخاص في 2026

التشغيل


كيف تبني صندوق بذرك الخاص على خادم: ما هو صندوق البذر، وكيف تُحدّد مواصفاته، وكيف تثبّت عميل تورنت بواجهة ويب، وكيف تحافظ على خصوصيته وأمانه.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/seedbox-setup-guide)
[### كيفية تجاوز رقابة DPI باستخدام خادم VPS خاص بك (دليل 2026)

الخصوصية


توقّف VPN الخاص بك عن العمل؟ كيفية تجاوز رقابة DPI باستخدام خادم VPS خاص بك: ما الذي يكشفه الفحص العميق للحزم فعليًا، وأي من البروتوكولات الخمسة لعام 2026 يتغلب على أي نوع من الحجب، بالإضافة إلى شرح كامل لإعداد VLESS+REALITY.


أسئلة شائعة (6 سؤال)](https://servhidden.com/ar/guides/bypass-dpi-censorship-with-your-own-vps)
[### تشفير القرص الكامل على VPS: إعداد LUKS وما يحميه فعليًا

التشغيل


كيفية تشفير VPS باستخدام LUKS: وحدات بيانات مشفّرة، وتشفير كامل للجذر مع فتح عن بُعد عبر SSH، والإعدادات المهمة على خادم صغير، وتقييم صادق لما يوقفه تشفير القرص فعليًا.


أسئلة شائعة (8 سؤال)](https://servhidden.com/ar/guides/full-disk-encryption-on-a-vps)
[### إخفاء عنوان IP الأصلي للخادم: CDN والبروكسي العكسي وما الذي يبقى مكشوفًا

الخصوصية


هل تضع CDN أمام خادمك الخارجي (offshore)؟ ما الذي يُخفيه، ومكتب الشكاوى الذي ترثه معه، والطرق الست التي يتسرب بها عنوان IP الأصلي رغم ذلك، وكيف تُدقق في وضع خادمك أنت.


أسئلة شائعة (8 سؤال)](https://servhidden.com/ar/guides/hiding-your-origin-server-ip)
[### استراتيجية نسخ احتياطي VPS: مشفّر، خارج الموقع، وقابل للاستعادة فعلاً

التشغيل


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


أسئلة شائعة (8 سؤال)](https://servhidden.com/ar/guides/vps-backup-strategy)
[### استضافة Matrix ذاتيًا: الفيدرالية وما لا يخفيه التشفير التام

التشغيل


ما الذي يمنحك خادم Matrix الذاتي فعليًا: المقارنة بين Synapse وConduit، وserver_name الذي لا يُغيَّر أبدًا، ووسائط تلتهم القرص، وما تكشفه الفيدرالية رغم التشفير التام.


أسئلة شائعة (8 سؤال)](https://servhidden.com/ar/guides/self-host-a-matrix-server)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

التشغيل


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


أسئلة شائعة (8 سؤال)](https://servhidden.com/ar/guides/self-host-a-crypto-payment-gateway)




## امنح ترحيلك مكاناً يحطّ فيه



سيرفرات KVM أوفشور في سبع ولايات قضائية بدءاً من 7.50$ شهرياً، بصلاحيات root كاملة، وتخزين NVMe، ونطاق ترددي غير محدود، تُنشَر خلال أقل من خمس دقائق فور تأكيد الدفع بالعملات الرقمية. جهّز الوجهة مبكراً، وانسخ بالوتيرة التي تناسبك، وحوّل عندما تكون جاهزة.


[عرض خطط VPS](https://servhidden.com/ar/vps)
[استضافة خارجية](https://servhidden.com/ar/offshore-hosting)
[جميع المواقع](https://servhidden.com/ar/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "خوادم VPS ومخصصة خارجية في 7 ولايات قضائية خارجية. بدون KYC، بدون سجلات، عملات رقمية فقط. الخصوصية بالتصميم.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "كيفية ترحيل موقع إلى استضافة أوفشور دون توقف",
    "description": "الترتيب الذي يجعل ترحيل السيرفر أمراً روتينياً بلا مفاجآت: خفض TTL الخاص بـDNS قبل أيام، تشغيل السيرفرين معاً بالتوازي، تجميد الكتابة لدقائق لا لساعات — وتنظيف أثر Passive DNS وCertificate Transparency وWHOIS الذي يخلّفه الانتقال وراءه.",
    "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-29T00:00:00+00:00",
    "dateModified": "2026-08-29T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting",
    "inLanguage": "ar",
    "keywords": "ترحيل موقع إلى استضافة أوفشور, تغيير مزود الاستضافة بدون توقف, نقل VPS إلى سيرفر جديد, ترحيل موقع ووردبريس بدون توقف, تخفيض TTL قبل تغيير DNS, الانتقال إلى استضافة بلا KYC, خطوات ترحيل سيرفر خطوة بخطوة, نقل بيانات السيرفر باستخدام rsync",
    "articleSection": "التشغيل",
    "wordCount": 2806
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "كم من التوقف يجب أن أتوقعه فعلياً؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "بالنسبة لموقع ثابت، لا شيء إطلاقاً — يستطيع السيرفران تقديم المحتوى نفسه في آن واحد، فيصبح تغيير DNS غير محسوس. أما أي شيء يحتوي قاعدة بيانات، فتوقفك هو بالضبط طول تجميد الكتابة لديك، وهو عادة بين دقيقتين وعشر دقائق إذا كنت قد شغّلت نسخاً كاملاً للبيانات مسبقاً. الرقم المهم ليس سرعة انتقال DNS؛ بل حجم ما تنسخه أثناء النافذة الزمنية. انسخ كل شيء تقريباً قبل أيام فتتقلص النافذة إلى حجم الفارق فقط."
            }
        },
        {
            "@type": "Question",
            "name": "كم يستغرق انتشار DNS؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "لا يوجد \"انتشار\" أصلاً — هذه الكلمة تصف شيئاً لا يحدث فعلياً. المُحلِّلات تخزّن سجلك مؤقتاً فقط للمدة التي حددها TTL، ثم تسأل من جديد عندما تنتهي صلاحيته. إذا كان TTL الفعّال 86400، فسيستمر بعض المُحلِّلات في تقديم IP القديم لـ24 ساعة إضافية. اخفض TTL إلى 300 ثانية قبل التحويل بفترة كاملة على الأقل تعادل TTL القديم، وسيتبع الإنترنت كله تغييرك خلال خمس دقائق."
            }
        },
        {
            "@type": "Question",
            "name": "هل يجب أن أنقل نطاقي أيضاً؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "لا. المسجّل والمزوّد مستقلان تماماً عن بعضهما، ونقل الموقع مع ترك النطاق كما هو تماماً يعمل بلا أي مشكلة. أما إن كان عليك نقله فهذا يعتمد على سبب ترحيلك: إن كان السبب الولاية القضائية أو السعر أو موقف DMCA، فاترك النطاق كما هو. أما إن كان السبب إخفاء الهوية، فلاحظ أن للنطاق تاريخه المنفصل الخاص به — أرشيفات WHOIS تحتفظ بأي تفاصيل سُجّل بها أول مرة، وتغيير الاستضافة لا يمسّ ذلك إطلاقاً."
            }
        },
        {
            "@type": "Question",
            "name": "هل يمكنني الترحيل دون أن يعرف المزوّد القديم إلى أين انتقلت؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "ليس إذا نسخت مباشرة بين الآلتين — فأحد الطرفين يتصل بالآخر، وتُسجَّل العملية في سجلات الوصول لكليهما. إذا كان هذا الرابط مهماً فعلاً لنموذج التهديد لديك، فلا تنسخ مباشرة بين السيرفرين إطلاقاً: استعِد السيرفر الجديد من نسختك الاحتياطية المشفّرة خارج الموقع، بحيث لا يتبادل المزوّدان أي حزمة بيانات أبداً. وفي كل الأحوال، لا تبدأ النقل أبداً من اتصال يكشف هويتك، وأبقِ وجهتك الجديدة بعيدة عن أي تذكرة دعم تفتحها مع المزوّد القديم."
            }
        },
        {
            "@type": "Question",
            "name": "هل يجب أن أحدّث نظام التشغيل أو الحزمة البرمجية في الوقت نفسه؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "لا، وهذا هو الفشل الأكثر شيوعاً الذي يتسبب به الناس لأنفسهم أثناء الترحيل. غيّر شيئاً واحداً فقط. إن أساء الموقع التصرف بعد التحويل، فأنت تريد تفسيراً محتملاً واحداً، لا اختياراً بين الآلة الجديدة وإصدار PHP الجديد وإصدار قاعدة البيانات الجديد. طابِق البيئة القديمة إصداراً بإصدار، أكمل الانتقال، تأكّد من أسبوع من سجلات نظيفة، ثم حدّث بشكل منفصل مع الاحتفاظ بالقدرة على التراجع."
            }
        },
        {
            "@type": "Question",
            "name": "هل سيضر الترحيل بترتيبي في نتائج البحث؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "ليس بشكل ملموس، طالما بقي النطاق وعناوين URL والمحتوى كما هي — فمحرك بحث Google يفهرس عناوين URL لا عناوين IP، وتغيير المزوّد وحده ليس إشارة ترتيب. حافظ على بنية URL كما هي، وأعِد رموز الحالة نفسها، ولا تجمع بين الانتقال وإعادة تصميم الموقع أو تغيير نظام العناوين. أما إذا كنت تنتقل إلى نطاق جديد بدلاً من ذلك، فتوقّع انخفاضاً مؤقتاً حتى مع إعادة توجيه 301 صحيحة، وافهم أن عمليات إعادة التوجيه هذه تربط الاسمين علنياً أيضاً."
            }
        },
        {
            "@type": "Question",
            "name": "هل أحتاج إلى إعادة إصدار شهادات TLS؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "نعم — يحتاج السيرفر الجديد شهادته الخاصة ومفتاحه الخاص، ونقل المفتاح القديم كما هو عادة سيئة حتى عندما يعمل تقنياً. أصدرها قبل التحويل باستخدام تحدّي DNS-01 الذي يتحقق عبر سجل TXT وبالتالي ينجح بينما ما زال سجل A يشير إلى السيرفر القديم. انتظار HTTP-01 بعد تغيير DNS يضمن فترة من تحذيرات الشهادة في النافذة نفسها التي كنت تحاول حمايتها."
            }
        },
        {
            "@type": "Question",
            "name": "متى يكون إلغاء السيرفر القديم آمناً؟",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "بعد أسبوع أو أسبوعين من سجلات هادئة على الآلة القديمة وسجلات نظيفة على الجديدة — فالتأخير هو خطة تراجعك، وثمنه بضعة دولارات فقط. قبل الإلغاء، تحقّق من ألا شيء خارجي ما زال يشير إلى IP القديم، ودوّر كل سر عاش يوماً عليه، ثم احذف بياناتك واكتب فوق المساحة الحرة. ألغِ في النهاية. الضغط على \"إنهاء\" أولاً يترك قاعدة بياناتك على قرص لم تعد تتحكم به."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "الرئيسية",
            "item": "https://servhidden.com/ar/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "أدلة الاستضافة الخاصة",
            "item": "https://servhidden.com/ar/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "كيفية ترحيل موقع إلى استضافة أوفشور دون توقف",
            "item": "https://servhidden.com/ar/guides/migrate-website-to-offshore-hosting"
        }
    ]
}
```