SparkBox/Guides/qBittorrent queue

qBittorrent Torrents Stuck on "Queued" and Not Downloading

You added a torrent, but instead of downloading it just sits there labelled Queued DL (or Queued UP for a completed one). The qBittorrent queue is doing exactly what it was told to do, or something upstream — usually a broken VPN bind — has quietly stopped every torrent while the status still looks like an ordinary wait. This guide separates the two and fixes both.

qBittorrent web UI behind the SparkBox VPN
qBittorrent web UI behind the SparkBox VPN

Rather not audit status surfaces by hand? SparkBox ships qBittorrent with honest status reporting, so a stuck queue that is really a dead VPN gets flagged instead of faked. See the walkthrough →

The 10-second version: Open Tools → Options → BitTorrent → Torrent Queueing. If torrents are queued but the active ones download fine, raise Maximum active downloads or untick queueing. If nothing moves, your VPN bind is dead — fix the interface and confirm qBittorrent's reported IP is your VPN.

First, decide which problem you actually have

"Queued" means two very different things, and the fix depends on which one you're looking at. Take ten seconds to check before you change any settings.

  • Some torrents download, others say "Queued": this is normal queueing. You've hit a limit. Jump to the next section.
  • Nothing downloads — everything is "Queued" or "Stalled" at 0 B/s: the queue is a symptom, not the cause. Your qBittorrent probably can't reach the network at all, most commonly because a VPN interface it's bound to went down. Skip to the VPN bind section.

The distinction matters because raising queue limits does nothing if the real problem is a dead network bind — you'll just have more torrents stuck at zero.

Cause 1: You've hit qBittorrent's queueing limit

Torrent queueing is a built-in feature that caps how many torrents run at once, so your bandwidth and connection count aren't spread across dozens of torrents. Anything over the cap waits, and qBittorrent labels it Queued DL or Queued UP. That's the app working as designed — it just may be set lower than you want.

Fix: raise or disable the limits

  1. Open qBittorrent and go to Tools → Options (the gear icon in the Web UI).
  2. Select the BitTorrent tab.
  3. Find the Torrent Queueing section.
  4. Either raise the numbers — Maximum active downloads, Maximum active uploads, and Maximum active torrents — or untick Torrent Queueing entirely to let everything run at once.
  5. Click Apply, then OK. Queued torrents should start within a few seconds.

Gotcha: Disabling queueing isn't always the better choice. If you run a media library and grab many torrents at once, a sensible cap (say, 3–5 active downloads) keeps each one fast instead of leaving them all crawling. Turn it off only if you truly want everything downloading in parallel.

Also check: "Do not count slow torrents"

In the same Torrent Queueing section there's an option to exclude slow torrents from the active count. If it's ticked and your torrents are genuinely slow, qBittorrent may not promote queued ones because it thinks slots are still occupied. Untick it if your queue seems stuck despite low activity.

Cause 2: A broken VPN bind stops everything (and can hide behind the queue)

Many self-hosters run qBittorrent bound to a VPN network interface — a rule that says "only send torrent traffic through the VPN, never the plain connection." That's good for privacy, but it has a failure mode: if the VPN interface drops, renews with a new address, or comes up after qBittorrent starts, the app is now bound to something that can't reach peers. Every torrent stalls or sits queued at 0 B/s.

The trap is that this can look like an ordinary queue. Older status displays would happily show a green, "healthy" state even when the underlying IP probe had failed — so you'd stare at a queue and never suspect the VPN. This is the exact class of bug the SparkBox status-honesty audit (21 July 2026) went after: a failed qBittorrent VPN IP probe now reports as qbt_ip_unknown instead of being quietly presented as fine. When the probe can't confirm your VPN IP, it says so.

