Torrent Leak Test
see the IP your torrent client really uses
Your browser and your torrent client are two different programs, and they do not always take the same route to the internet. This test shows you the address your torrent client actually announces — with the client's own name, its port, the reverse DNS and the IANA block — next to the address your browser is using right now. A torrent IP leak test has to work this way, from outside the browser, because a web page cannot see what a separate program on your machine is doing.
Test your torrent client for an IP leak
Start the test, open the magnet link in your torrent client, and watch the address it announces appear below. The whole thing takes about ten seconds.
Your browser is using
216.73.216.105
The address this page was requested from
Your torrent client is using
—
Not measured yet
Announces seen
0
Records are deleted after 15 minutes
- Open this magnet link in your torrent client. On most systems the button below hands it straight over.
- Let it start. There is nothing to download — the file is a placeholder with no content and no seeders. Your client only has to say hello to the tracker, and the tracker is this page.
- Watch the table. The address appears within a second or two of your client adding the link.
Quick Answer: how do you test a torrent IP leak?
Open a magnet link whose tracker you control, and read the address your client arrives from. That is what this page does: press Start, open the link in your torrent client, and the address it announces appears next to the address your browser is using. If the two differ, the two programs are taking different routes — which with a VPN running means one of them is outside the tunnel.
David Miller
Senior Privacy & VPN Architect
David works on VPN tunnels, protocols, kill switches and leak testing — the question of whether the thing you turned on is actually carrying the traffic you think it is.
This tool was built and checked against real torrent clients rather than described: Transmission 4.0.5 and aria2 1.37.0 were both run against it, from the magnet link and from the downloaded torrent file, behind Apache 2.4.58 using the site's own rewrite rules. The generated torrent file's info hash was recomputed from the file and matched the magnet's. Three defects surfaced during that testing and were fixed before release, one of them visible only under twenty-four simultaneous announces. Two more were found on the first live run and fixed the same day, and the page now checks its own tracker from the server when nothing arrives, so a silent result says which cause it was instead of listing possibilities. Everything tested, and everything not tested, is recorded in the file.
Last reviewed 29 September 2026 · Published 29 September 2026
View all articles by David MillerWhat the torrent leak test result shows
Two addresses, side by side. One is the address this page was requested from — your browser's. The other is the address your torrent client used when it contacted the tracker. They come from two separate programs making two separate connections, and the entire value of a torrent IP test is that those two can differ without anything on your screen telling you so.
For every announce your client makes, the table records:
| Column | Where it comes from | Why it matters |
|---|---|---|
| Address | The connection itself, nothing else | The one number the whole test exists to show you |
| Torrent client | The peer id every client sends, decoded per BEP 20 | Confirms it really was the client you meant — useful when a download manager has quietly taken over magnet links |
| Port | The announce | The port your client is listening on, or 0 if it is not |
| Reverse DNS | A PTR lookup on the address | Usually names the network on sight: a VPN host, or your own provider |
| IANA block | The IANA special-purpose registries | Separates ordinary public space from carrier-grade NAT, documentation ranges and the rest |
| Event | The announce | started when it joined, stopped when you removed it |
What the result is not: this page cannot know your real provider address, so it never tells you that you "are leaking" as though that were a measurement. It tells you what it saw and what that means. If you want the wider picture of how a tunnel fails and how to catch it, the guide to checking whether your VPN is leaking your IP covers every leak type in one place, and the comparison of VPNs on privacy grounds covers which ones handle this well.
Why your torrent IP can differ from your browser IP
A torrent leak is not usually a dramatic failure. It is almost always one of a handful of ordinary configuration states, and each one leaves a different fingerprint in the result above.
| What is happening | What you see here |
|---|---|
| No VPN at all. Both programs use your provider directly | Both addresses the same, and the reverse DNS names your ISP |
| VPN covering everything. The tunnel is the only route out | Both addresses the same, and the reverse DNS names a hosting network rather than a consumer ISP |
| Split tunnelling. The browser is in the tunnel, the torrent client is not — or the reverse | Two different addresses. This is the case the test exists for |
| The client is bound to the wrong adapter, or was started before the tunnel came up | Two different addresses, and the torrent one resolves to your ISP |
| A SOCKS5 proxy set for peers but not for tracker traffic — a very common qBittorrent and Deluge configuration | The announced address is your real one even though peer connections are proxied |
| The tunnel dropped and came back during the test | More than one address, with different times |
The reason a torrent privacy check has to be done from outside the browser is that none of these states is visible to the browser. Your VPN's own app will happily report "connected" while a torrent client bound to the physical adapter carries on as though the tunnel were not there.
Which one matters more: your browser outside the tunnel is a privacy problem. Your torrent client outside the tunnel is the one that reaches a rights holder's monitoring, because that address is announced to the swarm and to every tracker you use.
Nothing showed up? Five reasons, most likely first
Silence is the most common outcome of a torrent IP leak check, and it is not a pass. It means we never saw your client at all, which tells you nothing about which address it would have used. Every one of these has a different fix.
- Your client is set to DHT only and ignores trackers. Many are, deliberately. Look for "Enable tracker" or "Use tracker" in the connection settings; some clients also have a per-torrent toggle. This is the single commonest cause.
- The magnet link was never actually added. Clicking the button hands the link to whatever program claims magnet links on your system, which is not always the client you had in mind. Use Copy it instead and paste it into the client by hand.
- Outgoing HTTPS from the client is blocked. A firewall rule, a kill switch in its strictest mode, or a VPN that blocks everything but its own tunnel will stop the announce before it leaves your machine — which, to be fair, is the kill switch working.
- The client will not use an HTTPS tracker. A small number of older clients only support plain HTTP trackers. Try the downloaded torrent file rather than the magnet, and if that also does nothing, that is your answer.
- A proxy is configured for tracker traffic and is failing silently. If the client is set to route tracker announces through a proxy that is down or refusing, nothing arrives and the client usually says very little about it.
You do not have to guess between these. When the listening window closes with nothing recorded, this page asks the server to test its own tracker from the outside — fetching it three times with a torrent client's User-Agent, once as a plain page, once as an announce with ordinary characters, and once as a real announce carrying a twenty-byte info hash. Those three answers separate “the tracker is fine, your client never announced” from “something in front of this site is refusing torrent clients”, and the result appears above the table with the actual response that came back. No other torrent leak test tells you which of the two it was.
If that check says the tracker is reachable, the cause is on your side and the list above is the order to work through it. The quickest single experiment is to add the magnet with the VPN switched off: if the announce appears, the client and the tracker are both fine and something in your tunnel or firewall is stopping it — which, at least, is the kill switch doing its job. If it still does not appear, the cause is in the client's own settings.
The window is for you, not the protocol. An announce normally arrives within a second of the client adding the magnet. After the three minutes are up this page keeps checking every ten seconds for as long as the record lives, so if you install a client or change a setting and add the magnet late, the result still appears.
What this test does not cover
This page measures one thing precisely: the address your client used to reach an HTTPS tracker. That is a real answer, and it is not the whole picture. Being clear about the edges is more useful than implying there are none.
| Not tested here | Why, and what it means for you |
|---|---|
| DHT — the distributed hash table, BEP 5 | Peers find each other without any tracker. A client can expose an address through DHT while its tracker traffic is perfectly tunnelled. If you want no exposure at all, DHT has to be off as well |
| Peer exchange — PEX, BEP 11 | Peers pass each other's addresses between themselves. Same story: nothing to do with trackers |
| UDP trackers | Most public trackers are UDP. Answering them needs a process listening on a UDP port, which this server does not have, so a UDP-only client will show nothing here |
| Torrent DNS leaks | Whether your client resolves names through your VPN's resolver or your provider's needs an authoritative DNS server to observe, which is a different kind of infrastructure again |
| IPv6 announces | If your client reaches us over IPv6 the address is recorded and flagged like any other — but this was not tested during the build, because the build environment has no IPv6, so it is reported rather than promised |
The browser side of the same question — whether your browser is handing out your address through WebRTC — is a separate test entirely: the WebRTC leak test covers that one. And the broader point that a tunnel hides less than people assume is made well in the nine things a VPN still cannot hide.
A clean result here means: your client's tracker traffic went where you expected. It does not mean nothing else can expose you.
Binding qBittorrent, Transmission, Deluge and µTorrent to your VPN
If the torrent VPN test above showed two different addresses, the fix is almost always the same idea: stop the client being able to reach the internet by any route except the tunnel. Binding it to the VPN's network interface does that at the operating system level, so when the tunnel drops the client has no route at all rather than quietly falling back.
| Client | Where the setting lives |
|---|---|
| qBittorrent | Tools → Options → Advanced → Network interface. Pick the VPN adapter, not "Any interface". A qbittorrent ip leak is very often just this one dropdown |
| Transmission | No interface binding in the desktop app; bind at the firewall, or run it inside a network namespace or container that only has the tunnel |
| Deluge | Preferences → Network → Incoming/Outgoing interface. Deluge accepts an interface name or an address |
| µTorrent (written uTorrent almost everywhere) | Options → Preferences → Advanced → net.bind_ip, set to the address the VPN adapter holds |
Two things worth knowing before you rely on it:
- A kill switch is not the same thing. It stops traffic when the tunnel drops; it does nothing about a client that was never inside the tunnel. The two work together, and what a VPN kill switch actually protects explains where each one applies.
- Disable IPv6 in the client if your VPN is IPv4-only. Otherwise the client can reach a tracker over IPv6 on your ordinary connection while every IPv4 packet goes through the tunnel.
Re-run the test after any change. The address should move, and the reverse DNS should change with it.
What is my torrent IP, and is it my real one?
"What is my torrent IP" is a slightly different question from "what is my IP", and the difference is the whole point. Your browser's address is easy to see — every website you visit knows it. Your torrent client's address is only visible to the trackers and peers it talks to, which is exactly why it goes unnoticed when it is not the one you intended.
The same measurement goes by several names, which is worth knowing if you are comparing tools. TorGuard titles its page check my torrent IP, ipleak.net labels its section torrent address detection, and whatismyip.net calls its version a torrent IP checker. All three mean one thing: the torrent IP address your client hands to a tracker, as opposed to the address your browser hands to a website.
The address in the table above is the one your client announced. Whether it is your real one depends on what it resolves to:
- Reverse DNS naming a consumer ISP — something ending in a broadband provider's domain, often with your area or a line identifier in it — means the client is on your ordinary connection.
- Reverse DNS naming a hosting or datacentre network, or no PTR record at all, is the usual signature of a VPN exit.
- Carrier-grade NAT (
100.64.0.0/10) means your provider is sharing one public address across many subscribers, so the address is not uniquely yours to begin with.
If you want to go further than the name and see which network actually holds the address, run it through the ASN lookup, which reports the autonomous system and its operator. And if you have been relying on a proxy rather than a VPN, it is worth knowing that the proxy checker says plainly on its own page that a well-configured VPN produces the same clean signature as no proxy at all — browser-side header checks cannot answer this question, which is why this test has to happen outside the browser.
How the test works: a magnet link, one announce, and a peer id
There is no clever trick here. It uses the ordinary BitTorrent announce that every client makes before it can find a single peer, and it is worth showing the mechanism rather than asking you to trust a result.
- When you press Start, this page generates a random info hash — the identifier a torrent is known by — and builds a magnet link around it.
- The magnet names a tracker. A tracker is not software you install or a network you join; it is one web address whose only job is to answer "who else has this torrent?". The tracker named in this magnet is this page.
- Your client opens the magnet and, before it knows anything about the content, asks that tracker for peers. To ask, it has to connect — and that connection carries its address.
- The request also carries a peer id: twenty bytes every client sends. BEP 20 defines the convention as "a dash followed by two characters to identify the client implementation, four ascii digits to denote version number, and a dash", which is how
-TR4050-is read as Transmission 4.0.5. That is a more reliable identifier than an HTTP User-Agent, which many clients never send at all. - The tracker answers with zero peers — always, to everyone. There is nobody to connect to, nothing downloads, and the placeholder file has no content.
The announce format itself is set out in BEP 3, and the distributed alternative that this test deliberately does not cover is BEP 5.
On what this server is: the tracker answers only for hashes this page generated in the last fifteen minutes, returns zero peers to every request, has no index, no search and no listing, and deletes each record fifteen minutes after the test began. It is not capable of introducing two peers to each other, which means it cannot help anyone download anything. That is a property of how it is written, not a promise.
Frequently asked questions about torrent IP leaks
How do I check if my torrent client is leaking my IP address?
Press Start the test above and open the magnet link it gives you in your torrent client. The client contacts the tracker named in that link — which is this page — and the address it arrives from appears in the table within a second or two. No account, no download, nothing to install. The address shown is the one your torrent client really used, which is not always the one your browser is using.
My torrent IP is different from my browser IP — is that a leak?
It means the two programs took different routes to the internet, and that is worth understanding rather than panicking about. With a VPN running, it usually means one of them is outside the tunnel. Which one matters: your browser being outside is a privacy problem, your torrent client being outside is the one that shows up in a copyright notice. The reverse DNS on each address is the quickest way to tell which is your VPN and which is your provider.
I opened the magnet link and nothing appeared. Why?
Silence is not a pass — it means we never saw your client. The five common causes, in order: the client is set to DHT only and ignores trackers; the magnet was never actually added; a firewall or the VPN is blocking outgoing HTTPS from the client; the client does not support HTTPS trackers; or a proxy is set for peers but not for tracker traffic. The section on this page goes through each one.
Does this test cover DHT and peer exchange?
No, and that is a real limit rather than a detail. This test sees one thing: the address your client used to contact a tracker. DHT (BEP 5) and peer exchange (BEP 11) can expose an address without any tracker being involved, and a UDP tracker uses a protocol this server cannot answer. A clean result here means your tracker traffic is where you expect it, not that nothing else can leak.
Which torrent clients does this work with?
Any client that contacts an HTTPS tracker, which is almost all of them. Verified by running them: Transmission 4.0.5 and aria2 1.37.0, both from a magnet link and from the downloaded torrent file. qBittorrent, Deluge and anything else built on libtorrent use the same tracker code path, but they have not been run here and so are not claimed. If your client shows nothing, the troubleshooting section covers why.
What do you store, and for how long?
For each announce: the address, the port, the event, the peer id and the User-Agent header if one was sent. Nothing else — no account, no cookie, no browser fingerprint. Everything is deleted 15 minutes after the test was started, and the record is keyed only by the random hash in your magnet link, which is unguessable and known only to you. The tracker also refuses any hash it did not generate.
Does a VPN kill switch stop a torrent IP leak?
It stops one specific cause: the tunnel dropping while the client keeps running. It does not help when the client was never inside the tunnel to begin with, which is the more common case with split tunnelling or a client bound to the wrong adapter. Binding the client to the VPN network interface is the stronger fix, because then the client simply has no route at all when the tunnel is down.
Can I test qBittorrent specifically?
Yes — run the test and open the magnet in qBittorrent rather than any other client. The result names whichever client announced, read from its peer id, so you can confirm it really was qBittorrent that reported in. That matters when several clients are installed, or when a download manager has quietly registered itself as the magnet handler.
Related leak and address tools
This test covers the torrent client. These cover the browser, the proxy layer and the address itself.
Your torrent client is one program. Your browser is another.
A tunnel that covers one does not automatically cover the other, and the browser has leaks of its own that no torrent test can see. Check that side too.
Last updated 29 September 2026 · announces observed by this page's own tracker · records deleted after 15 minutes