Port flapping between old and new forwarded ports when using qsticky with qBittorrent

[Bastien42]

Description

When using Gluetun with ProtonVPN WireGuard and qsticky to update qBittorrent's listening port, the port flaps between the old port (61557) and the new forwarded port (33467). This causes repeated port change attempts and log spam in both qBittorrent and qsticky.

---

Logs

qBittorrent Log

qBittorrent v5.1.2 started. Process ID: 147
Using config directory: /config/qBittorrent
Trying to listen on the following list of IP addresses: "10.2.0.2:61557"
Peer ID: "-qB5120-"
HTTP User-Agent: "qBittorrent/5.1.2"
Distributed Hash Table (DHT) support: ON
Local Peer Discovery support: OFF
Peer Exchange (PeX) support: OFF
Anonymous mode: ON
Encryption support: ON
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/61557"
IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Oct 1 03:26:02 2025.
Using built-in WebUI.
WebUI translation for selected locale (en) has been successfully loaded.
WebUI: Now listening on IP: *, port: 8080
WebAPI login success. IP: ::ffff:172.16.4.1
Failed to listen on IP. IP: "10.2.0.2". Port: "TCP/61557". Reason: "Address not available"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/61557"
WebAPI login success. IP: ::ffff:172.16.4.3
Trying to listen on the following list of IP addresses: "10.2.0.2:33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/33467"
WebAPI login success. IP: ::ffff:172.16.4.1
WebAPI login success. IP: ::ffff:172.16.4.1
WebAPI login success. IP: ::ffff:172.16.4.1
Trying to listen on the following list of IP addresses: "10.2.0.2:61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/61557"
WebAPI login success. IP: ::ffff:172.16.4.3
Trying to listen on the following list of IP addresses: "10.2.0.2:33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/33467"
WebAPI login success. IP: ::ffff:172.16.4.3
WebAPI login success. IP: ::ffff:172.16.4.1
WebAPI login success. IP: ::ffff:172.16.4.1
Trying to listen on the following list of IP addresses: "10.2.0.2:61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/61557"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/61557"
WebAPI login success. IP: ::ffff:172.16.4.3
Trying to listen on the following list of IP addresses: "10.2.0.2:33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "TCP/33467"
Successfully listening on IP. IP: "10.2.0.2". Port: "UTP/33467"

qsticky Log

2025-10-20 19:24:22,458 - qsticky - INFO - Starting qSticky port manager (commit: 23ac5ae)...
2025-10-20 19:24:53,279 - qsticky - INFO - Successfully logged in to qBittorrent
2025-10-20 19:24:53,280 - qsticky - INFO - Port change needed: 61557 -> 33467
2025-10-20 19:24:53,297 - qsticky - INFO - Successfully updated port to 33467
2025-10-20 19:25:23,867 - qsticky - INFO - Port change needed: 61557 -> 33467
2025-10-20 19:25:23,895 - qsticky - INFO - Successfully updated port to 33467
2025-10-20 19:26:24,996 - qsticky - INFO - Port change needed: 61557 -> 33467
2025-10-20 19:26:25,011 - qsticky - INFO - Successfully updated port to 33467
2025-10-20 19:27:26,127 - qsticky - INFO - Port change needed: 61557 -> 33467
2025-10-20 19:27:26,139 - qsticky - INFO - Successfully updated port to 33467
2025-10-20 19:28:27,255 - qsticky - INFO - Port change needed: 61557 -> 33467
2025-10-20 19:28:27,297 - qsticky - INFO - Successfully updated port to 33467

---

Expected Behavior

qBittorrent should listen only on the new forwarded port (33467) after qsticky updates it, and not revert to the old port (61557).

---

Actual Behavior

qBittorrent alternates between the old and new ports, causing repeated port updates and log spam.

---

Environment

• Gluetun: latest
• ProtonVPN: WireGuard
• qBittorrent: v5.1.2
• qsticky: commit 23ac5ae
• Docker: TrueNAS SCALE

---

Configuration

• Gluetun is configured with VPN_PORT_FORWARDING=on and PORT_FORWARD_ONLY=on.
• qBittorrent is configured to use Gluetun's network stack (network_mode: service:gluetun).
• qsticky is configured to update qBittorrent's port using Gluetun's API.

---

Possible Cause

It seems that either:

1. Gluetun is not consistently providing the forwarded port to qsticky, or
2. qBittorrent is not retaining the new port and reverts to the old one after a short time.

---

Suggested Fix

Investigate why qBittorrent reverts to the old port and ensure the new port is persisted after the update. This may involve checking how Gluetun handles port forwarding updates or how qsticky interacts with Gluetun's API.

---

Additional Context

• The issue occurs even when the port is successfully updated by qsticky.
• The logs show that qsticky repeatedly detects the old port and updates it to the new one, indicating a loop.

[github-actions]

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

• do not ask for updates, be patient
• 👍 the issue to show your support instead of commenting
  @qdm12 usually checks issues at least once a week, if this is a new urgent bug,
  revert to an older tagged container image

[Bastien42]

Gluetun Logs

Here are the relevant Gluetun logs showing the port forwarding and API interactions:

2025-10-20T21:24:41+02:00 INFO [port forwarding] starting
2025-10-20T21:24:41+02:00 INFO [port forwarding] gateway external IPv4 address is 79.135.104.8
2025-10-20T21:24:41+02:00 INFO [port forwarding] port forwarded is 33467
2025-10-20T21:24:41+02:00 INFO [firewall] setting allowed input port 33467 through interface tun0...
2025-10-20T21:24:41+02:00 INFO [port forwarding] writing port file /tmp/gluetun/forwarded_port

