A TURN (Traversal Using Relays around NAT) server for WebRTC is a relay that forwards audio and video traffic between peers when direct peer-to-peer connections fail due to symmetric NAT or strict firewalls. STUN only helps peers discover their public addresses; TURN actively relays every media packet, which is why roughly 10 to 20 percent of real-world WebRTC calls depend on it. If you are building with a managed platform like VideoSDK, TURN infrastructure is handled for you; if you are self-hosting, this guide walks you through the full deployment path.
Imagine a telehealth consultation that connects perfectly in the office but fails the moment a patient joins from a corporate network behind a symmetric NAT. The call negotiates, the signaling succeeds, and then the media simply never flows. This is the single most common production failure in WebRTC, and it almost always traces back to one missing piece: a TURN server.
This article covers what a TURN server actually does, when you need one, how to choose between open-source coturn and managed cloud relays, how to deploy and secure it, and how to scale it for production traffic. By the end, you will know exactly which TURN architecture fits your application.
What Is a TURN Server for WebRTC?
A TURN server for WebRTC is defined as a network relay that receives media packets from one peer and forwards them to the other when a direct connection cannot be established. TURN works by allocating a relay address on a public IP for each participant, then forwarding all audio, video, and data-channel traffic through that address for the duration of the session.
The contrast with STUN matters. STUN (Session Traversal Utilities for NAT) is a lightweight discovery service: it tells a peer what its public IP and port look like from the outside. STUN handles the majority of connections, but it fails when a NAT rewrites ports differently for each destination, which is exactly what symmetric NATs do. TURN is the fallback of last resort in the ICE framework, and it is the only mechanism that guarantees connectivity, because the relay sits on a publicly reachable address that both peers can contact.
VideoSDK's real-time communication platform runs on WebRTC infrastructure that includes TURN fallback as part of its connectivity layer, so applications built on the VideoSDK video calling SDKs get reliable connections across hostile networks without operating relays themselves.
How TURN Completes the ICE Process
ICE (Interactive Connectivity Establishment) is the framework WebRTC uses to find a workable path between two peers. It gathers candidate addresses from three sources: local host addresses, server-reflexive addresses discovered via STUN, and relayed addresses allocated via TURN. ICE then tests candidates in pairs, starting with the cheapest and fastest options, and falls back to TURN only when every direct path fails. This tiered approach means most users never pay the latency cost of relaying, while users on restrictive networks still get connected.
Key TURN Terminology
Four terms dominate any TURN discussion. An allocation is a relay resource created on the TURN server for a client, identified by a relayed transport address. A permission is an IP-level filter the server installs so only traffic from the approved remote peer is relayed. A channel is a lightweight binding between a client and a remote peer that reduces per-packet overhead. The relay address is the public IP and port the server hands out, which the remote peer sends media to.
When Do You Need a TURN Server?
You need a TURN server when a meaningful fraction of your users sit behind network configurations that block direct peer-to-peer media. Industry measurements, including Google's published WebRTC usage data, consistently show that around 8 to 15 percent of sessions require TURN relaying, and that share rises sharply for enterprise, education, and mobile-carrier audiences.
The deciding factors are NAT behavior and firewall policy. Most consumer NATs (full-cone and restricted-cone) work with STUN alone. Symmetric NATs, common in corporate networks and some mobile carriers, break STUN because each outbound connection maps to a different external port. Firewalls that only allow outbound traffic to standard ports, or that block UDP entirely, also force TURN, often over TCP or TLS on port 443.
Symmetric NAT and Strict Firewalls
Symmetric NAT is the classic TURN trigger. When peer A contacts the STUN server and peer B through the same local port, the NAT assigns different external ports for each destination, so the address discovered via STUN is useless for peer B. Strict firewalls create a second failure class: some block all UDP, some block non-standard ports, and some inspect and drop traffic that looks like unknown protocols. In these cases, TURN over TLS on port 443 is frequently the only path that succeeds, because it is indistinguishable from ordinary HTTPS traffic.
High-Quality Video and Audio Requirements
Relaying adds a network hop, so relay placement directly affects media quality. A well-placed TURN server adds only a few milliseconds of latency, but a poorly placed one on another continent can add 150 milliseconds or more, which degrades call quality and interactivity. For high-bitrate video, the relay's bandwidth capacity matters as much as its location. This is why geo-distributed relays and network-adaptive streaming, both of which VideoSDK provides as part of its real-time communication infrastructure, are standard for production-grade applications.
Choosing a TURN Server for WebRTC
Choosing a TURN server for WebRTC comes down to a trade between operational control and operational burden. Open-source coturn gives you full control and zero licensing cost but makes you responsible for capacity, security patching, and global placement. Managed cloud relays give you auto-scaling and global points of presence but add per-gigabyte or per-minute costs.
Evaluate options against five criteria: protocol support (UDP, TCP, and TLS relaying), scalability model, geographic distribution of relay points, authentication method, and total cost at your expected relay traffic volume. Relay traffic is expensive by nature, because every relayed packet traverses the server twice, once in and once out, so bandwidth pricing deserves special attention.
Open-Source Option: coturn
Coturn is the de facto standard open-source TURN server, used in production by projects ranging from small startups to large platforms. Its strengths are maturity, broad protocol support (UDP, TCP, TLS, and DTLS), flexible authentication including both static and time-limited REST-based credentials, and an active community with extensive deployment documentation. Typical deployment patterns run coturn on a cloud VM with a public IP, fronted by TLS certificates, and paired with a signaling server that issues short-lived credentials. The trade-off is that you own everything: capacity planning, certificate rotation, security updates, and multi-region placement.
Managed Cloud Option
Managed TURN services, including Twilio's NAT traversal API and newer entrants like Turnix and Cloudflare's TURN offering, remove the operational burden entirely. You get auto-scaling relays, global geographic distribution, monitoring APIs, and usage-based billing. Managed services shine when your user base is international and you cannot justify operating relays in five regions yourself. The downside is cost predictability: heavy relay traffic on a per-gigabyte model can become expensive, and you depend on the provider's uptime for your hardest-to-connect users.
Decision Matrix
This comparison table is a [LINKABLE ASSET — comparison table] you can reuse when evaluating TURN options.
| Criterion | coturn (self-hosted) | Managed cloud TURN | VideoSDK platform |
|---|---|---|---|
| Cost model | VM + bandwidth, fixed | Per-GB or per-minute relay usage | Included in SDK plans |
| Scalability | Manual, horizontal | Automatic | Automatic |
| Geo-distribution | You deploy each region | Built-in global relays | Built-in global relays |
| Protocol support | UDP, TCP, TLS, DTLS | Varies by provider | UDP, TCP, TLS fallback |
| Operational burden | High | Low | None |
| Best for | Teams with DevOps capacity | International apps without infra teams | Apps embedding full WebRTC calling |
The most important row is operational burden: if your team has no dedicated infrastructure engineer, self-hosted coturn will quietly become a reliability liability, because TURN failures are invisible until your most restricted users cannot connect at all.
Deploying a TURN Server: Step-by-Step Guidance
Deploying a TURN server follows three phases: planning the architecture, configuring the server, and verifying that relaying actually works. The walkthrough below describes a coturn deployment, but the same phases apply to any TURN implementation.
Planning the Deployment Architecture
Start with capacity and placement. Size the virtual machine for your expected relayed bandwidth, remembering that relayed traffic is counted in both directions, so a 5 Mbps video stream consumes roughly 10 Mbps of server bandwidth. Place the relay in or near the region where your most restricted users live, because relay location sets your latency floor. Decide on ports: the standard TURN port range for UDP and TCP, plus TLS on port 443 for firewall-restricted networks. Plan for TLS certificates from a recognized authority, because self-signed certificates fail on some browser and mobile platforms.
Configuring coturn
Coturn's configuration centers on a handful of settings. The listening ports define where clients connect, and the relay IP range defines which public addresses the server hands out as relay addresses. The realm groups credentials under an authentication domain. The authentication method choice is critical: static long-term credentials are simple but risky if leaked, while time-limited REST-based credentials, generated by your signaling server with a shared secret, expire automatically and are the production standard. Firewall rules must allow both the listening ports and the entire relay port range, a detail that trips up many first deployments.
Verifying the Deployment
Before shipping, test relaying explicitly. Use a WebRTC ICE candidate test tool or a trickle-ICE test page to confirm that the server issues relay candidates and that allocations succeed over UDP, TCP, and TLS. Then place one test client behind a symmetric NAT or strict firewall (a corporate network or a mobile hotspot often works) and confirm media flows through the relay address.
The flow below shows how a client moves from address discovery to relayed media:
Securing Your TURN Server
An open TURN server is an attractive target, because relays can be abused to tunnel arbitrary traffic or amplify bandwidth costs. Security is not optional in production.
TLS/DTLS for Media Encryption
Enable TLS for TURN over TCP and DTLS for TURN over UDP so that both the control channel and relayed media are encrypted end to end. WebRTC media is already encrypted with SRTP between peers, but wrapping the TURN channel itself in TLS adds protection against interception of the relay leg and, critically, lets TURN traffic pass through deep-packet-inspection firewalls that would otherwise block it. Use certificates from a recognized authority and automate renewal.
Credential Management
Use short-lived, time-limited credentials generated by your signaling server rather than static usernames and passwords. In this model, the signaling server and the TURN server share a secret; the server issues credentials valid for a few minutes, and the TURN server verifies them without any database lookup. This prevents credential leakage from becoming a permanent open relay, and it lets you tie credentials to individual sessions for auditing. Never expose the shared secret to any client-side code.
Monitoring and Logging
Monitor allocation counts, relayed bandwidth, and authentication failure rates, and alert on sudden spikes, which are the classic signature of relay abuse.
Scaling TURN for Production
Scaling TURN for production means distributing relays geographically and sizing each one for peak relay traffic, because TURN usage is spiky: it concentrates exactly when networks are worst, such as during regional outages or peak evening hours.
Horizontal scaling is the standard pattern. Run multiple coturn instances behind a load balancer, each with its own public IP and relay port range, and distribute clients across instances via the signaling server rather than DNS round-robin, since TURN allocations are stateful and must stay pinned to one server for the session's duration. Health checks should verify not just that the process is alive but that allocations actually succeed.
Geo-Routing with Multiple Relays
With relays in multiple regions, the goal is sending each user to the nearest relay to minimize added latency. Two approaches dominate. A DNS-based approach uses geographic DNS to resolve the nearest relay automatically, which is simple but coarse. An API-driven approach has the signaling server measure or estimate client location and hand back a specific relay address, which is more precise and lets you factor in real-time relay load. Most large deployments converge on the API-driven model.
Autoscaling Strategies
For elastic capacity, run coturn in containers under an orchestration platform that scales instances based on relayed bandwidth and allocation count rather than CPU, because TURN is bandwidth-bound first. Set scale-out thresholds conservatively, since a relay that fills its port range mid-session degrades new allocations. Combine autoscaling with pre-warmed capacity in your primary regions, because the spiky nature of TURN demand means reactive scaling alone often lags behind real traffic.
A production multi-region topology looks like this:
Common Pitfalls and Troubleshooting
Most TURN failures in production fall into three buckets, and all three are diagnosable with a systematic approach.
Misconfigured Ports or Firewalls
The most frequent issue is a firewall that allows the TURN listening port but blocks the relay port range, so allocations succeed but media never flows. Verify that every port in the relay range is open in both directions on the server's security groups and host firewall, and confirm the relay IP configuration matches the machine's actual public address.
Authentication Failures
Authentication failures usually stem from credential expiry or a mismatch between the signaling server's shared secret and the TURN server's configured secret. With time-limited credentials, check that server clocks are synchronized, because skewed clocks make valid credentials appear expired. Confirm the username format matches what your credential generator produces.
Unexpected Latency
If relayed calls work but feel sluggish, the relay is likely in the wrong region or overloaded. Compare the relay's region to your users' locations, check the server's bandwidth saturation, and confirm the client is actually using the nearest relay rather than a default one. Latency above roughly 30 milliseconds of added relay overhead indicates a placement or capacity problem.
Best Practices Checklist
A production-ready TURN server should satisfy every item on this list:
- Deploy relays in or near every region with significant user traffic
- Support UDP, TCP, and TLS on port 443 for maximum firewall compatibility
- Use time-limited REST-based credentials, never static shared passwords
- Keep the credential secret exclusively on server-side infrastructure
- Encrypt the TURN channel with TLS and DTLS alongside SRTP media encryption
- Open the full relay port range in firewalls, not just the listening port
- Monitor allocation counts, relayed bandwidth, and auth failure rates with alerting
- Pin each session's allocation to a single relay for its duration
- Test connectivity from a symmetric NAT and a strict corporate firewall before launch
- Re-evaluate relay capacity against peak concurrent relayed sessions quarterly
Definitions Glossary
TURN server: A relay server that forwards WebRTC media between peers when direct peer-to-peer connections fail, allocating public relay addresses for each participant.
STUN server: A lightweight discovery service that tells a WebRTC peer its public IP and port as seen from the internet, enabling direct connections in most NAT scenarios.
ICE (Interactive Connectivity Establishment): The WebRTC framework that gathers host, STUN, and TURN candidates and tests them in pairs to find the best working connection path.
Allocation: A relay resource created on a TURN server for a client, identified by a relayed transport address that the remote peer sends media to.
Symmetric NAT: A NAT configuration that assigns a different external port for each destination, breaking STUN discovery and forcing WebRTC to fall back to TURN relaying.
Key Takeaways
- A TURN server is the only mechanism that guarantees WebRTC connectivity, relaying media when symmetric NATs and strict firewalls block direct peer-to-peer paths.
- Roughly 8 to 15 percent of real-world WebRTC sessions need TURN relaying, and that share rises for enterprise, education, and mobile-carrier users.
- Coturn is the proven open-source choice for teams with DevOps capacity, while managed cloud relays suit international apps without infrastructure teams.
- Production TURN deployments need time-limited credentials, TLS and DTLS encryption, geo-distributed relays, and monitoring for relay abuse.
- Platforms like VideoSDK handle TURN fallback, global relays, and network-adaptive streaming as part of the video and audio calling SDKs, removing the entire operational burden.
Conclusion
A reliable TURN server for WebRTC is the difference between an application that works for most users and one that works for all of them. The hardest-to-connect users, those behind symmetric NATs and corporate firewalls, are often exactly the users you cannot afford to lose. Choose the deployment model that matches your team's operational capacity, secure it with time-limited credentials and TLS, place relays near your users, and test from restricted networks before launch. If you would rather focus on your product than on relay infrastructure, VideoSDK's real-time communication platform includes TURN fallback and global relays out of the box, and you can start free at app.videosdk.live. What are you building with WebRTC? Drop a comment, I'd love to hear what kind of connectivity challenges your users are hitting.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