Gluetun Port Yönlendirme ve Torrent Ayarları

Neden port yönlendirmesi olmadan dışarıdan bağlantı sağlanamaz

Gluetun port yönlendirmesi, VPN sağlayıcınızdan çıkış adresindeki bir genel portu container'ınıza eşlemesini ister; başka bir eşin torrent istemcinize bağlantı başlatabilmesinin tek yolu budur. Bu eşleme olmadan tünel sağlıklı çalışır, indirmeler gerçekleşir ancak dışarıdan gelen hiçbir veri içeri ulaşamaz. Çalışan her bağlantı, istemcinizin ilk olarak başlattığı bağlantılardır.

Bu mekanizma NAT (ağ adresi çevirisi) olarak adlandırılır. Container'ınız, sağlayıcının çıkış adresini diğer birçok müşteriyle paylaşır. İstemciniz dışarıya doğru bir bağlantı açtığında, sağlayıcı bu akışı kaydeder ve yanıtları tünelinizden geri gönderir. Yabancı bir eşin içeriye doğru yaptığı bağlantı, kayıtlı hiçbir akışla eşleşmez; bu nedenle paket çıkış adresine ulaşır ve orada düşürülür. İstemciniz, kendisi bağlanabilir durumda olan her eşe ulaşmaya devam eder, bu yüzden indirmeler tamamlanır ve sorun görünmez kalır. Sorun, seeding (gönderim) aşamasında ortaya çıkar çünkü bir seeder, diğer insanların bağlandığı bir makinedir.

Açık bir gelen port iki şeyi değiştirir. Bir swarm'a daha hızlı katılırsınız çünkü kendileri bağlantı kabul edemeyen eşler artık size ulaşabilir ve bu eşlere veri yükleyebilirsiniz.

Çoğu VPN sağlayıcısının neden port yönlendirme sunmadığı

Port yönlendirme, paylaşımlı bir IP adresi üzerinde kısıtlı bir kaynaktır. Sağlayıcı, bir çıkış IP adresi üzerindeki tek bir port numarasını tek bir müşteri için rezerve eder ve bu port üzerinden yapılan tüm işlemlerden sorumlu tutulur. Birçok büyük sağlayıcı, kötüye kullanım yönetimi gerekçesiyle bu özelliği kaldırmıştır. Destek konusunu bir onay kutusu olarak değil, bir kategori sorusu olarak değerlendirin: Sağlayıcının bugün, mevcut planınızda ve seçebileceğiniz sunucularda port yönlendirme sunup sunmadığını sorgulayın.

Yönlendirme özelliği mevcut olduğunda, port dinamiktir. Port, hesabınıza değil VPN oturumunuza aittir; bu nedenle her yeniden bağlanma işleminden sonra farklı bir numara alabilir. Private Internet Access, gluetun tarafından yenilenen imzalı bir port sağlar. Üst kaynak belgelerine göre, /gluetun dizinini bind mount ile bağladığınız sürece, durum bilgisi yeniden başlatmalardan sonra da korunur ve aynı portu 60 gün boyunca kullanabilirsiniz. ProtonVPN ise NAT-PMP (NAT port mapping protocol) üzerinden kısa süreli kiralamalarla rastgele bir port atar ve bu portun sürekli yenilenmesi gerekir. İstemci üzerinde portu bir kez ayarlamanın kalıcı bir çözüm olmamasının nedeni budur.

gluetun'un port talep edebileceği sağlayıcılar

30 Temmuz 2026 tarihinde yayınlanan gluetun v3.41.3 sürümü itibarıyla, yerel entegrasyon dört sağlayıcı ismiyle doğrulanmaktadır: Private Internet Access, ProtonVPN, Perfect Privacy ve PrivateVPN. Bu özelliği, varsayılan olarak off olan VPN_PORT_FORWARDING=on ile etkinleştirin. Daha eski kılavuzlar PORT_FORWARDING veya PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING kullanmaktadır. Her iki isim de bu sürümde geriye dönük uyumlu olarak çalışmaya devam etmekte olup, kullanımdan kaldırılma sürecindedirler.

