uTorrent proxy settings are documented in a single vendor help article, and it is short: where the setting is, which four proxy types the client accepts, and one sentence about what those types can carry. That sentence is enough to choose a type. It is not enough to tell a reviewer what else the client sends outside the proxy, because the privacy options that would answer that are no longer documented anywhere we could find. This guide covers what is documented, what is not, and how to measure the rest on the machine where µTorrent (the vendor's spelling) is installed.
Classic, Web, and which one is documented
The vendor sells two desktop products. µTorrent Classic is listed for Windows, Mac and Linux; µTorrent Web for Windows and Mac. There is also an Android app. The proxy help article describes the Classic menu path, and we found no primary documentation of proxy support in Web. Everything below about menu paths and proxy types is therefore about Classic. If your fleet runs Web, treat its proxy behaviour as unknown until your own capture says otherwise.
Release notes matter here as well. The last public entries are Classic 3.6.0 (build 46590) on 22 November 2022 and Web 1.2.10 (5208) on 12 October 2022. Whether newer builds arrive silently through auto-update is not stated. The Mac and Linux Classic builds are older still, and their dates are not published.
The approval question on a managed fleet
A reviewer looking at µTorrent on a managed Windows machine has more to decide than the proxy.
- Software intake. µTorrent is proprietary, with no source published. The free tier carries advertising; paid tiers are listed on the vendor's compare page. The shared BitTorrent and µTorrent help centre says antivirus tools may flag the client "due to 3rd party offers we make in the installation process" and that the offers "are fully optional". That article is written for the BitTorrent client, but it is the same company and help centre, so expect the installer to need the same scrutiny.
- Patch posture. With public desktop release notes ending in 2022, an asset-management team cannot point to a changelog for the build it is approving.
- Traffic and content. Is BitTorrent permitted on this network at all, what is being fetched (a distribution's install images, an Internet Archive item, a public dataset), and who approves the exit it leaves through.
Peer-to-peer traffic for lawful content is permitted on our residential exits and on dedicated ISP and datacenter addresses with no traffic meter. Using any of our proxies to share material without the right to distribute it is prohibited by the acceptable use policy. The settings below assume the content question has already been answered.
What a metered proxy changes for this client
Before choosing a type, put the limits in writing:
- Traffic is paid both ways round. When peers go through the proxy, the download crosses it once and every byte you seed crosses it again. µTorrent's own help centre also calls discarded "wasted data" common: "Sometimes incoming data does not match what you requested, so the files are discarded." That is metered too. See how a gigabyte is measured for how our side counts it.
- UDP stops at our gateway. µTorrent supports UDP proxying over SOCKS5. Our SOCKS5 endpoints should be treated as TCP only, because UDP relay through them has not been verified, so DHT, UDP trackers and uTP will not work through ProxyForge. An HTTP proxy cannot carry UDP at all.
- Nothing is encrypted by the proxy. BitTorrent's protocol encryption exists "to prevent ISPs from identifying BitTorrent traffic", in the vendor's words; it is not confidentiality, and the proxy adds none.
- Anything sent outside the proxy carries the machine's own address. Which traffic that is in µTorrent is exactly what the documentation no longer says.
For the copyright question specifically, a proxy is the wrong control. Client projects themselves point people with that concern to a VPN; qBittorrent's wiki says so in as many words. The control that actually works is fetching only what you may share.
Four proxy types, two that carry peers
The path is Options > Preferences > Connection, then Proxy Server Type. The help article lists SOCKS4, SOCKS5, HTTP Connect and HTTP, and adds: "Peer communication proxying is not supported with standard HTTP proxies, and UDP proxying is only supported with SOCKS5. HTTP Connect proxies are HTTP proxies that support arbitrary TCP connections."
| Type | HTTP(S) trackers | TCP peers | UDP (DHT, UDP trackers, uTP) | On ProxyForge |
|---|---|---|---|---|
| HTTP | Yes | No, peers see the machine's address | No | Available, but peers are not covered |
| HTTP Connect | Yes | Yes, if the proxy allows tunnels to peer ports | No | Test whether the gateway accepts CONNECT to the ports peers use |
| SOCKS4 | Yes | Yes | No | Not offered; our gateways speak HTTP, HTTPS and SOCKS5 |
| SOCKS5 | Yes | Yes | Client supports it | TCP only; UDP will not relay |
Peers listen on arbitrary ports, and many HTTP proxies only allow CONNECT to port 443. We have not documented which ports our gateway accepts for CONNECT, so if you choose HTTP Connect, verify with the capture below before you sign anything. SOCKS5 avoids the question. SOCKS5 vs HTTP proxy covers the protocol difference in more depth.
The settings nobody documents any more
Guides elsewhere describe a username and password field, per-traffic switches and a set of "proxy privacy" checkboxes on the same page. We found no current primary documentation for any of them, so we will not reproduce their labels or describe their defaults. Two consequences:
- Authentication. Whether your build accepts credentials for the chosen type is something to check in the dialog itself. If it does not, authenticate by the machine's source address instead; IP allowlist vs username and password explains the trade.
- Fallback behaviour. The question that matters most for a reviewer, whether the client sends unsupported connections such as UDP directly when the proxy cannot carry them, is undocumented. Do not answer it from memory. Answer it with a capture.
Watching what the client opens
On the Windows machine, with µTorrent running a lawful torrent, list the client's established TCP connections and its UDP sockets. Replace uTorrent with the process name Task Manager shows if it differs:
$p = (Get-Process -Name uTorrent).Id
Get-NetTCPConnection -OwningProcess $p -State Established | Select-Object RemoteAddress, RemotePort
Get-NetUDPEndpoint -OwningProcess $p
Every established TCP connection should point at the gateway address. An open UDP socket is not itself a leak, because a socket says nothing about where datagrams go. For that, capture on the machine with Wireshark and apply a display filter that hides the proxy connection, so whatever remains left without it:
not (ip.addr == PROXY_IP and tcp.port == PROXY_PORT)
UDP datagrams to many different addresses while the torrent runs mean DHT or UDP trackers are going direct. If you see that, turn those features off in the client's own settings and capture again. Then confirm the exit address with the proxy checker, using the same credentials.
Reviewer's checklist
- Edition recorded (Classic or Web) and version noted, with the 2022 release-notes gap acknowledged
- Installer reviewed for optional third-party offers, and none accepted
- BitTorrent on this network approved, content source recorded
- Proxy Server Type set to SOCKS5, or HTTP Connect with a tested port
- Authentication method confirmed in the dialog, or IP allowlisting in place
- Capture shows no TCP connections and no UDP datagrams outside the proxy
- Seeding limits set and the gigabyte estimate includes upload
- Exit address recorded
µTorrent shares its proxy documentation word for word with the BitTorrent client. For a client whose proxy coverage can be read in its source, compare qBittorrent, or see the comparison of all fifteen clients.