Transmission proxy settings: what proxy_url covers, and what it never will

Transmission proxy settings, in one sentence: there is no proxy field in the app, and Transmission cannot send its peer connections through a proxy at all. Since version 4.1.0 a proxy_url key in settings.json sends its web requests, such as HTTP tracker announces and web seeds, through a proxy. Peers, UDP trackers and DHT always use your own connection.

So if you want peers to see a proxy's address, Transmission is the wrong client, and no setting will change that. If you only want a Linux image, which is what many people use Transmission for because Ubuntu ships it, you probably do not need a proxy at all.

What does proxy_url actually cover?

The 4.1.0 release notes say: "Added support for using a proxy server for web connections." Transmission's configuration documentation describes the key like this:

Proxy for HTTP(S) requests (for example, requests to tracker). Format [scheme]://[host]:[port], where scheme is one of: http, https, socks4, socks4h, socks5, socks5h.

Those requests go through libcurl, and the client's source shows the proxy is set only there. In practice:

Traffic	Through proxy_url?
HTTP and HTTPS tracker announces	Yes
Web seeds (files fetched from an HTTP mirror)	Yes
Peer connections, over TCP or uTP	No
UDP trackers	No
DHT	No

A SOCKS5 scheme in that list does not change the table. It changes how the web requests reach the proxy, nothing else.

We ran it: what went through the proxy

We wanted to see this rather than repeat it. On 8 October 2026 we ran transmission-daemon 4.1.3, the Alpine Linux package, in a container on our own machine. We pointed proxy_url at a local HTTP proxy (tinyproxy) that logs every request, added Debian 13.7.0's netinst torrent, and let it run for 45 seconds.

The proxy's log showed three kinds of request from Transmission, trimmed here:

CONNECT ip4.transmissionbt.com:443 HTTP/1.1
GET http://bttracker.debian.org:6969/announce?info_hash=...&port=51413&event=started HTTP/1.1
CONNECT cdimage.debian.org:443 HTTP/1.1

The last one appeared eight times: those were web-seed downloads from Debian's own server. Meanwhile Transmission reported 50 connected peers, and the container's connection list showed the daemon talking to dozens of peer addresses directly. Only five of its connections went to the proxy. That is the table above, live.

Two things to take from it. The proxy saw the tracker, so the tracker operator would see the proxy's address. Every peer saw ours. And web seeds are real file data: on a torrent that lists them, part of the download crosses the proxy and counts as traffic.

The limits to know before you edit anything

• Peers are never proxied. Not with SOCKS5, not with HTTP. Anyone in the swarm sees your own IP.
• UDP is out of reach anyway. Even in clients that can proxy peers, we treat SOCKS5 on ProxyPanda as TCP only, since we have not verified a UDP relay on our gateways, and an HTTP proxy carries no UDP at all. HTTP vs SOCKS5 explains the difference.
• No encryption. A proxy relays requests. It encrypts nothing on the way to itself.
• For copyright worries, a proxy is the wrong tool. The torrent projects that document this point people to a VPN; proxy vs VPN sets out why.

And the rule that applies whatever the client: use BitTorrent through ProxyPanda for things you may share, such as distribution images, open-source releases, Internet Archive and Creative Commons items or research data. Unauthorised sharing is not allowed on our network, and the acceptable use policy makes staying within the law your job. Peer-to-peer traffic as such is fine on our residential proxies and on dedicated ISP or datacenter IPs with no traffic cap, as long as the content is lawful.

How to set proxy_url

1. Close Transmission, or stop the daemon. The documentation is blunt about why: "otherwise settings will be reverted".
2. Open settings.json in Transmission's configuration folder. Where that folder is depends on your system and on which Transmission you run; the project's "Editing Configuration Files" page lists the locations.
3. Set the key. For SOCKS5 with the proxy resolving names:

"proxy_url": "socks5h://HOST:PORT",

http://HOST:PORT works as well, since only web requests go through it either way.

4. Start Transmission again. The daemon also rereads its settings when it receives SIGHUP.

Three details that trip people up:

• null and "" mean different things. With null, the default, Transmission "respects the CURL environment variables", so a proxy variable set in your shell can quietly apply. With an empty string, no proxy is used.
• Username and password are unconfirmed. Transmission's documentation does not mention a login. libcurl accepts one inside a proxy URL, but we could not confirm that Transmission passes it through. The simple way round it is to add your machine's address to the IP allowlist, so the proxy does not ask for a login.
• Old proxy keys are not current. The 1.4x-era keys beginning proxy- are listed under "Legacy Options" in the same documentation. Version 4.1 is also moving keys to snake_case, and the old kebab-case names still work.

The documentation names settings.json for the GTK app, the daemon and the command-line client. We could not confirm whether the macOS and Qt apps read proxy_url too.

What else the default settings turn on

Running transmission-daemon --dump-settings on 4.1.3 printed "proxy_url": null together with "dht_enabled": true, "pex_enabled": true, "lpd_enabled": true and "utp_enabled": true. Setting proxy_url changes none of those, and all four work outside any proxy.

What it costs, and how to read the meter

Tracker announces are small. Web seeds are not, as our test showed. So the honest expectation is: your proxy traffic stays low on a torrent with no web seeds, and can be a good share of the file on one that has them. How a gigabyte is counted is written up under metering.

To check, note the service's traffic figure in the dashboard, run the torrent, and look again after a few minutes, since the figures update regularly rather than live. How to see how much traffic is left shows where to look. Compare it with what Transmission reports as downloaded. A small movement means only announces went through. A larger one is web-seed data. Either way, the peers' share of the download never reaches the proxy, so it will never show on the meter.

If you need peers to go through a proxy

Use a client that does it and documents it. In qBittorrent you tick two boxes that start switched off; in Deluge peers are proxied as soon as you choose a proxy type. The comparison of torrent clients and SOCKS5 covers the rest.

Quick answers

Does Transmission support SOCKS5? Only for its web requests, through proxy_url, since 4.1.0. Peer connections are never proxied.

Where is the proxy setting in Transmission? There is none in the preferences window. It is the proxy_url key in settings.json.

Will proxy_url hide my IP from peers? No. Our test showed peers connecting to our own address while the tracker saw only the proxy.

Does it work in Transmission 4.0? No. The key arrived in 4.1.0, and when we ran --dump-settings on a 4.0.6 build it printed no proxy key at all.

Next step

If Transmission is set up the way you like and you only need a Linux image, skip the proxy and take the mirror or the torrent as it is. If you need a proxied client for a lawful job and are unsure which, ask in Discord before you top up.