A TURN server is a relay on the public internet that forwards media between two devices when they cannot reach each other directly. TURN stands for Traversal Using Relays around NAT. It is a standard NAT traversal method, defined in IETF RFC 5766 and later replaced by RFC 8656.
In WebRTC, TURN is the fallback that keeps a call connected when direct peer-to-peer media is blocked by a NAT or firewall. It is coordinated by ICE alongside STUN. If you ship WebRTC to real users, you need TURN. Make sure you have a very good reason if you decide to skip it.
A few important things about TURN:
- Used when a NAT or firewall blocks the direct P2P path
- Adds latency, because media takes a detour through the relay
- Costs bandwidth, because all the media flows through the server
STUN, TURN, ICE - getting WebRTC sessions to connect can be easier than you think. Check out my free mini course on the topic:
When do you need TURN?
Most connections do not need a relay. A direct path, or a path opened with the help of STUN, handles the easy majority. TURN is what saves the rest. You cannot know in advance which users will fall into that group, so a production deployment always has TURN configured.
Three situations force media onto a relay:
- Symmetric NAT. Some NATs assign a different public port for every destination. The public address STUN discovers is then useless to the peer, because return traffic arrives from a different port than the one the NAT expects. STUN cannot solve this. TURN can
- Mobile networks. Carrier-grade NAT on mobile operators behaves like a symmetric NAT and often blocks inbound UDP. Users on cellular data are a common reason connections end up relayed
- Corporate firewalls. Locked-down enterprise networks block UDP entirely and allow outbound traffic only on a few ports. Here TURN over TLS on port 443 is often the only path that gets through, because that port looks like ordinary HTTPS traffic
When can you skip TURN?
There are two main scenarios where TURN can be ignored and left unsupported:
- Policy decision. In some of the cloud contact centers and cloud gaming services there is a conscious decision to NOT use TURN. The assumption is that the user is either controlled (contact center agents can be directed to have better networks that don't rely on TURN relays) or expected (cloud gaming may need the lowest possible latency which means TURN is not desired)
- Architectural reasoning. Services where WebRTC clients always connect via media servers that have public IP addresses can mostly skip the use of TURN and use ICE-TCP instead. This is what Google Meet, Jitsi Meet and OpenAI's Realtime Voice API do
How a TURN server works
A WebRTC client asks the TURN server to allocate a relay address on the public internet. The client shares that relay address with its peer as an ICE relay candidate. Both peers then send their media to the relay, and the server forwards each stream to the other side. All the media flows through the server, which is exactly why TURN costs what it costs.
Because it relays everything, running TURN is a rather expensive endeavor, costing bandwidth and CPU at a data center. This is why public TURN servers are not usually available, and every service either installs and maintains its own or pays for a hosted service.
TURN can use different transport protocols to relay its media:
- TURN/UDP - relaying media over UDP. This is the preferred method for handling real time media
- TURN/TCP - relaying media over TCP. A fallback to UDP when UDP is not reachable from the device to the TURN server
- TURN/TLS - relaying media over TLS. The "worst case" option for when nothing else can be used, usually on port 443
Each of these transports is independent of the others. ICE decides which one can be used for a given connection.
STUN vs TURN: what is the difference
WebRTC is designed for peer-to-peer communication directly between browsers. A NAT or a firewall gets in the way of that, so WebRTC needs a way to work around them.
When a user is behind a NAT, their device holds a private IP address, like 10.0.0.1, that is not reachable from the public internet. A STUN server helps here: the device queries it to learn the public IP address and port the NAT assigned. Once the public address is known, the peer can try to connect directly, and the request also punches a "pinhole" in the NAT for return traffic.
STUN works well in many cases, but it falls short against symmetric NAT, where the pinhole only accepts traffic from the exact destination it was opened for. That is where TURN comes in. A TURN server relays all the traffic between the peers, so a connection succeeds even when no direct path exists. The trade-off is increased bandwidth usage, higher server-side CPU load, and added latency.
So the short version: STUN only discovers your public address, TURN relays the actual media.
Public STUN vs cloud TURN vs self-hosted TURN
There are three points on the NAT traversal spectrum, and picking between them is a cost, latency, and control decision.
| Public STUN | Cloud (managed) TURN | Self-hosted TURN | |
|---|---|---|---|
| What you get | Public IP discovery only, no relay | Relay as a service, global footprint | A relay you run on your own servers |
| Cost | Free or near free | Pay per GB of relayed traffic, expensive at scale | Server and bandwidth cost, cheaper per GB at volume |
| Latency | No media path, so nothing added | Low when the provider has an edge near the user | Depends on how close your servers sit to users |
| Control | None, and no SLA | Limited, you depend on the vendor | Full control over config, security, and placement |
| Ops effort | None | None, the vendor runs it | High: deploy, secure, and scale a global fleet |
| Best fit | The easy majority of connections, but it cannot relay | Small and medium deployments, a fast start | High volume or latency-sensitive deployments |
Public STUN is not really an alternative to TURN. It handles the connections that were going to succeed anyway and does nothing for the ones that need a relay. The real choice is cloud versus self-hosted TURN, and it usually comes down to volume: managed services win on peace of mind and low ops effort, self-hosting wins on per-GB bandwidth cost once traffic is high enough to justify the DevOps work.
One more thing to note here is that TURN servers second as STUN servers. This means that if you pay or host and maintain your own TURN servers, there is no real reason or need for you to use public STUN servers at all.
The cost and latency trade-off
Running STUN only is cheap and adds no latency, but it drops every user who needs a relay. That is not a real option in production. The moment you add TURN, you take on two costs.
- Bandwidth. Every relayed session pushes all of its media through your server, in and out. At scale this is the dominant line item in a WebRTC infrastructure bill
- Latency. Media now takes a detour through the relay instead of the shortest path. A relay close to the users adds little. A relay on the wrong continent adds a lot
You do not pay these costs on every connection, only on the ones that would otherwise fail. You can expect anything between 0 and 50 percent sessions to go via relay, depending on your user base and network conditions, which is why it is worth measuring rather than guessing. The goal is not to avoid TURN. It is to configure ICE so TURN is used only when a direct path genuinely is not available.
Choosing between STUN and TURN: the ICE protocol
The ICE (Interactive Connectivity Establishment) protocol makes the actual choice at connection time. ICE gathers candidates of different types (host, server-reflexive from STUN, and relay from TURN), runs connectivity checks across them, and picks the best path that works. A direct path is preferred, and the relay is used only when the checks show nothing else connects.
Frequently asked questions
A TURN server is a relay that forwards WebRTC media between two devices when they cannot connect directly. When a NAT or firewall blocks peer-to-peer traffic, WebRTC routes the audio, video, and data through the TURN server instead. It is the fallback that keeps a call connected when a direct path is unavailable.
No. Most WebRTC connections succeed on a direct or STUN-assisted path and never use TURN. But you cannot predict which users sit behind a symmetric NAT, a corporate firewall, or a mobile network that blocks UDP. The relayed share varies by audience, so any production deployment still needs TURN configured.
STUN only discovers a device's public IP address and port so two peers can attempt a direct connection. TURN goes further and relays the actual media when that direct connection fails. STUN carries no media and is cheap to run. TURN carries all the media, which makes it expensive in bandwidth and adds latency.
A WebRTC client asks the TURN server to allocate a relay address on the public internet. The client shares that relay address with its peer through ICE. Both peers then send their media to the relay, and the TURN server forwards each stream to the other side. All the media flows through the server.
More on TURN
Troubleshooting TURN and connectivity issues in WebRTC? rtcStats has great visualization and analysis covering this in detail.
