If qBittorrent shows only passive connectivity while seeding, check the same incoming peer port across three layers: qBittorrent, the Docker container, and the router. The July 2026 forum reply correctly identified that a router forward alone is not enough when qBittorrent runs inside Docker.
If all three layers match and the port still cannot be reached, the next high-value check is whether your ISP places you behind CGNAT. In that case, normal IPv4 port forwarding on your home router cannot create a public inbound path.
Match the Listening Port End to End
Choose a fixed incoming port in qBittorrent rather than a different random port at every startup. The upstream qBittorrent connection options documents the listening port used for incoming peers.
Then confirm Docker publishes the same port on TCP and UDP and that your router forwards that port to the current ZimaOS LAN address.
Check Docker Before Changing the Router Again
Use the ZimaOS app configuration or Docker inspection to verify what the container actually exposes. If qBittorrent listens on port 50000 internally but Docker publishes 6881, forwarding 50000 at the router will still fail.
The qBittorrent Docker guide focuses on storage paths, but the same host-versus-container distinction applies to ports.
Rule Out CGNAT
Compare the WAN IPv4 address shown by your router with the public IPv4 address seen from the internet. If they differ substantially—or your router receives a private/CGNAT-range address—your ISP may be upstream-NATing the connection.
A dynamic DNS name does not bypass CGNAT. The public IP checklist explains that distinction.
Do Not Assume Passive Means Seeding Is Impossible
Passive connectivity generally means peers cannot initiate a new inbound connection to you. qBittorrent can still make outbound peer connections, so some uploads may continue. The penalty is reachability: fewer peers can connect directly, especially in swarms where the other side is also not reachable.
Bottom Line
Troubleshoot in order: fixed qBittorrent listening port, matching Docker TCP/UDP publication, correct router destination IP, firewall rules, then CGNAT/public-IP status. Repeating router forwards without checking the container or ISP layer wastes time.
