إعداد إعادة توجيه منفذ Gluetun لتطبيقات التورنت

لماذا لا تصل أي اتصالات من الخارج من دون منفذ مُعاد توجيهه

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

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

يغيّر فتح منفذ وارد أمرين. تنضم إلى swarm بسرعة أكبر، لأن النظائر التي لا تستطيع قبول الاتصالات بنفسها تصبح قادرة على الوصول إليك. كما تتمكن من الرفع إلى تلك النظائر.

لماذا لا يوفّر معظم مزوّدي VPN منفذاً مُعاد توجيهه

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

عندما تتوفر إعادة التوجيه، يكون المنفذ ديناميكياً. فهو مرتبط بجلسة VPN وليس بحسابك، ولذلك قد يتغير رقمه بعد كل إعادة اتصال. يعيّن Private Internet Access منفذاً موقّعاً ويحدّثه gluetun، وتوضح الوثائق المصدرية أنك تحتفظ بالمنفذ نفسه لمدة 60 يوماً ما دمت تربط الدليل /gluetun باستخدام bind mount، بحيث تبقى هذه الحالة بعد إعادة التشغيل. يعيّن ProtonVPN منفذاً عشوائياً عبر NAT-PMP (بروتوكول تعيين منافذ NAT) بمدة تأجير قصيرة يجب تجديدها باستمرار. لذلك، لا يظل ضبط المنفذ مرة واحدة في العميل فعالاً.

ما موفّرو الخدمة الذين يستطيع gluetun طلب منفذ منهم

اعتباراً من gluetun v3.41.3، الذي صدر في 30 July 2026، يتحقق التكامل الأصلي من أربعة أسماء لموفّري الخدمة: Private Internet Access وProtonVPN وPerfect Privacy وPrivateVPN. فعّله باستخدام VPN_PORT_FORWARDING=on، وتكون قيمته الافتراضية off. تستخدم الأدلة الأقدم PORT_FORWARDING أو PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING. ولا يزال الاسمان يعملان في هذا الإصدار للتوافق مع الإصدارات السابقة، لكن يجري إيقاف استخدامهما تدريجياً.

تحدد تفاصيل خاصة بموفّر الخدمة ما إذا كان الطلب سينجح أساساً. يحتاج ProtonVPN إلى خطة مدفوعة، ويجب تفعيل NAT-PMP: فعّل NAT-PMP (Port Forwarding) ضمن خيارات VPN عند إنشاء إعداد WireGuard، أو أضف +pmp إلى اسم المستخدم عند استخدام OpenVPN. يتضمن Private Internet Access مع OpenVPN الخيار PORT_FORWARD_ONLY، الذي يقصر اختيار الخادم على الخوادم التي تدعم إعادة توجيه المنافذ، حتى لا تتصل بخادم لم يدعمها قط. يختلف WireGuard وOpenVPN في طريقة طلب المنفذ، لذلك اقرأ صفحة موفّر الخدمة قبل الاختيار.

عندما يشغّل gluetun إعداداً مخصصاً بدلاً من موفّر خدمة مضمّن، يحدد VPN_PORT_FORWARDING_PROVIDER واجهة API التي ينبغي لـ gluetun استدعاؤها. تربط صفحة Private Internet Access الرسمية هذا المتغير مع VPN_PORT_FORWARDING_USERNAME وVPN_PORT_FORWARDING_PASSWORD، وهما يحملان بيانات اعتماد الحساب اللازمة لطلب المنفذ.

فعّل إعادة توجيه المنافذ في gluetun ضمن docker compose

يفترض هذا أن النفق يعمل مسبقاً. إذا لم يكن كذلك، فابدأ بـتوجيه حركة مرور حاويات Docker عبر gluetun، ثم عد بعد بدء التنزيلات.

services:
  gluetun:
    image: qmcgaw/gluetun:v3.41.3
    container_name: gluetun
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8080:8080/tcp
      - 8000:8000/tcp
    volumes:
      - ./gluetun:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=${WIREGUARD_PRIVATE_KEY}
      - VPN_PORT_FORWARDING=on
      - TZ=Etc/UTC
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:5.2.3
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - WEBUI_PORT=8080
    volumes:
      - ./qbittorrent:/config
      - ./downloads:/downloads
    depends_on:
      - gluetun
    restart: unless-stopped

