Gluetun Portweiterleitung für Torrent-Clients einrichten

Warum ohne weitergeleiteten Port keine eingehenden Verbindungen zustande kommen

Die Portweiterleitung von Gluetun fordert Ihren VPN-Anbieter auf, einen öffentlichen Port an seiner Exit-Adresse zurück zu Ihrem Container weiterzuleiten. Nur so kann ein anderer Peer eine Verbindung zu Ihrem Torrent-Client starten. Ohne diese Zuordnung funktioniert der Tunnel, Downloads laufen, und es kommt nie selbstständig eine eingehende Verbindung an. Jede funktionierende Verbindung wurde zuerst von Ihrem Client geöffnet.

Der Mechanismus heißt NAT (Network Address Translation). Ihr Container verwendet die Exit-Adresse des Anbieters gemeinsam mit vielen anderen Kunden. Wenn Ihr Client eine ausgehende Verbindung öffnet, erfasst der Anbieter diesen Datenfluss und sendet die Antworten durch Ihren Tunnel zurück. Die Verbindung eines fremden Peers nach innen passt zu keinem erfassten Datenfluss. Das Paket erreicht daher die Exit-Adresse und wird dort verworfen. Ihr Client erreicht weiterhin jeden Peer, der selbst Verbindungen annehmen kann. Deshalb werden Downloads abgeschlossen und das Problem bleibt zunächst unbemerkt. Beim Seeding wird es sichtbar, weil ein Seeder ein Rechner ist, zu dem andere eine Verbindung herstellen.

Ein geöffneter eingehender Port ändert zwei Dinge. Sie treten schneller einem Swarm bei, weil Peers, die selbst keine Verbindungen annehmen können, Sie nun erreichen. Außerdem können Sie überhaupt Daten an diese Peers hochladen.

Warum die meisten VPN-Anbieter keinen weitergeleiteten Port anbieten

Ein weitergeleiteter Port ist eine knappe Ressource auf einer gemeinsam genutzten Adresse. Der Anbieter reserviert eine Portnummer auf einer Exit-IP für einen Kunden und ist anschließend für alles zuständig, was dieser Kunde darüber ausführt. Mehrere große Anbieter haben die Funktion entfernt und den Umgang mit Missbrauch als Grund genannt. Betrachten Sie die Unterstützung daher als Sachfrage und nicht als Kontrollkästchen: Fragen Sie, ob der Anbieter heute Portweiterleitung anbietet, ob sie in Ihrem Tarif enthalten ist und ob sie auf Servern verfügbar ist, die Sie tatsächlich auswählen können.

Wenn Portweiterleitung verfügbar ist, ist der Port dynamisch. Er gehört zur VPN-Sitzung und nicht zu Ihrem Konto. Nach jeder erneuten Verbindung kann es daher eine andere Portnummer sein. Private Internet Access stellt einen signierten Port bereit, den gluetun aktualisiert. In der Dokumentation des Upstream-Projekts steht, dass Sie denselben Port 60 Tage lang behalten, sofern Sie das Verzeichnis /gluetun per Bind-Mount einhängen, damit der Status einen Neustart übersteht. ProtonVPN weist über NAT-PMP (NAT port mapping protocol) einen zufälligen Port mit kurzer Lease-Dauer zu. Diese Lease muss fortlaufend erneuert werden. Deshalb funktioniert es nicht dauerhaft, den Port nur einmal im Client festzulegen.

Welche Anbieter gluetun für einen Port anfragen kann

Ab gluetun v3.41.3, veröffentlicht am 30 July 2026, validiert die native Integration vier Anbieternamen: Private Internet Access, ProtonVPN, Perfect Privacy und PrivateVPN. Aktivieren Sie sie mit VPN_PORT_FORWARDING=on. Der Standardwert ist off. Ältere Anleitungen verwenden PORT_FORWARDING oder PRIVATE_INTERNET_ACCESS_VPN_PORT_FORWARDING. Beide funktionieren in dieser Version weiterhin als rückwärtskompatible Namen, werden aber schrittweise entfernt.

