WSL أم VPS للتطوير؟ مقارنة التوافر وSSH والملفات

هل تستخدم WSL أم VPS للتطوير؟

يعتمد الاختيار بين WSL وVPS للتطوير على خاصية واحدة: التوافر. يعمل WSL (Windows Subsystem for Linux) على تشغيل Ubuntu داخل آلة افتراضية ترتبط جلسة تشغيلها بجلسة Windows لديك، وتتوقف عند انتهائها. أما VPS (الخادم الافتراضي الخاص)، فيشغّل Ubuntu نفسه على عنوان IP عام يظل متاحاً أثناء إغلاق حاسوبك المحمول. ينتهي الأمر بمعظم المطورين إلى استخدام الخيارين معاً، بحيث يكون الخادم هو الجهاز الذي يظل قابلاً للوصول.

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

لماذا تتوقف WSL عند إغلاق الحاسوب المحمول؟

تشغّل WSL 2 نواة Linux فعلية داخل آلة افتراضية خفيفة تبدأها Windows عند الطلب. لا تبقى هذه الآلة الافتراضية قيد التشغيل إلا عند تشغيل توزيعة، ولا تبقى التوزيعة قيد التشغيل إلا أثناء استخدام شيء لها. تحقّق من الحالة من PowerShell:

wsl --version
wsl --list --running

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

تؤدي وضعيّتا السكون والإسبات إلى إيقاف الآلة الافتراضية أيضاً. لا يعمل مؤقّت مضبوط لتفريغ قاعدة بيانات عند الساعة 03:00 أثناء إغلاق الغطاء، لأن النواة التي يفترض أن تنفّذ المهمة لا تكون قيد التشغيل. لا يسجّل أي مكوّن خطأ، لذلك تبدو المهمة وكأنها لم تُجدول قط. هذا السلوك وحده يدفع الناس إلى استخدام جهاز ثانٍ: إذ تحتاج قائمة انتظار البناء، أو روبوت الدردشة، أو النسخة الاحتياطية الليلية، أو مستقبِل webhook إلى حاسوب يظل قيد التشغيل.

هل يعمل systemd في WSL؟

نعم. أُضيف الدعم في WSL 0.67.6، ويكون معطّلاً افتراضياً في التثبيتات الأقدم. بدونه، يعرض systemctl status ssh ما يلي:

System has not been booted with systemd as init system (PID 1). Can't operate.

اقرأ ملف الإعداد أولاً، فقد يكون لديك ملف موجود مسبقاً. إذا لم يتضمن قسم [boot]، فأضف قسماً جديداً؛ وإذا كان يتضمنه، فأضف السطر الوحيد داخل القسم الموجود.

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

شغّل wsl --shutdown في PowerShell، وافتح جلسة Ubuntu جديدة، ثم تحقّق باستخدام systemctl list-units --type=service --state=running. ظهور قائمة بالوحدات يعني أن systemd هو PID 1، وأن journalctl -b يعمل بعد ذلك.

المشكلة تتعلق بما يضمنه enable على كل جهاز. في VPS، يعني sudo systemctl enable --now caddy أن الخدمة تبدأ عند الإقلاع، لذلك تعود للعمل بعد إعادة التشغيل أو ترقية النواة حتى إذا لم يسجّل أي مستخدم الدخول. أما في WSL، فيعني أن الخدمة تبدأ عند بدء التوزيعة، وتبدأ التوزيعة عند فتحك طرفية. لذلك لا تعمل الخدمة إلا أثناء استخدامك للنظام، وهذا يعاكس سبب وجود الخدمات. ترث الحاويات الفجوة نفسها، ولذلك يعتمد تشغيل خدمات Docker Compose عند الإقلاع على إقلاع لا ينفّذه WSL إلا عندما تطلبه.

هل يمكن لـ webhook الوصول إلى خادم يعمل داخل WSL؟

ليس من دون إعداد إضافي، والسبب هو تخطيط الشبكة. في الوضع الافتراضي، يضع WSL 2 الآلة الافتراضية خلف NAT (ترجمة عناوين الشبكة) على محول شبكة افتراضي خاص بها. اعرض العنوان:

ip -4 addr show eth0
ip route show default

هذا العنوان خاص، ويُسنَد من جديد في كل مرة تبدأ فيها الآلة الافتراضية، لذلك يتغير. يمكن لـ Windows نفسه الوصول إلى localhost:3000، لأن WSL يمرّر اتصالات localhost إلى التوزيعة. لكن لا يمكن لآلة أخرى على شبكتك الوصول إليه، إلا إذا أضفت قاعدة proxy من PowerShell بصلاحيات Administrator:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

