{"id":1065,"date":"2026-05-22T09:46:08","date_gmt":"2026-05-22T02:46:08","guid":{"rendered":"https:\/\/liveapi.com\/blog\/turn-server\/"},"modified":"2026-05-22T09:46:25","modified_gmt":"2026-05-22T02:46:25","slug":"turn-server","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/turn-server\/","title":{"rendered":"What Is a TURN Server? How It Works, Setup, and Use Cases"},"content":{"rendered":"Reading Time: <\/span> 12<\/span> minutes<\/span><\/span>

Roughly 20% of WebRTC sessions can’t connect peer-to-peer because of strict NAT, corporate firewalls, or symmetric NAT mappings. When that happens, the call drops \u2014 unless you route the media through a TURN server.<\/p>\n

A TURN server is the safety net that keeps real-time video, audio, and data flowing when a direct connection between two browsers or apps is blocked. It relays packets through a public host so both peers can reach each other, even when neither one can reach the other directly.<\/p>\n

This guide explains what a TURN server is, how it differs from STUN, how the protocol works step-by-step, what ports it uses, how to set one up with Coturn, what it costs to run, and when your project actually needs one. By the end, you’ll know how to add TURN to a WebRTC<\/a> app \u2014 and when you can skip it entirely by using a different streaming protocol.<\/p>\n

What Is a TURN Server?<\/h2>\n

A TURN server is a network relay that forwards media traffic between two devices when they can’t establish a direct peer-to-peer connection. TURN stands for Traversal Using Relays around NAT<\/strong>, and the protocol is defined in RFC 8656<\/a>, published by the IETF in 2020 as an update to the earlier RFC 5766.<\/p>\n

In plain terms, a TURN server is an internet-reachable host that both peers can connect to. When peer A sends a packet to peer B, it goes to the TURN server first, which then forwards it to peer B. The relay sits in the middle of the media path for the entire session \u2014 every audio, video, and data packet passes through it.<\/p>\n

TURN is most commonly used inside the WebRTC stack, where the ICE framework decides whether a session can connect directly or needs a relay. If direct paths fail, ICE falls back to TURN.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nDetail<\/th>\n<\/tr>\n<\/thead>\n
Full name<\/td>\nTraversal Using Relays around NAT<\/td>\n<\/tr>\n
Standard<\/td>\nRFC 8656 (2020), updates RFC 5766 (2010)<\/td>\n<\/tr>\n
Default port<\/td>\n3478 (TCP\/UDP)<\/td>\n<\/tr>\n
TLS port<\/td>\n5349<\/td>\n<\/tr>\n
Transport<\/td>\nUDP, TCP, TLS, DTLS<\/td>\n<\/tr>\n
Authentication<\/td>\nLong-term credentials or REST API auth<\/td>\n<\/tr>\n
Primary use<\/td>\nRelay media when peer-to-peer fails<\/td>\n<\/tr>\n
Common implementation<\/td>\nCoturn (open source)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A TURN server is not<\/strong> the same as a media server or WebRTC server<\/a>. A media server actively processes streams (mixing, recording, transcoding). A TURN server just forwards bytes without inspecting them \u2014 the media stays end-to-end encrypted with DTLS-SRTP, and the relay can’t decode what’s flowing through.<\/p>\n

TURN vs STUN vs ICE: How They Fit Together<\/h2>\n

Most articles treat TURN as a standalone topic, but TURN only makes sense inside the broader ICE framework. Here’s how all three work together.<\/p>\n

STUN: Find Your Public IP<\/h3>\n

STUN (Session Traversal Utilities for NAT) is a lightweight protocol that lets a device find its own public IP address and port as seen from the internet. The client sends a request to a STUN server<\/a> and gets back the public address the server saw.<\/p>\n

STUN does not<\/strong> relay any traffic. It’s a one-shot lookup. Once both peers know each other’s public addresses, they try to connect directly.<\/p>\n

TURN: Relay When STUN Fails<\/h3>\n

TURN takes over when direct connection attempts fail. The most common reason is symmetric NAT \u2014 a NAT type that assigns a different external port for every destination, making the address discovered by STUN useless for the actual peer.<\/p>\n

TURN relays every packet for the entire session. It’s expensive in bandwidth, but it works when nothing else does.<\/p>\n

ICE: The Decision Maker<\/h3>\n

ICE (Interactive Connectivity Establishment) is the framework that tests every possible connection path and picks the best one. It gathers candidates from:<\/p>\n