{"id":1062,"date":"2026-05-21T09:47:47","date_gmt":"2026-05-21T02:47:47","guid":{"rendered":"https:\/\/liveapi.com\/blog\/stun-server\/"},"modified":"2026-05-21T09:48:17","modified_gmt":"2026-05-21T02:48:17","slug":"stun-server","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/stun-server\/","title":{"rendered":"What Is a STUN Server? How It Works, Setup, and Use Cases"},"content":{"rendered":"Reading Time: <\/span> 11<\/span> minutes<\/span><\/span>

If you’ve built a video calling feature or any WebRTC integration, you’ve probably hit the same wall every other developer hits: two browsers behind home routers refuse to talk to each other directly. Network Address Translation (NAT) hides their real addresses behind a single public IP. Without a way to learn that public address, peer-to-peer media just doesn’t connect.<\/p>\n

A STUN server<\/strong> is the small but critical piece of infrastructure that solves this problem. It’s the first stop in almost every WebRTC call, every VoIP session, and many online game lobbies. This guide breaks down what a STUN server is, how the protocol works, which NAT types it handles, the public STUN servers you can use today, and how to deploy your own with open-source tools.<\/p>\n

What Is a STUN Server?<\/h2>\n

A STUN server<\/strong> (Session Traversal Utilities for NAT) is a lightweight server that helps a client behind a NAT or firewall learn its public IP address and the port mapping used by its router. With that information, two peers on different networks can attempt a direct connection without routing traffic through a relay.<\/p>\n

STUN is defined by RFC 8489<\/a>, which obsoletes the older RFC 5389. The protocol is intentionally simple: a client sends a binding request, the server returns the client’s reflexive (public) address, and the client uses that address as a connection candidate.<\/p>\n\n\n\n\n\n\n\n\n\n\n
Attribute<\/th>\nValue<\/th>\n<\/tr>\n<\/thead>\n
Full name<\/td>\nSession Traversal Utilities for NAT<\/td>\n<\/tr>\n
Defined by<\/td>\nRFC 8489 (replaces RFC 5389 and RFC 3489)<\/td>\n<\/tr>\n
Default ports<\/td>\nUDP\/TCP 3478, TLS 5349<\/td>\n<\/tr>\n
Protocol type<\/td>\nLightweight client-server, request\/response<\/td>\n<\/tr>\n
Primary use<\/td>\nPublic IP and port discovery for NAT traversal<\/td>\n<\/tr>\n
Common pairing<\/td>\nTURN servers and the ICE framework<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

If your application needs to set up a direct peer connection \u2014 a one-to-one video call, a game session, a screen-sharing channel \u2014 the STUN server is almost always the first step.<\/p>\n

How Does a STUN Server Work?<\/h2>\n

The STUN exchange is short. Most clients complete it in a single round trip. The point of the exchange is to tell the client one thing: from the public internet, here is what your address looks like.<\/p>\n

Here is the step-by-step flow:<\/p>\n

    \n
  1. The client picks a STUN server.<\/strong> This is configured in the application (for example, in a WebRTC RTCPeerConnection<\/code> config) or resolved through DNS SRV records such as _stun._udp<\/code>.<\/li>\n
  2. The client sends a binding request.<\/strong> It transmits a small UDP packet to the STUN server on port 3478. The packet contains a transaction ID and no authentication.<\/li>\n
  3. The server reads the source address.<\/strong> When the packet leaves the client’s network, the NAT rewrites the source IP and port. The STUN server sees those rewritten values, not the private LAN address.<\/li>\n
  4. The server returns the mapped address.<\/strong> The binding response contains an XOR-MAPPED-ADDRESS<\/code> attribute holding the public IP and port the server observed. XOR encoding prevents older Application Layer Gateways from mangling the value.<\/li>\n
  5. The client stores the reflexive candidate.<\/strong> That public address becomes one of several ICE candidates the client can offer to its peer through a WebRTC signaling server<\/a>.<\/li>\n
  6. The peers attempt a direct connection.<\/strong> Once both sides exchange candidates, ICE pairs them, runs connectivity checks, and picks the best path. If the direct path works, the STUN server’s job is done.<\/li>\n<\/ol>\n

    Here is a short JavaScript example showing how a browser uses a STUN server inside a WebRTC peer connection:<\/p>\n

    const pc = new RTCPeerConnection({\n  iceServers: [\n    { urls: 'stun:stun.l.google.com:19302' }\n  ]\n});\n\npc.onicecandidate = (event) => {\n  if (event.candidate) {\n    \/\/ Send candidate to the remote peer via your signaling channel\n    sendToPeer({ type: 'candidate', candidate: event.candidate });\n  }\n};<\/code><\/pre>\n
    The first time you call createOffer()<\/code> on this pc<\/code> object, the browser fires STUN binding requests to stun.l.google.com:19302<\/code>, then surfaces the resulting reflexive candidates through onicecandidate<\/code>. No SDK, no relay, no media yet \u2014 just address discovery.<\/p>\n
    STUN vs TURN vs ICE: How They Work Together<\/h2>\n
    People often confuse STUN, TURN, and ICE because they all show up in the same iceServers<\/code> array. They are not interchangeable; they solve different parts of the same problem.<\/p>\n\n\n\n\n\n\n\n
    Component<\/th>\nRole<\/th>\nWhen It Runs<\/th>\nBandwidth Cost<\/th>\n<\/tr>\n<\/thead>\n
    STUN<\/strong><\/td>\nFinds the public IP and port for a NATed client<\/td>\nBefore media starts<\/td>\nNear zero \u2014 a few small packets<\/td>\n<\/tr>\n
    TURN<\/strong><\/td>\nRelays media when direct paths fail<\/td>\nDuring the call, as a fallback<\/td>\nHigh \u2014 every byte of audio\/video flows through it<\/td>\n<\/tr>\n
    ICE<\/strong><\/td>\nFramework that gathers candidates and picks a working path<\/td>\nThroughout connection setup<\/td>\nNegligible \u2014 coordination only<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    A typical WebRTC live streaming<\/a> session starts by asking a STUN server for the public address, then collects host candidates (LAN addresses), then optionally collects relay candidates from a TURN server. ICE pairs them, runs connectivity checks, and chooses the best route \u2014 usually direct, sometimes relayed. For a deeper look at how ICE fits into the bigger picture, see our guide to NAT traversal<\/a>.<\/p>\n
    The key insight: STUN is cheap to run, TURN is expensive. You always try STUN first. You only fall back to TURN when STUN-mapped candidates fail to connect.<\/p>\n
    NAT Types and STUN Compatibility<\/h2>\n
    STUN works for most home and small-office networks, but it does not work everywhere. The success rate depends on the NAT type sitting between the client and the public internet.<\/p>\n
    There are four classic NAT behaviors:<\/p>\n
    Full Cone NAT<\/h3>\n
    Any external host can send packets to the mapped public address. Once the client has obtained its mapping through STUN, peers can reach it directly. STUN works.<\/strong><\/p>\n
    Restricted Cone NAT<\/h3>\n
    External hosts can reach the mapped address, but only if the client has previously sent a packet to that host’s IP. STUN-mapped addresses still work, but the client must initiate first. STUN works.<\/strong><\/p>\n
    Port-Restricted Cone NAT<\/h3>\n
    Like restricted cone, but the external host must also send from the exact port the client wrote to. Still solvable with hole punching. STUN works.<\/strong><\/p>\n
    Symmetric NAT<\/h3>\n
    The NAT creates a different public mapping for every destination. The mapping STUN returns is valid only for traffic to the STUN server itself \u2014 not for traffic to the peer. STUN fails. You need TURN.<\/strong><\/p>\n
    Symmetric NATs are common in cellular networks and many enterprise firewalls. Real-world WebRTC deployments report that 8-20% of calls require TURN fallback because of symmetric NAT or restrictive firewalls. That percentage matters when you are sizing TURN bandwidth budgets \u2014 TURN traffic isn’t free, and it dominates streaming costs once you scale.<\/p>\n
    If you are building a service where reliability matters more than infrastructure cost, plan for TURN from day one. If you are running a controlled environment (corporate LAN, gaming arena, fixed-location kiosks), STUN alone may be enough.<\/p>\n
    Common Use Cases for STUN Servers<\/h2>\n
    STUN underpins almost every real-time peer-to-peer protocol. Anywhere two clients need to find each other across the public internet, STUN is in the path.<\/p>\n
    WebRTC video and audio calls<\/h3>\n
    Every browser-based video call uses STUN. Google Meet, Discord voice, Slack huddles, and most video conferencing API<\/a> products configure at least one STUN server in their ICE servers list. Without it, the calling browser would only see its LAN address and peers across the internet would never connect.<\/p>\n
    VoIP and SIP signaling<\/h3>\n
    SIP phones, softphones, and PBX systems behind NAT use STUN to learn their public address before registering with a SIP registrar. This is how a desk phone behind a small-office router can receive a call from anywhere on the public internet.<\/p>\n
    Online gaming<\/h3>\n
    Multiplayer games that use peer-to-peer matchmaking \u2014 fighting games, racing games, party games \u2014 rely on STUN to let console-to-console connections form. Microsoft, Sony, and Nintendo all run STUN-like services for matchmaking.<\/p>\n
    Peer-to-peer file sharing<\/h3>\n
    Applications using NAT hole punching for file transfer (older versions of Skype, BitTorrent peer exchange, IPFS) use STUN to find reflexive candidates before negotiating direct paths.<\/p>\n
    IoT and home device control<\/h3>\n
    Smart home apps that connect to cameras and sensors behind a home router often use STUN to set up direct media streams instead of pushing every frame through a cloud relay.<\/p>\n
    Hybrid streaming architectures<\/h3>\n
    Some streaming platforms use WebRTC for ingest (the broadcaster’s upload) and HLS for delivery (the viewers’ download). The ingest leg uses STUN. The delivery leg uses CDN-distributed HLS. For more on these tradeoffs, compare WebRTC vs HLS<\/a>.<\/p>\n
    Public STUN Servers You Can Use<\/h2>\n
    You do not need to run your own STUN server to get started. Several large companies operate free, public STUN servers that anyone can use. They are widely deployed, well-maintained, and free to query at modest volumes.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
    Provider<\/th>\nServer URL<\/th>\nPort<\/th>\n<\/tr>\n<\/thead>\n
    Google<\/td>\nstun:stun.l.google.com<\/td>\n19302<\/td>\n<\/tr>\n
    Google<\/td>\nstun:stun1.l.google.com<\/td>\n19302<\/td>\n<\/tr>\n
    Google<\/td>\nstun:stun2.l.google.com<\/td>\n19302<\/td>\n<\/tr>\n
    Cloudflare<\/td>\nstun:stun.cloudflare.com<\/td>\n3478<\/td>\n<\/tr>\n
    Mozilla<\/td>\nstun:stun.services.mozilla.com<\/td>\n3478<\/td>\n<\/tr>\n
    OpenRelay (Metered)<\/td>\nstun:openrelay.metered.ca<\/td>\n80<\/td>\n<\/tr>\n
    Stunprotocol.org<\/td>\nstun:stun.stunprotocol.org<\/td>\n3478<\/td>\n<\/tr>\n
    Twilio<\/td>\nstun:global.stun.twilio.com<\/td>\n3478<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    A practical pattern: list two or three STUN servers in your iceServers<\/code> config so the client has fallbacks if one is slow or temporarily unreachable. Most browsers will use whichever returns the reflexive candidate first.<\/p>\n
    Public STUN servers come with one important caveat: they have no service-level agreement. They can disappear, throttle requests, or change addresses without notice. For a production app handling thousands of concurrent users, you should either pay for a managed TURN\/STUN service or run your own.<\/p>\n
    How to Set Up Your Own STUN Server<\/h2>\n
    If you want full control over latency, uptime, and logging, run your own STUN server. The reference open-source implementation is coturn<\/strong>, which provides both STUN and TURN functionality in one binary.<\/p>\n
    Here is a minimal setup on Ubuntu:<\/p>\n
    # Install coturn\nsudo apt update\nsudo apt install coturn\n\n# Enable the service\nsudo sed -i 's\/#TURNSERVER_ENABLED=1\/TURNSERVER_ENABLED=1\/' \/etc\/default\/coturn\n\n# Edit the config\nsudo nano \/etc\/turnserver.conf<\/code><\/pre>\n
    A starter turnserver.conf<\/code> for STUN-only use looks like this:<\/p>\n
    listening-port=3478\ntls-listening-port=5349\nfingerprint\nrealm=stun.yourdomain.com\nno-multicast-peers\nno-cli\nexternal-ip=YOUR.PUBLIC.IP.ADDRESS<\/code><\/pre>\n
    Then start the service and verify it’s listening:<\/p>\n
    sudo systemctl restart coturn\nsudo netstat -tulpn | grep 3478<\/code><\/pre>\n
    You should see coturn listening on UDP and TCP port 3478. To test the server from another machine, install turnutils_stunclient<\/code> (shipped with coturn):<\/p>\n
    turnutils_stunclient -p 3478 stun.yourdomain.com<\/code><\/pre>\n
    A correct response will print the client’s reflexive address. If you see a timeout, check that firewall rules allow inbound UDP\/TCP on 3478 and that the external-ip<\/code> value matches the host’s public IP.<\/p>\n
    For deployments behind a load balancer or in a Kubernetes cluster, you will need to expose the port directly (no L7 termination), pin the pod to a known public address, and configure liveness probes that send actual STUN binding requests rather than TCP health checks. STUN over TCP responds the same way as STUN over UDP, so a simple TCP probe can mislead you.<\/p>\n
    A note on hosting choices: building and operating low-latency, globally distributed STUN\/TURN infrastructure is its own engineering project. If your priority is shipping the streaming app rather than the plumbing under it, hosted platforms can abstract all of this. The LiveAPI live streaming API<\/a> handles RTMP and SRT ingest, multi-CDN delivery through Akamai, Cloudflare, and Fastly, and the broader infrastructure stack so your team can focus on application code.<\/p>\n
    Security Considerations for STUN Servers<\/h2>\n
    STUN itself is a simple protocol. It does not move user data \u2014 only address mapping information. But there are still security details worth getting right.<\/p>\n
    No authentication on classic STUN<\/h3>\n
    Vanilla STUN binding requests are unauthenticated. Anyone can query a public STUN server and learn their own public address. This is by design. You don’t lose anything by exposing your reflexive address; it’s already visible to anyone you send a packet to.<\/p>\n
    TURN credentials, not STUN credentials<\/h3>\n
    If you are running coturn for both STUN and TURN, the TURN side requires long-term or time-limited credentials. Most production deployments use a REST API pattern documented by the IETF<\/a> to mint short-lived TURN credentials per call. STUN-only queries remain open.<\/p>\n
    DDoS exposure<\/h3>\n
    Open STUN servers can be abused as amplification reflectors in some configurations. Restrict the server’s response sizes, rate-limit per source IP, and consider firewall rules that drop spoofed source addresses (BCP 38).<\/p>\n
    TLS for sensitive deployments<\/h3>\n
    For environments where even the server-client relationship is sensitive, run STUN over TLS on port 5349. The address discovery still works the same way; only the transport is encrypted.<\/p>\n
    Logging and PII<\/h3>\n
    A STUN server sees source IPs of every request. That data is personally identifiable. If you log it, treat it as user data \u2014 apply your retention policy and access controls accordingly.<\/p>\n
    STUN Server Limitations<\/h2>\n
    STUN solves a narrow problem well. It is worth knowing what it does not do.<\/p>\n