qBittorrent has a proxy section, and filling it in correctly is not the same as filling it in. The gap between those two is one checkbox, and missing it leaves your actual traffic going out of your own connection while every setting on screen looks right.
Where the settings are
Tools, then Options, then Connection in the left-hand list. Scroll to Proxy Server.
Filling it in
- 1
Set Type to SOCKS5
Not HTTP. The reason is the whole point of this page and gets its own section below.
- 2
Put the host in Host and the port in Port
The address on its own with no
socks5://in front of it. The port your provider gave you for SOCKS5, which is a different number from the HTTP one and cannot be guessed. - 3
Tick Authentication and fill in the username and password
Skip this only if your proxy genuinely has no login, which means a free proxy or a provider using IP authorisation.
- 4
Tick Use proxy for peer connections
The important one. Without it the proxy carries the tracker conversation and nothing else.
- 5
Tick Use proxy for hostname lookup
Sends DNS through the proxy too. Without it your own resolver looks up every tracker, which announces what you're doing to your ISP regardless of the proxy.
- 6
Tick Disable connections not supported by proxies
Makes qBittorrent refuse rather than quietly fall back to a direct connection when the proxy can't carry something.
- 7
Click OK, then fully close and reopen qBittorrent
Existing connections and pending announces keep using the old settings. A change that looks like it failed has usually just not been restarted.
Why HTTP is the wrong choice here
This is the part most qBittorrent proxy guides skip, and it changes the outcome completely.
An HTTP proxy understands web requests. In a torrent client that means it can carry the announce to the tracker, and web seeds, and nothing else. Peer connections are raw TCP to hundreds of other machines, which an HTTP proxy has no way to represent. So those connections go out of your own address as normal.
The result is a client that appears configured, where the tracker sees the proxy and every peer sees you.
SOCKS5 moves raw connections without caring what's inside them, so it carries peer traffic as easily as tracker traffic. That's the whole reason it exists and it's why torrent clients offer it.
What each protocol actually covers in a torrent client
| Feature | HTTP proxy | SOCKS5 proxy |
|---|---|---|
| Tracker announces | yes | yes |
| Web seeds | yes | yes |
| Peer connections, the actual transfer | no | yes |
| DHT and peer exchange | no | yes |
| Works with the Use proxy for peer connections option | no | yes |
If your provider only gave you an HTTP port, ask for the SOCKS5 one before configuring anything. An HTTP proxy here produces a false sense of a job done.
Check that it applied
Setting it is not proof. Two checks, in order.
The quick one. qBittorrent's status bar shows connection state. If the proxy details are wrong, trackers move to a "not working" state within a minute or two rather than failing silently, which at least tells you the setting took effect.
The real one. Add a torrent whose tracker reports back the address it saw, or use one of the tracker-based IP check torrents that exist for exactly this. What you're looking for is your proxy's address rather than your own. Anything else means the traffic went direct.
Before either, confirm the proxy itself is alive and speaks SOCKS5, because a dead proxy and a misconfigured client look identical from inside a stalled download. Paste it into our proxy checker: it opens a real connection and reports which protocols answered, so you learn whether SOCKS5 is even available on that port before you spend an hour on settings.
Things that catch people out
The port is different for SOCKS5. The same proxy usually speaks HTTP on one port and SOCKS5 on another. Entering the HTTP port with the type set to SOCKS5 produces a connection that hangs, which reads exactly like a dead proxy.
Free proxies are the wrong tool here. A public proxy from a list is an accidentally open machine that will vanish, often within hours, and it has no capacity for sustained transfer. We say the same about our own free proxy list: it's useful for testing and for one-off requests, and a torrent client is neither.
A residential proxy will be slow for this. Residential traffic runs through somebody's home connection, so sustained multi-peer transfer is not what it's built for and you'll be paying per gigabyte for every byte of it. Datacenter or ISP proxies suit this job far better on both speed and cost.
Nothing else on your computer is proxied. The setting applies to qBittorrent alone. Your browser, your updater and everything else carry on as normal, which is often what you want, and is worth knowing rather than assuming.
The proxy has no credential fields in some builds. Older qBittorrent versions handled proxy authentication inconsistently. If the username and password won't stick, running a local relay that attaches the credentials for you sidesteps the problem entirely.