BiglyBT documents its proxy support more completely than any other client in our comparison. Its wiki page "Proxies and VPNs" states what each mode covers, what it does not, and which features leak your address, and the options window has a Test SOCKS button. That makes it the easiest client to verify: you have a written claim for every connection type, and a socket table to check it against. We did not run BiglyBT in our lab; every behaviour below is the project's own statement, and the measuring is yours.
Limits to know before you start
- Per-GB meter. Residential traffic, and traffic beyond a shared IP's included gigabyte, is billed per GB. Seeding sends the payload through the proxy a second time. The terms say how traffic is counted; dedicated IPs have no bandwidth cap.
- No UDP through our SOCKS5. BiglyBT would use a SOCKS5 UDP association for tracker announces and scrapes. We do not advertise UDP relay, so treat our SOCKS5 as TCP only and expect UDP trackers to fail through it. HTTP proxies carry no UDP at all.
- No encryption, and no cover outside the proxy. A proxy relays; it does not encrypt. Anything BiglyBT sends around it uses your own IP, which is what the wiki's checklist is about.
- A VPN for the copyright question. BiglyBT's own wiki describes binding the client to a VPN interface, and the qBittorrent wiki tells users concerned about copyright trouble to use one. We write about lawful swarms; unauthorised sharing through our proxies is not allowed by the allowed-use policy.
Configure: tracker and peer boxes are separate
Switch the options window to advanced mode, then open Tools > Options > Connection > Proxy Options. The labels, from BiglyBT's message bundle:
- Enable proxying of tracker communications [restart required].
- I have a SOCKS proxy: tick it for SOCKS; untick it to enter an HTTP proxy, which the wiki says "affects tracker communications, HTTP seed connections" and "does NOT affect normal peer-to-peer connections".
- Host, port, SOCKS version (4, 4a or 5; choose 5 with the SOCKS5 port from your order), Username and Password.
- Enable proxying of peer communications (outgoing connections only) [restart required].
- Prevent local DNS lookups, so tracker names are not resolved by your own resolver.
- Disable plugin proxies (e.g. Tor/I2P Helper plugins) when a SOCKS server is configured, if you run those plugins.
Press Test SOCKS, then restart: both proxying boxes say so.
The wiki's leak checklist, and how to measure each item
The wiki says to "disable features that will otherwise allow your public IP address to leak". Each one has a measurable effect.
| Checklist item | Why | How to check it |
|---|---|---|
| In Peer Sources, keep only the first entry, "from a tracker" | The wiki lists the other sources as ways your address leaks | TCP connections only to the proxy's address |
| Make sure the Mainline DHT Plugin is not installed | DHT is UDP, and BiglyBT's SOCKS UDP support covers tracker announces and scrapes only | No UDP from the client's port to public addresses |
| Tick Prevent local DNS lookups | Tracker names would otherwise resolve locally | No DNS queries for tracker hosts from your machine during an announce |
| Tick both proxying boxes and restart | Each applies only after a restart | Run the count again after the restart, not before |
The count, on Linux, by process ID (find it with ps -e):
PID=1234
PROXY=203.0.113.10:1080
ss -Htnp state established | grep "pid=$PID," \
| awk -v p="$PROXY" '$4 == p { via++ } $4 != p { direct++ } END { print "via proxy:", via+0, "direct:", direct+0 }'
ss -Huanp | grep "pid=$PID,"
On Windows, Get-NetTCPConnection -OwningProcess PID -State Established gives the same list. For UDP, capture the listening port the second command prints, with sudo tcpdump -ni any udp port PORT or Wireshark's udp.port == PORT. The exit address to look for is the one the curl line on our proxy checker prints through your proxy.
The NAT problem is the expected result
The wiki is blunt: SOCKS support "does NOT support incoming proxied connections", and "you will appear to have a 'NAT problem'". Router port forwarding cannot fix it for proxied peers. You reach only peers that accept incoming connections, so a small swarm can look slow, and two proxied peers cannot connect to each other at all. Seeding still works over the connections BiglyBT opens itself.
If you use a VPN rather than a proxy, the wiki's equivalent setting is Bind to local IP address or interface with Enforce IP bindings even when interfaces are not available ticked. Our proxy vs VPN guide covers when each one fits.
Long-term seeding: per GB or per IP
If you use BiglyBT to seed open-source distributions for months, the billing model matters more than the client. Seeding 30 GB a month through proxied peers is $102.00 on residential at checkout, every month you do it. An ISP IP is $3.20/IP (dedicated) a month, and a datacenter IP $1.90/IP (dedicated), both with no bandwidth cap, though port speed and fair use still bound them. Peer-to-peer traffic for lawful content is fine on residential and on dedicated ISP and datacenter IPs, which carry no traffic meter. The dedicated vs shared comparison explains which plans include traffic, and the cost calculator finds the crossover for your volume. Every one of those gigabytes still has to pass the checklist above, or it is billed traffic that also shows the swarm your address.
The torrent client comparison sets BiglyBT's documented behaviour beside the other fourteen clients.