تحدد هذه القاعدة عنواناً واحداً، لذلك تتعطل في المرة التالية التي يتغير فيها العنوان. يُعد وضع Mirrored Networking الخيار الأفضل: إذ تحصل التوزيعة على واجهات الشبكة والعناوين نفسها التي يستخدمها Windows. اعتباراً من August 2026، يتطلب هذا Windows 11 22H2 أو إصداراً أحدث. أضف ما يلي إلى %UserProfile%\.wslconfig ثم شغّل wsl --shutdown:

[wsl2]
networkingMode=mirrored

يحل وضع Mirrored مشكلة الشبكة المحلية. لكنه لا يمنحك عنواناً عاماً. يعيد جهاز التوجيه استخدام NAT، ولا تتيح معظم الاتصالات المنزلية منفذاً وارداً يمكنك التحكم فيه، كما تضيف كثير من شركات ISP طبقة أخرى من NAT فوق ذلك. لذلك لا يستطيع GitHub إرسال حدث POST إلى حاسوبك المحمول، ولا يستطيع زميلك فتح رابط العرض التجريبي. يمكن لخدمة tunnel تجاوز ذلك، لكن عميل الـtunnel يعمل على الحاسوب المحمول، ما يعني أن الحاسوب المحمول يظل الجهاز الذي يجب أن يبقى قيد التشغيل.

يبدأ VPS من الجانب الآخر لهذه المشكلة. فهو يملك عنوان IPv4 عاماً، وعادةً عنوان IPv6 عاماً، مع المنافذ التي تفتحها فقط. وجّه سجل A إليه، واسمح بالمنفذين 80 و443، وسيستجيب من أي مكان. وهذا شرط الحصول على شهادة عامة أيضاً، لأن تحدي HTTP-01 يطلب من Let's Encrypt جلب ملف عبر المنفذ 80 باستخدام الاسم العام. يُعد الحصول على شهادة Let's Encrypt باستخدام Certbot وnginx مهمة تستغرق خمس دقائق على خادم، لكنها مستحيلة في WSL. وللعمل المحلي، لا يزال بإمكانك الحصول على HTTPS موثوق به من المتصفح داخل WSL عبر إضافة CA الخاص بك إلى مخزن الثقة في Ubuntu.

لماذا يكون git بطيئاً في /mnt/c؟

لأن الملفات ليست موجودة على نظام ملفات Linux. يوفّر لك WSL منطقتي تخزين بتكاليف مختلفة جداً. يوجد مجلد home الخاص بك على نظام ملفات ext4 داخل قرص افتراضي، ويعمل مثل أي قرص Linux عادي. أما /mnt/c فهو محرك Windows، وتخدمه عملية على جانب Windows عبر بروتوكول 9P (بروتوكول نظام ملفات Plan 9)، لذلك يعبر كل استدعاء open وكل استدعاء stat هذه الحدود.

ملف واحد لا يسبب مشكلة. لكن git status في مستودع كبير ينفّذ آلاف الاستدعاءات إلى stat، ويدفع كل استدعاء تكلفة العبور. قِس الأداء بدلاً من الاعتماد على رقم يقدّمه أي شخص، بما في ذلك هذه الصفحة:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

شغّل كل أمر مرتين، ثم قارن نتائج التشغيل الثاني، حتى تكون ذاكرة التخزين المؤقت دافئة في الحالتين. تضيف برامج مكافحة الفيروسات الفورية في Windows تكلفة أخرى على جانب /mnt/c، ولذلك قد يبدو المستودع نفسه أبطأ على حاسوب محمول تابع للشركة منه على حاسوب شخصي.

الحل داخل WSL هو إبقاء نسخة العمل ضمن ~ وفتحها باستخدام وضع WSL البعيد في محرر النصوص، إذ يشغّل هذا الوضع خادم المحرر داخل التوزيعة بدلاً من عبور الحدود. يظل بإمكان Explorer تصفح هذه الملفات عبر \\wsl.localhost\Ubuntu\home\you. لا تواجه VPS هذه المشكلة، لأن هناك نظام ملفات واحداً وهو Linux. لكنك تدفع هناك تكلفة زمن تأخر الشبكة أثناء التحرير، لذلك يعمل المستخدمون داخل terminal multiplexer أو جلسة محرر بعيدة. أما القيد الفعلي على خادم صغير فهو مشاركة CPU، ويظهر وقت المعالجة الذي يسرقه جار صاخب في top باعتباره عمود st.

متى يتفوّق WSL بوضوح

