Sazrika Foundation / Learn / STUN vs TURN
Interactive diagram

STUN vs TURN: what is a TURN server?

Most WebRTC calls connect directly between two browsers. Some cannot. Step through what STUN does, why direct connections fail, and what a TURN server actually relays.

Step 0 of 0
// Current step
Press Play to begin
Two people want to make a video call. Their browsers must find a network path to each other. This diagram shows how STUN helps them try a direct path, and what happens when that fails and TURN has to step in.
Want to see your own ICE candidates? The ICE Candidate Inspector shows exactly what your browser gathers, and can test your own TURN server.
Open ICE inspector →
STUN is cheap
A STUN server only answers one question: what public address do you appear to come from? That is a few bytes. This is why free public STUN servers exist.
TURN is expensive
A TURN server relays every single audio and video packet in both directions. You pay for all that bandwidth, which is why nobody offers free public TURN.
Most calls do not need TURN
Roughly 80 to 85 percent of connections succeed directly using STUN alone. TURN is the safety net for the rest.
But you still need TURN
Without it, that remaining 15 to 20 percent of your users simply cannot connect. Corporate firewalls and symmetric NAT are the usual culprits.
Symmetric NAT
Some routers give a different public port for every destination. The address STUN reported is then useless to the peer, so a direct path cannot be built.
TURN over TCP 443
Strict corporate firewalls block UDP entirely. Running TURN on TCP port 443 makes the traffic look like HTTPS and usually gets through.

STUN and TURN, in plain English

When your browser makes a WebRTC call, it has a problem: it does not know its own public address. Almost every device sits behind NAT, a router that shares one public IP address across many devices. Your browser only knows its private address, something like 192.168.1.20, which is meaningless to anyone outside your network.

What STUN does

STUN, Session Traversal Utilities for NAT, solves exactly one problem. Your browser sends a small request to a STUN server on the public internet and the server replies: this is the address and port I saw your request arrive from. That public address becomes a server reflexive candidate, usually shortened to srflx. Your browser sends it to the other peer, who can then try to reach you on it. STUN is tiny, cheap and stateless, which is why Google and Cloudflare run free public STUN servers.

What TURN does

Sometimes the direct path never works. The most common reason is symmetric NAT, where the router allocates a different public port for every destination the device talks to. The port STUN reported is only valid for talking to the STUN server, so when the peer tries to use it, the packets are dropped. Strict corporate firewalls that block all inbound UDP cause the same outcome.

TURN, Traversal Using Relays around NAT, is the fallback. Both peers make an outbound connection to a TURN server, which is almost always allowed, and the TURN server sits in the middle and forwards every packet between them. It always works, because both sides only ever make outbound connections. The cost is that all your media now flows through that server, so you pay for the bandwidth in both directions and you add a network hop that increases latency.

So do I need a TURN server?

If you are building anything real, yes. Around 15 to 20 percent of connections in the wild need a relay. Without TURN those users see a call that rings and then fails, with no explanation. You can run your own using coturn, or use a hosted provider. What you cannot do is rely on free public TURN, because it does not exist for the simple reason that relaying media costs real money.

This diagram is part of Sazrika Foundation. Test your own setup with the ICE Candidate Inspector, measure your relay path with the Connection Quality Analyzer, or read the companion diagram on ICE candidate types.