Fix: confirm and repair the bind

  1. Check what IP qBittorrent is actually using. In many setups qBittorrent (or a companion tool) reports its external IP. If it shows your real home/server IP — or reports "unknown" — the VPN isn't carrying the traffic. That mismatch is the real cause of the queue.
  2. Bring the VPN interface back up. Restart your VPN client or container so the tunnel interface exists and has an address again.
  3. Re-check the qBittorrent binding. In Tools → Options → Advanced, look at Network Interface. If it names a VPN interface that has since disappeared or been renamed, qBittorrent has nothing valid to bind to. Set it to the current interface, or set it to a value that reappears reliably after reboots.
  4. Restart qBittorrent last. The order matters: the VPN interface should exist before qBittorrent starts, otherwise it binds to nothing. Bring up the VPN, confirm the interface, then start qBittorrent.

Why "honest status" is the real fix here: The queue itself was never the problem — it was a truthful symptom of a silent bind failure. Fixing the reporting so a failed IP probe surfaces as unknown is what lets you skip an hour of poking at queue settings that were fine all along.

Cause 3: Duplicated or stale config drift (why the same bug came back)

If you self-host with install scripts or containers, one subtle way a "fixed" issue reappears is a second, un-synced copy of the same piece of config. During the SparkBox audit we found the qBittorrent injector log had a duplicate line in install.sh that hadn't been updated alongside the original — the same twin-copy pattern that had previously derailed a well-known upstream fix. One copy was correct; the stale twin quietly undid it.

You don't need SparkBox to run into this. The lesson is general:

  1. When a torrent-client fix "doesn't stick" after an update or reinstall, search your setup for a second place the same setting or script lives.
  2. Config that's edited both in a template and in a running instance is a classic drift source — decide which one is authoritative and remove the other.
  3. After any reinstall, re-verify the fix against the actual running config, not the file you meant to edit.

If you'd rather not manage this yourself, this is exactly the kind of thing a curated stack handles for you — see self-hosting without learning Docker.

Quick verification checklist

  1. Active torrents are downloading at real speeds, not stuck at 0 B/s.
  2. Torrents leave the Queued state within seconds once a slot frees up.
  3. qBittorrent's reported external IP matches your VPN, not your real connection.
  4. Your status dashboard shows a truthful state — including "unknown" when a probe fails — rather than a permanent green light. A beginner-friendly dashboard makes this easy to see at a glance.

Frequently asked

Why are my qBittorrent torrents stuck on "Queued"?

Usually you've reached qBittorrent's torrent queueing limit — once active torrents hit your Maximum active downloads or Maximum active torrents value, the rest wait in a Queued state. Raise the limits or turn queueing off under Options. If nothing is downloading, the queue is masking a broken network bind, not a limit.

What is torrent queueing in qBittorrent?

It's a built-in feature that caps how many torrents run simultaneously so bandwidth and connections aren't spread too thin. Extra torrents are held and shown as "Queued DL" or "Queued UP" until a slot opens. It lives under Tools → Options → BitTorrent → Torrent Queueing.

Why does everything queue or stall when I use a VPN?

If qBittorrent is bound to a VPN interface and that interface drops or changes, it can no longer reach peers, so every torrent sits queued or stalled at 0 B/s. Confirm the VPN interface is up before qBittorrent starts, and check that qBittorrent's reported IP is the VPN's.

Does SparkBox fix this automatically?

SparkBox doesn't override your queueing preferences, but after the July 2026 status-honesty audit it reports a failed qBittorrent VPN IP probe as qbt_ip_unknown instead of showing it as healthy. That means a queue that's really a dead VPN bind gets flagged, not disguised.

Skip the guesswork on a stuck queue

SparkBox runs qBittorrent behind a VPN with honest status surfaces — so a queue that's really a broken bind tells you the truth in the first hour, not after an evening of tweaking limits.

Get SparkBox → Or read the media-server walkthrough →

Questions, or did this not match your box?

Every guide here came from a real problem someone hit. If yours behaves differently, say so — that is how these get corrected, and how the fix gets prioritised.

Ask in the community →

We answer there rather than in a comment box, because that is where the people who have already solved it are.

About this guide: Written and tested by the SparkBox team on a UGREEN DXP4800 Plus and a $7/month Hostinger VPS, both running SparkBox 1.6.464. The causes above are the real ones we've diagnosed in d/sparkbox. If something doesn't match, tell us on YouTube.