🌐 ICE Server Tester

For each server you add, your browser creates a real RTCPeerConnection and gathers ICE candidates. A STUN server passes if it returns a server-reflexive (srflx) candidate containing your public IP. A TURN or TURNS server passes if it allocates a relay candidate, which proves your credentials were accepted and the server will relay traffic.

The test runs entirely in your browser. Credentials are sent only to the TURN server you are testing — exactly as your own WebRTC application would send them — and are never transmitted to icetester.org. They are optionally cached in your browser's local storage so the form is pre-filled next visit; use Clear History or your browser's site-data settings to remove them.

STUN and TURN are different protocols with different failure modes. The most common TURN-specific causes are wrong or expired credentials (especially time-limited REST credentials), using turn: when the server only listens for turns: (or the reverse), the relay port range (often UDP 49152–65535) blocked by a firewall, or the TURN server's quota limits. A passing STUN test only proves basic UDP reachability.

turn: uses plain UDP or TCP transport (default port 3478), while turns: wraps the TURN control connection in TLS (default port 5349). turns: is useful on networks that only allow outbound TLS traffic, but adds handshake latency and server CPU cost. Note that media relayed through the server is already encrypted by WebRTC (SRTP/DTLS) in both cases.

Under roughly 100 ms is typical for a server in your region. 100–300 ms usually indicates a cross-region or intercontinental server, which still works but adds call setup latency. Consistently above 500 ms, or timeouts, deserve investigation: distance, packet loss, or an overloaded server.

Modern browsers hide host candidate IPs behind mDNS .local names for privacy — that part is normal. But if a STUN test produces no srflx candidate at all, your network is likely blocking outbound UDP to port 3478/19302, a VPN is forcing traffic through a tunnel, or the STUN server is down. Try a known-good public server like stun.l.google.com:19302 to tell the two apart.

Yes — and you should. Because the test uses your real browser and network path, the results show exactly what your users on that network would experience: which servers are reachable, whether UDP is blocked, and whether only TLS relay (turns:) gets through.

For production applications, almost always yes. STUN is sufficient when both peers are behind well-behaved NATs, but symmetric NATs, strict corporate firewalls, and carrier-grade NAT on mobile networks defeat it. Typically a minority of connections — often cited around 10–20%, varying by audience — cannot connect without a TURN relay. Background: NAT traversal challenges in WebRTC.