TURN Servers Explained: How Video Gets Through Restrictive Networks

Every so often a screen share, a video call or a presenter's control connection just refuses to connect on one particular network, even though it works everywhere else. Nine times out of ten, the culprit is a blocked direct connection, and the fix is a TURN server. TURN servers explained simply: they are the relay that keeps a peer-to-peer connection working when the network will not allow two devices to talk to each other directly.

If you have ever wondered why your presentation tool needs a "relay" or "TURN" setting at all, this is the answer, and it is worth understanding whether you are troubleshooting a dropped connection tonight or evaluating a tool's networking claims before you buy it.

Why direct connections sometimes fail

WebRTC, the technology behind most peer-to-peer video and control tools, prefers to connect two devices directly to each other. That is efficient and fast: no third party sits between the presenter's phone and the host computer running the slides. The problem is that a genuinely direct connection depends on both devices being reachable on the open internet, and most devices are not.

Home routers use NAT (Network Address Translation) to share one public IP address across many devices, which already complicates direct connections. Corporate and venue networks go further, often blocking UDP traffic outright or restricting outbound connections to a short allow-list of ports. STUN, a lighter-weight protocol, can solve simple NAT cases by helping two devices discover their public address. It cannot solve everything.

What TURN actually does

TURN, Traversal Using Relays around NAT, is the fallback for exactly that situation. Defined in IETF RFC 8656, it works by giving both devices a relay address to send traffic to instead of each other. The relay simply forwards packets between the two sides.

Three things matter about how it does that:

STUN, TURN and TURNS: what is the difference

These three acronyms get used interchangeably and should not be:

That last row matters more than it looks. A network that blocks everything except standard HTTPS traffic on port 443 will still let a TURNS connection through, because to that network it looks identical to ordinary web browsing. This is exactly the mechanism behind why corporate firewalls block presentation tools, and why the good ones still get through anyway.

How Cliqer uses TURN

Cliqer's desktop and web clients attempt a direct WebRTC connection first, secured with DTLS and SRTP. If the network blocks that, the connection falls back automatically to an encrypted TURN relay, including a TURNS path over port 443 for networks that only allow standard web traffic outbound. TURN credentials are minted per request with a 24-hour time-to-live and rotate automatically, rather than being hard-coded values a client reuses indefinitely.

None of this requires any setup on your part. The fallback happens automatically and invisibly, whether you are presenting from a home office or a locked-down conference centre. If you want the full picture of how the rest of the connection is secured, see is WebRTC secure and the Security & Networking documentation.

What a relay costs you, and what it does not

TURN relaying is not free in engineering terms. Routing traffic through a third point adds a small amount of latency compared with a direct connection, and it uses more bandwidth on the relay operator's side. What it does not cost you is security: the relay never decrypts the payload, so a locked-down network does not force a trade-off between "it works" and "it is private."

For screen sharing specifically, where every extra hundred milliseconds is more noticeable than it is on a simple slide-advance signal, we cover the wider latency picture in how we made screen sharing four times faster and fixing screen sharing latency in hybrid meetings.

Troubleshooting a connection that will not go through

1. Try tethering to a mobile hotspot briefly. If the connection works there but not on the venue network, the network is the issue, not the app.
2. Check whether the app has a visible "relay" or "connection type" indicator, and confirm it is attempting TURN rather than failing outright.
3. Confirm outbound HTTPS on port 443 is allowed, since a TURNS fallback over 443 is the last line of defence on the most restrictive networks.
4. If none of that works, raise it with the venue or office's IT team using the specific ports and protocols from the vendor's documentation rather than a general "it's not working" report.

If you are evaluating networking behaviour as part of a wider vendor review, fold this into the full security checklist for presentation software, since how a tool handles restrictive networks is easy to overlook until the day it matters.

FAQ

Get started

If you present from venues, client offices or anywhere with a network you do not control, try Cliqer free and see the automatic fallback in action, or read the full security overview for how every layer of the connection is protected.