Proxy Leak Judge

Overview

The judge shows everything a platform's servers could learn about a device that connects through a proxy, VPN or tunnel. It covers four things. Does the real IP or location leak? Is the exit IP flagged? Can a proxy be detected at all? Does the device's own setup give it away?

• Running a test
• Reading results
• Every check
• Fixing common results
• What can't be faked
• iPhone app
• API
• How it works

Running a test

In a browser

Open https://leak.realrewards.shop/?device=phone07 on the device. Tap the TEST block under the judge to start. The run takes about 15 seconds. Add &auto=1 to start it as soon as the page loads (for automation). device is just a label; use one per phone.

Nothing is stored on the server. A test session lives in memory only while it runs, and is wiped as soon as the verdict is delivered (or after 10 minutes if the run is abandoned). The server writes no logs of client IPs. Your results are kept only in your browser: the last 20 appear under Saved in this browser. Use Download JSON to keep or share one.

In the iPhone app

The Leak Probe app runs the same test through the iPhone's own app networking stack, the one native apps use, not Safari's. It adds on-device checks a website can't do. Use the app for the most accurate picture of what an app sees.

Reading results

Overall: LEAKING if any check fails, DETECTABLE if any warns, otherwise CLEAN. Score = 100 − 25 per fail − 8 per warn.

Every check

APP = native app only. Everything else runs in both the browser and the app.

Leaks: does the real identity get out?

Network identity: what the exit IP looks like

Geography: does the device match the IP?

Proxy tells: can a proxy be detected?

Device

Fixing common results

What can't be faked

Three tells come from how the connection is built, not from configuration:

• TCP fingerprint. Proxies (SOCKS, HTTP and similar) open new connections from their own Linux stack. A layer-3 tunnel (WireGuard, OpenVPN tun) to an exit you control forwards the phone's own packets and passes.
• Latency triangulation. Same cause, same fix: with a layer-3 tunnel the whole path is one TCP connection.
• Distance. Physics. A device on another continent from its IP is at least 100 ms too slow for its IP's location, whatever the tunnel. Adding delay makes it worse. The only fixes are physical: put the device near its exit, or use exits near the device.

iPhone app: Leak Probe

Why use the app? The browser test shows what Safari gives away. Native apps aren't Safari. They have their own network code, and they can read things about the phone that a web page never can. A clean result in Safari doesn't mean a clean result in the apps. To find out whether an app can see your proxy, test from an app.

Use the browser for a quick check on any device. Use the app before trusting a phone with real accounts.

Build & install

1. Unzip and open LeakProbe.xcodeproj in Xcode 16 or later.
2. Target LeakProbe → Signing & Capabilities: pick your Team. Change the bundle ID if it's taken.
3. Connect the iPhone with Developer Mode on, select it, and press Run (⌘R).

A free Apple ID works, but the app expires after 7 days. A paid developer account lasts a year.

From the command line:

xcodebuild -project LeakProbe.xcodeproj -scheme LeakProbe \
  -destination 'generic/platform=iOS' -allowProvisioningUpdates \
  DEVELOPMENT_TEAM=<TEAM_ID> build
xcrun devicectl device install app --device <DEVICE_ID> <path>/LeakProbe.app

Run remotely

The URL scheme leakprobe://run?device=phone07 starts a run. You can trigger it from the Mac that drives the phone:

xcrun devicectl device process launch --terminate-existing --device <DEVICE_ID> \
  --payload-url "leakprobe://run?device=phone07" shop.realrewards.leakprobe

Privacy

Results stay on the phone. Use Share JSON to export one. The server keeps nothing.

API

POST /api/session?device=NAME        → { sid, zone, v4, v6, https_origin, ... }
GET  /api/ping?sid=                  RTT sample (TCP_INFO recorded)
GET  /api/probe/{alt|v6|tls|dns}?sid= path probes
POST /api/client?sid=                device-measured report (pings, env, webrtc, probes)
POST /api/app?sid=                   native app report (interfaces, proxy, path)
GET  /api/result?sid=[&final=1]      verdict JSON (final=1 wipes the session)
UDP  :3479  "PLK1 <sid> <tag>"        raw UDP echo
UDP  :3478                           STUN binding

How it works

One Go program runs on one server. It answers DNS for the test domain itself, so it sees every resolver that queries it. It captures the first packet (SYN) of incoming connections for fingerprinting, and reads the kernel's TCP stats for each connection. It runs its own STUN server and UDP echo port. It serves HTTPS and HTTP/3 with a Let's Encrypt certificate.