qBittorrent proxy settings, measured: four configurations, one socket table each, and the two boxes a fresh install leaves off

qBittorrent's proxy lives under Tools > Options... > Connection > Proxy Server. Pick SOCKS5, enter the host, port, username and password from your order, tick Perform hostname lookup via proxy, then tick Use proxy for BitTorrent purposes and the Use proxy for peer connections box inside it. On a fresh install both of those are off, and with them off the proxy carries none of the torrent traffic. We measured that, and the other three configurations, below.

Before the numbers, the limits that apply to every client on this site. Residential traffic is billed per GB, and so is traffic past a shared IP's included gigabyte; a seeded torrent moves its payload through the proxy twice, once on the way in and once on the way out, and the terms say how traffic is counted. A dedicated ISP or datacenter IP has no bandwidth cap. Treat our SOCKS5 as TCP only: UDP relay is not something we advertise, so DHT, UDP trackers and uTP will not run through it even though qBittorrent would try. An HTTP proxy cannot carry UDP at all. A proxy does not encrypt anything, and whatever the client sends outside it leaves from your own IP. qBittorrent's wiki itself says that if you are concerned about copyright trouble you should consider a VPN instead. This guide is for lawful swarms (Linux images, open-source releases, public-domain archives), and using a proxy for unauthorised sharing is not allowed under our allowed-use policy.

#What we measured

On 2026-10-08 we ran qbittorrent-nox 5.2.4 (the Alpine Linux package, built on libtorrent 2.1.0) in a Docker container with two test proxies on the same network:

• SOCKS5: Dante 1.4.4 with username and password, set to refuse UDP ASSOCIATE and BIND, so it behaves like a TCP-only gateway.
• HTTP: tinyproxy 1.11.3 with basic authentication, allowing CONNECT to any port.

Every run started from an empty profile. We set the proxy through the Web UI's preferences API, added the Debian 13.7.0 netinst torrent (792,723,456 bytes, one HTTP tracker, two web seeds) with a 1 MiB/s download cap, waited 90 seconds, captured 60 seconds of UDP with tcpdump, then listed established TCP connections with ss. Packets were classified by their first bytes as uTP, DHT or UDP-tracker traffic.

In the second run the SOCKS5 log showed the client authenticating and connecting to the tracker on port 6969 three times: the tracker was proxied, the swarm was not. In the third, the proxy logged qBittorrent's UDP ASSOCIATE request and refused it, and qBittorrent's connection status changed to "firewalled", which is what a client with no incoming connections reports. The fresh-profile preferences, read back from the API before we changed anything, had proxy_bittorrent and proxy_peer_connections both false.

A test proxy on one machine proves routing, not anonymity: every exit address was ours. It also says nothing about speed, and we publish no speed figure.

#The two boxes, and why to check them whatever your history

The tooltip on Use proxy for peer connections reads "Otherwise, the proxy server is only used for tracker connections", and the second row of the table is that sentence in numbers. With only the outer box ticked, the tracker sees the proxy's address and every peer sees yours.

On a fresh install both boxes are off. A settings file that qBittorrent converts from an older version can come out with Use proxy for BitTorrent purposes switched on, so what you find depends on your install's history. Check both boxes whatever that history is, restart the client, and measure again rather than trusting the dialog.

The rest of the group:

• Types: (None), SOCKS4, SOCKS5 and HTTP. Username and password work with SOCKS5 and HTTP only. Choosing SOCKS4 disables hostname lookup, RSS and general-purpose proxying, and the dialog warns "Some functions are unavailable with the chosen proxy type!"
• Perform hostname lookup via proxy: keep it ticked so tracker names are resolved by the proxy, not your local resolver. The socks5h entry explains the difference.
• Use proxy for RSS purposes and Use proxy for general purposes: the second covers "Search engine, software updates or anything else". Neither affects the swarm.

#Prove it on your own machine

The test is the same on a desktop install. Take the proxy's IP and port, start a lawful torrent, and count where the client's connections go.

Linux:

PROXY=203.0.113.10:1080
ss -Htnp state established | grep qbittorrent \
  | awk -v p="$PROXY" '$4 == p { via++ } $4 != p { direct++ } END { print "via proxy:", via+0, "direct:", direct+0 }'
ss -Huanp | grep qbittorrent

Windows (PowerShell):

$p = (Get-Process qbittorrent).Id
Get-NetTCPConnection -OwningProcess $p -State Established | Group-Object RemoteAddress | Select-Object Count, Name
Get-NetUDPEndpoint -OwningProcess $p

A correct setup prints one remote address, the proxy, for every TCP line. The UDP command shows the port the client listens on; capture it with sudo tcpdump -ni any udp port PORT or the Wireshark filter udp.port == PORT. Packets from your machine to public addresses on that port are DHT or uTP leaving direct. With both boxes ticked and a TCP-only proxy, there should be none.

Before you start, confirm the proxy itself works and note its exit IP with the curl line on our proxy checker. That is the only address any peer should see.

#UDP: DHT, uTP and UDP trackers

The engine's source shows it relaying UDP over SOCKS5 with UDP ASSOCIATE when the proxy supports it, and refusing to send it at all over HTTP or SOCKS4. Our third and fourth runs show the practical result on a proxy without UDP relay: no UDP left the container, DHT stayed at zero nodes, and every peer came from the HTTP tracker. On a public swarm with a good tracker that was enough to fill 100 connections. On a torrent that depends on DHT or a UDP-only tracker, expect few or no peers. "Disable connections not supported by proxies" is no longer an option: qBittorrent's wiki says it has been always enabled since 4.2.

#qbittorrent-nox and the config file

On a headless box, the same settings sit in qBittorrent.conf. The keys the source reads are Network\Proxy\Type, IP, Port, AuthEnabled, Username, Password and HostnameLookupEnabled, the profile switches Network\Proxy\Profiles\BitTorrent, \RSS and \Misc, and BitTorrent\Session\ProxyPeerConnections. Stop the daemon before editing. The Web UI has the same Proxy Server page, and its API reports the two switches as proxy_bittorrent and proxy_peer_connections, which makes a scripted check of a fleet of seedboxes one authenticated API call per host.

#What the Debian image costs through the proxy

The netinst torrent is 0.79 GB. Through proxied peers that is at least 0.79 GB in, and seeding to a ratio of 1.0 adds as much again on the way out, plus protocol overhead and any discarded pieces. On residential, a 1 GB order is $5.50 and a 2 GB order $10.40, from a minimum top-up of $10. A datacenter IP is $1.90/IP (dedicated) a month with no bandwidth cap, though port speed and fair use still apply. Peer-to-peer traffic for lawful content is fine on residential and on dedicated ISP and datacenter IPs, which carry no traffic meter. In our 150-second runs the upload counter stayed at zero because nearly every peer was already a seed; the second half of the bill arrives when you seed.

Put your own gigabytes into the cost calculator to compare the two models. If all you want is the file, Debian also publishes it over HTTP, and a mirror moves it through the proxy once.

#Anonymous mode is not routing

Tools > Options > BitTorrent > Privacy > Enable anonymous mode (tooltip: "Enable when using a proxy or a VPN connection") makes the client use a generic user agent with trackers and stop sending its version to peers. It does not move a single connection. Leave it on if you like; measure with the socket table either way.