İki sağlayıcı detayı, talebin başarılı olup olamayacağını belirler. ProtonVPN ücretli bir plan gerektirir ve NAT-PMP özelliğinin açık olması gerekir: WireGuard yapılandırmasını oluştururken VPN seçenekleri altında NAT-PMP (Port Forwarding) ayarını etkinleştirin veya OpenVPN kullanırken kullanıcı adınızın sonuna +pmp ekleyin. OpenVPN üzerindeki Private Internet Access, sunucu seçimini port yönlendirmeyi destekleyen sunucularla kısıtlayan PORT_FORWARD_ONLY özelliğine sahiptir; böylece bu özelliği hiç desteklemeyen bir sunucuya denk gelmezsiniz. WireGuard ve OpenVPN'in port talep etme yöntemleri farklıdır, bu nedenle seçim yapmadan önce sağlayıcınızın sayfasını okuyun.

gluetun yerleşik bir sağlayıcı yerine özel bir yapılandırma ile çalıştığında, VPN_PORT_FORWARDING_PROVIDER değişkeni gluetun'un çağırması gereken API'yi belirtir. Yukarı akış (upstream) Private Internet Access sayfası, bu değişkeni port talebinin ihtiyaç duyduğu hesap kimlik bilgilerini taşıyan VPN_PORT_FORWARDING_USERNAME ve VPN_PORT_FORWARDING_PASSWORD ile eşleştirir.

Docker compose icerisinde gluetun port yonlendirmeyi etkinlestirme

Bu adimlar, tunelin halihazirda calistigini varsayar. Eger calismiyorsa, once Docker container trafigini gluetun uzerinden yonlendirme islemini tamamlayin ve indirmeler basladiginda geri donun.

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

Etiketi sabitleyin. qmcgaw/gluetun:latest, port yonlendirme ic yapisinin v4 icin degistigi master dalini takip eder; bu nedenle sabitlenmemis bir imaj, bir sonraki docker compose pull sirasinda davranis degisikligine yol acabilir. Ozel anahtari compose dosyasinin disinda tutmak icin compose gizli bilgileri icin bir env dosyasi kullanin.

Gluetun'un yönlendirilen portu nereye yazdığı

Gluetun, port bilgisini üç farklı yerde sunar ve bunların hepsi aynı değeri taşır.

Portu her edinimde bir kez günlüğe kaydeder. Satır port forwarded is 45678 şeklinde görünür; istek sonuç vermediğinde ise no port forwarded ifadesi yer alır.

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

Port numarasını VPN_PORT_FORWARDING_STATUS_FILE ile belirtilen dosyaya yazar; bu dosyanın varsayılan değeri /tmp/gluetun/forwarded_port şeklindedir. Dosya satır başına bir port tutar, 0644 moduyla yazılır ve container'ın PUID ve PGID kullanıcı/grup sahipliğine atanır. Yönlendirme durduğunda gluetun dosyayı silmek yerine içeriğini temizler; böylece bir tüketici uygulama, dosyanın eksik olması hatasıyla karşılaşmak yerine boş bir dosya okuyabilir.

docker exec gluetun cat /tmp/gluetun/forwarded_port

Değeri, varsayılan olarak :8000 üzerinde dinleme yapan ve HTTP_CONTROL_SERVER_ADDRESS ile ayarlanan kontrol sunucusu üzerinden sunar.

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

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

Gluetun ayrıca bu portu VPN arayüzündeki kendi güvenlik duvarında açar; bu nedenle yerel entegrasyon işini yaparken FIREWALL_VPN_INPUT_PORTS değişkenine gerek duyulmaz. Bu değişken diğer durumu kapsar: gluetun'un sorgulayamadığı bir sağlayıcıda, size bant dışından statik bir port atandıysa ve bunu manuel olarak izin vermeniz gerekiyorsa kullanılır.

