WebTorrent Desktop proxy support is a short topic: there is none. The client's source shows a preferences page with five sections, "Folders", "Playback", "Default torrent app", "General" and "Trackers", and no proxy field in any of them. Whether any of its traffic follows an operating-system proxy could not be confirmed. For anyone asked to state what this app sends out and through which exit, the defensible answer is that everything leaves from the machine's own address, and any control has to be applied around the app rather than inside it.
That is not a criticism of what the app is for. WebTorrent Desktop streams video while it downloads, which suits public-domain and Creative Commons films such as those on the Internet Archive or the Blender open movies. It just cannot be pinned to a proxy.
Three facts that frame the review
| Question | Finding |
|---|---|
| Can it be configured to use a proxy? | No; no setting exists in the preferences source |
| Does it honour a system proxy? | Not confirmed; treat as no |
| Is it maintained? | Last release v0.24.0, 29 August 2020; MIT licence; only dependency bumps since |
Before any of that, the usual approvals apply: whether BitTorrent traffic is permitted on this network, who owns that decision, and what content will be streamed. Sharing anything you are not entitled to distribute through our network is excluded by the acceptable use policy, and with this client our network would not be involved anyway. For clients that can use a proxy, peer-to-peer traffic for lawful content is fine on our residential exits and on dedicated ISP and datacenter addresses with no traffic meter.
Browser peers and WebRTC
WebTorrent's distinguishing feature is that it talks to browser-based peers over WebRTC as well as to ordinary BitTorrent peers. WebRTC data connections normally run over UDP, and that has two consequences:
- Even a proxy-aware build would struggle. An HTTP proxy cannot carry UDP, and SOCKS5 can only if both the client and the proxy server implement UDP relay.
- On our gateways it would not work regardless. Treat ProxyForge's SOCKS5 endpoints as TCP only; UDP relay through them has not been verified, so DHT, UDP trackers, uTP and WebRTC traffic would not get through.
Our proxy checker shows the same effect for browsers: its WebRTC test asks a public STUN server which address it sees over UDP, which can reveal an address other than the proxy's.
If you were planning to use a metered proxy
The general limits are worth stating because they explain why a proxy is the wrong instrument here even if one could be configured:
- A torrent streamed and then seeded passes through a proxy twice, once in and once out, and a metered line counts both under our gigabyte definition.
- A proxy does not encrypt anything, and any traffic outside it carries the machine's own address.
- For copyright exposure, client projects point users to a VPN rather than a proxy; qBittorrent's wiki is explicit about it. The real control is the content.
For watching a public-domain film once, the Internet Archive's own HTTPS download is usually simpler than any torrent: one transfer, no seeding, nothing for a reviewer to trace.
What the egress statement has to say
Write it plainly in the review, because a reader will otherwise assume a proxy is involved:
WebTorrent Desktop has no proxy setting. Its tracker requests, BitTorrent peer connections and WebRTC connections leave from this machine's own address over TCP and UDP. Containment, if required, is provided by the network the machine is on.
Containing it at the host instead
Because the app cannot be configured, the controls are all outside it:
- Put the machine where peer-to-peer egress is approved. A workstation segment or VM whose network policy already allows BitTorrent, with that approval on record, is the simplest honest answer.
- Route the whole machine. A VM or network namespace whose only route out is a tunnel to an approved exit contains every protocol the app speaks, UDP included, without the app knowing. A host-level VPN is the common way to do this, and it is also the tool the client projects recommend for privacy concerns.
- Do not use an allow-only-the-proxy firewall. Restricting the machine to a proxy endpoint would leave this client unable to reach anything, because it never uses the proxy. That is a broken app, not a contained one.
On container platforms the same principle is what egress policy is for; our Kubernetes egress guide covers how pod traffic is scoped, though for this app the route, not a proxy variable, is the control.
Confirming it on your machine
If a review needs evidence that no proxy is used, set a system proxy, start a lawful torrent, and capture everything 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'
TCP to peer addresses and UDP to many destinations will appear. That capture also closes the unconfirmed system-proxy question for the build and platform you tested.
Before it is approved
- Recorded that the app has no proxy setting and is not maintained since 2020
- BitTorrent and WebRTC traffic permitted on the network the machine is on
- Content source recorded, public-domain or openly licensed
- Containment named: approved segment, or a whole-machine route
- Capture attached for the build in use
- HTTPS download considered first for one-off viewing
WebTorrent Desktop is one of three clients in this series whose peers never use a proxy; Transmission and aria2 are the others. See torrent client proxy support compared for the full picture.