Which torrent clients work with a SOCKS5 proxy, and what each still sends direct

Of 15 widely used torrent clients, nine document a SOCKS5 proxy for peer connections: qBittorrent, Deluge, Tribler, BiglyBT, Tixati, BitComet, µTorrent Classic, BitTorrent Classic and rTorrent. Transmission and aria2 can proxy only their web requests, WebTorrent Desktop has no proxy setting, and Free Download Manager, Flud and Vuze document too little to say. Even the nine still leave something out, and which part differs from client to client.

This page is the overview. Each client has its own guide, linked in the table, with the settings and the evidence.

First: do you need a proxy for torrents at all?

Often not. The files people legitimately fetch over BitTorrent, distribution images, open-source releases, Internet Archive and Creative Commons items, research datasets, game and software patches, are fine to download from your own connection. Many also have an HTTP mirror, which puts nothing on a metered proxy.

A proxy fits a narrower job: one application leaving from a separate address while the rest of the machine does not, or a client that needs a fixed exit. It does not make unauthorised sharing acceptable. That is not allowed on ProxyPanda, and our acceptable use policy makes staying within the law your responsibility. Peer-to-peer traffic itself is fine with us: lawful torrents can run on our residential proxies and on dedicated ISP or datacenter IPs with no traffic cap.

And if your worry is privacy in public swarms because of copyright enforcement, a proxy is the wrong tool. qBittorrent's wiki says it as well as anyone: "If you are concerned about legal authorities and copyright trouble, for example, consider using a VPN instead (or in addition to it)." Proxy vs VPN is our plain comparison.

Four limits that apply to every client on ProxyPanda

Before the table, the limits that come from the proxy rather than the client:

1. Treat our SOCKS5 as TCP only. The SOCKS5 standard defines a UDP relay, and several clients will try to use it. We have not verified it on our gateways, as HTTP vs SOCKS5 says. DHT, UDP trackers and uTP all run over UDP, so expect none of them to work through us, whatever the client could do in principle. An HTTP proxy carries no UDP at all.
2. No incoming connections. Every client that documents this says a proxied client does not accept, or may not receive, connections from other peers. Port forwarding does nothing for it, and you see fewer peers.
3. No encryption. A proxy relays your connections. It encrypts nothing on the way to itself, and a SOCKS5 login crosses the network in plain text.
4. Two directions of traffic. A torrent downloads pieces and, while it seeds, uploads them to other peers. Both cross the proxy when peers are proxied. How each direction counts on your plan is written under metering.

The 15 clients at a glance

"Outside the proxy" means traffic the client sends from your own address, or switches off, while a proxy is set.

Client	Proxies peers over SOCKS5?	Outside the proxy, or switched off
qBittorrent	Yes, once two boxes that start off are ticked	With both ticked, UDP is refused, not leaked, when the proxy cannot relay it
µTorrent Classic	Yes	Whether UDP falls back to your own address is undocumented
BitTorrent Classic	Yes	As µTorrent: the help article is the same, word for word
Transmission	No	Peers, UDP trackers and DHT always go direct
Free Download Manager	Unconfirmed	Not documented for torrents at all
Vuze	Unverifiable	Documentation offline, last release 2017
Deluge	Yes, by default once a type is chosen	UDP is refused, not leaked, as in qBittorrent
Flud	Listed, not documented	Unknown
WebTorrent Desktop	No proxy setting	Everything
Tixati	Yes	DHT always goes direct; switch it off
Tribler	Yes, for zero-hop downloads	Anonymous downloads use Tribler's own network instead
BiglyBT	Yes, outgoing only	Extra peer sources and the DHT plugin, until you switch them off
BitComet	Yes, unless the bypass option is set for peers	DHT and UDP handling undocumented
rTorrent	Yes, from 0.16.16	UDP trackers, DHT and listening are switched off; logins look unreliable
aria2	No SOCKS at all	Peers, DHT and UDP trackers always go direct

What "outside the proxy" means in practice

The right-hand column falls into four groups, and they matter differently.

Refused rather than leaked

qBittorrent, Deluge and Tribler run on libtorrent. Its source shows that, with peer and tracker proxying both on, UDP packets for DHT, trackers and uTP are sent to the proxy, never around it: over SOCKS5 it asks the proxy for a UDP relay, and over HTTP or SOCKS4 the send simply fails. With peer proxying off, uTP traffic to peers goes direct like the rest of the peer traffic. Through a proxy that relays only TCP, which is how to treat ours, those features stop working instead of exposing your address. We saw this happen in qBittorrent; see the test below.

