Back to blog
FILE 0x8E·QBITTORRENT WAS ON THE WRONG VPN PORT FORWARD

qBittorrent was on the wrong VPN port forward

May 4, 2026 · homelab, qbittorrent, vpn

The music torrent container had 349 torrents and zero of them were doing anything. Every single one was stuck in metaDL with 0 peers, 0 bytes. DHT showed 4 nodes. It looked like a network problem, but the container could ping out fine.

What was happening

curl ifconfig.io from inside the container returned the VPN exit IP, so the tunnel was up. Outbound TCP worked. The qBittorrent WebUI was responding. Just nothing was getting bytes in.

For comparison, the TV and movies containers on the same VPN provider were fine. So the problem wasn't the VPN account, it was something instance-specific.

What I found

The VPN provider gives each subscription a fixed set of forwarded ports. Each port is bound to a specific allocation. If you put the wrong port in qBittorrent's listen settings, the rest of the swarm can't reach you, and you get exactly this symptom — outbound looks fine, but no inbound connections, so no peers, so no metadata.

The music container was configured to listen on port 25672. The actual forwarded port for that allocation was 2567. Someone (me, months ago) had typed an extra digit. The TV and movies containers had the correct forwards because I'd set them up later more carefully.

DHT-only swarms can sometimes paper over this — they bootstrap to nodes that aren't behind NAT. But popular trackers and most modern private trackers want a reachable listen port and will refuse to seed to you otherwise.

The fix

Fix the port in qBittorrent's preferences:

curl -X POST "$QBT/api/v2/app/setPreferences" \
  --data-urlencode 'json={"listen_port": 2567}'

Immediate result: DHT bootstrapped to 301 nodes within 30 seconds. Download speed jumped to 1.68 MB/s. Five torrents started actually downloading.

What I'd do differently

The forwarded port belongs in a single source-of-truth file (or env var) per container, not typed by hand into the qBittorrent settings UI. The next iteration of my container provisioning script reads the port from /etc/torrent-vpn.env and pushes it into qBittorrent via the API at startup, so if I rotate the port in one place, all clients pick it up. Eliminates the "typo from six months ago" failure mode entirely.