BiglyBT proxy settings are the best documented of any torrent client we reviewed. The project's wiki page "Proxies and VPNs" says, option by option, which traffic each setting affects and which it does not, and the client exposes the same distinctions as separate switches. For a platform owner who has to state what a long-running seeding host sends out, that is the difference between an egress statement copied from documentation and one guessed from a menu.
BiglyBT is the maintained fork of the Azureus and Vuze code base, "maintained by two of the original developers", GPL-2.0, ad-free, with an installer that "contains no third party offers". Version 4.1.0.0 was released on 20 May 2026 for Windows, macOS and Linux. Quotations below are from the wiki; exact option labels are read from the client's MessagesBundle.properties. We did not run BiglyBT for this article.
Read the documentation as the reviewer will
Before configuring anything, settle the policy side:
- Is long-term seeding from this host approved? BiglyBT is often chosen for it, and seeding is where both the traffic and the review effort are.
- What is being seeded? An open-source distribution's images, a project's release torrents, a public dataset. Record each source.
- Which exit, and who approved it? A named proxy, a VPN, or the host's own address.
Seeding lawful content is fine on our side: peer-to-peer traffic is allowed on residential exits and on dedicated ISP and datacenter addresses with no traffic meter. Our acceptable use policy does not permit a ProxyForge exit to be used for sharing material without the right to distribute it.
What a metered proxy means for a seeding host
- Seeding is the expensive half. A proxied peer connection carries the payload in when you download, and out again for every byte you seed. A host that seeds an image for months can move many times the image's size through the gateway. Plan against our gigabyte definition, and set upload limits.
- UDP will not relay through our gateway. BiglyBT relays only tracker UDP over SOCKS5, never peer UDP. Treat ProxyForge's SOCKS5 endpoints as TCP only, since UDP relay through them has not been verified, so UDP tracker announces, DHT and uTP will not work through us. An HTTP proxy cannot carry UDP.
- The proxy adds no encryption, and SOCKS5 credentials cross in cleartext.
- Any traffic outside the proxy uses the host's own address. The wiki's peer-source advice below is how to keep that list empty.
- For copyright exposure, a proxy is not the control. BiglyBT's own wiki covers VPN binding for that reason, and qBittorrent's wiki recommends a VPN outright. The control that holds is seeding only what you may.
For a host whose whole job is long-term seeding of open-source releases, a per-GB proxy is usually the wrong tool. If the host's own address is approved for the swarm, seeding from it costs nothing per peer and needs no egress statement beyond that approval. A proxy earns its place only when policy requires the traffic to leave through a named exit. When it does, a dedicated ISP or datacenter address suits long-term seeding better than a per-GB line: it has no traffic meter up to its port speed, so what you pay is the rate for the address and its term, not a figure that grows with every peer.
Advanced mode and the Proxy Options page
The page is Tools > Options > Connection > Proxy Options, visible in advanced mode. Its options, with exact labels:
- "Enable proxying of tracker communications [restart required]"
- "I have a SOCKS proxy"
- "Enable proxying of peer communications (outgoing connections only) [restart required]"
- "SOCKS version", "Username", "Password"
- "Prevent local DNS lookups"
- "Disable plugin proxies (e.g. Tor/I2P Helper plugins) when a SOCKS server is configured"
The page also has a Test SOCKS button. A server check is useful, but it is not a coverage check; it does not tell you which of the client's connections use the proxy. The capture below does.
Tracker proxying and peer proxying are separate decisions
The two "Enable proxying" options are independent, and the wiki says tracker and data proxying are configured separately. The combinations:
| Tracker proxying | Peer proxying | Who sees the host's address |
|---|---|---|
| On | Off | Every peer in the swarm |
| Off | On | The tracker operator |
| On | On | Nobody, if peer sources and DHT are handled as below |
Tracker-only proxying is cheap and is not masking: every peer still connects to the host directly. For a single named exit, both must be on, with "I have a SOCKS proxy" ticked, because peers cannot be proxied over HTTP.
HTTP or SOCKS: what each carries
| HTTP proxy | SOCKS proxy | |
|---|---|---|
| How to select | Untick "I have a SOCKS proxy" | Tick it and choose the version |
| Tracker communications | Yes | Yes |
| HTTP seed connections | Yes | Not stated |
| Peer connections | "does NOT affect" them | Outgoing only |
| UDP | No | Tracker announces and scrapes over SOCKS 5; not peers |
| Incoming connections | Not stated | Not supported |
SOCKS versions 4, 4a and 5 are supported. Our gateways speak HTTP, HTTPS and SOCKS5, so choose version 5. Tick "Prevent local DNS lookups" so names are resolved at the gateway, and tick "Disable plugin proxies" so a Tor or I2P helper plugin cannot quietly take over the route.
Peer sources and the DHT plugin
The wiki is explicit about the leak paths outside the proxy: "disable features that will otherwise allow your public IP address to leak ... Look for the 'Peer Sources' section and deselect everything apart from the first one, 'from a tracker'. Also ensure that you haven't got the 'Mainline DHT Plugin' installed".
On a managed host, check both in the build you deploy and record them. Removing the DHT plugin is a stronger statement than disabling a feature, because a plugin that is not installed cannot be re-enabled by accident.
Incoming connections and the NAT warning
SOCKS support "does NOT support incoming proxied connections", and the wiki warns that you "will appear to have a 'NAT problem'". That is expected, not a fault to fix with port forwarding. The host still seeds over connections it opens to peers that accept them, so expect a smaller reachable swarm than the same host without a proxy.
Binding instead of proxying
For a host that uses a VPN rather than a proxy, the wiki describes binding: set "Bind to local IP address or interface" to the VPN interface and tick "Enforce IP bindings even when interfaces are not available", so that, as the option's name says, the binding holds even while the interface is down instead of the client falling back to another route. The wiki contrasts the two approaches: a VPN works by "intercept[ing] your network packets at the point where the operating system routes them", which is why it covers DHT and UDP that a proxy cannot.
Verifying after the restart
Both proxying options say "[restart required]". Restart BiglyBT, start a lawful torrent, and only then measure. Capture everything on the host that is not the proxy connection:
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'
The capture should stay quiet. TCP to peer addresses means peer proxying is off or the client was not restarted; UDP to many addresses means a peer source or the DHT plugin is still active. Confirm the exit address with the proxy checker.
Checklist for a seeding host
- Long-term seeding approved; every seeded source recorded
- "I have a SOCKS proxy" ticked, SOCKS version 5, credentials or allowlisting set
- Tracker and peer proxying both enabled, then the client restarted
- "Prevent local DNS lookups" and "Disable plugin proxies" ticked
- Peer Sources limited to "from a tracker"; Mainline DHT Plugin not installed
- Upload limits set, and the gigabyte estimate covers months of seeding
- Capture after restart attached
BiglyBT is also the recommended replacement for Vuze, whose documentation is offline. Compare its documented DHT handling with Tixati, which cannot proxy DHT at all, or see torrent client proxy support compared.