An rTorrent proxy became a first-class setting in version 0.16.16, released on 3 July 2026, whose notes describe "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". Before that, rTorrent had only an HTTP proxy for its libcurl requests. For the platform owner running rTorrent on a seedbox-style host, usually behind ruTorrent, the new commands make it possible to state that peers and trackers leave through one exit. Two details in the current release decide whether that statement is true: how credentials are handled, and who can change the setting over XML-RPC.
rTorrent is very actively developed; v0.16.25 and ruTorrent v5.3.16 were both released on 5 October 2026. Facts below are from the release notes, the project wiki page "Proxy-Configuration" and the source at v0.16.25. We did not run rTorrent for this article.
Approval for a seedbox-style host
A host that seeds around the clock needs the policy settled before the configuration:
- Is continuous peer-to-peer egress approved for the network or hosting provider the machine sits on?
- What will it seed? Distribution images, open-source release torrents, research datasets. Keep the list with the change request.
- Does it need a proxy at all? A dedicated host with an approved address can seed from that address, and the egress statement is then the host's address. A proxy is justified when policy requires traffic to leave through a named exit.
A seedbox's traffic is fine on our side when the content is lawful: peer-to-peer is allowed on residential exits and on dedicated ISP and datacenter addresses with no traffic meter. Using a ProxyForge exit for unauthorised sharing breaches our acceptable use policy.
The cost and coverage limits
- Around-the-clock seeding through a metered exit is expensive by design. Every byte uploaded to a peer crosses the gateway, on top of the original download, and a seedbox exists to upload. Estimate against our gigabyte definition before enabling it, and set upload limits. For many seedbox workloads a per-GB proxy is simply the wrong tool. If the seeding must leave through one of our exits, a dedicated ISP or datacenter address has no traffic meter, up to its port speed, and suits a seedbox better than any per-GB line.
- UDP is off by design. With the global proxy set, "UDP (trackers/dht) and listening ports are disabled", per the wiki. That also suits our gateways: treat ProxyForge's SOCKS5 endpoints as TCP only, since UDP relay through them has not been verified. HTTP proxies cannot carry UDP in any case.
- No encryption. A proxy relays bytes, and SOCKS5 credentials, where used, cross in cleartext.
- Anything outside the proxy shows the host's address. With UDP and listening disabled, the remaining risk is a setting changed at runtime, covered below.
- A proxy is not a privacy measure. For copyright exposure, torrent client projects point people to a VPN; qBittorrent's wiki says so explicitly. The working control is seeding only what you may.
The proxy commands in 0.16.16 and later
| Command | Scope | Notes |
|---|---|---|
network.proxy.global.set |
All proxied traffic, including peer connections | http://host:port, socks5://user:pass@host:port, socks5h://user:pass@host:port |
network.proxy.http.set |
HTTP requests made through libcurl, such as tracker announces | "Sets HTTP proxy (overrides global)"; "Supports all native libcurl schemas" |
network.http.proxy_address.set |
The pre-0.16.16 HTTP proxy | Deprecated; remove it from old configurations |
Use socks5h:// so hostnames are resolved at the proxy. Peer proxying is documented for SOCKS5; what happens to peer connections with an http:// global proxy is not stated, so choose SOCKS5.
A block for .rtorrent.rc
The wiki's own example is network.proxy.global.set = "socks5h://user:[email protected]:1080". Because of the credential issue below, the configuration we would put in front of a reviewer authenticates the host by source address and carries no password:
network.proxy.global.set = "socks5h://PROXY_HOST:PROXY_PORT"
Put it in ~/.rtorrent.rc for the user rTorrent runs as, and restart rTorrent so it takes effect from the first connection. Remove any network.http.proxy_address.set line left from an older setup, so the configuration has one source of truth.
Credentials: what the source does at v0.16.25
The wiki documents user:pass in the SOCKS5 URL. The client's source at tag v0.16.25 shows something narrower. In libtorrent/src/torrent/runtime/proxy_manager.cc, the user and password are parsed from a socks5:// URL, and the SOCKS5 connection is then constructed as ProxySocks5(&proxy_union.sa, connect_sa), without them; the constructor defaults both to empty strings.
Read literally, an authenticated SOCKS5 proxy would see peer connections arrive without credentials and refuse them. Treat socks5h:// the same way until tested. The HTTP side is handled separately through libcurl, which may authenticate where the peer side does not, so a configuration with credentials can show trackers working and peers failing. Two ways forward:
- Use IP allowlisting. The gateway accepts connections from the host's registered address with no credential, so nothing depends on the client passing one. IP allowlist vs username and password covers the trade-offs, including what to do when the host's address can change.
- Test before relying on credentials. If the release you deploy is newer than v0.16.25, check its notes and source for a fix, then verify with the steps below.
XML-RPC can change the proxy at runtime
network.proxy.global.set and network.proxy.http.set are marked RPC-safe in command_network.cc. Any process with access to rTorrent's XML-RPC interface, which is how ruTorrent and automation tools talk to it, can set or clear the proxy while the client runs. Whether ruTorrent exposes a proxy setting in its interface could not be confirmed, but the capability does not depend on that.
For the review, that makes the XML-RPC endpoint part of the egress control. Restrict it to a local socket or the front-end that needs it, keep ruTorrent behind authentication, and treat access to either as the ability to change where the host's traffic goes. Periodic verification, below, catches a change that was not made through configuration management.
Verifying from the host
Three checks, all from the host itself, with rTorrent seeding a lawful torrent:
ss -tnp | grep rtorrent
ss -unp | grep rtorrent
ss -tlnp | grep rtorrent
- Established TCP connections should all point at the gateway.
- There should be no UDP sockets, since UDP trackers and DHT are disabled while the proxy is set.
- There should be no listening socket for peers. If you exposed XML-RPC on a TCP port, that one will appear; nothing else should.
Run the same checks from a scheduled job and alert on a change; it is the cheapest way to catch a runtime edit over XML-RPC. Record the exit address once with the proxy checker.
Checklist for a seedbox-style host
- Continuous peer-to-peer egress approved; seeded sources listed
- Proxy justified over seeding from the host's own approved address
- rTorrent 0.16.16 or later; deprecated
network.http.proxy_address.setremoved -
network.proxy.global.setwithsocks5h://and IP allowlisting, or credentials tested on this build - XML-RPC restricted, and ruTorrent behind authentication
-
sschecks scheduled, with an alert on change - Upload limits and a gigabyte estimate that covers continuous seeding
For a headless alternative on the libtorrent-rasterbar engine, see qBittorrent, whose qbittorrent-nox starts with peer proxying off on a fresh install and needs both BitTorrent boxes checked whatever its history. All fifteen clients are compared in torrent client proxy support compared.