ثبّت الوسم. يتبع qmcgaw/gluetun:latest فرع master، حيث يجري تغيير مكونات إعادة توجيه المنافذ الداخلية للإصدار v4، لذلك قد تغيّر صورة غير مثبتة سلوكها عند docker compose pull التالية. أبقِ المفتاح الخاص خارج ملف compose باستخدام ملف بيئة لأسرار compose.

مكان كتابة gluetun للمنفذ المُعاد توجيهه

يُظهر Gluetun المنفذ في ثلاثة مواضع، وتحمل هذه المواضع جميعاً القيمة نفسها.

يسجّل المنفذ مرة واحدة لكل عملية الحصول عليه. يكون السطر على الصورة port forwarded is 45678، وعلى الصورة no port forwarded عندما لا تُرجع العملية أي قيمة.

docker logs gluetun 2>&1 | grep -i "port forwarded"

يكتب الرقم في الملف الذي يحدده VPN_PORT_FORWARDING_STATUS_FILE، وتكون قيمته الافتراضية /tmp/gluetun/forwarded_port. يحتوي الملف على منفذ واحد في كل سطر، ويُكتب بالنمط 0644، وتُضبط ملكيته لصالح PUID وPGID في الحاوية. عند توقف إعادة التوجيه، يمسح gluetun محتوى الملف بدلاً من حذفه، لكي يقرأ المستهلك ملفاً فارغاً بدلاً من مواجهة ملف مفقود.

docker exec gluetun cat /tmp/gluetun/forwarded_port

يقدّم القيمة عبر خادم التحكم، الذي يستمع افتراضياً على :8000، وتحدده HTTP_CONTROL_SERVER_ADDRESS.

curl -s http://127.0.0.1:8000/v1/portforward

{"port":45678,"ports":[45678]}

يفتح Gluetun هذا المنفذ أيضاً في جدار الحماية الخاص به على واجهة VPN، لذلك لا تكون FIREWALL_VPN_INPUT_PORTS مطلوبة أثناء تنفيذ التكامل الأصلي للمهمة. تغطي هذه المتغيرات الحالة الأخرى: مزود خدمة لا يستطيع gluetun الاستعلام عنه، حيث مُنحت منفذاً ثابتاً خارجياً وعليك السماح به يدوياً.

أحد هذه المواضع الثلاثة دائم، واثنان غير دائمين. تضع وثائق upstream ملف الحالة في قائمة المهجور اعتباراً من v4.0.0، كما أن GET /v1/openvpn/portforwarded يجيب بالفعل بـ301 Moved Permanently ويشير إلى /v1/portforward. يجب أن تقرأ الأعمال الجديدة خادم التحكم.

سبب ضرورة إبلاغ العميل بالمنفذ عند كل إعادة اتصال

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

لذلك يجب تطبيق المنفذ لحظة حصول gluetun عليه. توجد طريقتان لربط ذلك، وتختلفان في العملية التي تنفّذ المهمة.

الخيار 1: يمرّر gluetun المنفذ باستخدام أمر up

يُشغَّل VPN_PORT_FORWARDING_UP_COMMAND عند تفعيل إعادة توجيه المنفذ، ويُشغَّل VPN_PORT_FORWARDING_DOWN_COMMAND عند إيقافها. يستبدل Gluetun القيمة {{PORT}} (المنفذ الأول)، والقيمة {{PORTS}} (جميع المنافذ مفصولة بفواصل)، والقيمة {{VPN_INTERFACE}} (اسم واجهة النفق، وتكون tun0 افتراضياً) قبل تشغيل الأمر. تتطلب صياغة Shell غلاف /bin/sh -c صريحاً. هذا هو مثال qBittorrent الوارد من المشروع، مكتوباً كإدخالي بيئة في compose:

      - VPN_PORT_FORWARDING_UP_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":{{PORT}},\"current_network_interface\":\"{{VPN_INTERFACE}}\",\"random_port\":false,\"upnp\":false}" http://127.0.0.1:8080/api/v2/app/setPreferences'
      - VPN_PORT_FORWARDING_DOWN_COMMAND=/bin/sh -c 'wget -O- -nv --retry-connrefused --post-data "json={\"listen_port\":0,\"current_network_interface\":\"lo\"}" http://127.0.0.1:8080/api/v2/app/setPreferences'

