Transmission proxy: proxy_url in settings.json, and what our test run showed it does and does not carry

Transmission has no proxy field anywhere in its interface. Since version 4.1.0 it reads one key, proxy_url, from settings.json, and its documentation scopes it to "HTTP(S) requests (for example, requests to tracker)". We ran Transmission 4.1.3 with that key pointing at an authenticating SOCKS5 server and counted connections. The tracker announce and the web-seed downloads went through the proxy. The peers did not, and neither did any UDP.

That makes Transmission the clearest case of a rule that holds for every client here: what the client sends outside the proxy leaves from your own address. For Transmission that is almost everything. The other limits, briefly: a proxy does not encrypt; residential traffic and traffic beyond a shared IP's included gigabyte is billed per GB, and the terms describe how it is counted; treat our SOCKS5 as TCP only, so UDP features would not run through it even in a client that tried; an HTTP proxy carries no UDP. The qBittorrent project's wiki tells people worried about copyright trouble to consider a VPN, which is the right tool for that question. Using our proxies for unauthorised sharing is not allowed; the allowed-use policy is the line.

#The run

On 2026-10-08, in a Docker container on Alpine Linux edge, we started transmission-daemon 4.1.3 with this settings.json:

{
  "proxy_url": "socks5h://lab:labpass@hb-socks:1080",
  "download-dir": "/downloads",
  "speed-limit-down": 1024,
  "speed-limit-down-enabled": true,
  "speed-limit-up": 256,
  "speed-limit-up-enabled": true,
  "rpc-whitelist-enabled": false
}

The proxy was Dante 1.4.4 with username and password, refusing UDP ASSOCIATE so it behaved like a TCP-only gateway. We added the Debian 13.7.0 netinst torrent, waited 90 seconds, captured 60 seconds of UDP and listed established TCP connections with ss.

So the credentials inside proxy_url worked, which Transmission's own docs do not state, and the scope in the docs is exact: libcurl requests use the proxy, the peer engine does not.

#Set proxy_url

1. Quit the client. The docs warn that settings edited while it runs are reverted.
2. Open settings.json in the client's configuration directory.
3. Add the key with the SOCKS5 port from your order:

"proxy_url": "socks5h://USERNAME:PASSWORD@HOST:SOCKS5_PORT"

Accepted schemes are http, https, socks4, socks4h, socks5 and socks5h. Use socks5h so tracker hostnames are resolved by the proxy rather than your own resolver. A null value means Transmission follows the curl environment variables; an empty string means no proxy.

4. Start the client again, or for transmission-daemon send it SIGHUP to reload.

Version 4.1 is moving keys to snake_case; the older kebab-case names still work. Keys from the 1.4x era, the proxy-* family, are legacy options. They do not configure anything current, whatever an old forum post says.

#Web seeds go through the proxy, and that costs traffic

The Debian torrent lists two web seeds on cdimage.debian.org. In our run Transmission's connections to them went through the proxy: a web seed is an HTTPS request, and HTTPS requests are what proxy_url covers. That is payload, not a few kilobytes of tracker chatter, and on a per-GB plan it is billed like any other traffic. A torrent with web seeds can therefore run up proxy traffic while hiding nothing from the swarm.

To estimate it, count what the proxy carries: on Linux, ss -Htnp state established | grep transmission lists the client's connections; the ones to your proxy's address and port are the billable part. A residential gigabyte at the 10 GB rung is $3.95/GB, and a datacenter IP at $1.90/IP (dedicated) a month has no bandwidth cap. Peer-to-peer traffic for lawful content is fine on residential and on dedicated ISP and datacenter IPs, which carry no traffic meter. The cost calculator compares the two for your volume.

#Check it on your own install

On a desktop, the same three commands answer the question:

ss -Htnp state established | grep -i transmission
ss -Huanp | grep -i transmission
sudo tcpdump -ni any -c 50 udp port LISTEN_PORT

The first shows peers at their own addresses. The second shows the UDP port the client listens on; put it into the third, and every line from your machine to a public address is uTP or DHT leaving direct. On macOS, lsof -nP -i -a -c Transmission lists the same sockets. The exit address to compare against is the one the curl line on our proxy checker prints through your proxy.

#When the peers need to be proxied

Transmission cannot do it. The choices are a client that proxies peer connections, such as qBittorrent with both BitTorrent boxes ticked, or a VPN when the goal is to hide your address from the swarm. On a NAS or router where Transmission is the only client available, use proxy_url for what it is: a way to reach a tracker or mirror through a different address, not cover in the swarm.

Our comparison of 15 torrent clients puts Transmission next to the others on peers, trackers, DHT and UDP.