بدأت المشكلة بعد أن انتهى التنزيل، لا قبله. كنت قد حمّلت نسخة Ubuntu 26.04 LTS عبر ملف BitTorrent الرسمي، ثم تركت qBittorrent مفتوحًا كي أشارك الملف بدل أن أغلق البرنامج فور وصوله إلى 100%. Ubuntu بعد ساعة عدت إلى الجهاز فوجدت شيئًا محبطًا: Downloaded: مكتمل. Uploaded: بالكاد تحرك. افترضت أن إعدادات qBittorrent هي السبب. رفعت حدود الرفع، أعدت تشغيل البرنامج، ثم راقبت عدد الـPeers. قليل من النشاط، ثم صمت. عندها بدأت أبحث عن أفضل VPN للتورنت مع Port Forwarding وأنا مقتنع أن المنفذ المفتوح هو القطعة الوحيدة الناقصة. بعد يومين تغير السؤال: لم يعد «هل لدي Port Forwarding؟» بل «هل أستطيع ترك الـtorrent يعمل ساعات من دون أن أعود لإصلاح الاتصال؟»
فكرة Port Forwarding لم تأتِ من فراغ.
qBittorrent يستخدم منفذًا للاتصالات الواردة، ويمكن ضبطه يدويًا أو الاعتماد على UPnP/NAT-PMP عندما تسمح الشبكة بذلك. qBittorrent Wiki فإذا كنت خلف NAT يمنع الاتصالات الواردة، يمكن لمنفذ مفتوح عبر VPN أن يجعل الوصول إليك أسهل.
لهذا تبدو الميزة جذابة جدًا عندما يكون التنزيل مكتملًا بينما الـUpload شبه ساكن.
ملخص المقال والسياق العملي
لماذا كان استمرار الـSeeding أهم من رقم المنفذ؟
وتظهر المشكلة نفسها باختصار في نقاشات مستخدمي qBittorrent خلف CGNAT: بعضهم يلجأ إلى VPN مع Port Forwarding لتحسين قابلية الوصول أثناء الـseeding.
ما الذي يستحق تذكره؟
- لماذا تصبح استمرارية الاتصال أهم من ذروة السرعة في جلسات P2P الطويلة؟ qBittorrent يستخدم منفذًا للاتصالات الواردة، ويمكن ضبطه يدويًا أو الاعتماد على UPnP/NAT-PMP عندما تسمح الشبكة بذلك. qBittorrent Wiki فإذا كنت خلف NAT يمنع الاتصالات الواردة، يمكن لمنفذ مفتوح عبر VPN أن يجعل الوصول إليك أسهل.
- ما الذي يستحق اختباره أولًا قبل تغيير إعدادات التورنت كلها؟ لكنني أردت اختبار السبب الحقيقي الذي جعلني أبحث عن الميزة أصلًا: هل أستطيع ترك qBittorrent يعمل بصورة مفيدة من دون أن أعود إلى إعداداته كلما تغير الاتصال؟
مصدر المنتج: الموقع الرسمي لـ OnlydogVPN
وتظهر المشكلة نفسها باختصار في نقاشات مستخدمي qBittorrent خلف CGNAT: بعضهم يلجأ إلى VPN مع Port Forwarding لتحسين قابلية الوصول أثناء الـseeding. Reddit كنت أفكر بالطريقة نفسها تمامًا.
المزود الأول أعطاني الميزة التي بحثت عنها
بدأت بخدمة VPN كبيرة تدعم Port Forwarding. وهذه نقطة قوة حقيقية لها. شغلت خادم P2P. فعّلت Port Forwarding. ظهر رقم منفذ. فتحت qBittorrent. Tools. Options. Connection. أدخلت الرقم في Port used for incoming connections. ثم عدت إلى الـtorrent. بعد فترة تحرك الرفع بصورة أوضح.
ظهر Peer جديد. ثم آخر. وأخيرًا شعرت أنني أصلحت المشكلة. بدل الاعتماد فقط على الاتصالات التي يبدأها جهازي، أصبح لدي منفذ وارد عبر الـVPN. والخدمة نفسها تشرح رسميًا إدخال المنفذ النشط في qBittorrent بهذه الطريقة. Proton VPN في تلك اللحظة كان حكمي بسيطًا:
هذا بالضبط ما كنت أبحث عنه.
ثم انقطع Wi-Fi.
عند إعادة الاتصال، تغير الشيء الذي ظننته ثابتًا
اتصال البيت عندي يمر أحيانًا بدقائق يصبح فيها Hotspot الهاتف أسرع من انتظار الراوتر. انتقلت إلى بيانات الهاتف. عاد الإنترنت. الـVPN أعاد الاتصال. qBittorrent استأنف عمله. لكن الـUpload أصبح هادئًا مرة أخرى. فتحت تطبيق الـVPN، وهنا لاحظت رقم المنفذ. لم يعد الرقم السابق.
الخدمة توضح أن رقم Port Forwarding قد يتغير عند إعادة اتصال الـVPN، وعندها يجب تحديثه في برنامج التورنت. Proton VPN رجعت إلى qBittorrent. Options. Connection. مسحت الرقم القديم. كتبت الجديد. OK. وبعد فترة عاد الرفع. الميزة كانت تعمل كما يفترض. لكنني اكتشفت أن المنفذ المفتوح أضاف شيئًا آخر إلى يومي: إعدادًا يجب أن يظل متزامنًا مع جلسة الـVPN.
عندها بدأت أقيس النتيجة بدل الإعداد
لو كان عندي Desktop يعمل على Ethernet ثابت طوال الأسبوع، لما أزعجني ذلك كثيرًا. لكن استخدامي مختلف. اللابتوب ينتقل بين Wi-Fi وHotspot. أغلق الغطاء أحيانًا. الشبكة تنقطع. والـVPN يعيد الاتصال. ومع كل تغيير، لم أعد واثقًا أن رقم المنفذ داخل qBittorrent ما زال هو الرقم الصحيح.
فجأة أصبحت أدير الاتصال بدل أن أترك الـtorrent يعمل في الخلفية. وهنا تغير المعيار. بدل أن أسأل: هل Port Forwarding مفعّل؟ بدأت أسأل:
بعد ساعتين من ترك الجهاز وحده، هل ما زال Uploaded يتحرك؟
جربت OnlydogVPN↗ وأنا أعرف أن المقارنة ليست متطابقة
فتحت OnlydogVPN. الخدمة لا تقدم لي Port Forwarding يدويًا بالطريقة نفسها، وهذه محدودية واضحة إذا كنت تحتاج منفذًا واردًا ثابتًا أو قابلًا للضبط. لكنني أردت اختبار السبب الحقيقي الذي جعلني أبحث عن الميزة أصلًا: هل أستطيع ترك qBittorrent يعمل بصورة مفيدة من دون أن أعود إلى إعداداته كلما تغير الاتصال؟
أعدت qBittorrent إلى إعداده العادي. شغلت الاتصال. وتركت Ubuntu في حالة Seeding. لم أراقب Port Checker هذه المرة. راقبت Uploaded. ظهر Peer. ثم آخر. والرفع بدأ يتحرك. بعد ذلك فعلت الشيء الذي عطل التجربة السابقة. انتقلت إلى Hotspot.
هذه المرة لم أفتح Options
توقف النشاط للحظة. ثم عاد الاتصال. عادت الـPeers. وبدأ الرفع يتحرك من جديد. لم يكن لدي رقم منفذ جديد أنسخه من تطبيق الـVPN إلى qBittorrent. ولم أفتح Tools → Options → Connection. تركت الجهاز على Hotspot قليلًا، ثم عدت إلى Wi-Fi عندما استقر. مرة أخرى، تعافى الاتصال واستمر الـseeding.
وهنا أصبحت ميزة الخدمة الأهم واضحة بالنسبة إلي. هي تستخدم نقلًا مبنيًا على HTTP/3 ومصممة للتعافي عندما تضعف الشبكة أو تتغير. بالنسبة إلى torrent أريد تركه ساعات في الخلفية، كانت النتيجة أبسط من شرح البروتوكول:
الشبكة تغيرت، لكنني لم أضطر إلى العودة لإدارة الـVPN أو qBittorrent.
لا أستطيع من اللابتوب رؤية كل قرارات NAT والتوجيه الداخلية بين مزود الإنترنت وشبكة الهاتف وخوادم الـVPN والـPeers، لذلك لا أستطيع تحديد القرار الداخلي المفرد الذي صنع الفرق. لكن عداد Uploaded ظل هو الاختبار الذي يهمني.
هنا فهمت ما الذي يفعله Port Forwarding وما الذي لا يفعله
Port Forwarding يجعل جهازك أكثر قابلية لاستقبال اتصالات واردة. وهذا قد يكون مهمًا جدًا. خصوصًا إذا كنت تستخدم Private Tracker صغيرًا، أو swarm قليل النشاط، أو تحتاج أعلى Connectability ممكنة أثناء الـseeding. لكن ذلك ليس الشيء نفسه مثل ضمان أن جلسة التورنت ستظل بلا إدارة عندما تتغير الشبكة أو يعيد الـVPN الاتصال.
وهذا هو الجزء الذي كنت أخلط بينه في البداية. كنت أرى Upload ضعيفًا. أبحث عن Port Forwarding. أفعل الميزة. ثم أفترض أن كل مشكلة لاحقة في الـseeding قد حُلّت معها. تجربتي لم تكن بهذه البساطة.
الاستخدام الفعلي هو الذي حسم المقارنة
هناك مستخدم يحتاج منفذًا واردًا حقيقيًا. بالنسبة إليه، يجب أن يكون دعم Port Forwarding شرطًا من البداية.
وهذا سبب بقاء الميزة مهمة لدى خدمات توفرها وتشرح استخدامها مع qBittorrent رسميًا. Proton VPN وفي الاتجاه الآخر، أوقفت Mullvad دعم المنافذ المحولة منذ 2023 بعد مشكلات إساءة استخدام أثرت في عناوينها وعلاقاتها مع مزودي الاستضافة. Mullvad
إذن وجود الميزة ليس أمرًا يمكن افتراضه في كل VPN. لكن حالتي كانت مختلفة قليلًا. أنا أستخدم torrents عامة ونشطة، وأريد أن أترك qBittorrent يعمل على لابتوب يتنقل أحيانًا بين شبكتين. بالنسبة إلي، Port Forwarding أعطاني Connectability أفضل، لكنه جعلني أراقب رقمًا آخر أيضًا.
الخدمة الأصغر لم تعطِني ذلك المنفذ اليدوي، لكنها جعلت الـseeding أقل حاجة إلى تدخلي. وهذا، في الاستخدام اليومي، كان أكثر قيمة مما توقعت.
ما كنت أريده فعلًا هو أن أترك qBittorrent وحده
بدأت الاختبار لأنني أردت Upload أفضل لنسخة Ubuntu. في المحاولة الأولى حصلت على منفذ وارد ورأيت فائدته مباشرة. ثم تغير الاتصال، فتغير المنفذ، وعدت إلى الإعدادات. في المحاولة الثانية لم أحصل على Port Forwarding يدوي، لكن الاتصال تعافى عندما انتقلت بين Wi-Fi وHotspot، واستمر qBittorrent من دون جولة إعداد جديدة.
بعد عدة ساعات لم أعد أفكر في أي خيار يبدو أكثر تقدمًا. نظرت إلى شيء واحد: هل ما زلت Seed؟ نعم. وهنا اكتشفت أن عبارة البحث نفسها كانت أضيق من مشكلتي. إذا كنت تحتاج منفذًا واردًا حقيقيًا، فاختر VPN يوفر Port Forwarding بوضوح. أما إذا كنت تبحث عنه لأن هدفك الفعلي هو torrent يواصل العمل والرفع من دون أن تضطر إلى رعايته كلما تغير اتصالك، فقد يكون التعافي المستقر أكثر قيمة من رقم منفذ تحتاج إلى متابعته.
أفضل VPN للتورنت في اختباري لم يكن الذي أعطاني رقم Port جديدًا كلما اتصلت؛ كان الذي جعلني أغلق إعدادات qBittorrent وأترك Ubuntu يواصل الـseeding من دوني.
أسئلة قد تخطر ببالك بعد القراءة
أسئلة قد تخطر ببالك بعد القراءة
لماذا كان استمرار الـSeeding أهم من رقم المنفذ؟
وتظهر المشكلة نفسها باختصار في نقاشات مستخدمي qBittorrent خلف CGNAT: بعضهم يلجأ إلى VPN مع Port Forwarding لتحسين قابلية الوصول أثناء الـseeding.
لماذا تصبح استمرارية الاتصال أهم من ذروة السرعة في جلسات P2P الطويلة؟
qBittorrent يستخدم منفذًا للاتصالات الواردة، ويمكن ضبطه يدويًا أو الاعتماد على UPnP/NAT-PMP عندما تسمح الشبكة بذلك. qBittorrent Wiki فإذا كنت خلف NAT يمنع الاتصالات الواردة، يمكن لمنفذ مفتوح عبر VPN أن يجعل الوصول إليك أسهل.
ما الذي يستحق اختباره أولًا قبل تغيير إعدادات التورنت كلها؟
لكنني أردت اختبار السبب الحقيقي الذي جعلني أبحث عن الميزة أصلًا: هل أستطيع ترك qBittorrent يعمل بصورة مفيدة من دون أن أعود إلى إعداداته كلما تغير الاتصال؟