Zwei Anbieteranforderungen bestimmen, ob die Anfrage überhaupt erfolgreich sein kann. Für ProtonVPN benötigen Sie einen kostenpflichtigen Tarif. Außerdem muss NAT-PMP aktiviert sein: Aktivieren Sie NAT-PMP (Port Forwarding) unter den VPN-Optionen, wenn Sie die WireGuard-Konfiguration erzeugen. Bei OpenVPN hängen Sie stattdessen +pmp an Ihren Benutzernamen an. Bei Private Internet Access unter OpenVPN gibt es PORT_FORWARD_ONLY. Diese Option beschränkt die Serverauswahl auf Server, die Portweiterleitung unterstützen. Dadurch wird kein Server ausgewählt, bei dem diese Funktion nie verfügbar war. WireGuard und OpenVPN unterscheiden sich darin, wie der Port angefragt wird. Lesen Sie daher die Dokumentation Ihres Anbieters, bevor Sie sich entscheiden.

Wenn gluetun eine benutzerdefinierte Konfiguration anstelle eines integrierten Anbieters verwendet, gibt VPN_PORT_FORWARDING_PROVIDER die API an, die gluetun aufrufen soll. Die Upstream-Seite von Private Internet Access verknüpft diese Variable mit VPN_PORT_FORWARDING_USERNAME und VPN_PORT_FORWARDING_PASSWORD. Diese Variablen enthalten die Zugangsdaten, die die Portanfrage benötigt.

Port-Forwarding für gluetun in Docker Compose aktivieren

Dies setzt voraus, dass der Tunnel bereits funktioniert. Falls nicht, beginnen Sie mit Docker-Containerverkehr über gluetun routen und kehren Sie zurück, sobald Downloads laufen.

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

Fixieren Sie das Tag. qmcgaw/gluetun:latest folgt dem master-Branch, in dem sich die Interna der Portweiterleitung für v4 ändern. Ein Image ohne festgelegtes Tag kann sein Verhalten beim nächsten docker compose pull ändern. Halten Sie den privaten Schlüssel mit einer env-Datei für Compose-Secrets aus der Compose-Datei heraus.

Wo gluetun den weitergeleiteten Port schreibt

Gluetun stellt den Port an drei Stellen bereit. Alle drei enthalten denselben Wert.

Es protokolliert den Port einmal pro Abruf. Die Zeile lautet port forwarded is 45678 beziehungsweise no port forwarded, wenn die Anfrage keinen Wert geliefert hat.

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

Es schreibt die Nummer in die durch VPN_PORT_FORWARDING_STATUS_FILE angegebene Datei. Standardmäßig ist dies /tmp/gluetun/forwarded_port. Die Datei enthält einen Port pro Zeile, wird mit dem Modus 0644 geschrieben und dem PUID und PGID des Containers zugewiesen. Wenn die Weiterleitung endet, leert gluetun die Datei, anstatt sie zu löschen. Ein Verbraucher kann dadurch eine leere Datei lesen, statt auf eine nicht vorhandene Datei zu stoßen.

docker exec gluetun cat /tmp/gluetun/forwarded_port

Es stellt den Wert über den Control-Server bereit. Dieser lauscht standardmäßig auf :8000 und wird durch HTTP_CONTROL_SERVER_ADDRESS festgelegt.

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

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

Gluetun öffnet diesen Port außerdem in seiner eigenen Firewall auf der VPN-Schnittstelle. Daher ist FIREWALL_VPN_INPUT_PORTS nicht erforderlich, solange die native Integration diese Aufgabe übernimmt. Diese Variable ist für den anderen Fall vorgesehen: für einen Provider, den gluetun nicht abfragen kann, bei dem Sie einen statischen Port außerhalb des Systems erhalten haben und diesen manuell freigeben müssen.

