Live IP view

Probing your current IP fingerprints...

Overview

IP Inspector gives you a side-by-side look at the IP your request exposes at the edge and the WebRTC candidates your browser reveals. It is ideal for validating VPN, proxy, or corporate network setups without extra steps. WebRTC gathers ICE candidates from three lanes: host (local/LAN), srflx (public STUN-mapped), and relay (TURN). Host shows the interface your browser uses, srflx is what a STUN server sees on the Internet, and relay indicates traffic would proxy through TURN when direct paths fail. Multiple IPs are normal—compare them against your VPN/expected exit. Blocking WebRTC or disabling srflx/relay in hardened browsers can reduce leakage but may break audio/video apps.

How to Use

Open and auto-detect
The tool runs as soon as the page loads; there is no form to fill.
Toggle your network
Enable a VPN, switch Wi-Fi, or join a hotspot, then click "Run detection" to refresh the readings.
Compare the lanes
Edge IP shows what servers see; WebRTC candidates reveal potential local or relay addresses from your browser.

Use Cases

VPN and proxy checks

Confirm the IP shown to edge services matches your VPN while WebRTC is not leaking a different route.

Remote support handoff

Copy the detected IPs to share accurate context with network or security teams when debugging access issues.

Privacy audits

See whether WebRTC exposes local or relay addresses so you can disable or sandbox it when needed.

WebRTC deep dive: why you may see multiple IPs

Running this diagnostic contacts the ToolCLI edge API, which sees request metadata including your source IP and User-Agent. WebRTC probing also contacts Cloudflare and Google STUN servers, which can observe the public network details needed to return ICE candidates.

WebRTC uses ICE (Interactive Connectivity Establishment) to find the best path between peers. It gathers host candidates from your local interfaces (Wi-Fi, Ethernet, virtual adapters), srflx candidates from STUN servers that reveal your public/NAT-mapped address, and relay candidates from TURN servers that proxy traffic when direct paths fail. Seeing several IPs is expected and helps browsers choose the fastest and most reachable route.

Host candidates often include private ranges (192.168.x.x, 10.x.x.x, fd00::/8) or VPN-assigned addresses. These do not leave your LAN but can reveal network topology to scripts if not blocked. Srflx candidates reflect what the STUN server sees on the Internet side of your NAT—this is usually your real public exit, even when a proxy is in place. Relay candidates come from TURN and hide your real IP behind the relay, but they add latency and require a TURN service.

Privacy-minded setups sometimes block srflx/relay collection or disable WebRTC entirely. Hardened browsers and some extensions do this to reduce IP leakage, but it can break video/voice apps. Corporate policies may also restrict UDP, forcing WebRTC to fall back to TURN or fail.

If you are testing a VPN/proxy, compare the Edge IP (what the server sees) with srflx candidates. If they differ, WebRTC may be bypassing your tunnel. To mitigate leaks, disable WebRTC, restrict ICE to relay-only, or use browsers/clients that honor VPN routing for UDP.

The displayed result combines the ToolCLI edge API response with ICE candidates in your browser. ToolCLI does not intentionally persist the result, but the edge and STUN providers handle the requests under their own policies.