• إنه مجاني وموجود على الجهاز مسبقاً. فعِّله، وثبّت Ubuntu، وابدأ العمل خلال دقيقة، من دون دفع أي تكلفة ومن دون سطح عام يجب تأمينه.
• يمكن التخلص منه بسهولة، بخلاف الخادم. يكتب wsl --export Ubuntu D:\wsl-backups\ubuntu.tar التوزيعة كاملة في ملف واحد، ويستعيدها wsl --import أو يستنسخها باسم ثانٍ. تجربة إصدار Ubuntu جديد هنا تعني إنشاء نسخة واستعادة الحالة السابقة، بينما ترقية VPS من 24.04 إلى 26.04 خطوة باتجاه واحد يجب جدولتُها بما يتناسب مع الخدمات التي تعمل عليه مسبقاً.
• العمل على GPU مباشر. مع برنامج تشغيل GPU حديث في Windows، تصبح البطاقة متاحة داخل التوزيعة، لذلك تعمل أحمال CUDA وROCm على العتاد الذي تملكه مسبقاً. أما استئجار GPU من الفئة نفسها بالساعة فيكلف مالاً فعلياً.
• دورة التحرير أقصر. ملفاتك ومتصفحك محليان معاً، لذلك يفتح خادم التطوير على localhost:5173 في المتصفح الذي سجّلت الدخول إليه مسبقاً.

هذه مزايا فعلية، ولذلك تكون الإجابة المعتادة هي استخدام الجهازين معاً بدلاً من الاكتفاء بأحدهما.

من المسؤول عن النسخ الاحتياطية؟

أنت المسؤول في الحالتين، وتحديداً في WSL تظهر مفاجأة لكثير من المستخدمين. التوزيعة عبارة عن ملف قرص افتراضي (ext4.vhdx) داخل ملف تعريف مستخدم Windows. لا ينشئ أي مزود لقطة له تلقائياً. يحذفه wsl --unregister Ubuntu نهائياً دون إمكانية التراجع، كما أن إعادة تثبيت Windows تحذفه مع كل شيء آخر. صدّره وفق جدول زمني يمكنك الالتزام به فعلاً:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

في VPS تحميك لقطة المزود من تعطل المضيف. لكنها لا تحميك من rm -rf في الدليل الخطأ، كما أن الاحتفاظ باللقطة في الحساب نفسه الذي يوجد فيه الخادم يعني أن سرقة بيانات تسجيل دخول واحدة تكفي لفقدانها مع الخادم. ادفع النسخ الاحتياطية على مستوى الملفات إلى خارج الخادم، واستعد نسخة منها قبل أن تحتاج إليها. تقع المسؤولية عليك في الحالتين. والفرق العملي هو أن الخادم يستطيع إرسال نسخته الاحتياطية بنفسه عند الساعة 03:00 من دون أن يطلب من أي شخص إبقاء حاسوب محمول قيد التشغيل.

الجسر: الاتصال عبر SSH من WSL إلى VPS

لا يصبح استخدام جهاز ثانٍ عبئاً إلا قبل إعداد الاتصال بطريقة صحيحة. نفّذ ذلك مرة واحدة داخل WSL.

أنشئ المفتاح داخل التوزيعة بدلاً من إنشائه على جانب Windows، حتى يبقى المفتاح الخاص على نظام ملفات ext4 مع أذونات Unix التي يقبلها ssh:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

تكون مفاتيح Ed25519 قصيرة وسريعة، ويضيف ssh-copy-id المفتاح العام إلى ~/.ssh/authorized_keys على الخادم مع الأوضاع الصحيحة. يشرح أساسيات إدارة مفاتيح SSH كيفية تدويرها وإبطالها لاحقاً.

امنح الخادم اسماً في ~/.ssh/config:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

يتصل ssh dev الآن. يمنع IdentitiesOnly yes العميل من عرض كل مفتاح يحتفظ به، وهذا ما يسبب Too many authentication failures عندما يكون لدى agent عدة مفاتيح محمّلة. يحافظ ServerAliveInterval 30 على استمرار الجلسة عبر اتصال منزلي من دون انقطاعها بصمت.

يمثل ForwardAgent yes السطر الذي يجعل سير العمل سهلاً. عند تحميل مفتاحك في agent على الحاسوب المحمول، يعمل git clone git@github.com:you/app.git على الخادم من دون نقل مفتاح خاص إليه مطلقاً. اختبر ذلك باستخدام ssh -T git@github.com من VPS، وينبغي أن يجيب بـ Hi you! You've successfully authenticated. لا تمرّر agent إلا إلى الخوادم التي تثق بها، لأن root على ذلك الجهاز يستطيع استخدام مقبس agent أثناء اتصالك. على خادم تشاركه مع أشخاص آخرين، يكون مفتاح النشر الخاص بكل مستودع خياراً أكثر أماناً.

لا يحافظ WSL على agent قيد التشغيل بين الصدَفات، لذلك يطلب كل طرفية جديدة المفتاح مرة أخرى. يحل keychain هذه المشكلة:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

