leak suite
DNS & WebRTC leak suite
Live checks that run in your browser: is your DNS actually filtered through the node's AdGuard, and does WebRTC quietly leak your real address? Nothing you see here is stored or logged.
dns filter
$ dns --filter-check
probing…
$ dns --trackers
probing…
The filter check quietly tries to load a domain the node's AdGuard is set to block — if it fails, your lookups are going through the filter; if it loads, they're being answered somewhere else. The tracker rows do the same for well-known ad domains: blocked = your resolver refused it, reachable = it would load. A partial score (say 2 of 3) means some trackers are caught and the rest slip through — the reachable ones simply aren't on the node's blocklists yet.
webrtc
$ webrtc --full-scan
scanning…
$ ip --dual-stack
probing…
WebRTC can hand a web page your real local and public addresses to set up peer-to-peer calls — sometimes straight past a VPN. This asks a public STUN server what it sees and compares it to your visible IP.
why no resolver list?
What this can & can't show
Some leak tests print the exact IP of every DNS resolver handling your traffic. That trick needs a dedicated nameserver sitting on the public internet, logging who asks it questions — an extra listening service and an open port we've deliberately chosen not to run on the node.
Instead this suite answers the question that actually matters — are you filtered, or are you leaking? — by watching whether a blocked domain resolves. Same verdict, no exposed infrastructure.