qBittorrent proxy settings: the two boxes that decide coverage

qBittorrent proxy settings look complete once a host and port are filled in, and they are not. The client's source at the current release shows that, on a fresh install, the two switches deciding whether BitTorrent traffic uses the proxy at all start unticked, so a configuration that passes a quick review can leave every peer connection on the host's own address. This guide is for the engineer running qBittorrent, usually qbittorrent-nox on a build server, a lab machine or a seedbox-style host, and for the reviewer who has to sign off what that host sends out and through which exit.

The facts below come from qBittorrent's repository at tag release-5.2.4 (released 2026-09-28) and from libtorrent's own documentation. Where a statement rests on reading source code rather than documentation, it says so. We did not run qBittorrent for this article; the capture procedure at the end is how you confirm the behaviour on your own build.

Who has to say yes first

Three questions come before any setting:

• Is BitTorrent permitted on this network? Many egress policies block or flag peer-to-peer traffic regardless of content. Sending it through a proxy does not change the answer. It changes where the traffic appears to come from, which a security team will treat as an escalation unless it approved it.
• What is the data source? Legitimate cases are specific: a distribution's install images, an open-source project's release torrents, an Internet Archive item, a research dataset. Record the source URL in the change request.
• Who approves the exit? If traffic is to leave through a third-party proxy, the reviewer needs the vendor, the exit type and which traffic it carries. The rest of this guide is how to state that last item accurately.

On our side the answer is settled: peer-to-peer traffic for lawful content is fine on ProxyForge residential exits and on dedicated ISP and datacenter addresses, which carry no traffic meter. Sharing material you are not entitled to distribute is outside our acceptable use policy whichever client or network carries it, and nothing here is a way around that.

What the proxy will and will not do

State these limits in the change request, not after the first invoice:

• Seeding doubles the metered traffic. With peers proxied, every payload byte crosses the gateway on the way in, and again for every copy you upload. A 4 GB image downloaded and seeded to a ratio of 1.0 moves at least 8 GB through the proxy, before protocol overhead and discarded pieces. How those bytes count against an order is set out under how a gigabyte is measured.
• No UDP through our gateway. Treat ProxyForge's SOCKS5 endpoints as TCP only; UDP relay through them has not been verified. DHT, UDP trackers and uTP are all UDP, so they will not work through our proxy even though qBittorrent can request a relay. An HTTP proxy cannot carry UDP at all.
• No encryption. A proxy relays bytes. SOCKS5's username and password method sends the password in cleartext (RFC 1929), and an HTTP proxy is plaintext unless reached over TLS.
• Whatever bypasses the proxy shows the host's address. That includes everything left unticked below.
• A proxy is not a privacy tool. qBittorrent's wiki tells users worried about "legal authorities and copyright trouble" to "consider using a VPN instead (or in addition to it)". Our position is simpler still: the content has to be yours to share.

If the job is only to get an image onto a build server, the project's HTTPS mirror and its published checksums deliver the same bytes once, with no seeding and no peer traffic. A proxied torrent fits when policy requires egress through a named exit and the swarm is the distribution channel you were given.

The two checkboxes that start off on a fresh install

The settings live under Tools > Options... > Connection, in the group Proxy Server. The Web UI has the same page, which is what you use on qbittorrent-nox.

The type list offers (None), SOCKS4, SOCKS5 and HTTP. Credentials are accepted for SOCKS5 and HTTP only. Choosing SOCKS4 disables hostname lookup, RSS and general-purpose proxying, and the dialog warns that some functions are unavailable. For our gateways, choose SOCKS5 and tick "Perform hostname lookup via proxy" so names are resolved at the gateway rather than by the host's resolver.

Below the address fields sit four switches. The two that matter for BitTorrent are nested:

• "Use proxy for BitTorrent purposes", containing
• "Use proxy for peer connections", whose tooltip reads "Otherwise, the proxy server is only used for tracker connections".

On a fresh install, the client's source shows both start off. preferences.cpp reads Network/Proxy/Profiles/BitTorrent as a boolean with no default, which is false, and sessionimpl.cpp initialises ProxyPeerConnections to false.

An upgraded install can differ. The source also shows that when qBittorrent converts a settings file from an older version, it switches "Use proxy for BitTorrent purposes" on, which leaves peer proxying to the second box alone. So what a host has depends on its history, not only on its version. Check both boxes on every host, whatever its history, and treat neither state as a default you can assume. One further observation, which we have not reproduced: ticking the outer box while the client was running did not take effect until the client was restarted. Restart after changing either box, then capture.

What each state means in practice:

The middle row is the one to watch. It hides the host from the tracker operator and from nobody else, since every peer in the swarm sees the address on the data connection. It also costs almost nothing in proxy traffic, which is why it can look like a working setup on the bill.

