STUN / TURN Server Test

Verify from your browser that your ICE servers work and which candidates they return.

Server URL

Result

    ICE candidates

    TypeAddressProtocolTime

    What STUN and TURN servers do

    WebRTC powers video calls, screen sharing and browser-to-browser file transfers. Before two devices can talk directly, each needs to know at which address the other can be reached. Most devices, however, sit behind a home router or corporate firewall using private addresses translated by NAT. STUN and TURN servers solve this:

    • STUN tells a device how it looks from the internet: its public IP address and port. With that information, two peers can often connect directly.
    • TURN acts as a relay when a direct connection is impossible, for example behind symmetric NAT, strict firewalls or networks that only allow TCP.

    Running the test

    1. Enter the server URL with a stun:, turn: or turns: prefix (for example stun:server.example.com:3478 or turn:server.example.com:3478?transport=tcp).
    2. For TURN servers, fill in the username and credential. If you use time-limited credentials, make sure they have not expired.
    3. Add more servers if needed and run the test. Your browser gathers ICE candidates and lists each one with its type, address, protocol and how long it took to arrive.

    If you do not have your own server, use the option to test our servers to see what a working result looks like.

    Reading the candidate types

    Each row in the result is an ICE candidate. What it means depends on its type:

    • host: the device's own local address. Modern browsers hide it behind a random .local name for privacy.
    • srflx: the public address reported by the STUN server. If you see one, STUN works.
    • relay: the relay address allocated by the TURN server. If you see one, TURN and authentication work.
    • prflx: an address discovered during connectivity checks; rarely seen in a one-sided test.

    The time column shows how many milliseconds after the start each candidate arrived. It gives a sense of the server's distance and load; times of several hundred milliseconds can noticeably delay call setup.

    Common problems

    • No relay candidate: wrong username or password, a mismatched static-auth-secret on the server, or the TURN port blocked by a firewall.
    • Works over UDP only: for users on restricted networks, add ?transport=tcp or turns: (TLS) on port 443.
    • turns: fails but turn: works: the TLS certificate may be invalid, expired or not match the hostname.
    • Unexpected srflx address: with CGNAT or a VPN, the public address belongs to your ISP or VPN provider.

    The test runs entirely in your browser; the credentials you enter are only used by your browser to connect to the server you specified. To see your public IP and WebRTC leak status, visit What Is My IP. To measure real packet loss over a WebRTC data channel, try the packet loss test, and check baseline latency with the ping test before tuning call quality in your own application.

    Tools