STUN and TURN appear beside each other in nearly every WebRTC configuration, which makes them sound like two versions of the same relay. Their workloads are very different. STUN is closer to asking for directions: it tells a browser how its connection appears from the public internet. TURN steps in when the route cannot be opened and forwards every packet for both endpoints.
That distinction explains why public STUN services are common while TURN usually comes with a quota, why a relayed connection can add latency, and why “P2P” does not honestly mean “no network service is ever involved.”
NAT creates the puzzle
A home router lets several devices share one public IP address. The laptop may be 192.168.1.20 and the phone 192.168.1.35; neither private address can be routed across the public internet. When a device sends traffic out, the router creates a temporary public address and port mapping and uses it to return replies to the right device.
The browser sees its local side but may not know the mapping the router created. The remote browser also does not know which sources that mapping will accept. WebRTC’s ICE process collects several kinds of candidate address and tests candidate pairs, rather than assuming one guessed address will work.
STUN holds up a mirror
The browser sends a request to a STUN server. The server writes the observed source IP and port into its response. That gives the browser a server-reflexive candidate: the mapping as seen from outside. Once both peers exchange candidates, they may be able to reach each other through those mappings.
After a direct connection is selected, chat, files, and media do not continue through STUN. The service handles small connectivity checks, not the session’s payload. That is why STUN is comparatively inexpensive. A robust application can still list more than one well-operated server and use sensible timeouts, so one failed hostname does not delay every connection.
TURN carries traffic when checks fail
An enterprise network may permit web traffic only through tightly controlled paths. A campus network may isolate clients. Carrier-grade NAT can use mappings that are difficult for an unrelated endpoint to reach. When direct candidate pairs fail, the browser requests a relay allocation from TURN. Each endpoint connects to the relay, which forwards packets between them.
This route exchanges efficiency for reachability. Packets travel farther, so latency often rises. The server handles traffic in both directions, making cost proportional to actual use. Location matters as well: two endpoints in Asia should not have to relay through Europe if a regional service is available.
| Question | STUN | TURN |
|---|---|---|
| Main job | Discover a public mapping | Relay when direct routes fail |
| Session payload | Does not carry it | Carries encrypted WebRTC packets |
| Resource use | Small requests | Scales with transferred bytes |
| Operational focus | Availability and low lookup delay | Capacity, region, authentication, quotas, abuse control |
How ICE chooses a path
Candidate types include host candidates from network interfaces, server-reflexive candidates learned through STUN, and relay candidates allocated by TURN. The browsers form candidate pairs and run connectivity checks. Priority usually favors a cheaper direct path, but a path has to work before preference matters.
A network change can invalidate the selected pair. Moving from Wi-Fi to cellular, enabling a VPN, or waking a laptop may require an ICE restart or a complete session rebuild. Applications should update their route indicator from the current selected pair, not preserve a “direct” badge merely because the previous connection was direct.
Is TURN still private?
WebRTC protects media and DataChannel transport. A TURN relay forwards protected packets rather than accepting a readable file as cloud storage would. The relay still sees metadata: network addresses, timing, duration, and byte counts. Operators should minimize retention and access, and should never add connection codes, filenames, or message bodies to relay analytics.
TURN is also a valuable public resource that attracts abuse. A fixed username and long-lived password can be copied and used to burn bandwidth. Safer deployments issue short-lived credentials, associate them with an allowed session or user, cap daily usage and concurrency, and alert on unusual rates.
Connection status should be for people
“Connected” says that a channel works; it does not say how. A useful status area distinguishes local direct, public direct, and TURN relay, and changes when the selected route changes. It can explain that relay may be slower and uses service capacity while the transport remains encrypted, without dumping an ICE debug log on the user.
After connecting in uCopy, the workspace shows the active route. If two devices on the same LAN always use TURN, check guest Wi-Fi isolation, VPN software, and router client isolation. A relay between two locked-down corporate networks, on the other hand, is a successful fallback rather than a defect.
The one-line version
STUN answers, “How do I appear from outside?” TURN says, “You still cannot reach each other, so send the packets through me.” One helps discover a shorter path; the other keeps difficult networks connected.
A serious WebRTC product configures both. It tries the efficient route first, moves promptly to a controlled relay when necessary, and reports the path honestly instead of making a brittle promise that every connection will be direct.