TURN servers are relay servers that keep real-time audio and video flowing when direct peer-to-peer WebRTC connections fail behind strict NATs, firewalls, or corporate proxies. A TURN server receives media from one participant and forwards it to the other, trading a small latency cost for guaranteed connectivity. Most production WebRTC deployments report that roughly 10 to 20 percent of calls need TURN relaying, which is why every serious real-time application needs a TURN strategy. Managed platforms like VideoSDK handle TURN infrastructure for you, but self-hosted options such as coturn and turn-rs remain popular for teams that need full control.
When two browsers try to establish a direct WebRTC connection, they first attempt to discover each other's public network address and punch a path through whatever NAT or firewall sits between them. Most of the time this works. But a meaningful fraction of real-world networks, hotel Wi-Fi, corporate firewalls, carrier-grade NAT on mobile networks, simply refuse to let unsolicited UDP packets through. Without a fallback, those users see a black screen and dead silence.
That fallback is a TURN server. TURN, which stands for Traversal Using Relays around NAT, is the protocol of last resort in the WebRTC connectivity toolkit. In this guide you will learn how TURN servers work, how they fit into the ICE framework, which open-source implementations are worth running in 2026, and how to deploy, scale, secure, and maintain them in production.
What Are Turn Servers?
TURN servers are defined as network relays that receive a participant's media traffic and forward it to the other side when no direct connection path exists. The TURN protocol, standardized in RFC 5766, lets a client allocate a relayed address on the server, then send and receive audio, video, and data through that allocation. The server never inspects or transcodes the media; it just moves packets.
The contrast with STUN is where most confusion happens. A STUN server (Session Traversal Utilities for NAT, RFC 5389) is a lightweight discovery service. The client asks the STUN server what its public IP address and port are, gets an answer, and goes away. STUN involves no media forwarding at all. It is cheap, stateless, and handles the majority of connections.
TURN is the opposite: stateful, bandwidth-heavy, and expensive to run, but it works when nothing else does. A useful mental model is that STUN tells you where you live, while TURN forwards your mail when the postal system refuses to deliver to your door.
In practice, teams deploying real-time communication at scale consistently find that TURN bandwidth costs dominate their infrastructure bill, because every relayed packet crosses the server twice. That is the price of universal connectivity.
How Turn Servers Fit Into the ICE Process
ICE, which stands for Interactive Connectivity Establishment, is the framework WebRTC uses to find a working path between two participants. TURN servers are one of several candidate types ICE evaluates, and understanding the sequence explains exactly when TURN gets used.
The process runs in three phases. First, during gathering, each client collects every possible route to the outside world: its local network address, its public address discovered via STUN, and optionally a relayed address allocated on a TURN server. Second, during checking, the two clients exchange candidate lists through the signaling channel and test each pairing for bidirectional reachability. Third, during nomination, ICE selects the best working candidate, preferring local connections, then STUN-assisted paths, and only falling back to TURN relays when direct options fail.
This ordering matters for cost. Because ICE only uses TURN when nothing cheaper works, a well-tuned deployment relays only the traffic that genuinely needs it. If you see TURN relay usage above roughly 20 percent of sessions, that usually signals a network or configuration problem worth investigating rather than an unavoidable reality.
Key Protocols and RFCs Behind Turn Servers
The TURN ecosystem is built on a stack of IETF specifications, and knowing which RFC covers what saves real debugging time.
RFC 5766 defines the core TURN protocol itself, including allocations, permissions, and channel binding. RFC 5389 defines STUN, the messaging format TURN inherits and extends. RFC 6062 adds TCP relaying, essential for clients on networks that block UDP entirely. RFC 6156 extends TURN to IPv6, which matters as IPv4 address space runs out. RFC 7350 specifies DTLS for STUN, enabling encrypted transport over UDP. RFC 7635 defines OAuth-based authentication, a modern alternative to static shared secrets for larger deployments.
A production TURN server that supports all of these gives you flexibility across hostile networks: UDP first, TCP where UDP is blocked, TLS where even plain TCP is filtered, and IPv6 where available.
Choosing an Open-Source Turn Server
Picking a TURN server implementation in 2026 comes down to three credible open-source projects, each with distinct trade-offs in language, performance, and operational maturity.
Coturn is the veteran. Written in C, it has powered WebRTC infrastructure for over a decade, supports long-term credentials, the TURN REST API authentication pattern, relational database back-ends for multi-server credential sharing, and every RFC extension listed above. Its configuration surface is large, documentation is community-maintained, and it is the default choice for most production deployments. The trade-off is that C codebases demand careful security patching and conservative tuning.
Turn-rs is the modern challenger. Written in Rust, it emphasizes performance and low memory overhead, and its published benchmarks report handling on the order of 40 million channel messages per second on a single node. It supports the TURN REST API, database and Redis back-ends, and container-first deployment. It is an excellent fit for teams comfortable with a younger project and smaller community.
Turn-server (Node.js) is the lightweight option. Easiest to embed in JavaScript-centric stacks and simple to reason about, but it generally trails both alternatives in raw throughput and protocol coverage, making it better suited to development, testing, and small-scale production.
| Feature | coturn | turn-rs | turn-server (Node.js) |
|---|---|---|---|
| Language | C | Rust | JavaScript |
| Maturity | Very high, decade-plus | Younger, actively developed | Moderate |
| Throughput | High, battle-tested | Very high, ~40M channel msgs/sec claimed | Moderate |
| Auth options | Long-term creds, REST API, DB back-ends | REST API, DB/Redis back-ends | Basic, REST API |
| TCP and TLS relaying | Yes | Yes | Limited |
| Best for | General production, maximum compatibility | High-density, performance-critical clusters | Dev, testing, small deployments |
[LINKABLE ASSET — comparison table]
For most teams, coturn remains the safe default, while turn-rs is the choice when relay density and per-node throughput drive cost. If you would rather not run any of this yourself, VideoSDK's real-time communication platform handles NAT traversal and TURN fallback as part of its video calling infrastructure.
Deploying Turn Servers in Production
Deployment is where TURN projects go from a weekend experiment to a real service, and the decisions you make here determine your reliability ceiling.
Infrastructure Options for Turn Servers
Four deployment patterns dominate. Bare metal gives the best packet throughput and predictable latency, since there is no virtualization overhead on the media path. A cloud VM is the pragmatic middle ground and where most teams start. Docker containers simplify reproducibility and pair well with infrastructure-as-code. Kubernetes suits large fleets, though you must configure host networking for the UDP media ports, because the default service abstraction was designed for TCP and can break TURN's port-dependent permissions.
Configuration Essentials for Turn Servers
Three configuration areas deserve the most attention. First, listening ports: the standard TURN port is 3478 for UDP and TCP, with TLS typically on 5349, and you must open a large UDP port range for the relayed media itself, commonly thousands of ports. Second, transport: enable UDP, TCP, and TLS listeners together so clients on restrictive networks can always find a working path. Third, authentication: static long-term credentials are fine for small deployments, but the TURN REST API pattern, where your application server generates short-lived time-boxed credentials, is the production standard because it prevents credential sharing and enables per-user revocation.
Monitoring and Logging Best Practices
A TURN server you cannot observe is a TURN server you cannot trust. Track allocations created and destroyed, active relay bandwidth in and out, packets dropped due to authentication failures, and per-listener connection counts. Ship logs to a central aggregator, alert on abnormal allocation spikes (a classic sign of credential leakage or abuse), and graph relay usage as a percentage of total sessions so you can spot network regressions in your user base.
The architecture above, a load balancer in front of stateless TURN nodes sharing a credential database, is the standard scalable pattern. Because each allocation lives on exactly one node, clients reconnecting after a node failure simply re-allocate elsewhere, which makes horizontal scaling straightforward.
Performance and Scalability Considerations for Turn Servers
TURN performance is fundamentally a bandwidth and packet-processing problem, and the metrics that matter reflect that.
Monitor three things continuously: relay latency (the round-trip overhead your relay adds, which should stay in the low single-digit milliseconds on a healthy node), concurrent allocations (how many active relay sessions each node carries), and aggregate bandwidth (the total media throughput, which is usually your real capacity limit long before CPU is). A single modern node can typically sustain tens of thousands of concurrent allocations, but bandwidth caps will bite first on video-heavy traffic.
For tuning, pin each UDP listener to dedicated CPU cores to reduce cross-core packet handoffs, pre-allocate memory buffers at startup rather than growing them under load, and size your relay port range generously so allocations never wait on port exhaustion. Prefer UDP listeners for media whenever possible, since TCP relaying adds head-of-line blocking that degrades real-time quality.
For a concrete reference point, the turn-rs project's published benchmarks report handling roughly 40 million channel messages per second on a single node, demonstrating that with a modern implementation the bottleneck shifts decisively from CPU to network capacity. Even if you run coturn instead, the lesson holds: buy network bandwidth before you buy more servers.
Security Hardening for Turn Servers
An open, unauthenticated TURN server is an open relay, and open relays get found and abused within days, typically for traffic relaying or as anonymization hops. Security is not optional here.
Start with transport encryption: enable DTLS on UDP and TLS on TCP listeners, and manage certificates with automated renewal so expired certificates do not silently break connectivity. Use the TURN REST API credential pattern so every user receives short-lived, time-boxed credentials tied to their session, rather than a shared static secret that leaks once and compromises everything.
Layer access control on top: whitelist the IP ranges your application servers use for credential generation checks, rate-limit allocation creation per credential to blunt abuse, and monitor for allocation spikes from single sources. Rotate database credentials regularly and keep your TURN software current, because coturn in particular has had security-relevant fixes over its lifetime.
The two most common pitfalls are running with static credentials shared across all users, and exposing the admin interface on a public address. Both are one-line mistakes with expensive consequences.
Turn Server Maintenance and Updates
Maintaining TURN infrastructure is mostly about never dropping healthy allocations during change.
Use rolling upgrades: drain a node by stopping new allocations while existing ones finish, update it, verify, then repeat across the fleet. Because TURN allocations are short-lived by nature, this achieves zero-downtime upgrades without complex orchestration. Back up your credential database before every upgrade, and test restoration, since a corrupted credential store locks every user out at once.
Stay plugged into the community. Coturn's issue tracker and the turn-rs repository on GitHub are where deployment-breaking bugs surface first, and the broader WebRTC community, including VideoSDK's Discord and the videosdk.live tag on Stack Overflow, are good places to compare operational notes with other teams running relays at scale.
Definitions Glossary
TURN server: A relay server that receives and forwards a client's media traffic when direct peer-to-peer connectivity fails, standardized in RFC 5766 and used as the last-resort path in WebRTC connectivity.
STUN server: A lightweight discovery service defined in RFC 5389 that tells a client its public IP address and port so it can attempt direct connections; it forwards no media.
ICE (Interactive Connectivity Establishment): The WebRTC framework that gathers all candidate connection paths, tests them in pairs, and nominates the best working route, using TURN only when direct options fail.
TURN allocation: A reserved relay address and port on a TURN server that a client uses to send and receive media, living on exactly one server node for its lifetime.
TURN REST API authentication: A production credential pattern where an application server issues short-lived, time-boxed usernames and secrets, preventing shared-secret leakage and enabling per-user revocation.
Key Takeaways
- TURN servers are the guaranteed-connectivity fallback for WebRTC, relaying media when NATs and firewalls block every direct path, and typically carry 10 to 20 percent of sessions in production.
- STUN discovers addresses while TURN relays traffic; ICE orchestrates both, preferring cheaper direct paths and using TURN only as a last resort.
- Coturn is the battle-tested default, turn-rs offers exceptional per-node throughput, and the Node.js turn-server suits development and small deployments.
- Production deployments need UDP, TCP, and TLS listeners, short-lived REST API credentials, a wide relay port range, and monitoring of allocations, bandwidth, and relay usage percentage.
- If running TURN infrastructure yourself is not the best use of your engineering time, VideoSDK's real-time communication SDKs handle NAT traversal and relay fallback as part of the platform.
Conclusion
TURN servers are the unglamorous insurance policy behind every reliable real-time application. Choose an implementation that matches your scale, deploy it with proper authentication and transport encryption, monitor relay usage as a health signal, and maintain it with rolling, allocation-aware upgrades. If you would rather focus on your product than on relay infrastructure, try VideoSDK's video calling SDK, which handles NAT traversal end to end, or explore the code samples to see real-time communication running in minutes. What are you building with real-time communication? Drop a comment, I'd love to hear what kind of connectivity challenges your users face.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