لكل حقل في هذا الاستدعاء وظيفة. يمثّل listen_port المنفذ الجديد. يربط current_network_interface qBittorrent بالنفق. يمنع تعيين random_port إلى false qBittorrent من اختيار منفذه الخاص عند التشغيل التالي. ويمنع تعيين upnp إلى false البرنامج من محاولة تعيين منفذ عبر موجّه غير موجود.

يتطلب هذا الأسلوب شرطين. يجب أن تستجيب واجهة الويب الخاصة بـqBittorrent على 127.0.0.1:8080 من داخل حاوية gluetun. يحدث ذلك تلقائياً عندما يشارك العميل مساحة أسماء الشبكة الخاصة بـgluetun. ويجب تفعيل Bypass authentication for clients on localhost (bypass_local_auth)، لأن الأمر لا يرسل بيانات اعتماد. يوجد أمر down لأن qBittorrent لا يعيد دائماً إنشاء المنفذ بعد انقطاع الاتصال.

يُشغَّل الأمر داخل حاوية gluetun، المبنية على Alpine والمزوّدة بـwget. ولا يوجد curl في تلك الصورة. ويفشل كل مرة تبدأ فيها إعادة توجيه المنفذ أي أمر يسمّي ملفاً تنفيذياً غير موجود في الصورة.

الخيار 2: عملية خارج gluetun تقرأ المنفذ

يعتمد النمط الآخر على تشغيل عملية صغيرة بجانب gluetun، حيث تجلب المنفذ وتدفعه إلى العميل عبر API الخاص بالعميل. اقرأه من خادم التحكم:

