qBittorrent - No upload speed

LSIO Discussion Container Support
1

I am using the latest docker image and running using docker compose on Debian 12. This debian 12 is a VM in Proxmox.
I have a 100/40 connection.
I get good download speeds ~9 MB/s, but no upload at all. sometimes it goes upto a few KB/s, but then drops back to 0B.
Still very new to all this, but unable to determine what the issue is.

I was first routing qbittorrent behind Gluetun using Torguard VPN and was getting the same issue. Now have moved to just qbittorrent and no VPN or port forwarding of whatsoever.

My docker compose file below:

version: "3"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbit-test
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Australia/Melbourne
      - WEBUI_PORT=8080
    volumes:
      - /mnt/docker/qbit/data:/config
      - /mnt/media/qBittorrent:/downloads
    ports:
      - 8080:8080

    restart: unless-stopped

Qbit_Download issue

I know about port forwarding, however I should still be seeing some upload speed without port forwarding. This is really strange.

How do I go about debugging this issue?

2

Also below is my docker compose file with Torguard VPN and Gluetun using wireguard config.

I have port forwarded port 51934 from torguard on a fixed ip. If i use this port Qbittorrent connections, then I have the orange flame connection status symbol and no upload speeds.

If I select some random port, then it goes to green globe icon, and get some upload speeds ~10 - 20 KB, but then drops back to 0B.

I have used a few ubuntu torrents to test as well as a few trending torrents that have a lot of peers and seeds.

version: "3"

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    restart: unless-stopped
    networks:
      - proxy
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    ports:
      - 8080:8080 # qBittorrent
      - 51934:51934
      - 51934:51934/udp
    volumes:
      - /mnt/docker/gluetun/data:/gluetun
    environment:
      - VPN_SERVICE_PROVIDER=custom
      - VPN_TYPE=wireguard
      - VPN_ENDPOINT_IP=103.231.XX.X
      - VPN_ENDPOINT_PORT=1443
      - WIREGUARD_PUBLIC_KEY=
      - WIREGUARD_PRIVATE_KEY=
      - WIREGUARD_ADDRESSES=10.13.XXX.XX/24
      - TZ=Australia/Melbourne
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.gluetun-qbittorrent.entrypoints=http"
      - "traefik.http.routers.gluetun-qbittorrent.rule=Host(`qbit.XXXXX.XX`)"
      - "traefik.http.middlewares.gluetun-qbittorrent-https-redirect.redirectscheme.scheme=https"
      - "traefik.http.routers.gluetun-qbittorrent.middlewares=gluetun-qbittorrent-https-redirect"
      - "traefik.http.routers.gluetun-qbittorrent-secure.entrypoints=https"
      - "traefik.http.routers.gluetun-qbittorrent-secure.rule=Host(`qbit.XXXXX.XX`)"
      - "traefik.http.routers.gluetun-qbittorrent-secure.tls=true"
      - "traefik.http.routers.gluetun-qbittorrent-secure.service=gluetun-svc"
      - "traefik.http.services.gluetun-svc.loadbalancer.server.port=8080"

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    restart: unless-stopped
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Australia/Melbourne
    volumes:
      - /mnt/docker/qbittorrent/config:/config
      - /mnt/media/qBittorrent:/downloads

networks:
  proxy:
    external: true
3

Unfortunately, we don’t offer support for routing a container through another container, such as a vpn. I would suggest you remove all the VPN bits and check if it’s working as expected.

We also do not support the application, we only support the container, aside from missing the mandatory port (because you have it on the vpn container) it looks fine.

tl;dr test without vpn and see if the issue persists.

4

Hi driz,

The issue persists without vpn as well. Thats my original post/comment.
I thought vpn might be an issue hence created a new test docker compose file. But its the same issue.

version: "3"
services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbit-test
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Australia/Melbourne
      - WEBUI_PORT=8080
    volumes:
      - /mnt/docker/qbit/data:/config
      - /mnt/media/qBittorrent:/downloads
    ports:
      - 8080:8080

    restart: unless-stopped
5

got it, I missed that, sorry.
As you already know, DNATing the port will increase your speeds you can seed, HOWEVER, you only seed when someone wants something that you can offer enough chunks of, fast enough. You are seeding in the worst possible way and you could be seeding stuff no one wants.
That all said, we support the container, not the application. I would suggest installing on bare metal in the same way (no port forward) with the same torrents and see if there’s a difference. If there isn’t, you know it’s not the container, if there is, you know where to dig in. Unfortunately, in this case, even if it is the container we do not list port 6881/tcp_udp as optional and our expectation is that you have it in your ports section of compose and DNAT it from the edge to your docker host.