The other two switches are "Use proxy for RSS purposes" and "Use proxy for general purposes" ("Search engine, software updates or anything else will use proxy"). On a managed host, decide both explicitly. Update checks and search plugins through a metered exit are usually traffic nobody asked for.

Pinning the configuration on a headless host

On qbittorrent-nox the settings persist in qBittorrent.conf. The client's source (proxyconfigurationmanager.cpp and sessionimpl.cpp) names these keys:

The documentation does not give the value format for every key, so do not hand-write the file. Configure a scratch instance once through the Web UI, stop the client, diff qBittorrent.conf against the copy you took before the change, and commit that diff to configuration management. The image then carries exactly what the client writes. Stop the client before copying or editing the file; a running client can write its own settings back over an edit.

Two consequences follow for the review:

• The file holds the proxy password in whatever form the client stores it. Treat it as a secret and deliver it the way you deliver other credentials; managing proxy credentials in a secrets manager covers the store side. Authenticating by source address removes the password from the file entirely; IP allowlist vs username and password compares the two.
• The two booleans are assertable. A pipeline step that renders the file can refuse to ship it unless both read true:

grep -E 'Profiles\\BitTorrent=|ProxyPeerConnections=' qBittorrent.conf

DHT, UDP trackers and uTP behind the proxy

qBittorrent does not override libtorrent's proxy_tracker_connections, which defaults to true, and since qBittorrent 4.2 the old "Disable connections not supported by proxies" option is "Always enabled". What happens to UDP is therefore libtorrent's behaviour. Its source at v2.0.15 (src/udp_socket.cpp) shows a UDP packet goes to the proxy when it is a peer packet and peer proxying is on, a tracker packet and tracker proxying is on, or a packet with neither flag, which is how DHT packets are sent.

• Over SOCKS5, those packets are wrapped in a UDP ASSOCIATE request. Through a TCP-only SOCKS5 endpoint, which is how to treat ours, that relay is not available.
• Over HTTP or SOCKS4, libtorrent fails the send with permission_denied instead of sending it directly. DHT, UDP trackers and uTP stop working rather than leaking.

The practical effect through our gateway is that a torrent depends on its TCP peers and on announce URLs that start with http:// or https://. Check the tracker list in the .torrent file before approving a job; a torrent whose only trackers are udp:// entries will find few or no peers behind the proxy.

Incoming connections stop as well. With a proxy set, libtorrent's listen interface "will not accept incoming TCP connections, will not map ports with any gateway", and since libtorrent 1.2.8 the client announces listen port 1. Seeding still works over connections the host opens.

Anonymous mode changes identity, not routing

Tools > Options > BitTorrent > Privacy > "Enable anonymous mode" carries the tooltip "Enable when using a proxy or a VPN connection". In libtorrent terms it uses a generic user agent for trackers and stops sending the client version to peers. It moves no traffic anywhere. The wiki is explicit that it "doesn't provide strong privacy guarantees on its own". Leave it on or off as you prefer; do not cite it in a review as an egress control.

Prove the coverage with a capture

Run this on a test host or container where qBittorrent is the only process generating traffic. First list every address the gateway name resolves to, then capture everything that is not the proxy connection, your SSH session or loopback:

getent ahosts PROXY_HOST
sudo tcpdump -ni any 'not (host PROXY_IP and tcp port PROXY_PORT) and not port 22 and not net 127.0.0.0/8'

Add a lawful torrent, such as a distribution's install image, and watch the capture. Do it three times, once for each row of the table above. In the first two runs you should see connections to peer addresses on arbitrary ports leaving directly; that is the fresh-install state, and the converted-settings state, made visible. Restart the client between runs. In the final configuration the capture should stay quiet apart from anything unrelated you forgot to exclude. Alongside it, ss -tnp lists the client's open TCP sockets, and every established one should point at the gateway:

ss -tnp | grep -i qbittorrent

Finally, record the exit address the gateway presents. The proxy checker prints a one-line curl command that reports it through the same credentials. That address, the proxy type and the capture result are what the reviewer signs.

Sign-off checklist

• Content source recorded by URL, and redistribution of it is permitted
• BitTorrent on this network approved by the owner of the egress policy
• Proxy type SOCKS5, with "Perform hostname lookup via proxy" ticked
• "Use proxy for BitTorrent purposes" and "Use proxy for peer connections" both checked on this host, whether fresh or upgraded, and asserted in the pipeline
• Client restarted after changing either box
• RSS and general-purpose proxying decided explicitly
• Password held as a secret, or IP allowlisting used instead
• Torrent lists at least one http:// or https:// tracker
• Upload cap or ratio limit set, and the gigabyte estimate includes seeding
• Capture run in the final configuration, with no traffic outside the proxy endpoint
• Exit address recorded

For how qBittorrent compares with the other fourteen clients on the same questions, see torrent client proxy support compared. Deluge uses the same engine and proxies peers by default.