adversarial test

We attacked our own client to find the real IP.

Proxy on, nothing exempt — not even the app's own helper process. Every channel a website or a local probe could use to deanonymize the machine came back sealed.

egress IPproxy exit · not the real IP
physical NIC · raw TCPblocked by kill switch
physical NIC · raw UDPblocked by kill switch
IPv6no route · no leak
DNSintercepted · fake-IP resolved
WebRTC / STUNone .local candidate · no IP
real public IPunreachable

The only thing observable is the RFC-1918 LAN address every machine can read about itself — never your public IP or location.

how it holds

Defense in depth, not a single setting.

Interface-scoped kill switch

A firewall rule scoped to the physical adapter drops sockets that try to bind it directly — the classic bypass on Windows where strict routing isn't enough.

Fake-IP DNS interception

DNS is answered inside the tunnel with synthetic addresses, so lookups can't leak to an ISP resolver and a hostname can't be raced around the proxy.

WebRTC contained

The browser only ever emits a single mDNS .local candidate — no host or reflexive IP — kept consistent across page, worker and OffscreenCanvas contexts so it doesn't read as suppressed.

No IPv6 escape

IPv6 is handled at the routing layer, so a dual-stack request can't quietly exit on a path the proxy doesn't cover.

Coherent, not just hidden

Spoofed values are generated to match your real host class. A fingerprint that's internally inconsistent is itself a tell — coherence is the harder, better goal.

Nothing exempt

The test ran with the app's own helper removed from the allow-list, probing through non-whitelisted tools — so the result isn't a false pass from a trusted process.

The honest ceiling is on-device correlation: a malicious program running locally can read your machine's own hardware — but it can't reach the internet off-tunnel to phone it home.

Run the test yourself.

Install PROXA, turn the proxy on, and point any leak-test site at your machine.

Download PROXA →