port=$(curl -s http://127.0.0.1:8000/v1/portforward | jq -r .port)

أو اقرأ الملف إذا كانت العملية تستطيع رؤيته. يوجد /tmp/gluetun/forwarded_port داخل حاوية gluetun، لذلك تحتاج الحاوية الجانبية إلى volume مشترك مركّب في /tmp/gluetun داخل كلتا الحاويتين، أو توجّه VPN_PORT_FORWARDING_STATUS_FILE إلى مسار ضمن volume مركّب لديك مسبقاً.

المصادقة مهمة هنا. في الإصدار v3.41.3، ينتمي المسار GET /v1/portforward إلى دور افتراضي اسمه public مع auth = "none"، لذلك يستجيب من دون بيانات اعتماد، ويسجّل gluetun تحذيراً يبدأ بـ route GET /v1/portforward is unprotected by default, please set up authentication. سيغلق المشروع upstream هذا المسار في إصدار لاحق. عرّف دوراً الآن في الملف المرتبط عبر bind mount في /gluetun/auth/config.toml:

roles = [
  { name = "qbittorrent", routes = ["GET /v1/portforward"], auth = "apikey", apikey = "myapikey" }
]

أنشئ مفتاحاً باستخدام docker run --rm qmcgaw/gluetun:v3.41.3 genkey وأرسله في ترويسة X-API-Key. يؤدي HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE الغرض نفسه الذي يؤديه متغير بيئة واحد بترميز JSON عندما تفضّل عدم تركيب ملف. إن نشرت المنفذ 8000 من دون دور، فسيتمكن كل من يستطيع الوصول إليه من التحكم في حالة VPN. لذلك حدّد عمداً نطاق وصوله عند تحديد كيفية الوصول إلى gluetun من المضيف والحاويات الأخرى.

اختر الأمر up عندما يوفّر العميل API يمكن لنداء واحد من wget تشغيله، لأنه يُنفَّذ مرة واحدة بالضبط لكل حدث ولا يضيف عملية مستمرة. اختر عملية خارجية عندما يحتاج العميل إلى تدفق تسجيل دخول، أو إعادة كتابة ملف إعداد، أو إعادة تشغيل. في مكدس arr خلف حاوية gluetun واحدة ينتهي الأمر عادةً إلى poller صغير واحد، لأن عميل التورنت وحده يحتاج إلى المنفذ.

الفخ: مشاركة مساحة أسماء الشبكة لا تضبط منفذ الاستماع

يهدر هذا العطل معظم الوقت. يضع network_mode: "service:gluetun" العميلَ في مساحة أسماء شبكة gluetun، ولذلك يحصل على عنوان VPN ومسارات النفق وقواعد جدار gluetun النارية. لا يضبط أيٌّ من ذلك منفذ استماع العميل. يفتح Gluetun المنفذ المُعاد توجيهه على واجهة VPN، وتصل الحزم الخاصة به إلى مساحة الأسماء، لكن إذا كان العميل يستمع على منفذ مختلف فلن يجد kernel شيئاً يسلّم الحزم إليه. يُرفض الاتصال أو تنتهي مهلته، مع أن كل فحوصات الاتصالات الصادرة تبدو سليمة. المنفذ المُعاد توجيهه ومنفذ استماع العميل رقمان منفصلان، ومهمتك الوحيدة هي إبقاؤهما متساويين.

قارنهما بدلاً من التخمين. يُنفَّذ كلا الأمرين على مساحة الأسماء نفسها:

docker exec gluetun cat /tmp/gluetun/forwarded_port
docker exec gluetun wget -qO- http://127.0.0.1:8080/api/v2/app/preferences | grep -o '"listen_port":[0-9]*'

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

كيفية إثبات إمكانية الوصول إلى المنفذ المُعاد توجيهه

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

docker stop qbittorrent
docker exec -it gluetun /bin/sh

داخل الحاوية، غيّر amd64 بما يناسب معمارية CPU لديك، وغيّر 4567 إلى المنفذ المُعاد توجيهه:

wget -qO port-checker https://github.com/qdm12/port-checker/releases/download/v0.4.0/port-checker_0.4.0_linux_amd64
chmod +x port-checker
./port-checker --listening-address=":4567"

ابحث الآن عن عنوان الخروج الذي يستخدمه gluetun. تكون الاستجابة بتنسيق JSON، ويظهر العنوان في الحقل public_ip.

curl -s http://127.0.0.1:8000/v1/publicip/ip

افتح http://<that address>:4567 من جهاز لا يتصل بشبكة VPN نفسها. يكفي استخدام هاتف متصل ببيانات الهاتف المحمول. إذا ظهرت صفحة تعرض عنوان IP الخاص بمتصفحك ووكيل المستخدم، وسُجّل طلب مطابق بواسطة port-checker، فهذا يعني أن حركة TCP الواردة تصل إلى مساحة الأسماء. يعني انتهاء المهلة أنها لا تصل، وأن السبب يقع في طبقة أعلى من العميل. أوقف الأداة باستخدام CTRL+C، واخرج من الصدفة باستخدام exit، ثم شغّل العميل مجدداً. يختبر هذا الفحص TCP فقط. تستخدم حركة DHT (جدول التجزئة الموزع) وuTP بروتوكول UDP على رقم المنفذ نفسه، ولا يغطي هذا الاختبار ذلك.

حالات الفشل والنصوص التي ستظهر لك

لا يظهر أي سطر للمنفذ في السجل. لم يطلب أي شيء منفذاً. تأكد من وصول المتغير فعلياً إلى الحاوية باستخدام docker exec gluetun printenv | grep PORT_FORWARDING، لأن ضبط متغير في خدمة Compose خاطئة سبب شائع لذلك.

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

يقول السجل no port forwarded. أرسل Gluetun الطلب، لكن المزوّد لم يُعد أي نتيجة. في ProtonVPN يعني ذلك عادةً أن NAT-PMP لم يكن مفعّلاً في الإعداد الذي أنشأته، أو أن الخطة لا تتضمن إعادة توجيه المنافذ. وفي Private Internet Access يعني ذلك عادةً أن الخادم المحدد لا يوفّر هذه الميزة.

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

يبدو أن الأمر up لا يفعل شيئاً. شغّل الأمر نفسه داخل الحاوية لرؤية الخطأ: docker exec gluetun /bin/sh -c '<your command>'. النتيجة المعتادة هي curl: not found، لأن الصورة تتضمن wget فقط.

401 Unauthorized من خادم التحكم. عرّفت إعداد مصادقة، لكن الدور لا يسرد المسار الذي تستدعيه. تتم مطابقة المسارات وفق الطريقة والمسار، لذلك لا يغطي دور يسرد /v1/portforward وحده GET /v1/portforward.

منفذ مختلف في Private Internet Access بعد كل إعادة تشغيل. اربط /gluetun باستخدام bind mount حتى تبقى حالة المنفذ المحفوظة بعد إعادة التشغيل. من دون هذا الـvolume، يطلب Gluetun منفذاً جديداً في كل مرة.

FAQ

لماذا تُنزَّل ملفات التورنت لديّ، لكن لا تصل إليها اتصالات واردة؟

من دون منفذ مُعاد توجيهه، لا يملك مزوّد VPN قاعدة NAT تُرسل الحزم الواردة على أي منفذ إلى النفق الخاص بك، لذلك تُسقط الاتصالات التي لم تبدأها أنت عند عنوان الخروج. تستمر التنزيلات في العمل لأن العميل يفتح هذه الاتصالات بنفسه، ويمكنه الوصول إلى أي نظير يمكن الاتصال به. يتأثر التوزيع والانضمام إلى أسراب التورنت، لأن كليهما يعتمد على قدرة الآخرين على الوصول إليك. الحل هو استخدام مزوّد يوفّر إعادة توجيه المنافذ، وVPN_PORT_FORWARDING=on في gluetun، ثم تطبيق المنفذ الناتج على منفذ الاستماع الخاص بالعميل.

هل يعمل gluetun مع إعادة توجيه المنافذ لدى أي مزوّد VPN؟

لا. يوفّر gluetun v3.41.3 تكاملاً أصلياً مع 4 مزوّدين: Private Internet Access وProtonVPN وPerfect Privacy وPrivateVPN. يفشل أي مزوّد خارج هذه القائمة في التحقق من VPN_PORT_FORWARDING_PROVIDER، وتتوقف الحاوية عند بدء التشغيل. إذا كان مزوّدك يعيّن منفذاً ثابتاً عبر لوحة التحكم الخاصة به، فلا يستطيع gluetun طلبه نيابةً عنك، لكن FIREWALL_VPN_INPUT_PORTS سيسمح لهذا المنفذ الثابت بالمرور عبر جدار gluetun الناري. تتغير سياسات المزوّدين، لذا تحقّق من صفحة المزوّد الحالية قبل شراء خطة لهذا الغرض.

هل يجب أن أحدّث المنفذ بعد كل إعادة اتصال؟

نعم، ويجب أن يتم هذا التحديث تلقائياً. يرتبط المنفذ المُعاد توجيهه بجلسة VPN، لذلك قد تنتج إعادة تشغيل الحاوية، أو تغيير الخادم، أو فشل تجديد الحجز رقماً جديداً، بينما يحتفظ العميل بالمنفذ المخزّن في إعداداته الخاصة. إما أن تسمح لـgluetun بدفعه باستخدام VPN_PORT_FORWARDING_UP_COMMAND، الذي يعمل فور تفعيل إعادة التوجيه، أو شغّل عملية صغيرة تقرأ GET /v1/portforward من خادم التحكم وتكتب القيمة في العميل عبر واجهة API الخاصة به.

كيف أتحقق من أن المنفذ المُعاد توجيهه مفتوح فعلاً؟

شغّل مستمعاً على المنفذ نفسه داخل مساحة أسماء الشبكة الخاصة بـgluetun، ثم اتصل به من خارج VPN. أوقف عميل التورنت أولاً حتى يصبح المنفذ متاحاً، ثم شغّل ملف port-checker الثنائي المورّد من upstream داخل حاوية gluetun باستخدام --listening-address=":<port>". احصل على عنوان الخروج من curl -s http://127.0.0.1:8000/v1/publicip/ip، وافتح http://<address>:<port> من هاتف يستخدم بيانات الهاتف المحمول. يثبت ظهور طلب في سجل port-checker وصول TCP الوارد. ويعني انتهاء مهلة الاتصال أنه لم يصل، بغض النظر عما تعرضه أيقونة الحالة في العميل.