How to check if your VPN is actually working (and not silently leaking it)

Open any single-IP checker — ifconfig.me, ip.sb, ipinfo.io. If the IP you see is your VPN's exit (and not your home IP), the VPN's HTTP layer is working. This is necessary but far from sufficient: a tunnel can route HTTP perfectly and still leak via DNS or WebRTC.

Common pitfall: the VPN is 'on' but your system proxy or browser proxy is set to 'direct' (no proxy), and the VPN client only catches traffic that goes through its TUN interface. Some apps bypass the TUN. The IP echo is showing the right thing, but a background app is leaking.

DNS is the phone book of the Internet. When you type 'github.com', your computer asks a DNS resolver for the IP. If your VPN is up but DNS still goes to your ISP's resolver, your ISP sees every domain you visit, even though the IP itself is hidden.

How to test: run IPCombo, look at the 'resolver' line under the public IP. If the resolver is your ISP or a known public DNS (8.8.8.8, 1.1.1.1), the DNS is leaking. If the resolver is the VPN provider's DNS, it's working. DoH (DNS over HTTPS) and DoT (DNS over TLS) hide DNS queries from your ISP even when the resolver is upstream — but they require the VPN client to set them.

WebRTC negotiates peer-to-peer connections by gathering candidate IP addresses. Even if your HTTP traffic is tunneled, WebRTC can collect your real local and public IPs and send them to the remote peer. A website running a few lines of JavaScript can harvest them.

IPCombo's WebRTC probe runs the standard ICE candidate gathering and reports every candidate type — host (your LAN), srflx (your public NAT IP), and relay (TURN fallback). If the srflx is your home IP but the public IP echo shows your VPN exit, the WebRTC layer is leaking.

Modern VPN clients that implement WebRTC masking at the network layer (not the browser layer) prevent this leak. Browser extensions like uBlock Origin can also replace srflx candidates. If your VPN does neither, you leak.

The most thorough check: load a target whose real-exit IP you trust, and compare it to your HTTP echo. If you trust the cdn-cgi/trace endpoint on cloudflare.com, and your HTTP echo comes back US-east, but cloudflare's trace says your IP is in JP — your VPN is splitting routes.

This is by design for many users — direct for local sites, proxy for foreign ones. But it's also the most common silent failure mode: a new VPN rule that wasn't supposed to match still matches, or a whitelist that wasn't supposed to apply now applies. The per-route check is the only way to surface these.

IPCombo's connectivity matrix does all four stages in one run. It shows the HTTP echo, the DNS resolver, every WebRTC candidate, and the per-target real IP for 34 destinations. If any of the four disagree with what you expect, the diagnosis card flags it. If everything is green, your VPN is doing its job.