BitComet proxy settings are documented on the project's official Options help page in three lines: the proxy type, a list of supported protocols, and one option whose wording is easy to misread. That option, "Don't use proxy for tracker/peer-to-peer connections", exists to send part of the traffic around the proxy. On a review it is the line to check first, because a negative checkbox ticked for peers produces a configuration that looks proxied and is not.
BitComet is proprietary freeware for Windows, macOS, Linux and Android. The current release is 2.22, dated 4 September 2026. It has its own engine, a long-term seeding feature, and HTTP and FTP downloading in the same app. We did not run BitComet for this article; everything below is from its help page or is stated as unconfirmed.
What has to be agreed first
On managed infrastructure, the configuration is the last step:
- Peer-to-peer traffic on this network has to be permitted by whoever owns egress policy.
- The content has to be lawful to redistribute: distribution images, open-source releases, archive items, research data. Write down the sources.
- The exit has to be named: a proxy and its vendor, a VPN, or the machine's own address.
- The software has to pass intake. Whether BitComet's installer bundles offers or shows ads could not be confirmed, so the person installing it should check and record what the installer presents.
Peer-to-peer traffic for lawful content is allowed on our residential exits and on dedicated ISP and datacenter addresses without a traffic meter. Sharing material without the right to distribute it is not permitted on our network under the acceptable use policy.
The proxy section of the Options dialog
The help page describes a Proxy section in BitComet's Options dialog. Which menu opens Options is not stated on the page, so we do not give one. The section has:
- Proxy Type, defaulting to "No Proxy";
- the supported types, "Socks4, Socks4a, Socks5, HTTP1.1";
- the exemption option described next.
Our gateways speak HTTP, HTTPS and SOCKS5, so the choice is between HTTP1.1 and Socks5. Choose Socks5 if peers are to be proxied; an HTTP proxy relays HTTP requests and needs CONNECT tunnels to carry peer traffic, which many proxies allow only to port 443. SOCKS5 vs HTTP proxy explains the difference.
The option that turns the proxy off for part of the traffic
The help text reads: "Don't use proxy for tracker/peer-to-peer connections: specifies if you want to bypass the proxy server for connections to the tracker or for connections to peers. (introduced in v.1.20)".
Its two settings change the egress statement entirely:
| Exempted from the proxy | Who sees the machine's own address | Metered proxy traffic |
|---|---|---|
| Nothing | Not stated for DHT and UDP; see below | Full payload, both ways |
| Tracker connections | The tracker operator | Full payload, both ways |
| Peer connections | Every peer in the swarm | Almost none |
The last row is the common trap. Exempting peers keeps the bill small, which can make it look like a sensible saving. It also means the proxy is doing nothing for the traffic that matters. If the requirement is a single named exit, record in the review that neither exemption is selected.
What the help page leaves open
The following are not documented, and we will not guess:
- whether the proxy accepts a username and password, so plan on IP allowlisting until the dialog shows otherwise;
- whether DHT is sent through the proxy, dropped, or sent directly;
- how UDP trackers and uTP behave with a proxy set.
On our network the UDP question has a partial answer whatever BitComet does: treat ProxyForge's SOCKS5 endpoints as TCP only, because UDP relay through them has not been verified. DHT, UDP trackers and uTP will therefore not work through our proxy, and an HTTP proxy cannot carry UDP at all. What remains open is whether BitComet sends that UDP directly instead, which the measurement below answers.
Long-term seeding on a metered exit
BitComet promotes "Long-Term Seeding Technology", which it says "can find more seeds". Seeding is the half of a torrent that costs most on a metered proxy: the payload comes in once and goes out again for every copy uploaded, so a 4 GB image seeded to a ratio of 1.0 moves at least 8 GB, and a long-term seed keeps going. Our gigabyte definition is how that is counted on our side.
If long-term seeding of an open-source release is the goal, a per-GB proxy is usually the wrong tool. Seed from an address that is approved for the swarm and not metered per gigabyte, such as a dedicated ISP or datacenter address, unmetered up to its port speed, or cap upload. Reducing proxy bandwidth covers the general habits.
Two further limits apply as they do to every client: a proxy does not encrypt traffic, and anything sent outside it shows the machine's own address. For copyright exposure, a proxy is not the control; client projects point users to a VPN, as qBittorrent's wiki does in plain terms.
A measurement that answers the open questions
On Windows, run Wireshark on the machine during a ten-minute lawful download with the proxy set and no exemption selected. Then open Statistics > Conversations and sort by bytes. The list is every remote address the machine exchanged traffic with:
- The gateway should account for almost all the bytes.
- TCP conversations with many other addresses mean peers are going direct, so check the exemption option.
- UDP conversations with many addresses mean DHT or UDP trackers are going direct.
To isolate what left without the proxy, apply this display filter before opening the statistics:
not (ip.addr == PROXY_IP and tcp.port == PROXY_PORT)
On Linux the equivalent capture is sudo tcpdump -ni any 'not (host PROXY_IP and tcp port PROXY_PORT) and not port 22'. Record the exit address the gateway presents with the proxy checker.
What to record before approval
- Peer-to-peer traffic approved; content sources recorded
- Installer reviewed and what it presented recorded
- Proxy Type set to Socks5
- "Don't use proxy for tracker/peer-to-peer connections" not selected for either
- Authentication confirmed in the dialog, or IP allowlisting in place
- Conversations list attached, with no peer or UDP traffic outside the gateway
- Upload capped or long-term seeding moved to an unmetered, approved address
BitComet's split between tracker and peer proxying resembles BiglyBT, which documents far more of what happens to UDP. The full comparison is in torrent client proxy support compared.