Torrent client proxy support varies far more than the settings screens suggest. Some clients route trackers and peers through a proxy by default, some start with the important box unticked on a fresh install, some can only send tracker requests through it, and one has no proxy setting at all. Every one of them leaves something outside the proxy unless it is configured and verified. This comparison covers fifteen clients from the point of view of the person who has to state, for a reviewer, what a host running one of them sends out and through which exit.
Each row links to a per-client guide with the sources. Facts come from each project's own documentation, release notes, help pages or source code, and where a primary source could not be found, the table says so rather than filling the gap. We did not run these clients for this comparison.
The policy question comes before the client
Whichever client is chosen, three answers belong in the change request before any configuration:
- Is BitTorrent permitted on this network? Many egress policies say no regardless of content. A proxy changes where the traffic appears to come from, not whether it is allowed.
- What is the data source? The lawful cases are specific and common: distribution images, open-source release torrents, Internet Archive items (more than 1.4 million are available over BitTorrent, by the Archive's own count), research datasets, game and software patches, internal large-file distribution.
- Who approves the exit, and which one? A named proxy, a VPN, or the host's own address.
Using a ProxyForge exit to share material without the right to distribute it is prohibited by our acceptable use policy, whatever the client.
What any proxy can carry for BitTorrent
Four protocol facts explain most of the table below.
- HTTP proxies carry HTTP. Tracker announces and web seeds work through any HTTP proxy. Peer connections need a tunnel for arbitrary TCP, which means
CONNECTor SOCKS, and many HTTP proxies only allowCONNECTto port 443. - UDP needs SOCKS5, and SOCKS5 needs the server's help. DHT, UDP trackers and uTP all run over UDP. Only SOCKS5 defines UDP relaying, through
UDP ASSOCIATE, and only if the proxy server implements it. - A proxied client is unreachable. Clients that proxy peers stop accepting incoming connections, so port forwarding does nothing, fewer peers are reachable, and two proxied peers cannot connect to each other. Seeding still works over outgoing connections.
- Tracker-only proxying is not masking. It hides the host from the tracker operator while every peer sees the host's address on the data connection. It also costs almost no proxy traffic, which is why it can look like a working setup.
SOCKS5 vs HTTP proxy covers the protocol details.
What changes on ProxyForge gateways
Four limits apply to every row:
- Treat our SOCKS5 endpoints as TCP only. UDP relay through them has not been verified, so DHT, UDP trackers and uTP will not work through our proxy even in clients that can request a relay.
- On per-GB lines, metering covers both halves of a torrent. With peers proxied, the download crosses the gateway and every byte seeded crosses it again. How a gigabyte is counted is published in the FAQ.
- A proxy does not encrypt. It relays bytes; SOCKS5 credentials cross in cleartext.
- Peer-to-peer traffic for lawful content is fine on residential exits and on dedicated ISP and datacenter addresses, which have no traffic meter. Residential is metered per gigabyte; a dedicated address is unmetered up to its port speed, which makes it the cheaper place to seed from. Datacenter addresses come from our own ranges and can be checked in public registries; sourcing and compliance explains how each line is sourced. Check the traffic terms of whichever line you choose on its pricing page.
Where it is set and what it accepts
| Client | Where the setting is | Proxy types | Basis |
|---|---|---|---|
| µTorrent Classic | Options > Preferences > Connection | SOCKS4, SOCKS5, HTTP Connect, HTTP | Vendor help article |
| BitTorrent Classic | Options > Preferences > Connection | SOCKS4, SOCKS5, HTTP Connect, HTTP | Vendor help article |
| qBittorrent | Tools > Options > Connection > Proxy Server | SOCKS4, SOCKS5, HTTP | Source, release-5.2.4 |
| Transmission 4.1+ | proxy_url in settings.json; no interface field |
http, https, socks4, socks4h, socks5, socks5h | Docs and source, 4.1.3 |
| Free Download Manager | Settings > Network > Configure manually | Not documented | Vendor tutorial |
| Vuze | Not verifiable | Not verifiable | Documentation offline |
| Deluge | Edit > Preferences > Proxy, applied by the daemon | Socks4, Socks5, Socks5 Auth, HTTP, HTTP Auth, I2P | Source |
| Flud | Not documented | Not documented | Play listing |
| WebTorrent Desktop | No setting | None | Source |
| Tixati | Help page "Settings - Network - Proxy" | SOCKS4, SOCKS4a, SOCKS5, HTTP | Help page |
| Tribler | Settings > Connection > Torrent proxy settings | Socks4, Socks5, HTTP, each with or without authentication except Socks4 | Source, v8.4.3 |
| BiglyBT | Tools > Options > Connection > Proxy Options, advanced mode | SOCKS 4, 4a, 5; HTTP | Project wiki |
| BitComet | Proxy section of the Options dialog | Socks4, Socks4a, Socks5, HTTP1.1 | Help page |
| rTorrent 0.16.16+ | network.proxy.global.set in .rtorrent.rc, or over XML-RPC |
http, socks5, socks5h | Release notes, wiki, source |
| aria2 | --all-proxy and per-protocol flags |
HTTP only | Manual, issue tracker, source |
What each one covers
| Client | Trackers | Peers | DHT, UDP trackers, uTP |
|---|---|---|---|
| µTorrent, BitTorrent Classic | Yes | Not with a plain HTTP proxy | Only over SOCKS5 |
| qBittorrent | Only with "Use proxy for BitTorrent purposes", off on a fresh install | Only with "Use proxy for peer connections", off on a fresh install | Relayed over SOCKS5; refused, not leaked, over HTTP or SOCKS4 |
| Transmission | HTTP(S) trackers only | Never | Never; direct |
| Free Download Manager | Not confirmed | Not confirmed | Not confirmed |
| Vuze | Not confirmed | Not confirmed | Not confirmed |
| Deluge | Yes, on by default | Yes, on by default | As qBittorrent, through the same engine |
| Flud | "Proxy Support for trackers and peers" | As stated | Not confirmed |
| WebTorrent Desktop | No | No | No |
| Tixati | Selectable | Selectable | DHT never; UDP trackers and UDP peers not confirmed |
| Tribler | Zero-hop downloads only | Zero-hop downloads only | As qBittorrent, for zero-hop downloads |
| BiglyBT | Separate switch | Separate switch; SOCKS only; outgoing only | Tracker announces and scrapes over SOCKS 5; not peers |
| BitComet | Yes, unless exempted | Yes, unless exempted | Not confirmed |
| rTorrent | Yes | Yes, over SOCKS5 | Disabled while the proxy is set |
| aria2 | HTTP trackers only | Never | Never; direct |
"Relayed over SOCKS5" in that table describes the client. On our gateways, as above, the relay should be expected to fail.
What each one leaves outside the proxy
| Client | Left outside unless you act | What closes it |
|---|---|---|
| µTorrent, BitTorrent | Undocumented; possibly UDP | SOCKS5, then a capture |
| qBittorrent | Everything BitTorrent on a fresh install; peers on some upgraded installs | Check both boxes whatever the history; restart; assert them in config |
| Transmission | Peers, uTP, UDP trackers, DHT | Nothing in the client; route the host |
| Free Download Manager | Unknown | Three captures: HTTP, trackers, peers |
| Vuze | Unknown | Replace with BiglyBT |
| Deluge | Little, if the defaults are untouched | Keep the checkboxes on; capture |
| Flud | Unknown | Capture at the access point; device-level control |
| WebTorrent Desktop | Everything | Route the host |
| Tixati | DHT | Disable DHT; enforce with an egress rule |
| Tribler | Every hop download, by design | Permit zero-hop downloads only |
| BiglyBT | Peer sources beyond trackers; the DHT plugin | Deselect them; uninstall the plugin |
| BitComet | Whatever is exempted; UDP unknown | No exemption; capture |
| rTorrent | Runtime changes over XML-RPC | Restrict XML-RPC; scheduled checks |
| aria2 | Peers, DHT, UDP trackers | Use the HTTP mirror instead |
Four patterns behind the leaks
Across the fifteen clients, traffic ends up outside the proxy in four recurring ways:
- Defaults that do less than they appear to. qBittorrent is the clearest case: on a fresh install both BitTorrent boxes start unticked, so host and port are filled in and no BitTorrent traffic is proxied, while a settings file converted from an older version can have only the outer box on, which proxies trackers and not peers. Check both boxes whatever the install's history.
- Proxying by design limited to trackers. Transmission's
proxy_urland aria2's--all-proxycover HTTP requests, and peers never use them. - UDP that cannot be proxied. Tixati's DHT, aria2's DHT and UDP trackers, and anything on an HTTP proxy. Some clients refuse the traffic, some send it directly.
- Traffic the configuration screen does not describe. Tribler's hop downloads, BiglyBT's DHT plugin, rTorrent's runtime XML-RPC.
A configuration review catches the first. Only a capture on the host catches all four. Each guide includes one; the simplest form on Linux hides the proxy connection and shows whatever is left:
sudo tcpdump -ni any 'not (host PROXY_IP and tcp port PROXY_PORT) and not port 22 and not net 127.0.0.0/8'
Where the documentation runs out
Some rows rest on thin evidence, and the guides say so. Not confirmed from primary sources: Free Download Manager's proxy types and whether its setting reaches the torrent engine; everything about Vuze, whose documentation is offline; Flud's types, authentication and UDP behaviour; µTorrent's and BitTorrent's authentication fields and privacy options, and proxy support in their Web editions; Tixati's authentication; BitComet's authentication and UDP behaviour; authenticated SOCKS5 for rTorrent peer connections, which the source at v0.16.25 appears not to pass through. For each, measure on your own build rather than rely on a guide.
When a metered proxy is the wrong tool
For many torrent workloads on managed infrastructure, a per-GB proxy is not the right answer, and saying so is part of an honest egress review:
- Fetching a file once. The project's HTTPS mirror and published checksum deliver the same bytes in one transfer with nothing seeded. This covers most build-server cases.
- Long-term seeding. A host whose job is uploading pays for every byte through a metered exit. Seeding from an address approved for the swarm is cheaper and simpler to state. If the seeding has to leave through one of our exits, a dedicated ISP or datacenter address carries it with no traffic meter, up to the address's port speed.
- Privacy from rightsholders. A proxy covers one application and encrypts nothing. Client projects recommend a VPN for that concern, and the only reliable control is to share only what you may.
- Clients that cannot be pinned. For Transmission's peers, aria2's peers and WebTorrent Desktop, the control is the host's route, not a proxy.
A proxied torrent fits when policy requires traffic to leave through a named exit and the swarm is the distribution channel the publisher provides.
Choosing a client for a managed host
If a proxied client is the right tool, the best-documented options are, in order of how much a reviewer can verify:
- BiglyBT, whose wiki states what every option covers and what it does not.
- qBittorrent or Deluge, whose behaviour is readable in source, with both of qBittorrent's BitTorrent boxes checked on every host, fresh or upgraded.
- rTorrent 0.16.16 or later on a server, with IP allowlisting instead of credentials and its XML-RPC locked down.
Avoid Vuze and WebTorrent Desktop on managed hosts, and use Transmission and aria2 only where tracker-level proxying is all that is required.
A checklist that works for any client
- BitTorrent approved on this network, and content sources recorded
- Exit named: vendor, line and address, or the host's own address
- Peers proxied, not only trackers, if a single exit is the requirement
- SOCKS5 with hostname resolution at the proxy, or IP allowlisting where credentials are unproven
- DHT, peer sources and UDP features disabled where the client cannot proxy them
- Upload capped, and the gigabyte estimate includes seeding
- Capture on the host attached, showing nothing outside the proxy endpoint
- Exit address recorded with the proxy checker
If a workload does not fit neatly in any row, an engineer can look at it with you before anything is ordered; talk to us.