QBittorrent "stalled" issue

[gniting]

Below is my docker compose file for making Gluetun and QBit and to have all traffic from QBit flow through the Gluetun container.

Once up, QBit can't download any torrents even though it can see seeds and peers. The public IP of the QBit container is the same as the one for the Gluetun container. All I see for each torrent is the infamous "stalled" msg.

Tried several things, can't seem to resolve. I've opened port 6881 on my firewall as well.

Any clues?

version: '3.8'

services:
  gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    devices:
      - /dev/net/tun:/dev/net/tun
    cap_add:
      - NET_ADMIN
    ports:
      - 8080:8080 #qbit
      - 6881:6881 #qbit
      - 6881:6881/udp #qbit
    environment:
      - TZ=Europe/Paris
      - VPN_SERVICE_PROVIDER=vpn unlimited
      - OPENVPN_USER=xxxxxx
      - OPENVPN_PASSWORD=yyyyyy
      - SERVER_COUNTRIES=Switzerland
    volumes:
      - /opt/gluetun:/gluetun
      - /etc/localtime:/etc/localtime:ro
    networks:
      - vpn
    restart: unless-stopped

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1002
      - TZ=Europe/Paris
    volumes:
      - /path/qbittorrent:/config
      - /path/Downloads:/downloads
    network_mode: service:gluetun
    depends_on:
      - gluetun
    restart: unless-stopped

networks:
  vpn:
    external: true

[ksurl]

known issue with qbittorrent and gluetun. when gluetun restarts the vpn due to health check, qbittorrent doesn't switch to the new connection. a workaround is to use the lscr.io/linuxserver/qbittorrent:libtorrentv1 image or use another client like transmission

[jostyee]

So is it a regression of libtorrent v2?

[ksurl]

So is it a regression of libtorrent v2?

Either that or the implementation in qbittorrent but the discussion on the parent github issue is probably indicating a libtorrentv2 issue

[FunctionDJ]

@ksurl can you link the qbittorrent issue?

[christaikobo]

#1277
For anyone in the future going through this.

[Meguinness]

im having the same problem, having Sickchill and Qbittorrent going thru Gluetun,,,,qbit will stop working after few hours and need to be restarted.
if im only using sickchill thru gluetun then the problem is that sickchill will not communicate with qbit by using http://192.168.1.6:8080/ or http://localhost:8080
ideas? ta

containers running on OMV Portainer

sickchill error if running thru gluetun with qbit running outside gluetun

Failed to authenticate with qBittorrent, Failed to connect to qBittorrent. Connection Error: ConnectionError(MaxRetryError("HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /api/v2/auth/login (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 111] Connection refused'))"))

[darqlt]

