rTorrent gained proxy support for peer connections in version 0.16.16, released 2026-07-03: "new proxy support, using network.proxy.global.set and network.proxy.http.set, with http://, socks5:// and socks5h:// support", and "support for socks5 for peer connections". One line in ~/.rtorrent.rc sends trackers and peers through a SOCKS5 proxy, and while it is set the client disables UDP trackers, DHT and its listening ports. The catch is authentication. The project's wiki documents socks5h://user:pass@host:port, and the source of rTorrent's own libtorrent library (not the libtorrent-rasterbar that qBittorrent and Deluge use) at the current tag, v0.16.25, parses that user and password and then does not hand them to the SOCKS5 connection. On a seedbox, the robust answer is an IP allowlist.

We wanted to test that last point and could not: the rTorrent package in our Alpine Linux lab image was 0.16.12, older than the proxy support. So the credentials finding below is from the source, worded as such, and the check at the end is how you test your own build.

What changes when the global proxy is on

The wiki's own summary: "UDP (trackers/dht) and listening ports are disabled." In practice:

  • Peers and HTTP trackers go through the proxy.
  • DHT and UDP trackers stop. Nothing UDP leaves around the proxy, and torrents that depend on DHT or a UDP-only tracker will find fewer peers or none.
  • No listening port. The client only connects out, so it reaches peers that accept connections.
  • network.proxy.http.set "Sets HTTP proxy (overrides global)" and "Supports all native libcurl schemas", for the client's HTTP requests.
  • network.http.proxy_address, the old setting, is deprecated.

Our side of the line: treat our SOCKS5 as TCP only, since we do not advertise UDP relay, which fits rTorrent's behaviour exactly. A proxy does not encrypt, so tracker announces and peer traffic are as readable as they would be without it. Residential traffic, and traffic past a shared IP's included gigabyte, is billed per GB, and a 24/7 seeder pays for every byte out; the terms describe the count. A copyright-enforcement concern is a VPN question, as the qBittorrent wiki tells its users, and unauthorised sharing through our proxies is not allowed under the allowed-use policy.

Credentials: what the source shows

At tag v0.16.25, libtorrent/src/torrent/runtime/proxy_manager.cc reads the user and password out of a socks5:// URL and constructs ProxySocks5(&proxy_union.sa, connect_sa) without them; the constructor's defaults are empty strings. Read literally, a proxy that requires a username and password would refuse rTorrent's peer connections even though the URL contains them. We have not tested it at runtime, so treat it as a strong reason to test rather than a proven failure.

Use an IP allowlist instead

A seedbox has a fixed public address, which is the case an allowlist is made for:

  1. In the dashboard, switch the order's authentication to the IP allowlist and add the seedbox's public IP.
  2. Leave credentials out of the URL:
network.proxy.global.set = "socks5h://HOST:SOCKS5_PORT"
  1. Restart rTorrent, or set it at runtime over XML-RPC; both proxy commands are marked RPC-safe in command_network.cc.

socks5h hands hostnames to the proxy to resolve. Proxy authentication: allowlist vs password covers what an allowlist protects against and what it does not.

Check it on the server

On the seedbox, with a lawful torrent such as a distribution image active:

PROXY=203.0.113.10:1080
ss -Htnp state established | grep rtorrent \
  | awk -v p="$PROXY" '$4 == p { via++ } $4 != p { direct++ } END { print "via proxy:", via+0, "direct:", direct+0 }'
ss -Htlnp | grep rtorrent
ss -Huanp | grep rtorrent

With the proxy working: every established connection is to the proxy, the second command shows no listening port for peers (an SCGI or XML-RPC port you opened yourself will still appear), and the third shows no UDP socket for DHT. If peer connections fail while the tracker answers, check the proxy's authentication method first; that is the credentials question above, answered on your build. Run the curl line from our proxy checker on the same box to see the exit address the swarm should see.

What a 24/7 seeder costs per GB and per IP

On a seedbox that seeds Linux distributions or open datasets around the clock, the meter never stops. Seeding 100 GB a month through the proxy is $265.00 on residential at checkout, recurring. A datacenter IP is $1.90/IP (dedicated) a month with no bandwidth cap, bounded by port speed and fair use, and as a static address it gives the swarm one exit to see, which keeps the check above unambiguous. Peer-to-peer traffic for lawful content is fine on residential and on dedicated ISP and datacenter IPs, which carry no traffic meter. Run your own monthly volume through the cost calculator before you pick.

For a client whose authenticated SOCKS5 we did test on peer connections, see Deluge. All fifteen clients are compared in the torrent client proxy table.