Eine dieser drei Möglichkeiten ist dauerhaft, zwei sind es nicht. Die Upstream-Dokumentation kennzeichnet die Statusdatei in v4.0.0 als veraltet. Außerdem antwortet GET /v1/openvpn/portforwarded bereits mit 301 Moved Permanently und verweist auf /v1/portforward. Neue Implementierungen sollten den Control-Server auslesen.

Warum der Client den Port bei jeder erneuten Verbindung erhalten muss

Ein Torrent-Client speichert seinen Listening-Port in der eigenen Konfiguration und verwendet diese Nummer auch nach Neustarts weiter. Der weitergeleitete Port ist eine Eigenschaft der VPN-Sitzung. Nach einer erneuten Verbindung stimmen die beiden Nummern nicht überein. Der Provider ordnet dann einen Port zu, auf dem kein Prozess lauscht, während der Client einen Port verwendet, für den keine Zuordnung besteht. Erneute Verbindungen sind nicht selten: Sie können durch einen Neustart des Containers, einen Serverwechsel, einen abgebrochenen Tunnel, den gluetun aufgrund seines Healthchecks neu startet, oder eine nicht verlängerbare Lease ausgelöst werden. Das Ergebnis ist eine Konfiguration, die gestern erreichbar war und heute unbemerkt nicht mehr erreichbar ist. In keinem der beiden Logs muss dabei ein Fehler erscheinen.

Der Port muss daher in dem Moment gesetzt werden, in dem gluetun ihn erhält. Dafür gibt es zwei Möglichkeiten. Sie unterscheiden sich darin, welcher Prozess diese Aufgabe übernimmt.

Option 1: gluetun übermittelt den Port mit einem up-Befehl

VPN_PORT_FORWARDING_UP_COMMAND wird ausgeführt, sobald die Portweiterleitung aktiviert ist, und VPN_PORT_FORWARDING_DOWN_COMMAND, sobald sie deaktiviert wird. Gluetun ersetzt vor der Ausführung des Befehls {{PORT}} (den ersten Port), {{PORTS}} (alle Ports, durch Kommas getrennt) und {{VPN_INTERFACE}} (den Namen des Tunnel-Interfaces, standardmäßig tun0). Für Shell-Syntax ist ein expliziter /bin/sh -c-Wrapper erforderlich. Dies ist das Upstream-Beispiel für qBittorrent, dargestellt als zwei Compose-Umgebungseinträge:

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

Jedes Feld dieses Aufrufs erfüllt eine bestimmte Aufgabe. listen_port ist der neue Port. current_network_interface bindet qBittorrent an den Tunnel. Wenn random_port auf false gesetzt ist, wählt qBittorrent beim nächsten Start keinen eigenen Port. Wenn upnp auf false gesetzt ist, versucht qBittorrent nicht, einen Port über einen nicht vorhandenen Router weiterzuleiten.

Für diesen Ansatz gelten zwei Voraussetzungen. Die Weboberfläche von qBittorrent muss innerhalb des gluetun-Containers auf 127.0.0.1:8080 antworten. Das geschieht automatisch, wenn der Client den Netzwerk-Namespace von gluetun verwendet. Außerdem muss Bypass authentication for clients on localhost (bypass_local_auth) aktiviert sein, da der Befehl keine Zugangsdaten übermittelt. Der down-Befehl ist erforderlich, weil qBittorrent den Port nach einer Verbindungsunterbrechung nicht immer erneut einrichtet.

Der Befehl wird innerhalb des gluetun-Containers ausgeführt. Dieser basiert auf Alpine und enthält wget. In diesem Image gibt es kein curl. Ein Befehl, der ein im Image nicht vorhandenes Binary aufruft, schlägt jedes Mal fehl, sobald die Portweiterleitung aktiviert wird.

Option 2: Ein Prozess außerhalb von gluetun liest den Port

