VPN and proxy checks
Confirm the IP shown to edge services matches your VPN while WebRTC is not leaking a different route.
IP Inspector
See what IP your request shows at the edge and via WebRTC in one glance.
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.
Use Cases
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.
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.
Related Tools
WebRTC deep dive: why you may see multiple IPs
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.
Remember that this tool runs entirely in your browser. No IPs are persisted; the readout combines the edge API response and local ICE candidates for your reference.