Tixati proxy settings are documented in a single help page that is unusually candid about its own gap. It says a "SOCKS4/4a/5/HTTP proxy server can be used for tracker, peer, or both types of connections", and in the next sentence: "It is not possible to use a proxy for DHT UDP packets, and using a proxy for peers may prevent incoming connections from being received." For a reviewer, that second sentence is the whole egress story. With DHT on, part of Tixati's traffic always leaves from the host's own address, and no setting inside the client changes that.
Tixati is proprietary freeware with its own engine, for Windows, Linux and Android. The current release is 3.44, from 21 June 2026; version 3.43, two days earlier, brought major DHT changes. We did not run Tixati for this article. The facts are from its help pages. The firewall ruleset below was loaded, with sample values, into nftables in a test container to check its syntax and its counter; it was not run against Tixati.
Three questions for the approver
Ask these before the configuration:
- May this host send BitTorrent traffic at all, and who approved it?
- What does it distribute? Distribution images, open-source releases, public datasets, archive items. Record the sources.
- Is DHT acceptable outside the proxy? If the answer is no, DHT has to be off, and the review should say how that is enforced, not only that a box was unticked.
Peer-to-peer traffic for lawful content is fine on our residential exits and on dedicated ISP and datacenter addresses, which have no traffic meter. Our acceptable use policy prohibits using a ProxyForge exit for unauthorised sharing.
What the proxy costs and cannot carry
The limits for Tixati on our gateways:
- Upload is paid traffic too. With peers proxied, the file crosses the proxy coming in and again for every byte seeded out; a 4 GB image to a ratio of 1.0 is at least 8 GB. Our gigabyte definition says how that is counted.
- DHT never reaches the proxy, by Tixati's design. Separately, our SOCKS5 endpoints should be treated as TCP only, since UDP relay through them has not been verified, so UDP trackers and uTP would not work through us even where a client could relay them. An HTTP proxy cannot carry UDP.
- A proxy does not encrypt. It relays bytes, and SOCKS5 credentials cross in cleartext.
- Outside the proxy means the host's real address, which with Tixati always includes DHT unless it is off.
- For copyright exposure, use the right tool, which is not a proxy. Torrent client projects point those users to a VPN; qBittorrent's wiki says it outright.
Tracker, peer, or both
The help page offers three scopes. What each means for the egress statement:
| Scope | Who sees the host's address | Proxy traffic |
|---|---|---|
| Trackers only | Every peer, and the DHT | Small: announces only |
| Peers only | The tracker operator, and the DHT | The full payload, both ways |
| Both | The DHT, unless it is disabled | The full payload, both ways |
Trackers-only is the cheapest and the least honest to describe as masking, since every peer in the swarm still connects to the host directly. If the requirement is a single named exit, the answer is "both" with DHT off.
Closing the DHT gap
Turning DHT off in the client is the first step. We could not confirm the exact label from the documentation, so find it in the build you deploy and record it. A reviewer will reasonably ask what happens if someone turns it back on. On Linux, the answer can be enforced below the application: run Tixati as a dedicated user and allow that user to reach only the proxy endpoint and loopback.
table inet torrent_egress {
chain output {
type filter hook output priority 0; policy accept;
meta skuid "tixati" oif "lo" accept
meta skuid "tixati" ip daddr PROXY_IP tcp dport PROXY_PORT accept
meta skuid "tixati" counter reject
}
}
Create the tixati user first, since nftables resolves the name when the rules load. Load it with sudo nft -f torrent-egress.nft after replacing the placeholders, with one accept line per gateway address if the name resolves to several. The last rule has no address family, so it rejects IPv6 as well. Name resolution keeps working on hosts with a local stub resolver, because the lookup goes over loopback and the resolver's own query runs as a different user.
Two consequences to accept knowingly: with this rule, trackers-only or peers-only scopes stop working for the unproxied half, because that half is now rejected; and any UDP Tixati sends, DHT included, is refused rather than leaked.
A leak test that comes with the rule
The rule's counter is the leak test. Start a lawful torrent, let it run for a few minutes, and read the counter:
sudo nft list chain inet torrent_egress output
A counter at zero means Tixati attempted nothing outside the proxy. A rising counter means it tried, and was refused. To see what it tried, capture the rejected traffic on the host while it happens:
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'
UDP to many addresses is DHT, which should not appear once it is disabled. Confirm the exit address with the proxy checker. On Windows, where this rule does not apply, the capture alone is the evidence, with Wireshark and the filter not (ip.addr == PROXY_IP and tcp.port == PROXY_PORT).
Incoming connections
The help page's warning about incoming connections matches every other client in this series: a peer behind a proxy is, in effect, unreachable. Router port forwarding does nothing for proxied peer connections. Tixati can still seed over connections it opens, but it only meets peers that accept connections themselves, so the swarm looks smaller. Two proxied peers cannot reach each other at all.
What remains unconfirmed
From the documentation we could not confirm:
- whether Tixati accepts a username and password for the proxy, so plan on IP allowlisting until you see a credential field;
- how UDP trackers behave with a proxy set;
- how Tixati's own UDP peer connections behave with a proxy set.
The egress rule above makes the last two moot on Linux, because the traffic is refused whatever the client intends.
Before Tixati goes live
- BitTorrent approved for this host; content sources recorded
- Proxy scope set to both trackers and peers
- DHT disabled in the client
- On Linux: dedicated user, egress rule loaded, counter read after a test run
- On Windows: capture attached showing no UDP or peer traffic outside the proxy
- Authentication method confirmed, or allowlisting in place
- Seeding capped; gigabyte estimate includes upload
Tixati shares its DHT gap with aria2, whose UDP also goes direct. BiglyBT is the client whose documentation goes furthest on the same questions. The full comparison is in torrent client proxy support compared.