Bu üç yöntemden biri kalıcıdır, diğer ikisi değildir. Üst kaynak belgeleri, durum dosyasını v4.0.0 sürümünde kullanımdan kaldırılmış (deprecated) olarak işaretlemiştir ve GET /v1/openvpn/portforwarded zaten /v1/portforward adresini işaret eden 301 Moved Permanently yanıtını vermektedir. Yeni geliştirmelerde kontrol sunucusunun okunması önerilir.

İstemciye her yeniden bağlanmada portun bildirilmesi gerekliliği

Bir torrent istemcisi, dinleme portunu kendi yapılandırmasında saklar ve yeniden başlatmalarda bu numarayı korur. Yönlendirilen port ise VPN oturumunun bir özelliğidir. Yeniden bağlanma sonrasında bu iki numara uyuşmaz; bu durumda sağlayıcı, hiçbir şeyin dinlemediği bir porta eşleme yapar ve istemci de hiçbir şeyin eşlenmediği bir portu dinler. Yeniden bağlanmalar nadir değildir: bir container yeniden başlatması, sunucu değişikliği, gluetun sağlık kontrolünün yeniden başlattığı kopuk bir tünel veya yenilenemeyen bir kiralama süresi buna neden olabilir. Sonuç, dün erişilebilir olan ancak bugün sessizce erişilemez hale gelen ve her iki günlük kaydında da hata görünmeyen bir yapıdır.

Bu nedenle port, gluetun onu elde ettiği anda uygulanmalıdır. Bunu bağlamanın iki yolu vardır ve bunlar, işi hangi sürecin yaptığına göre farklılık gösterir.

Seçenek 1: gluetun portu bir up komutu ile iletir

VPN_PORT_FORWARDING_UP_COMMAND port yönlendirme aktif olduğunda, VPN_PORT_FORWARDING_DOWN_COMMAND ise devre dışı kaldığında çalışır. Gluetun, komutu çalıştırmadan önce {{PORT}} (ilk port), {{PORTS}} (virgülle ayrılmış tüm portlar) ve {{VPN_INTERFACE}} (varsayılan olarak tun0 olan tünel arayüz adı) değişkenlerinin yerine değerlerini yerleştirir. Kabuk sözdizimi, açık bir /bin/sh -c sarmalayıcısı gerektirir. Aşağıdaki örnek, iki compose ortam girdisi olarak yazılmış qBittorrent yapılandırmasıdır:

      - 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'

Bu çağrıdaki her alanın belirli bir görevi vardır. listen_port yeni portu temsil eder. current_network_interface, qBittorrent'i tünel arayüzüne bağlar. random_port değerinin false olarak ayarlanması, qBittorrent'in bir sonraki başlatmada kendi portunu seçmesini engeller. upnp değerinin false olarak ayarlanması ise, mevcut olmayan bir yönlendirici üzerinden port eşlemeye çalışmasını durdurur.

Bu yaklaşım iki gereksinimi beraberinde getirir. qBittorrent web arayüzü, gluetun container'ı içinden 127.0.0.1:8080 adresine yanıt vermelidir; istemci gluetun'ın ağ ad alanını (network namespace) paylaştığında bu durum otomatiktir. Ayrıca, komut herhangi bir kimlik bilgisi göndermediği için Bypass authentication for clients on localhost (bypass_local_auth) etkinleştirilmelidir. Down komutu, qBittorrent'in bağlantı kesildikten sonra portu her zaman yeniden oluşturmaması nedeniyle gereklidir.

Komut, Alpine tabanlı olan ve wget içeren gluetun container'ı içinde çalışır. Bu imaj içerisinde curl bulunmaz. İmajda yer almayan bir ikili dosyayı çağıran komut, yönlendirme her aktif olduğunda başarısız olur.

Seçenek 2: gluetun dışındaki bir süreç portu okur

