What Is a TURN Server? How It Works, Setup, and Use Cases

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 — unless you route the media through a TURN server.

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.

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 app — and when you can skip it entirely by using a different streaming protocol.

What Is a TURN Server?

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, and the protocol is defined in RFC 8656, published by the IETF in 2020 as an update to the earlier RFC 5766.

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 — every audio, video, and data packet passes through it.

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.

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

TURN vs STUN vs ICE: How They Fit Together

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.

STUN: Find Your Public IP

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 and gets back the public address the server saw.

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

TURN: Relay When STUN Fails

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

TURN relays every packet for the entire session. It’s expensive in bandwidth, but it works when nothing else does.

ICE: The Decision Maker

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

• Host (local IP address)
• Server-reflexive (public IP via STUN)
• Relayed (TURN server allocation)

ICE pairs candidates from both peers, runs connectivity checks, and picks the working pair with the lowest priority cost. TURN is always the last resort because it adds latency and bandwidth cost.

For a deeper look at how NAT blocks direct connections, see our guide on NAT traversal.

How Does a TURN Server Work?

The TURN protocol uses a four-step allocation and relay process. Here’s what happens when a WebRTC client connects through TURN.

Step 1: Allocate a Relay Address

The client sends an Allocate request to the TURN server, authenticated with a username and credential. The server reserves a public IP and port — called the relayed transport address — and returns it to the client.

Client → TURN: Allocate Request (auth, request UDP relay)
TURN → Client: Allocate Success (relay address: 198.51.100.10:49321)

This relay address is what the client will share with its peer as an ICE candidate.

Step 2: Create Permissions

By default, the TURN server drops any packet from an unknown peer. The client sends a CreatePermission request listing the IP addresses of peers it expects to communicate with. The server adds those IPs to its allow list.

Permissions expire after 5 minutes unless refreshed, which protects the relay from being abused as an open proxy.

Step 3: Send and Receive Data

Once permissions are set, the client and peer exchange media in one of two ways:

• Send/Data Indications: Each packet carries a 36-byte TURN header identifying the peer. Simple but adds bandwidth overhead.
• Channels: The client binds a 16-bit channel number to a peer with ChannelBind, then uses a 4-byte channel header on later packets. Much more efficient for high-bandwidth media like video.

Client → TURN: Send Indication (peer: 203.0.113.5, payload: media)
TURN → Peer: UDP packet from relay address
Peer  → TURN: UDP packet to relay address
TURN → Client: Data Indication (from peer: 203.0.113.5, payload)

Step 4: Refresh and Release

Allocations have a default lifetime of 10 minutes. The client sends Refresh requests to extend the allocation as long as the session is active. When the call ends, the client sends a Refresh with lifetime 0 to release the relay address.

This whole cycle is invisible to the application code. A WebRTC developer just passes the TURN server URL into RTCPeerConnection configuration, and the browser handles the protocol exchange automatically.

TURN Server Ports and Transport Protocols

TURN can run over multiple transports, which matters when your peers sit behind restrictive corporate firewalls.

Production TURN deployments often listen on port 443 with TLS because corporate networks frequently block everything except HTTPS. Running TURN on 443 makes the relay traffic indistinguishable from a normal web connection, which dramatically improves connection success rates.

For real-time media, UDP is always preferred. TCP retransmissions add latency and can cause head-of-line blocking that ruins audio and video quality. TLS-over-TCP is the connection of last resort.

Why TURN Servers Matter for WebRTC

Roughly 80% of WebRTC connections succeed without TURN. The remaining 20% — across enterprise networks, mobile carriers, and certain home routers — fail without a relay. Here’s why.

Symmetric NAT

Most home routers use cone NAT, which keeps the same external port mapping for outbound traffic from a given internal port. STUN works because the public address it discovers is the same one a peer can use to send packets back.

Enterprise networks and many mobile carriers use symmetric NAT, which allocates a new external port for every destination. The address STUN reports is only valid for the STUN server — it won’t work for the peer. TURN is required.

Restrictive Firewalls

Corporate firewalls often block all UDP traffic outbound, or only allow connections on ports 80 and 443. WebRTC tries UDP first because it has lower latency, but when UDP is blocked, TURN over TLS on 443 is the only path through.

Mobile Networks

Cellular carriers use carrier-grade NAT (CGN) that often behaves symmetrically. A WebRTC app that works fine on Wi-Fi can drop the moment a user switches to LTE without TURN configured.

Privacy

