STUN Server Test: Discover Your Public IP and NAT

STUN Server Test: Discover Your Public IP and NAT

STUN servers expose your public IP instantly. Sending a binding request to a STUN server, your browser receives back the public IP address and port your router assigned to the outbound connection (information your router holds but does not expose directly to applications). This is the same mechanism WebRTC uses to discover how to reach you from outside your local network, and the same information exchange that determines whether a direct peer-to-peer connection can succeed.

The STUN probe on this page runs automatically on load, contacting public STUN servers from Google (stun.l.google.com:19302) and Cloudflare to collect reflexive IP:port pairs. Comparing the external port assigned for each request determines your NAT type: identical external ports across multiple destinations indicate Full Cone (Open) NAT; different ports indicate Symmetric NAT, which blocks most direct WebRTC connections¹.

What the STUN binding request returns

A STUN binding request sends a small UDP packet to the STUN server. The server reads the source IP and port from the UDP header (which reflects the public IP and port your NAT router inserted) and writes this information into a STUN binding response. The browser receives the response and reads the XOR-MAPPED-ADDRESS attribute, which contains the public IP and port². Consequently, no special permissions are needed: the STUN server is a passive mirror for the NAT information already present in outbound packets. The STUN protocol is defined in RFC 8489 and the fundamental binding mechanism has not changed since RFC 5389.

Why XOR-MAPPED-ADDRESS prevents information correlation

The XOR-MAPPED-ADDRESS attribute obfuscates the public IP and port by XORing them with the magic cookie and transaction ID of the STUN message. This prevents a STUN server operator from correlating a client's internal IP address with the public IP revealed in the response, which would otherwise allow mapping a private network topology from a single STUN transaction. WebRTC applications read the XOR-MAPPED-ADDRESS and reverse the XOR to recover the actual public address.

Reading NAT type from STUN results

A Full Cone router assigns the same external port to all outbound connections from the same internal IP:port pair, regardless of destination. The STUN probe confirms this by sending requests to two different STUN server IPs and checking whether both responses contain the same external port. If ports match, the NAT is Full Cone or Restricted Cone, both of which allow ICE hole-punching. If ports differ, the NAT is Symmetric¹. Building on this distinction, the tool displays the public IP and the NAT classification directly below the probe results, giving you the same classification a WebRTC application's ICE agent uses when planning its candidate strategy.

What to do with the STUN results

If the probe shows Full Cone or Restricted Cone NAT, your network supports direct WebRTC connections for most peer configurations. If it shows Symmetric NAT, direct WebRTC connections to peers behind any non-Full-Cone NAT will require TURN relay. The public IP displayed by the probe is your router's current WAN IP, which is useful for verifying that a static IP assignment took effect or that a VPN is routing traffic through the expected exit IP. Furthermore, if the probe fails entirely (returning no reflexive candidates), your network blocks UDP to port 3478, the default STUN port², which will cause ICE failures in WebRTC applications unless TCP-based TURN is configured.

IPv6 and STUN: how global addressing bypasses NAT traversal

IPv6 eliminates NAT for endpoints with a globally routable IPv6 address. IPv6 provides enough address space (approximately 3.4 × 10^38 addresses)³ that every device can have a unique globally reachable IP without address sharing. On an IPv6-capable connection, the STUN probe returns an IPv6 address as a host candidate rather than discovering an external port through NAT traversal. ICE prefers host candidates over server-reflexive candidates, so WebRTC connections between two IPv6-capable peers use the host candidate path directly, avoiding NAT mapping entirely.

Enabling IPv6 on your router and ISP connection produces host candidates for devices with global IPv6 addresses, which are the highest-priority ICE candidates. Both symmetric NAT and CGNAT are IPv4-specific conditions; they do not apply to IPv6 connections. Verifying IPv6 connectivity is as simple as running the STUN probe in this tool: if the discovered IP address contains colons (IPv6 notation), your connection has a globally routable IPv6 address and NAT traversal is not required.

Checking dual-stack behavior with the STUN probe

On a dual-stack (IPv4 and IPv6) connection, WebRTC ICE gathers both IPv4 and IPv6 candidates. If both peers have IPv6 connectivity, the active candidate will be an IPv6 host type, bypassing NAT entirely. If only one peer has IPv6, ICE falls back to IPv4 reflexive or relay candidates for the cross-protocol path. Spotting a global IPv6 address in the probe results, rather than a link-local or IPv4-mapped one, confirms full IPv6 reachability before you test with a remote peer who may or may not share that same dual-stack capability.

STUN server unavailability and the ICE failure cascade

A STUN probe that returns no reflexive candidates indicates one of three conditions: the STUN server is unreachable, UDP port 3478 is blocked by your network's firewall, or the network blocks all outbound UDP above a specific port threshold. Corporate guest Wi-Fi networks frequently block UDP on ports above 1024⁴, preventing STUN from functioning on the standard port. When the STUN probe fails, ICE has no server-reflexive candidates and falls back entirely to relay candidates; if no TURN server is configured either, ICE has only host candidates and the connection fails for any cross-network peer.

Public STUN servers from Google (stun.l.google.com:19302) and Cloudflare (stun.cloudflare.com:3478) maintain high availability, so a probe failure is almost always on the client network side rather than the server side. The most reliable diagnostic step is attempting STUN over a different transport: some STUN implementations support binding requests over TCP on port 3478. TURN over TLS on port 443 is the universal fallback⁵, because almost all firewalls allow HTTPS port traffic; configuring a TURN server on port 443 restores WebRTC connectivity even on networks that block all other UDP.

What no reflexive candidates means for a WebRTC application

If the probe consistently returns no reflexive candidates, add TURN with TLS to your WebRTC iceServers configuration. A { urls: 'turns:your-turn-server.example.com:443', username: 'user', credential: 'password' } entry provides relay candidates via TURN over TLS, which nearly all firewalls permit. This configuration ensures WebRTC connections complete on restricted networks, though at the cost of relay server latency overhead on all affected connections.

The TLS port matters because almost every network policy permits outbound 443 traffic, while raw UDP on 3478 is frequently filtered on guest and corporate Wi-Fi. Adding this fallback before deploying your application avoids the class of failures where STUN works in the lab but fails on a real user's restricted network. Treat the absence of reflexive candidates as a hard signal to ship TURN over TLS rather than assuming the client network resembles your own development environment.

When to use this

Run this test to discover your public IP address, to verify your NAT type before deploying or troubleshooting a WebRTC application, or to confirm that a router configuration change moved your NAT classification from Symmetric to Full Cone.

Examples