Learning objectives
After reading this article you will be able to:
- Understand why WebRTC gathers network candidates
- Distinguish local, public and relay observations
- Investigate unexpected public addresses alongside the normal web connection
Why WebRTC gathers addresses
Real-time peers need a way to find a working route between them.
ICE evaluates candidate paths. STUN can help discover an address visible from outside a network, while TURN can relay traffic. The available candidates reflect the connection setup and browser policy.
Candidate gathering is distinct from recording a microphone or camera. Whether a particular test can gather information without media permission depends on the browser and how the test is implemented.
What the candidate types mean
Read the type and address category before drawing a conclusion.
| Observation | Meaning | Useful next check |
|---|---|---|
| Private address, such as 192.168.x.x | An internal network address | Distinguish local information from public egress |
| mDNS hostname | A hostname used to obscure a local address | Check how the browser represents host candidates |
| Server-reflexive public candidate | An address observed through address discovery | Compare with the intended network route |
| Relay candidate | A route through a relay server | Interpret it as relay infrastructure |
A page may receive only a subset of these, or no usable candidates. An empty report needs its own explanation: gathering may be blocked, unavailable or unsuccessful.
What to do when WebRTC and HTTP show different public IPs
Treat the difference as a reason to inspect routing and address families.
Record the public IP from the ordinary web request, the candidate type and whether each address is IPv4 or IPv6. A browser-only proxy, split tunnel, multiple interfaces or dual-stack connection can produce different paths.
Then compare the observation with your intended setup. If traffic was supposed to use one VPN route, a candidate outside that route deserves investigation. A private address alone is not the same observation as an unexpected public address.
Rerun the WebRTC check inside the affected profile after changing one relevant setting. Use the IP lookup and DNS test separately to inspect the other routes.
Why separate network tests help
A successful page load proves one route works. WebRTC and DNS can involve different components, so checking them separately gives a clearer view of which connection changed.
Interpreting the result
- Candidate visibility depends on browser policy and network conditions.
- A public-IP difference needs routing context; it is not automatically a physical-location measurement.
- A WebRTC result does not audit every network request an application makes.
Frequently asked questions
Is a 192.168 address my public IP?
No. It is a private address used inside a local network. It should be distinguished from a public address visible to an external service.
Why do I see a hostname ending in .local?
Some browsers use mDNS hostnames to obscure local addresses in WebRTC candidates. Interpret it as a representation choice, not a public exit IP.
Can my page use a proxy while WebRTC follows another route?
That is possible depending on proxy coverage, browser configuration and network policy. Compare actual observations in the same profile.