Diğer yöntem, gluetun yanında portu alan ve istemcinin kendi API'si aracılığıyla istemciye ileten küçük bir süreç çalıştırmaktır. Portu kontrol sunucusundan okuyun:

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

Veya süreç dosyayı görebiliyorsa dosyayı okuyun. /tmp/gluetun/forwarded_port, gluetun container'ı içinde yer alır; bu nedenle bir sidecar'ın her iki container'da da /tmp/gluetun konumuna mount edilmiş paylaşımlı bir volume'a ihtiyacı vardır ya da VPN_PORT_FORWARDING_STATUS_FILE değerini halihazırda mount ettiğiniz bir volume altındaki yola yönlendirmeniz gerekir.

Burada kimlik doğrulama önemlidir. v3.41.3 sürümünde GET /v1/portforward rotası, auth = "none" ile public adlı varsayılan bir role aittir; bu nedenle kimlik bilgisi olmadan yanıt verir ve gluetun, route GET /v1/portforward is unprotected by default, please set up authentication ile başlayan bir uyarı günlüğü oluşturur. Upstream, sonraki bir sürümde bu erişimi kapatacaktır. Şimdi /gluetun/auth/config.toml konumuna bind mount edilmiş dosyada bir rol tanımlayın:

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

docker run --rm qmcgaw/gluetun:v3.41.3 genkey ile bir anahtar oluşturun ve bunu X-API-Key başlığında gönderin. HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE, bir dosyayı mount etmek istemediğiniz durumlarda JSON kodlu bir ortam değişkeni ile aynı işi görür. Bir rol olmadan yayınlanan 8000 numaralı port, ona erişebilen herkese VPN durumu üzerinde kontrol sağlar; bu nedenle gluetun'a host ve diğer container'lardan nasıl erişileceği konusunu çalışırken bu erişimin ne kadar geniş olacağına bilinçli bir şekilde karar verin.

İstemci, tek bir wget çağrısı ile yönetilebilen bir API sunduğunda up komutunu seçin; çünkü bu komut her olayda tam olarak bir kez çalışır ve arka planda çalışmaya devam etmesi gerekmez. İstemci bir giriş akışı, yapılandırma dosyası yeniden yazımı veya yeniden başlatma gerektirdiğinde harici bir süreç seçin. Bir gluetun container'ı arkasındaki arr yığını içinde bu genellikle küçük bir poller ile sonuçlanır, çünkü port ile yalnızca torrent istemcisi ilgilenir.

Tuzak: namespace paylaşımı dinleme portunu ayarlamaz

Bu hata en çok zaman kaybettiren sorundur. network_mode: "service:gluetun", istemciyi gluetun'ın ağ namespace'ine dahil eder; böylece istemci VPN adresine, tünel rotalarına ve gluetun'ın güvenlik duvarı kurallarına sahip olur. Bunların hiçbiri istemcinin dinleme portunu ayarlamaz. Gluetun, yönlendirilen portu VPN arayüzünde açar, bu porta gelen paketler namespace içine ulaşır; ancak istemci farklı bir portta dinleme yapıyorsa çekirdeğin paketleri teslim edeceği bir hedefi olmaz. Dışa giden bağlantı kontrolleri sağlıklı görünse de gelen bağlantı reddedilir veya zaman aşımına uğrar. Yönlendirilen port ile istemcinin dinleme portu iki ayrı numaradır; bunları aynı tutmak temel görevdir.

Tahmin etmek yerine bunları karşılaştırın. Her iki komut da aynı namespace üzerinde çalıştırılır:

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]*'

Bir diğer ayar ise kullanıcıları yanlış yönlendirir. VPN_PORT_FORWARDING_LISTENING_PORT, iptables kullanarak gelen trafiği yönlendirilen porttan sabit bir yerel porta aktarır. Upstream, torrent istemcileriyle bu ayarın kullanılmamasını önerir; çünkü istemci kendi dinleme portunu tracker'lara ve eşlere (peer) duyurur, bu durumda swarm yanlış numarayı öğrenmiş olur.