Some users disable WebRTC IP leaking in their browsers, which forces all candidates through TURN. The relay hides the user’s real IP from the remote peer.

Without TURN, all of these users see broken calls. With TURN configured, the connection silently falls back to the relay and the user never notices.

TURN Server Setup with Coturn

Coturn is the de facto open-source TURN server. It’s actively maintained on GitHub, runs on Linux, supports both STUN and TURN, and is what most production deployments are built on.

Here’s a minimal setup on Ubuntu.

Install Coturn

sudo apt update
sudo apt install coturn

Enable the service at boot by editing /etc/default/coturn:

TURNSERVER_ENABLED=1

Configure the Server

Edit /etc/turnserver.conf with the basics:

listening-port=3478
tls-listening-port=5349
listening-ip=0.0.0.0
external-ip=YOUR_PUBLIC_IP
realm=turn.yourdomain.com
server-name=turn.yourdomain.com
lt-cred-mech
user=webrtcuser:webrtcpassword
min-port=49152
max-port=65535
cert=/etc/letsencrypt/live/turn.yourdomain.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.yourdomain.com/privkey.pem
log-file=/var/log/turnserver.log
fingerprint
no-multicast-peers
no-cli

Key fields:

• external-ip: The public IP of the server (required for cloud VMs behind NAT).
• realm: Authentication domain — typically your TURN domain.
• lt-cred-mech: Enables long-term credential authentication (required for production).
• user: Static user credentials. For real apps, replace this with use-auth-secret and time-limited REST API credentials.
• min-port / max-port: Range of UDP ports for relay allocations. Open these in your firewall.

Open the Firewall

On the host and any cloud security group, allow:

• TCP/UDP 3478
• TCP/UDP 5349
• UDP 49152–65535

Restart Coturn:

sudo systemctl restart coturn

Test Your TURN Server

Use the Trickle ICE tool from the WebRTC samples. Add your TURN URL, username, and credential, then click Gather candidates. A successful TURN setup returns candidates of type relay. If you only see host and srflx, the relay isn’t working — usually a firewall or external-ip misconfiguration.

Use TURN in a WebRTC Client

In your browser code, pass the TURN server to RTCPeerConnection:

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.l.google.com:19302' },
    {
      urls: [
        'turn:turn.yourdomain.com:3478?transport=udp',
        'turn:turn.yourdomain.com:3478?transport=tcp',
        'turns:turn.yourdomain.com:5349?transport=tcp'
      ],
      username: 'webrtcuser',
      credential: 'webrtcpassword'
    }
  ]
});

For production, never embed static credentials in client code. Generate short-lived credentials on a backend using the REST API auth pattern (HMAC-signed timestamp + username), or use a managed TURN provider.

For mobile, the same configuration applies — see our walkthrough on React Native WebRTC for client implementation details.

Managed TURN vs Self-Hosted: Which to Choose

You have three paths to TURN in production: self-host with Coturn, use a managed TURN service, or build TURN into a larger video platform. Each has trade-offs.

Self-Hosted Coturn

Cheapest at low scale — a $20/month VPS handles thousands of concurrent low-bandwidth sessions. But you own everything: TLS certificate renewal, DDoS protection, kernel tuning, multi-region failover, credential rotation, and abuse monitoring. Misconfigured Coturn servers regularly end up as open relays used by attackers, which gets the IP blocklisted.

Managed TURN Providers

Twilio, Cloudflare, Xirsys, and Metered all offer pay-as-you-go TURN. The signup-to-production path is under an hour. You get global anycast endpoints, automatic credential rotation, and abuse protection out of the box. The downside is per-GB pricing — Twilio charges $0.40–$0.80/GB depending on region, while Cloudflare prices at $0.05/GB with 1 TB free monthly. A single 720p video call uses roughly 1–2 GB per hour relayed.

For most teams, managed is the right call until traffic grows large enough that the unit economics favor self-hosting.

Build TURN Into a Platform

If you’re building a video conferencing API product or any WebRTC-heavy app, you’ll likely end up running an SFU (Selective Forwarding Unit) anyway. SFUs handle the media forwarding for multi-party calls and partly absorb the TURN function for routes through the SFU. You still need TURN for peer-to-SFU traversal in restricted networks.

When You Need TURN — And When You Don’t

Not every video app needs TURN. The decision depends on the streaming protocol and topology you’re using.

You Need TURN If