Idk about first part, qluetun works for me stable with libtorrentv1 and with v2 - have no issues at all (ofc i don't have health checks or auto server updates, so maybe it impacts that).

Regarding second part - looks like you have little to no knowledge about docker networking.. Each docker image is kinda like different "server", so if you are calling http://localhost:8080/ it will look for other port in same docker image.. http://192.168.1.6:8080/ looks like your docker host ip, so if you forwarded ports to it - it can work, but looks like you didn't do that.. You need publish ports or use internal network to do communication between 2 docker images - if both images uses qluetun - use qluetun:port in configs. If sickchill images are "outside", you can use --network container:qbit on it to join to qbit network (or switch it around if qbit is outside).
I suggest to read: https://docs.docker.com/network/ it explains everything kinda good.

If you still have issues - post docker commands your are using or docker-compose.yaml for us, to understand how your network are configured

[camilosampedro]

Maybe it's a very manual solution, but I was able to mitigate this by having another container restart the qbittorrent container every N seconds:

  restarter:
    image: docker:cli
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    # Restart every 20 minutes (1200 secs)
    command: ["/bin/sh", "-ex", "-c", "while true; do sleep 1200; echo restarting; docker restart qbittorrent; done"]
    restart: unless-stopped
    depends_on:
      - qbittorrent

[bradenmitchell]

I use a similar approach in setting up a cron job on the host (I'm using a raspberry pi) to do a docker restart qbittorrent every 24 h at like 1 am. Has worked well for me for several years.

[FunctionDJ]

you might want to try the libtorrentv1 variant of the lsio qbittorrent image instead

[rtmmbarbosa]

I am pulling my heart out because I cannot understand what am I doing wrong here.

gluetun:
    image: qmcgaw/gluetun
    container_name: gluetun
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - SYS_MODULE
    devices:
      - /dev/net/tun:/dev/net/tun
    environment:
      - VPN_SERVICE_PROVIDER=custom
      - VPN_TYPE=wireguard
      - VPN_INPUT_PORT=6881,8080
      - WIREGUARD_PRIVATE_KEY=""
      - WIREGUARD_ADDRESSES=xxx.xxx.xxx.xxx/32
      - WIREGUARD_ENDPOINT_IP=xxx.xxx.xxx.xxx
      - WIREGUARD_ENDPOINT_PORT=xxx
      - WIREGUARD_PUBLIC_KEY=""
      - WIREGUARD_PRESHARED_KEY=""
      - WIREGUARD_ALLOWED_IPS=0.0.0.0/0
      - WIREGUARD_PERSISTENT_KEEPALIVE=25
      - DOT=off
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./gluetun:/gluetun
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.qbittorrent.rule=Host(`qbittorrent.${HOST}`)"
      - "traefik.http.routers.qbittorrent.entrypoints=https"
      - "traefik.http.routers.qbittorrent.tls.certresolver=gbresolver"
      - "traefik.http.routers.qbittorrent.service=gluetun"
      - "traefik.http.services.gluetun.loadbalancer.server.port=8080"

  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:libtorrentv1
    container_name: qbittorrent
    network_mode: "service:gluetun"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Lisbon
      - WEBUI_PORT=8080
      - TORRENTING_PORT=6881
      - UMASK_SET=002
    volumes:
      - qbittorrent_config:/config
      - qbittorrent_downloads:/downloads
    restart: unless-stopped
    depends_on:
      - gluetun

I can reach the webgui, I get a certificate, I get the IP address from the VPN, I have Internet access. The thing is that I am not getting DHT nodes and the downloads are always stalled.

Can anyone help me understanding what is happening?

[christaikobo]

Maybe it's a DNS issue, try ping and nslookup in your container.

[rtmmbarbosa]

Thanks @christaikobo but accessability seems to be working and is not an issue. The only issue is with downloading because everything gets stalled.

root@08bbec5f5417:/# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=107 time=65.106 ms
64 bytes from 8.8.8.8: seq=1 ttl=107 time=67.024 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 65.106/66.065/67.024 ms
root@08bbec5f5417:/# curl ifconfig.io
94.131.xxx.xxx
root@08bbec5f5417:/# nslookup google.com
Server:         1.1.1.1
Address:        1.1.1.1:53

Non-authoritative answer:
Name:   google.com
Address: 216.58.215.142

Non-authoritative answer:
Name:   google.com
Address: 2a00:1450:4003:800::200e

I already changed the port configuration to match the one from @gniting :

    ports:
      - 6881:6881 # qbittorrent tcp port
      - 6881:6881/udp # qbittorrent udp port

And confirmed the port is exactly the one in Options -> Connection.

I thought it could be a Traefik issue and tried to download plain and clear without gluetun and everything worked without problems.

Any other idea of what could be preventing my qbittorrent to download? Or any other test I could try to debug it?

[Mr-DS-ML-85]

Not working with lscr.io/linuxserver/qbittorrent:libtorrentv1 image with gluetun vpn btw using proton vpn

[NewittAll]

Issue is resolved after running docker pull qmcgaw/gluetun today and it pulling an updated image.

I started experiencing this issue after updating my gluetun, I don't remember exactly what update it was on before but it said I was 19 updates behind before I had done an image pull on it yesterday.

[NewittAll]

The issue has come back and wont go away with another docker pull.

[xenago]

I am using health checks to restart the lscr.io/linuxserver/qbittorrent:libtorrentv1 container whenever the connection status in the API drops. This prevents unnecessary restarts and restores connectivity quickly.

1. Enable the qBittorrent setting WebUI > Bypass authentication for clients on localhost

2. Define a healthcheck for the container in the compose file similar to the following (can replace $$WEBUI_PORT with 8080 if not using a custom port), which will check to ensure the connection status remains green:

    healthcheck:
      test: ["CMD-SHELL", "curl -s http://localhost:$$WEBUI_PORT/api/v2/transfer/info | jq -e '.connection_status == \"connected\"' > /dev/null || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

Once applied, the container's health should reflect the connection_status from the qBittorrent API at the time of the last poll. This should be sufficient for those using container orchestration systems or those who will define their own cron job to monitor and perform restarts.

For a standalone compose setup, the willfarrell/autoheal container can do the job of restarting it automatically when the health drops.

1. Define an autoheal service similar to the following:

  autoheal:
    image: willfarrell/autoheal:latest
    network_mode: none
    restart: always
    deploy:
      replicas: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      # Times are in seconds
      - AUTOHEAL_INTERVAL=60
      - AUTOHEAL_DEFAULT_STOP_TIMEOUT=30

2. Apply the autoheal label to the qBittorrent container so it will be restarted automatically by the service:

    labels:
      autoheal: true

Result:

[spawn-guy]

Do you really need /dev/null and exit 1 at the end? -e already returns exit status 0 when the statement is true (according to the jq docs) and non0 otherwise

[xenago]

Probably not required, feel free to adjust however you like. I usually throw it in at the end of healthchecks since it doesn't hurt and makes the intent clear, but it shouldn't make much, if any, difference to remove it!

[Infonautica]

Thank you @xenago, this solution works great! Also in logs now i see a suspicious pattern showcasing that in my setup qBittorrent was becoming unhealthy every 185 second, but it doesn't matter since autohealer takes care 🤩 🙇

11-01-2026 18:24:15 Container /qbittorrent (708197a475a4) found to be unhealthy - Restarting container now with 30s timeout
11-01-2026 18:27:20 Container /qbittorrent (708197a475a4) found to be unhealthy - Restarting container now with 30s timeout
11-01-2026 18:30:25 Container /qbittorrent (708197a475a4) found to be unhealthy - Restarting container now with 30s timeout
11-01-2026 18:33:31 Container /qbittorrent (708197a475a4) found to be unhealthy - Restarting container now with 30s timeout
11-01-2026 18:36:36 Container /qbittorrent (708197a475a4) found to be unhealthy - Restarting container now with 30s timeout

[xenago]

@Infonautica 185 seconds of uptime is barely even starting up, you should be able to have uptime of at least a few hours unless your connection/VPN is really unreliable. I'd increase the startup time/retries, assuming everything is configured correctly for the health check to work. If that doesn't help, disable the healthcheck and figure out if it's actually healthy. If it's actually healthy, you may need to use some other metric instead of connection_status.