Bei diesem Muster läuft neben gluetun ein kleiner Prozess. Er ruft den Port ab und übergibt ihn über die eigene API des Clients an den Client. Lesen Sie ihn vom Control-Server:

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

Sie können auch die Datei lesen, sofern der Prozess darauf zugreifen kann. /tmp/gluetun/forwarded_port befindet sich im gluetun-Container. Ein Sidecar benötigt daher ein gemeinsames Volume, das in beiden Containern unter /tmp/gluetun eingehängt ist. Alternativ können Sie VPN_PORT_FORWARDING_STATUS_FILE auf einen Pfad unter einem bereits eingehängten Volume verweisen.

Die Authentifizierung ist hier wichtig. In v3.41.3 gehört die Route GET /v1/portforward zu einer Standardrolle namens public mit auth = "none". Daher antwortet sie ohne Zugangsdaten, und gluetun protokolliert eine Warnung, die mit route GET /v1/portforward is unprotected by default, please set up authentication beginnt. Upstream schließt diesen Zugang in einem späteren Release. Definieren Sie jetzt eine Rolle in der Datei, die unter /gluetun/auth/config.toml eingebunden wird:

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

Generieren Sie mit docker run --rm qmcgaw/gluetun:v3.41.3 genkey einen Schlüssel und senden Sie ihn im Header X-API-Key. HTTP_CONTROL_SERVER_AUTH_DEFAULT_ROLE erfüllt dieselbe Funktion wie eine JSON-codierte Umgebungsvariable, wenn Sie keine Datei einbinden möchten. Ein veröffentlichter Port 8000 ohne Rolle gibt jedem, der ihn erreichen kann, Kontrolle über den VPN-Zustand. Legen Sie daher bewusst fest, wie weit er erreichbar ist, wenn Sie den Zugriff auf gluetun vom Host und von anderen Containern aus planen.

Wählen Sie den Befehl up, wenn der Client eine API bereitstellt, die sich mit einem einzelnen wget-Aufruf steuern lässt. Der Befehl wird dann genau einmal pro Ereignis ausgeführt und muss nicht dauerhaft laufen. Wählen Sie einen externen Prozess, wenn der Client einen Anmeldevorgang, das Umschreiben einer Konfigurationsdatei oder einen Neustart benötigt. In einem arr-Stack hinter einem gluetun-Container läuft dies normalerweise auf einen kleinen Poller hinaus, da nur der Torrent-Client den Port benötigt.

Die Falle: Ein gemeinsam genutzter Network Namespace legt den Listening-Port nicht fest

Dieser Fehler kostet am meisten Zeit. network_mode: "service:gluetun" fügt den Client in den Network Namespace von gluetun ein. Dadurch verwendet er die VPN-Adresse, die Tunnel-Routen und die Firewall-Regeln von gluetun. Nichts davon legt den Listening-Port des Clients fest. Gluetun öffnet den weitergeleiteten Port auf dem VPN-Interface. Die dafür bestimmten Pakete treffen im Namespace ein. Wenn der Client jedoch auf einem anderen Port lauscht, kann der Kernel sie keinem Prozess zustellen. Die Verbindung wird abgewiesen oder läuft in einen Timeout, obwohl alle ausgehenden Prüfungen erfolgreich sind. Der weitergeleitete Port und der Listening-Port des Clients sind zwei verschiedene Werte. Sie müssen identisch sein.

Vergleichen Sie die Werte, statt zu raten. Beide Befehle greifen auf denselben Namespace zu:

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

Eine weitere Einstellung führt häufig in die falsche Richtung. VPN_PORT_FORWARDING_LISTENING_PORT leitet eingehenden Traffic vom weitergeleiteten Port mithilfe von iptables an einen festen lokalen Port weiter. Upstream weist darauf hin, dass Sie diese Einstellung nicht mit Torrent-Clients verwenden sollten. Der Client teilt Trackern und Peers seinen eigenen Listening-Port mit. Dadurch erfährt der Swarm die falsche Portnummer.