• You’re building a peer-to-peer WebRTC application: video calls, voice chat, screen sharing, file transfer.
• You expect users on corporate networks, mobile carriers, or restrictive ISPs.
• You need sub-500ms latency and can’t tolerate the buffering of segmented protocols.
• Your app supports two-way interactive video like telehealth, live tutoring, or interactive live shopping.

You Probably Don’t Need TURN If

• You’re doing one-way broadcast streaming with RTMP or SRT ingest and HLS playback. The encoder pushes to a server, and viewers pull from a CDN — no peer-to-peer involved.
• You’re streaming on-demand video from a CDN to an HTML5 player.
• Your latency budget is 3 seconds or higher (most live streaming use cases).
• Your media flows through a central server for transcoding, recording, or distribution.

For broadcast-style live streaming — where one publisher reaches many viewers — TURN is unnecessary. The encoder pushes RTMP or SRT to an ingest endpoint, the server transcodes to HLS, and a CDN for video streaming delivers it globally. No NAT traversal needed because viewers initiate outbound HTTP requests that any firewall allows.

If you’re weighing WebRTC vs broadcast protocols for your use case, our WebRTC vs HLS and WebRTC vs RTMP comparisons cover the trade-offs in detail.

TURN Server Security Best Practices

A poorly configured TURN server is a security liability. Open relays get abused for credential stuffing, DDoS reflection, and traffic laundering. Here’s how to lock yours down.

Use Time-Limited Credentials

Never ship static TURN credentials in client code. Generate short-lived credentials on a backend using the TURN REST API auth scheme — an HMAC-SHA1 of a timestamp signed with a shared secret. Credentials should expire within minutes.

Enable TLS

Always enable port 5349 with a valid TLS certificate (Let’s Encrypt is free and well-supported). TLS protects credentials in transit and lets TURN punch through firewalls that only allow HTTPS.

Restrict Permissions

Coturn’s no-multicast-peers and denied-peer-ip settings prevent the relay from forwarding to private RFC 1918 ranges, multicast addresses, or known abuse targets. Block 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, and 127.0.0.0/8 to prevent the relay from being used as a portal into private networks.

Rate Limit Allocations

Use user-quota and total-quota in Coturn to cap per-user and per-server allocation rates. This blunts the impact of credential theft.

Monitor Traffic

Log bandwidth per user and watch for anomalies. A normal video call uses 1–3 Mbps. A relay session pushing 100 Mbps is almost certainly being abused.

Keep Coturn Patched

Coturn has had CVEs over the years. Subscribe to the GitHub repo notifications and patch promptly.

TURN Server Performance Considerations

TURN adds latency and bandwidth cost. How much depends on geography and configuration.

Latency: A TURN relay adds one extra network hop. If the server is geographically close to both peers, the added latency is 20–50ms. If it’s on another continent, it can add 200ms or more. For real-time communication, this matters — see our guide on video latency for a deeper breakdown.

Bandwidth doubling: Every byte sent through TURN is received by the server and re-transmitted. A 2 Mbps video call relayed through TURN costs the server 4 Mbps total (2 in + 2 out). Multiply by your concurrent session count to size capacity.

Geographic distribution: A single TURN server in one region causes high latency for global users. Production deployments use multiple TURN servers worldwide and pick the closest one for each session via DNS-based geolocation or anycast.

CPU: Coturn is lightweight and bottlenecks on bandwidth, not CPU. A modest 4-core VPS can max out a 1 Gbps NIC handling hundreds of concurrent sessions.

For ultra-low-latency video streaming, TURN’s added hop is acceptable for interactive use cases but unnecessary for one-way broadcast where alternatives like Low-Latency HLS (LL-HLS) or CMAF reach sub-3-second latency without relays.

How LiveAPI Fits Into the Picture

LiveAPI takes a different architectural approach from WebRTC. Instead of peer-to-peer media, it uses centralized ingest with CDN-distributed playback — which means no TURN servers, no STUN setup, no ICE candidate gathering.

You publish a stream from any RTMP, SRT, or RTSP encoder to LiveAPI’s ingest endpoint. The platform transcodes it, generates an HLS manifest, and serves it through Akamai, Cloudflare, and Fastly CDNs to viewers anywhere. Viewers pull the stream over standard HTTPS, which works on every network without firewall traversal concerns.

This trade-off matters for the right use cases:

