WebRTC ICE Tester

ICE (Interactive Connectivity Establishment) is how two WebRTC peers agree on a network path between them, trying a direct connection first and falling back to a TURN relay when one isn't possible. This tool runs a trickle ICE test against any STUN or TURN server you give it and shows every candidate your browser gathers, with the errors spelled out instead of left as raw codes.

What the candidate types mean

How to test a TURN server

1. Add your TURN server's URL, using turn: for plain UDP/TCP or turns: for TLS.
2. Enter the username and credential your TURN server issues. If you use time-limited credentials, generate a fresh pair right before testing.
3. Set the ICE transport policy to Relay only.
4. Click Run ICE gathering.
5. Confirm at least one relay candidate appears in the results table - that proves TURN can carry a call on its own.
6. If no relay candidate appears, check the error list and read "No relay candidates with TURN configured" below.

Common ICE and TURN problems

• No relay candidates with TURN configured: the usual causes are wrong credentials, a time-limited credential that's already expired, the relay port range blocked by a firewall or cloud security group, or TURN listening on a different transport (UDP vs TCP) than the one you requested. Run again with Relay only selected to isolate the problem to TURN alone.
• 401 unauthorized from TURN: the username or credential is wrong, or your server uses time-limited credentials that have expired. Coturn's use-auth-secret mode generates a credential as an HMAC of a timestamp - if your server's clock has drifted, credentials can expire before you finish typing them in.
• Time-limited credentials failing intermittently: check your TURN server's system clock (NTP drift is the most common cause) and the TTL you're generating credentials with. A TTL of a few seconds is too short for a human to test manually - generate a fresh credential immediately before running this tool.
• turns: failing on certificate validation: turns: connects over TLS, which means the hostname you use has to match the certificate the server presents. Connecting to a bare IP address, an expired certificate, or a self-signed certificate the browser doesn't trust will all fail here - use a proper hostname with a valid certificate.
• Works on UDP but not TCP, or blocked entirely: add a row with ?transport=tcp and test it on its own. Some corporate networks allow outbound TCP on common ports (443) but block UDP and non-standard TCP ports outright - if your TURN server only listens on a blocked port, TCP relay traffic will never arrive.
• Candidates gather but calls still fail: if this test returns healthy host, srflx and relay candidates but your actual application still can't connect, ICE isn't the problem. Check your signalling layer (SDP offer/answer exchange, WebSocket connection, session negotiation) instead.
• Only .local addresses appear: Chrome (and other Chromium browsers) replace your real local IP in host candidates with a randomly generated .local mDNS hostname, so a website can't fingerprint your local network just by starting a peer connection. This is intentional privacy behaviour, not a bug, and it doesn't affect whether the candidate actually works for a call.
• Coturn behind NAT without external-ip set: if your Coturn server itself sits behind a NAT (common on cloud VMs with a private and a public IP), it needs external-ip=<public-ip>/<private-ip> in turnserver.conf. Without it, Coturn advertises its private IP as the relay address, which is unreachable from the internet - candidates will appear to gather but the relay address won't actually work.
• Works locally, fails in production: almost always a firewall, cloud security group, or network ACL blocking the TURN port or the relay port range in the production environment but not your local network. Run this test from the same network your users will be on, and check that the relay port range is open both inbound and outbound.

Once ICE looks healthy, verify your signalling and media stack end to end. If a call still won't connect, check the SDP itself with the SDP inspector - missing ICE credentials or a missing DTLS fingerprint will break a connection even when STUN and TURN both work fine. If you're troubleshooting a live deployment rather than a single server, browse Meetrix's guide to SIP and Jitsi audio infrastructure , check out Meetrix's self-hosted Coturn AMI if you need to stand up your own TURN server, or browse all Meetrix features. If it's your own camera, mic, speakers or connection you're checking rather than a server, run the pre-call check instead, or see whether your connection has the bandwidth for the call in the first place with the bandwidth calculator.