افتح صدفة جديدة وشغّل ssh-add -l. ينبغي أن يطبع بصمة المفتاح. يعني Error connecting to agent بدلاً من ذلك أن السطر لا تتم قراءته، لذا تحقق من أن صدفتك تستورد ~/.bashrc فعلياً.

نفّذ العمل على الخادم داخل مُضاعِف طرفية، حتى لا يؤدي انقطاع الاتصال إلى إيقافه:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

يستمر البناء أثناء إغلاقك للحاسوب المحمول، وهذا هو السبب الأساسي لاستخدام الجهاز الثاني. النمط نفسه هو ما يتيح للناس تشغيل Claude Code على VPS داخل tmux واستئناف الجلسة من جهاز آخر.

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

أي جهاز للمهمة المناسبة؟

استخدم WSL عندما يكون العمل أمامك على الشاشة. يشمل ذلك تحرير الملفات، وتشغيل مجموعة الاختبارات، وخادم تطوير على localhost، ودفاتر الملاحظات، وتجارب GPU، وأي مهمة تبدأها ثم تراقبها.

استخدم VPS عندما يجب أن يكون العمل قابلاً للوصول أو أن يستمر بعد انتهاء جلستك. يشمل ذلك عنوان staging يمكن للعميل فتحه، ونقطة نهاية webhook، ومهمة cron تعتمد على ساعة فعلية، وbot، وقاعدة بيانات صغيرة تتصل بها خدمة أخرى، وعملية استيراد تبدأها بعد ظهر يوم الجمعة.

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

تمنعك عادة واحدة من تحويل الجهازين إلى جهازين ناقصي الإعداد: يكون الكود في git، ويكون الجهازان عميلين للمستودع. لا يوجد شيء مهم على أحدهما فقط.

FAQ

هل يمكنني استضافة موقع باستخدام نطاق حقيقي من WSL؟

ليس بشكل موثوق. يعمل WSL 2 خلف NAT داخل جهازك، ويطبّق موجّهك NAT مرة أخرى، كما أن معظم اتصالات المنازل لا توفر منفذاً وارداً يمكنك إعادة توجيهه. يمكن لخدمة tunnel إتاحة منفذ محلي، لكن عميل tunnel يعمل على الحاسوب المحمول، لذلك يتوقف الموقع عندما يدخل الحاسوب في وضع السكون. وتجعل الشهادات الأمر أصعب، لأن تحدي HTTP-01 يتطلب من Let's Encrypt جلب ملف عبر المنفذ 80 باستخدام الاسم العام. يحقق VPS مع عنوان IP عام وسجل A الشرطين من دون حل بديل.

هل يعمل systemctl enable في WSL؟

يعمل بعد تفعيل systemd، وهذا يعني systemd=true ضمن [boot] في /etc/wsl.conf، ثم تنفيذ wsl --shutdown. من دونه، يرد systemctl بالرسالة System has not been booted with systemd as init system (PID 1). Can't operate.. حتى عند تشغيل systemd، يبدأ enable الخدمة عند بدء التوزيعة، وتبدأ التوزيعة عند فتح shell. على الخادم، يعني الأمر نفسه عودة الخدمة بعد إعادة التشغيل من دون تسجيل دخول أي مستخدم.

لماذا يستمر عنوان IP الخاص بـ WSL في التغير؟

في وضع NAT الافتراضي، تحصل الآلة الافتراضية على عنوان خاص جديد من محول WSL الافتراضي عند كل بدء تشغيل. تتوقف أي قاعدة netsh interface portproxy أو عنوان مضمّن في الإعدادات عن العمل بعد wsl --shutdown. تحقّق من العنوان الحالي باستخدام ip -4 addr show eth0. يزيل وضع الشبكات المتطابقة في Windows 11 العنوان المنفصل، إذ يمنح التوزيعة الواجهات نفسها الموجودة في Windows: اضبط networkingMode=mirrored ضمن [wsl2] في %UserProfile%\.wslconfig.

هل /mnt/c أبطأ فعلاً، أم أن ذلك مجرد خرافة؟

إنه أبطأ، ويمكن لدقيقة واحدة من الاختبار إثبات ذلك على جهازك. توجد الملفات ضمن ~ على قرص افتراضي بنظام ext4. أما الملفات ضمن /mnt/c فتُخدَم عبر بروتوكول 9P بواسطة مكوّن يعمل في Windows، لذلك يعبر كل استدعاء stat الحد الفاصل، وتُنفّذ git status آلاف الاستدعاءات منها عند العمل على شجرة كبيرة. انسخ المستودع إلى ~، وشغّل time git status مرتين في كل موقع، ثم قارن نتائج التشغيلات الدافئة. احتفظ بنسخ العمل ضمن ~ واستخدم الوضع البعيد لـ WSL في المحرر.

هل ما زلت بحاجة إلى WSL بعد امتلاكي VPS؟

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