• Broadcast use cases (live events, sports, OTT, church services, conferences) — LiveAPI handles ingest, transcoding, adaptive bitrate streaming, and CDN delivery without TURN. Latency is typically 3–10 seconds depending on configuration.
• Two-way interactive use cases (video calling, screen sharing between two people) — WebRTC with TURN is the right fit. LiveAPI isn’t designed for symmetric peer-to-peer.
• Live streaming SDK integration — for mobile and web apps that broadcast to many viewers, our live streaming SDK handles the encoder side, and the playback side works through any HLS player.

The pay-as-you-grow pricing model is based on streaming minutes, not relay bandwidth, so the cost structure is predictable as you scale.

Is a TURN Server Right for Your Project? Quick Checklist

Answer these questions to decide.

1. Do you need sub-second latency between two specific users? If yes → WebRTC + TURN. If no, you have alternatives.
2. Is the use case symmetric (both sides send video)? If yes → WebRTC + TURN. If no → broadcast protocol probably fits better.
3. Will your users sit behind corporate firewalls or mobile carriers? If yes → TURN is mandatory for WebRTC.
4. Are you handling more than 100 concurrent viewers per stream? If yes → SFU or broadcast architecture, not pure peer-to-peer.
5. Do you have the ops capacity to run Coturn securely? If no → use a managed TURN provider.

If you answered “no” to most of these, you’re probably looking for a broadcast platform with RTMP/SRT ingest and HLS output — not a WebRTC stack with TURN.

TURN Server FAQ

What does a TURN server do?

A TURN server relays media packets between two devices that can’t connect directly because of NAT or firewall restrictions. It receives packets from one peer and forwards them to the other, staying in the media path for the entire session.

Do I really need a TURN server?

If you’re building a WebRTC application that needs to work for users on corporate networks, mobile carriers, or strict firewalls, yes. Roughly 20% of WebRTC connections fail without TURN. For one-way broadcast streaming with protocols like RTMP, SRT, or HLS, you don’t need TURN at all.

What port does a TURN server use?

The default port is 3478 for both TCP and UDP. Port 5349 is used for TLS-encrypted TURN. Production deployments often also listen on port 443 to bypass firewalls that block everything except HTTPS.

What is the difference between a STUN and TURN server?

STUN only helps a device find its public IP address — it doesn’t relay any traffic. Once found, peers connect directly. TURN actively relays every packet between peers when direct connection isn’t possible. STUN is free to run and lightweight; TURN is bandwidth-intensive and expensive.

Is there a free TURN server?

Public free TURN servers exist (like Open Relay Project), but they’re unreliable for production use because they’re shared, rate-limited, and have no SLA. You can run your own Coturn instance on a cheap VPS for free, or use a managed provider’s free tier — Cloudflare offers 1 TB of relayed bandwidth per month free.

What is Coturn?

Coturn is the most widely used open-source TURN and STUN server implementation. It runs on Linux, supports all current TURN features including authentication and TLS, and is what most managed TURN services run under the hood.

Does TURN use TCP or UDP?

Both. UDP is preferred for media because it has lower latency. TCP and TLS-over-TCP are fallbacks for networks that block UDP. The TURN client and server negotiate which transport to use, usually via the URL scheme (turn: for plain, turns: for TLS) and a transport= parameter.

How much does it cost to run a TURN server?

Self-hosted on a $20/month VPS handles low-to-moderate traffic. Managed services charge per GB relayed — Cloudflare at $0.05/GB (1 TB free), Twilio at $0.40–$0.80/GB, Metered at $0.40/GB. A 1-hour 720p video call uses roughly 1–2 GB.

Can a TURN server see my video?

No. WebRTC media is encrypted end-to-end with DTLS-SRTP. The TURN server forwards encrypted bytes without being able to decode them. It only sees source and destination addresses, packet sizes, and timing.

What is the latency added by a TURN server?

A TURN relay adds one network hop. If the server is geographically close (same region as both peers), the added latency is typically 20–50ms. Cross-continent relays can add 200ms or more, which is why production deployments use multiple geographic regions.

Build Live Video Without Managing TURN Servers

A TURN server is essential infrastructure for WebRTC apps, but it’s also one more thing to deploy, secure, and scale. If your use case is broadcast streaming rather than peer-to-peer calling, you can skip TURN entirely by using RTMP/SRT ingest and HLS playback.

LiveAPI gives you that architecture out of the box — RTMP, SRT, and RTSP ingest, adaptive bitrate streaming, multi-CDN delivery, and an embeddable player — without TURN servers, signaling infrastructure, or NAT traversal to manage. Try LiveAPI free and ship a live streaming feature in days instead of months.