Why a transfer is slow
Most slow BitTorrent transfers are slow because of the swarm, not because of the client, so the way to increase torrenting speed is to check four things in the order they actually cause the problem: the swarm, the connection, the client, and the line.
Only the last three are yours to change, and the first one accounts for most of it. A torrent with two distant seeders will not go faster because a setting was adjusted, and the hours spent adjusting settings are the reason this order is worth keeping.
How long will it take
Start with the swarm, because most slow transfers stop there
The swarm sets the ceiling for every transfer, and no client can exceed it. Your download speed is the sum of what other people's machines are willing and able to send you at that moment, which depends on how many of them hold the pieces you still need, how much upstream capacity each of them has, and how many other peers they are serving at the same time. One seeder on a slow home connection, divided among forty leechers, gives every one of them a small share and there is nothing to be done about it from your end.
Three figures in the client tell you whether the swarm is the answer. The seeds count, the peers count, and availability. When seeds is low, when availability sits near or below 1.000, or when the peers list is short and every row is idle, the swarm is the cause and the other three checks are a waste of an evening. The swarm explains what each of those figures counts.
Two swarm effects surprise people. A transfer that starts slowly and accelerates after a few minutes is normal: the client has to find peers, handshake, and work out which of them are worth trading with, and rate limits inside the protocol ramp rather than jump. And a transfer whose speed fluctuates by large amounts every few seconds is also normal, because peers choke and unchoke each other continuously, which means the set of connections actually sending you data is rewritten every few seconds.
Then the connection, because firewalled means no incoming connections
The connection question is not whether you have internet, it is whether other peers can start a connection to you. A client that reports itself as firewalled is working: it reaches outward, finds peers, and downloads. What it cannot do is accept an incoming connection, so it only ever trades with peers it found and dialed itself, and it is invisible to everybody else in the swarm. On a busy torrent that costs a little. On a thin one, where a handful of usable peers exist and most of them are behind their own routers, it can be the whole difference between a transfer that moves and one that does not.
The status is shown at the bottom of the qBittorrent window, and equivalent indicators exist in Deluge and Transmission. Ports, NAT and being firewalled covers what to do about it, what port forwarding changes and what it does not. Two other connection level causes belong in the same check: a client showing offline rather than firewalled has not reached a tracker or the DHT at all, and a home router that has run out of connection table entries will start dropping new peer connections regardless of what the client asks for.
Then the client, and the settings that genuinely change a rate
The client has a handful of settings that really do change a transfer rate, and a much longer list of settings that do not. The ones that matter are the deliberate limits, because a limit set once and forgotten is the single most common self inflicted cause of a slow download.
| Setting | What it does | What goes wrong |
|---|---|---|
| Global download rate limit | Caps incoming payload across all torrents | Set during a call months ago and never cleared, or an alternate rate limit is active on a schedule |
| Global upload rate limit | Caps outgoing payload | Set to almost nothing, which starves the reciprocity the protocol runs on and gets you deprioritized by peers |
| Maximum connections | How many peer connections the client will hold at once | Set very low, so the client never reaches enough peers, or set absurdly high, which overwhelms a consumer router |
| Connections per torrent and upload slots | How the total is divided between active torrents | Ten torrents active at once, each with a share too small to be useful |
| Queueing and active torrent limits | How many torrents run rather than wait | A torrent that shows queued is not slow, it has not started |
| Protocol encryption mode | Whether the client requires, allows or refuses encrypted peer connections | Set to require, which refuses every peer that does not offer it, shrinking the usable swarm |
The order to work through them is short. Clear every rate limit and check whether an alternate limit schedule is switched on. Set the encryption mode to allow rather than require, which Encryption in a client explains in detail. Bring the number of active torrents down so that one transfer gets the whole connection instead of a tenth of it. Leave the connection limits near the client's defaults, which are chosen to work on ordinary hardware. qBittorrent covers where each of these lives in that program, and the equivalents in Deluge and uTorrent sit in the same kind of place under different words.
Last, the line itself and everything sharing it
The line is the capacity you actually have, and it is shared with everything else in the building. A transfer cannot exceed the downstream your provider sells you, cannot exceed what your Wi-Fi is delivering to that particular room, and competes with every video stream, game update and backup running at the same time. It is worth converting the units before deciding a transfer is slow, because lines are sold in megabits per second and clients report megabytes per second, a factor of 8: a 100 Mbit line tops out near 12 MB/s before any overhead, and a client showing 11 MB/s on it has nothing left to give. Three checks separate a line problem from the three causes above it.
- Compare against a plain download from a fast web source. If that is slow too, the transfer is not the problem.
- Move the machine onto a cable instead of Wi-Fi, or closer to the access point, and watch whether the ceiling changes.
- Watch the upstream. A saturated upload delays the acknowledgements every download depends on, which is why an unlimited upload rate can make a download slower on an asymmetric connection.
The disk sits at the end of the line and behaves like part of it. A client writes pieces as they arrive, and on a slow external drive, a nearly full disk, or a machine where a security product inspects every write, the client will throttle itself to whatever the disk can absorb. qBittorrent reports this plainly, since a transfer bottlenecked on writes shows as an overloaded disk queue rather than as a network problem.
The changes that do not make a transfer faster
Several popular adjustments change nothing, and knowing which they are saves the evening. Raising the maximum connection count into the thousands does not add peers that do not exist, and on consumer hardware it makes things worse. Switching client does not help, because qBittorrent, Deluge and uTorrent implement the same protocol and are limited by the same swarm; a difference between them on the same machine is a difference in their settings or in the swarm at the time of the test. Forcing a recheck does not speed anything up, it only reverifies what is already on disk.
A VPN or proxy service does not increase the speed of a transfer either. Such a service changes which address peers see and adds a hop between you and them, and unless it offers a forwarded port it removes the ability to accept incoming connections entirely, which is the firewalled state described above. It is a privacy tool with a speed cost, not a speed tool.
Why a transfer that was fast yesterday is slow today
A transfer that was fast yesterday and is slow today has almost always lost seeders rather than gained a fault. Swarms empty out on a schedule that follows people's evenings and their time zones, and a torrent that had a dozen complete copies at nine in the evening can have two at nine in the morning. The other durable answer is congestion: the same line delivers different capacity at different hours because the local segment is shared.
Where a slow transfer has instead stopped entirely, showing stalled, downloading metadata or checking resume data, it is a different problem with a different set of causes, and Stalled and stuck transfers covers what each of those states means. How a transfer works is the page underneath all of this: the piece by piece mechanism that decides what your client asks for and from whom.