Yönlendirilen portun erişilebilir olduğu nasıl kanıtlanır

İstemcinin kendi bağlantı göstergesi giden izleyici bağlantılarını yansıtır; bu nedenle hiçbir şey size ulaşamasa bile yeşil görünebilir. Tünelin dışındaki bir ağdan, kontrol ettiğiniz bir dinleyici ile test yapın. Upstream bunun için küçük bir araç yayınlamaktadır. Önce torrent istemcisini durdurun, çünkü iki süreç aynı porta bağlanamaz.

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

Container içinde, amd64 kısmını CPU mimarinize, 4567 kısmını ise yönlendirdiğiniz porta göre değiştirin:

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"

Şimdi gluetun tarafından kullanılan çıkış adresini bulun. Yanıt JSON formatındadır ve adres public_ip alanında yer alır.

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

VPN ile aynı ağda olmayan bir cihazdan http://<that address>:4567 adresini açın. Mobil veri kullanan bir telefon iş görecektir. Tarayıcınızın IP adresini ve kullanıcı aracısını gösteren bir sayfa ile port-checker tarafından kaydedilen eşleşen bir istek, gelen TCP trafiğinin namespace'e ulaştığı anlamına gelir. Zaman aşımı hatası, trafiğin ulaşmadığını gösterir ve sorun istemcinin üzerindeki bir katmandan kaynaklanıyordur. Aracı CTRL+C ile durdurun, exit ile kabuktan çıkın ve istemciyi yeniden başlatın. Bu kontrol yalnızca TCP trafiğini test eder. DHT (dağıtık karma tablosu) ve uTP trafiği aynı port numarası üzerinden UDP kullanır; bu test UDP trafiğini kapsamaz.

Hata modları ve karşılaşacağınız dizgeler

Log dosyasında hiçbir port satırı yok. Hiçbir şey port talebinde bulunmamıştır. Değişkenin docker exec gluetun printenv | grep PORT_FORWARDING ile container'a ulaştığını doğrulayın; yanlış compose servisinde tanımlanan değişkenler yaygın bir hata nedenidir.

Gluetun başlatılamıyor ve sağlayıcı hakkında hata veriyor. VPN_PORT_FORWARDING_PROVIDER, desteklenen dört isimle doğrulanır; bu nedenle yapılan bir yazım hatası, yönlendirme yapmadan sessizce çalışmak yerine container'ı durdurur.

Log dosyasında no port forwarded ifadesi yer alıyor. Gluetun talepte bulundu ancak sağlayıcı yanıt vermedi. ProtonVPN üzerinde bu durum genellikle oluşturduğunuz yapılandırmada NAT-PMP özelliğinin etkinleştirilmediği veya planınızın yönlendirmeyi desteklemediği anlamına gelir. Private Internet Access üzerinde ise genellikle seçilen sunucunun bu özelliği sunmadığı anlamına gelir.

Bir port geliyor ancak bağlantı sağlanamıyor. Yönlendirilen portu, yukarıdaki iki komutu kullanarak istemcinin dinleme portu ile karşılaştırın. Eğer eşleşiyorlarsa, istemcinin tünel arayüzüne bağlı olduğundan ve rastgele port (random-port) seçeneğinin kapalı olduğundan emin olun; çünkü bu seçenek her başlatmada dinleme portunu yeniden yazar.

up komutu hiçbir işlem yapmıyor gibi görünüyor. Hatayı görmek için komutu container içinde doğrudan çalıştırın: docker exec gluetun /bin/sh -c '<your command>'. curl: not found genellikle beklenen sonuçtur, çünkü imaj yalnızca wget içerir.

Kontrol sunucusundan 401 Unauthorized hatası. Bir kimlik doğrulama yapılandırması tanımladınız ancak rol, çağırdığınız rotayı içermiyor. Rotalar, yöntem ve yol birleşimiyle eşleştirilir; bu nedenle yalnızca /v1/portforward içeren bir rol, GET /v1/portforward rotasını kapsamaz.