So weisen Sie nach, dass der weitergeleitete Port erreichbar ist

Der eigene Verbindungsindikator des Clients zeigt ausgehende Tracker-Verbindungen an. Er kann daher grün erscheinen, obwohl niemand eine Verbindung zu Ihnen herstellen kann. Testen Sie mit einem Listener, den Sie kontrollieren, aus einem Netzwerk außerhalb des Tunnels. Upstream stellt dafür ein kleines Tool bereit. Beenden Sie den Torrent-Client zuerst, da zwei Prozesse nicht denselben Port binden können.

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

Ändern Sie innerhalb des Containers amd64 für Ihre CPU-Architektur und 4567 für Ihren weitergeleiteten Port:

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"

Ermitteln Sie jetzt die Exit-Adresse, die gluetun verwendet. Die Antwort ist JSON, und die Adresse steht im Feld public_ip.

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

Öffnen Sie http://<that address>:4567 auf einem Gerät, das sich nicht im selben VPN befindet. Ein Smartphone im Mobilfunknetz ist dafür geeignet. Eine Seite, die die IP-Adresse und den User-Agent Ihres Browsers anzeigt, zusammen mit einer passenden, von port-checker protokollierten Anfrage, bedeutet, dass eingehendes TCP den Namespace erreicht. Ein Timeout bedeutet, dass dies nicht der Fall ist und die Ursache oberhalb des Clients liegt. Beenden Sie das Tool mit CTRL+C, verlassen Sie die Shell mit exit und starten Sie den Client erneut. Dieser Test prüft ausschließlich TCP. DHT (distributed hash table) und uTP verwenden UDP über dieselbe Portnummer. Dieser Test deckt das nicht ab.

Fehlerbilder und die angezeigten Meldungen

Keine Port-Zeile im Log. Es wurde kein Port angefordert. Prüfen Sie mit docker exec gluetun printenv | grep PORT_FORWARDING, ob die Variable tatsächlich im Container angekommen ist. Eine Variable, die im falschen Compose-Dienst gesetzt wurde, ist eine häufige Ursache.

Gluetun startet nicht und meldet ein Problem mit dem Provider. VPN_PORT_FORWARDING_PROVIDER wird gegen die vier unterstützten Namen geprüft. Ein Tippfehler beendet daher den Container, statt ihn stillschweigend ohne Portweiterleitung auszuführen.

Im Log steht no port forwarded. Gluetun hat eine Anfrage gestellt, aber vom Provider keine Antwort erhalten. Bei ProtonVPN bedeutet das normalerweise, dass NAT-PMP in der erzeugten Konfiguration nicht aktiviert wurde oder der Tarif keine Portweiterleitung umfasst. Bei Private Internet Access bedeutet es normalerweise, dass der ausgewählte Server diese Funktion nicht anbietet.

Ein Port wird zugewiesen, aber es kann keine Verbindung hergestellt werden. Vergleichen Sie den weitergeleiteten Port mit dem Listening-Port des Clients mithilfe der beiden oben genannten Befehle. Stimmen sie überein, prüfen Sie, ob der Client an das Tunnel-Interface gebunden ist und die Option für einen zufälligen Port deaktiviert ist. Diese Option ändert den Listening-Port bei jedem Start.

Der Befehl zum Aktivieren scheint keine Wirkung zu haben. Führen Sie den exakten Befehl im Container aus, um den Fehler anzuzeigen: docker exec gluetun /bin/sh -c '<your command>'. curl: not found ist das übliche Ergebnis, weil das Image nur wget enthält.

401 Unauthorized vom Control-Server. Sie haben eine Authentifizierungskonfiguration definiert, aber die Rolle enthält die Route, die Sie aufrufen, nicht. Routen werden als Kombination aus Methode und Pfad abgeglichen. Eine Rolle, die nur /v1/portforward enthält, deckt GET /v1/portforward daher nicht ab.

