WebRTC ICE Test
Run a WebRTC ICE test online. Gather host, server-reflexive and relay candidates, inspect protocols and addresses, and debug ICE connectivity in your browser.
ICE candidate gathering
How to read your WebRTC ICE test
ICE is the connectivity layer WebRTC uses to discover possible routes between peers. This tool creates a real browser peer connection, gathers candidates and shows the candidate type, transport protocol, address, port and associated ICE server. It is useful when diagnosing why a browser call works on one network but fails on another.
Host, server-reflexive and relay candidates
A host candidate represents a local interface path. A srflx candidate is discovered through STUN and often reflects the public-facing network address. A relay candidate is allocated through TURN. If you specifically need to validate a custom endpoint, use the STUN server test or TURN server test.
Why candidate results differ by browser
Modern browsers may mask local addresses with mDNS hostnames and may expose different candidate sets depending on privacy settings, VPN configuration, network interfaces and browser policy. Candidate gathering alone does not guarantee that a complete media session will succeed, but it is one of the fastest ways to find WebRTC connectivity problems.
For a broader readiness check that also includes camera and microphone access, run the main WebRTC test. If your goal is privacy rather than connectivity, use the WebRTC leak test.
WebRTC ICE test FAQ
What is an ICE candidate?
An ICE candidate describes a possible network path that WebRTC can use to connect peers. Common types include host, server-reflexive and relay candidates.
What does srflx mean?
A server-reflexive candidate is discovered through STUN and normally represents the public-facing address seen by the STUN server.
Why is there no relay candidate?
Relay candidates require a configured TURN server with valid credentials. A STUN-only test will not normally produce relay candidates.