Private Internet Access üzerinde her yeniden başlatmadan sonra farklı bir port geliyor. Kaydedilen port durumunun yeniden başlatmalardan etkilenmemesi için /gluetun yolunu bind mount ile bağlayın. Bu volume olmadan gluetun her seferinde yeni bir port talep eder.

FAQ

Torrent dosyalarım neden indiriliyor ancak gelen bağlantıları kabul etmiyor?

Bağlantı noktası yönlendirmesi (port forwarding) yapılmadığında, VPN sağlayıcısının tünele gelen paketleri herhangi bir porta iletecek bir NAT kuralı bulunmaz; bu nedenle sizin başlatmadığınız bağlantılar çıkış adresinde düşürülür. İndirme işlemleri, istemciniz bu bağlantıları kendisi açtığı ve bağlanılabilir durumdaki tüm eşlere ulaşabildiği için çalışmaya devam eder. Ancak seeding ve swarm katılımları, her iki tarafın da size ulaşabilmesine bağlı olduğundan bu durumdan olumsuz etkilenir. Çözüm, port yönlendirmeyi destekleyen bir sağlayıcı kullanmak, gluetun içinde VPN_PORT_FORWARDING=on ayarını yapmak ve elde edilen portu istemcinin dinleme portuna uygulamaktır.

gluetun her VPN sağlayıcısının port yönlendirme özelliğiyle çalışır mı?

Hayır. gluetun v3.41.3, dört sağlayıcı için yerel entegrasyona sahiptir: Private Internet Access, ProtonVPN, Perfect Privacy ve PrivateVPN. Bu listenin dışındaki herhangi bir sağlayıcı VPN_PORT_FORWARDING_PROVIDER için doğrulamadan geçemez ve container başlangıçta durur. Sağlayıcınız kendi kontrol paneli üzerinden statik bir port veriyorsa, gluetun bunu sizin yerinize talep edemez; ancak FIREWALL_VPN_INPUT_PORTS ayarı, bu sabit portun gluetun güvenlik duvarından geçmesine izin verecektir. Sağlayıcı politikaları değişebildiği için bir plan satın almadan önce güncel sağlayıcı sayfasını kontrol edin.

Her yeniden bağlanmadan sonra portu güncellemem gerekir mi?

Evet, bu güncelleme otomatik olarak yapılmalıdır. Yönlendirilen port VPN oturumuna aittir; bu nedenle container yeniden başlatıldığında, sunucu değiştiğinde veya kira yenileme başarısız olduğunda yeni bir numara atanabilir, ancak istemci eski portu kendi yapılandırmasında tutmaya devam eder. Port yönlendirme aktif olduğu anda çalışan VPN_PORT_FORWARDING_UP_COMMAND ile gluetun'un bunu iletmesini sağlayın ya da kontrol sunucusundan GET /v1/portforward değerini okuyup API aracılığıyla istemciye yazan küçük bir süreç çalıştırın.

Yönlendirilen portun gerçekten açık olduğunu nasıl kontrol ederim?

gluetun ağ ad alanı içinde tam olarak o portta bir dinleyici çalıştırın ve VPN dışından buna bağlanın. Portun boşta kalması için önce torrent istemcisini durdurun, ardından --listening-address=":<port>" ile gluetun container'ı içinde yukarı akış port denetleyici ikili dosyasını çalıştırın. curl -s http://127.0.0.1:8000/v1/publicip/ip üzerinden çıkış adresini alın ve mobil veri kullanan bir telefondan http://<address>:<port> adresini açın. Port denetleyici günlüğünde bir isteğin görünmesi, gelen TCP bağlantısının ulaştığını kanıtlar. Zaman aşımı hatası, istemcinin kendi durum simgesi ne gösterirse göstersin, bağlantının ulaşmadığı anlamına gelir.