Nach jedem Neustart wird bei Private Internet Access ein anderer Port verwendet. Binden Sie /gluetun als Mount ein, damit der gespeicherte Portstatus den Neustart überdauert. Ohne dieses Volume fordert gluetun jedes Mal einen neuen Port an.

FAQ

Warum laden meine Torrents herunter, erhalten aber nie eingehende Verbindungen?

Ohne weitergeleiteten Port verfügt der VPN-Anbieter über keine NAT-Regel, die eingehende Pakete an einem beliebigen Port an Ihren Tunnel weiterleitet. Verbindungen, die Sie nicht selbst gestartet haben, werden daher an der Exit-Adresse verworfen. Downloads funktionieren trotzdem, weil Ihr Client diese Verbindungen selbst öffnet und jeden Peer erreichen kann, der Verbindungen annimmt. Beim Seeding und beim Beitritt zu einem Swarm treten Probleme auf, da beides davon abhängt, dass andere Teilnehmer Sie erreichen können. Die Lösung ist ein Anbieter mit Portweiterleitung, VPN_PORT_FORWARDING=on in gluetun sowie die Übernahme des resultierenden Ports als Listening-Port des Clients.

Funktioniert gluetun mit der Portweiterleitung jedes VPN-Anbieters?

Nein. gluetun v3.41.3 bietet eine native Integration für vier Anbieter: Private Internet Access, ProtonVPN, Perfect Privacy und PrivateVPN. Alles außerhalb dieser Liste schlägt bei der Validierung für VPN_PORT_FORWARDING_PROVIDER fehl, und der Container wird beim Start beendet. Wenn Ihr Anbieter über ein eigenes Control Panel einen statischen Port bereitstellt, kann gluetun diesen nicht für Sie anfordern. FIREWALL_VPN_INPUT_PORTS ermöglicht jedoch, diesen festen Port durch die Firewall von gluetun zuzulassen. Die Richtlinien der Anbieter ändern sich. Prüfen Sie daher vor dem Abschluss eines Tarifs die aktuelle Seite des Anbieters.

Muss ich den Port nach jeder erneuten Verbindung aktualisieren?

Ja. Diese Aktualisierung sollte automatisch erfolgen. Der weitergeleitete Port gehört zur VPN-Sitzung. Daher können ein Neustart des Containers, ein Serverwechsel oder eine fehlgeschlagene Verlängerung der Lease eine neue Portnummer erzeugen, während der Client weiterhin den in seiner eigenen Konfiguration gespeicherten Port verwendet. Lassen Sie den Port entweder mit VPN_PORT_FORWARDING_UP_COMMAND von gluetun übertragen. Dieser Befehl wird ausgeführt, sobald die Portweiterleitung aktiv ist. Alternativ können Sie einen kleinen Prozess ausführen, der GET /v1/portforward vom Control Server liest und den Wert über die API in den Client schreibt.

Wie prüfe ich, ob der weitergeleitete Port tatsächlich geöffnet ist?

Starten Sie innerhalb des Netzwerk-Namespace von gluetun einen Listener an genau diesem Port. Verbinden Sie sich anschließend von außerhalb des VPN damit. Beenden Sie zuerst den Torrent-Client, damit der Port frei ist. Führen Sie dann das Upstream-Port-Checker-Binary im gluetun-Container mit --listening-address=":<port>" aus. Ermitteln Sie die Exit-Adresse mit curl -s http://127.0.0.1:8000/v1/publicip/ip und öffnen Sie http://<address>:<port> auf einem Smartphone über das Mobilfunknetz. Wenn im Log des Port-Checkers eine Anfrage erscheint, trifft eingehendes TCP ein. Ein Timeout bedeutet, dass dies nicht der Fall ist, unabhängig davon, welches Statussymbol der Client anzeigt.