aria2 proxy for torrents: --all-proxy reaches the tracker, never the peers, and here is the packet count

aria2 takes one proxy flag for everything, --all-proxy=http://USER:PASSWORD@HOST:PORT, and it is HTTP only: the manual never mentions SOCKS. For plain HTTP, HTTPS and FTP downloads that is all you need. For BitTorrent it covers the tracker and the web seeds, and nothing in the swarm. The project's maintainer put it in one line, "aria2 can connect to tcp tracker via HTTP proxy. There is no proxy support for UDP traffic", and our packet capture agrees.

Five facts frame the rest. Peers and DHT leave from your own address, so the proxy masks nothing in the swarm. A proxy is not encryption: our test proxy's log printed aria2's whole tracker announce, info hash and listening port included, because an HTTP announce through an HTTP proxy is plain text. Residential traffic, and traffic past a shared IP's included gigabyte, is billed per GB; the terms set out how it is counted. Our SOCKS5 should be treated as TCP only, which aria2 cannot use anyway. And the projects' own documentation points people with a copyright-enforcement worry at VPNs, not proxies; qBittorrent's wiki says so directly. Unauthorised sharing through our proxies is not allowed under the allowed-use policy.

#The run

On 2026-10-08 we ran aria2 1.37.0 (Alpine Linux edge) in a Docker container against tinyproxy 1.11.3 with basic authentication:

aria2c --all-proxy=http://lab:labpass@hb-http:8888 \
  --dir=/downloads --max-download-limit=1M --max-upload-limit=256K --seed-time=0 \
  debian-13.7.0-amd64-netinst.iso.torrent

After 90 seconds we captured 60 seconds of UDP and listed established TCP connections.

aria2's own progress line showed 44 connections and 29 seeds at the time. None of them touched the proxy.

#What --all-proxy is for

The manual describes the flag as "Use a proxy server for all protocols", in the format [http://][USER:PASSWORD@]HOST[:PORT]. Per-scheme flags exist too: --http-proxy, --https-proxy and --ftp-proxy. Credentials go in the URL or in --all-proxy-user and --all-proxy-passwd, and --proxy-method takes get or tunnel.

For BitTorrent, the client's source settles what the manual leaves open: it shows the peer connection code calling establishConnection(getPeer()->getIPAddress(), ...), the peer's own address. We found no setting that routes it elsewhere, and our run matched.

#Cut what goes direct

You cannot proxy the peers, but you can stop the UDP:

aria2c --all-proxy="http://$PROXY_USER:$PROXY_PASS@$PROXY_HOST:$PROXY_PORT" \
  --enable-dht=false --seed-time=0 FILE.torrent

--enable-dht=false also turns off UDP tracker support, per the manual. Without DHT, aria2 finds peers through the trackers it can reach. Then measure, on a machine where aria2 is the only program moving traffic:

ss -Htnp state established | grep aria2c
sudo tcpdump -ni any -c 20 "udp and not port 53"

Every line in the first command that is not your proxy is a peer seeing your own IP. That number will not reach zero; aria2 is the wrong tool when it has to.

#Use the mirror, and pay once

aria2's strength is that it downloads the same file from HTTP mirrors and a swarm at once, or from mirrors alone. Through a proxy, the mirror is the better deal on every measure we care about:

For the Debian netinst image (792,723,456 bytes), the mirror route moves under 1 GB through the proxy: $5.50 on residential at checkout, or nothing extra on a datacenter IP, which is $1.90/IP (dedicated) a month with 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. Check the file against Debian's published SHA256SUMS with sha256sum -c and you have a verified image that never touched the swarm.

When the job is HTTP downloads at scale, the cURL proxy guide covers the same proxy URL format, and the Docker guide shows how to give a container its proxy through the environment. The torrent client comparison lists which clients can proxy peers, if that is what you need.