Switched off on purpose

rTorrent's wiki says that with a global proxy set, "UDP (trackers/dht) and listening ports are disabled." Nothing leaks; torrents that depend on UDP trackers or DHT just find no peers.

Sent from your own address

• Tixati: "It is not possible to use a proxy for DHT UDP packets."
• Transmission: its proxy_url covers HTTP(S) requests only; peers, UDP trackers and DHT never use it.
• aria2: HTTP proxies only, and its maintainer says "There is no proxy support for UDP traffic"; peers connect directly as well.
• BiglyBT: extra peer sources and the Mainline DHT plugin, which its wiki tells you to switch off.

Not documented

µTorrent and BitTorrent say UDP can be proxied only over SOCKS5, but not what happens when the proxy cannot relay it. BitComet, Flud, Free Download Manager and Vuze say less still. For these, the meter check at the end of this page is the most reliable evidence you will get.

Tracker-only proxying is not hiding anything from peers

Several clients can proxy the tracker but not the peers, by choice or by design: qBittorrent with only its outer box ticked, BitComet with its bypass option set for peers, BiglyBT with one checkbox of two, and Transmission and aria2 always. In that mode, the tracker operator sees the proxy's address, and every peer in the swarm sees yours. It costs almost no proxy traffic, which is why it can look like a working setup on the meter. It is not one.

What we ran, and what we only read

We tested three clients on 8 October 2026, in containers on our own machine, against small test proxies that log every request. Each time we used Debian 13.7.0's netinst torrent.

• qBittorrent 5.2.4 (qbittorrent-nox, libtorrent 2.1.0), through a SOCKS5 test server that relays TCP and refuses UDP. On a fresh install with only the host and port set, nothing went through the proxy. With both BitTorrent boxes ticked, 122 connections to 120 different addresses went through it, it asked once for a UDP relay, was refused, and sent no UDP around the proxy.
• Transmission 4.1.3, with proxy_url set to an HTTP test proxy. The proxy saw the tracker announce and requests to the torrent's web seed; peers connected to our own address.
• aria2 1.37.0, with --all-proxy set to the same HTTP test proxy. The same pattern: tracker and web seed through the proxy, 30 to 44 peer connections direct.

Everything else on this page comes from each client's own documentation or source code, and each guide says which. Where neither says anything, we have written "unconfirmed" rather than guess.

How to check any client: the meter

Whatever you choose, one test shows whether peers are going through the proxy:

1. Prove the proxy itself answers: curl -s -x socks5h://USERNAME:PASSWORD@HOST:PORT https://api.ipify.org should print an address that is not yours.
2. Note the traffic figure for your service in the dashboard. How to see how much traffic is left shows where.
3. Download a small, lawful torrent and note what the client says it transferred.
4. After a few minutes, since dashboard figures update regularly rather than live, compare.

About the same means peers went through the proxy. Barely moved means they did not. Slightly more on the dashboard is normal: protocol messages and discarded pieces count as traffic too. How to check your proxy provider's meter has the longer method.

Choosing a product and keeping the cost down

For a torrent client that runs for hours, a static ISP or datacenter IP is the steadier fit: one address in front of trackers and peers. If you seed heavily, choose a dedicated one with no traffic cap: it is billed per IP for its term, so seeding adds no per-gigabyte cost. Residential is fine for lawful P2P too, but it is metered by the gigabyte. Set an upload limit or a stop ratio while the proxy is on. In most clients the proxy applies to every torrent at once, so switch it off when you run torrents that do not need a separate address. Seeding open-source releases is good citizenship; on a metered proxy it is also paid traffic, so decide how much of it you want. Rates are on the pricing page.

Quick answers

Which torrent client is best with a SOCKS5 proxy? The ones that document every switch: qBittorrent, Deluge and BiglyBT. Which suits you depends on the rest of your setup.

Can a SOCKS5 proxy carry DHT? Only if both the client and the proxy relay UDP. We have not verified that on our gateways, so do not count on it with us.

Does an HTTP proxy work for torrents? For trackers and web seeds. Not for UDP, and for peers only where the proxy tunnels to arbitrary ports.

Will a proxy make my torrents faster? No. Losing incoming connections usually means fewer peers.

Next step

Pick the client you already use from the table, follow its guide, and run the meter check once. If something does not match what we have written, tell us in Discord: these pages get updated when a reader finds a difference.