2025-10-20T21:24:53+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:24:53+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:56480 in 312.708µs

2025-10-20T21:25:23+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:25:23+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:35288 in 247.213µs

2025-10-20T21:25:54+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:25:54+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:54672 in 49.916µs

2025-10-20T21:26:24+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:26:24+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:38148 in 40.166µs

2025-10-20T21:26:55+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:26:55+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:36476 in 37.201µs

2025-10-20T21:27:25+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:27:25+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:59586 in 40.978µs

2025-10-20T21:27:56+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:27:56+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:38892 in 33.724µs

2025-10-20T21:28:26+02:00 WARN [http server] route GET /v1/openvpn/portforwarded is unprotected by default, please set up authentication following the documentation at https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md#authentication since this will become no longer publicly accessible after release v3.40.
2025-10-20T21:28:26+02:00 INFO [http server] 200 GET /portforwarded wrote 15B to 172.16.4.3:49904 in 47.521µs

Observations

• Gluetun successfully forwards port 33467 and writes it to /tmp/gluetun/forwarded_port.
• qsticky (IP 172.16.4.3) repeatedly queries the /portforwarded endpoint and receives the correct port (33467).
• Despite this, qBittorrent alternates between the old port (61557) and the new port (33467), indicating that qBittorrent may not be retaining the updated port or is being reset by another process.

Additional Context

• The issue persists even though Gluetun consistently provides the correct port to qsticky.
• qsticky logs confirm it updates qBittorrent's port to 33467 each time, but qBittorrent reverts to 61557 shortly after.

This suggests the issue may be with qBittorrent's handling of the port update, or a race condition in how qsticky or Gluetun interacts with qBittorrent.

[Bastien42]

Stack Configuration (Redacted for Privacy)

Here is the relevant part of my stack configuration:

version: '3.8'

services:
  gluetun:
    cap_add:
      - NET_ADMIN
    container_name: gluetun
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - TZ=Europe/Paris
      - VPN_SERVICE_PROVIDER=protonvpn
      - VPN_TYPE=wireguard
      - VPN_PORT_FORWARDING=on
      - SERVER_COUNTRIES=Switzerland
      - WIREGUARD_PRIVATE_KEY=<REDACTED>
      - PORT_FORWARD_ONLY=on
      - CONTROL_SERVER_AUTH_TYPE=apikey
      - CONTROL_SERVER_APIKEY=<REDACTED>
    image: qmcgaw/gluetun:latest
    ports:
      - '8080:8080'
    restart: unless-stopped

  qbittorrent:
    container_name: qbittorrent
    depends_on:
      - gluetun
    environment:
      - PUID=568
      - PGID=568
      - TZ=Europe/Paris
      - WEBUI_PORT=8080
    image: linuxserver/qbittorrent:latest
    network_mode: service:gluetun
    restart: unless-stopped
    volumes:
      - /mnt/config/apps/qbittorrent:/config
      - /mnt/Tank/media:/media

  qsticky:
    container_name: qsticky
    depends_on:
      - gluetun
      - qbittorrent
    environment:
      - QBITTORRENT_HOST=gluetun
      - QBITTORRENT_HTTPS=false
      - QBITTORRENT_PORT=8080
      - QBITTORRENT_USER=<REDACTED>
      - QBITTORRENT_PASS=<REDACTED>
      - GLUETUN_HOST=gluetun
      - GLUETUN_AUTH_TYPE=apikey
      - GLUETUN_APIKEY=<REDACTED>
    image: ghcr.io/monstermuffin/qsticky:latest
    restart: unless-stopped

Key Points

• network_mode: service:gluetun ensures qBittorrent uses Gluetun's network stack.
• VPN_PORT_FORWARDING=on and PORT_FORWARD_ONLY=on are set for Gluetun.
• qsticky is configured to update qBittorrent's port using Gluetun's API.

[scraunt]

@Bastien42

You should try using this instead: "(Q)GSP : Qbittorrent - Gluetun Synchronised Port mod", it's been working great for me since the Gluetun API changes. I am using the default settings for the docker mod, and also using the LinuxServer qbittorrent image. I would be interested to hear if your issue persists.

Besides that, this is certainly an issue with qSticky and not Gluetun, if Gluetun is writing the port forwarded file correctly, then it's work is done so to speak, so your issue is with qSticky and/or qBittorrent (as it's the port not being set in qbittorrent which is your problem).

[Bastien42]

I ended up using this repo
https://hotio.dev/containers/qbittorrent/#__tabbed_2_2

Works well and port forwarding works flawlessly

[scraunt]

Please close this issue. Thanks.

…

On 31 October 2025 06:42:04 UTC, Ymir ***@***.***> wrote: Bastien42 left a comment (passteque/gluetun#2945) I ended up using this repo https://hotio.dev/containers/qbittorrent/#__tabbed_2_2 Works well and port forwarding works flawlessly -- Reply to this email directly or view it on GitHub: #2945 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[github-actions]

Closed issues are NOT monitored, so commenting here is likely to be not seen.
If you think this is still unresolved and have more information to bring, please create another issue.

This is an automated comment setup because @qdm12 is the sole maintainer of this project
which became too popular to monitor issues closed.