Check guide · In the browser

WebRTC network clues

The addresses your browser volunteers for voice and video.

What this check is

WebRTC, the browser's calling technology, discovers network addresses it could be reached at and shares them with the page so calls can connect. Those candidate addresses can include the machine's real public IP, even when the browsing itself travels through a VPN or proxy. This check lists what WebRTC exposes and compares it with the address the HTTP request arrived from.

What Tells reads

WebRTC ICE candidates gathered in the page (via a public STUN server)
The request's public IP, for the comparison

How to read your result

Fail: WebRTC exposed a public IP that differs from the request IP: the connection claims one address while the browser volunteers another.
Pass: WebRTC's public addresses agree with the request, or it exposed only local addresses.
Not available: WebRTC is unsupported, blocked, or produced no candidates. Privacy tools often disable it; that reads as Not available, not as a failure.

Why it matters

This is the classic proxy leak, and it cuts both ways. For a person using a VPN for privacy, it is a genuine exposure worth knowing about. For an automated setup, it is proof the network story is staged: the proxy says one country while the browser's own calling stack names another. Sites that run WebRTC probes treat a mismatch as one of the strongest single signals available to them.

Where this matters most

On the platforms Blowhorn works with, this tell rates Low everywhere: none of LinkedIn, X, Reddit, GitHub, Slack, Bluesky or Hacker News has public evidence of using it as an anti-bot input. It stays in the tool because it matters on the wider web (it is a standard input to commercial fingerprinting and bot-management products) and because Low is a snapshot, not a law: a platform that buys such a product changes this row without announcing it. The full reasoning is in the platform guide.

In your report

Find it in the checks table on the tool page, with the detail in the WebRTC comparison section. The same findings appear in the report JSON under verdict.reasons, and the agent guide explains how to read them programmatically.