Transmission Proxy Variables Affect HTTP Trackers, Not Peers
Separate Transmission's HTTP tracker requests from peer connections and DHT before treating a changed tracker route as a proxied download.
A tracker responds after you give Transmission a proxy URL built from your service's details or an entry in a proxy list. That can fix tracker access without changing where the torrent's peer traffic goes.
Transmission's environment-variable documentation identifies libcurl as the component making HTTP and HTTPS tracker announces and scrapes. Proxy variables consumed by that library customize those requests. They are not a global network policy for the whole application.
| Operation | What the tracker-proxy setting establishes |
|---|---|
| HTTP or HTTPS tracker request | The libcurl request can select the configured proxy |
| Connection to a peer | No conclusion from that tracker result |
| DHT or other UDP activity | No conclusion from that tracker result |
A torrent can contain several discovery mechanisms. Receiving a peer list through a proxy is therefore compatible with later connections leaving through an ordinary interface.
If you run the daemon, its environment also belongs to that service, rather than the terminal running a remote-control command. On systemd-based installations, set the variables on the daemon service. Supplying the right variable to the right process is necessary for the documented libcurl path; it still does not enlarge that path's scope.
Describe a result per operation. “The tracker request used the proxy” is useful. “The download's network identity changed” needs evidence about the peer connections carrying the data.