The same WebRTC code connects directly in two seconds at home and uses a relay at the office. A phone moving from Wi-Fi to 5G recovers briefly, then disconnects again. NAT traversal is not random; networks apply different rules to outbound port mappings, allowed return sources, and transport protocols. ICE gathers plausible routes, tests them, and keeps a pair that works now.
Once that chain is visible, “add more STUN servers” stops being the only troubleshooting idea. You can ask whether candidates were gathered, signaling delivered them, connectivity checks were blocked, the wrong path was selected, or a network change failed to trigger new negotiation.
What NAT maps
When a private-address device sends a packet, the router replaces the source with a public address and temporary port. It records how to return replies. A permissive mapping may accept replies from several remotes; a strict mapping may accept only the exact address and port the device contacted. When both endpoints use restrictive behavior, the mappings learned from STUN may not be mutually reachable.
The traditional full-cone, restricted-cone, port-restricted, and symmetric categories are useful teaching tools, but real equipment can mix behavior and an enterprise firewall adds another policy layer. Running actual ICE checks is more reliable than naming the NAT first and guessing a route.
Candidate families
- Host candidates come from local interfaces. Modern browsers may expose an mDNS name instead of a private IP to reduce fingerprinting.
- Server-reflexive candidates are public mappings learned through STUN and often enable direct connections between home networks.
- Relay candidates are TURN allocations that preserve reachability when direct pairs fail.
- IPv6 candidates can avoid parts of IPv4 NAT when both endpoints and the path support them, while still obeying firewall policy.
Candidates travel through signaling. Trickle ICE sends them as they appear instead of waiting for the full list, reducing setup time. Every candidate belongs to a session. After refresh or renegotiation, reject candidates from a superseded session so late signaling cannot contaminate the new connection.
How candidate pairs are checked
Each endpoint combines local and remote candidates into pairs and sends authenticated connectivity checks. A successful check means the addresses can communicate both ways. ICE then nominates a pair and WebRTC completes secure handshakes such as DTLS. Priority favors lower-cost routes, but availability always comes first.
ICE roles are explicit: one side is controlling and the other controlled. A role collision is resolved through the protocol’s tie-breaker. Applications that create two PeerConnections and let them overwrite each other reintroduce a race the underlying protocol already knows how to solve.
Networks that commonly need a relay
Strict port mappings, carrier-grade NAT layered over a home router, enterprises that permit only port 443, blocked UDP, and guest Wi-Fi isolation can defeat direct routes. A VPN adds virtual interfaces and changes routing; depending on policy, WebRTC may bypass the tunnel, use it, or fail.
TURN should offer UDP plus TCP or TLS entry points for restrictive environments, often with a 443 fallback. TCP improves reachability but can suffer head-of-line blocking and should not be expected to match UDP. With relays on several continents, credential delivery should select a nearby healthy region rather than making the browser wait through long sequential failures.
Why the same LAN can still fail
Guest networks and access-point isolation prevent wireless clients from talking to each other. A host firewall may reject inbound browser UDP. One device can sit behind a second downstream router. Enterprise endpoint policy may filter mDNS or WebRTC traffic.
Same-exit discovery may still find both devices because each can reach the public service, while host candidates cannot communicate. Discovery, signaling, and data path are three separate facts. A UI should not translate “device found” into “local direct connection” before checks succeed.
Recover after a network change
A browser online event means the operating system reports some network; it does not make old candidates valid. Observe PeerConnection state, the selected pair, and application heartbeats. When the path fails, an ICE restart creates new credentials and descriptions. If the connection object has entered an unrecoverable state, start a new session.
Recovery needs deduplication. Both peers may detect failure and send an offer at once, so a deterministic rule or negotiation queue merges the work. Use jittered backoff for repeated failures, but retry promptly after a genuine network-type change. Once a person presses Stop, online and visibility events must not wake the connection.
Collect evidence without collecting secrets
Candidate type and protocol, final route, stage timings, failure state, ICE restart count, and a coarse network class are enough for product analysis. IPs, full candidate strings, ICE usernames, and TURN credentials do not belong there. Security diagnostics also need redaction, restricted access, and a retention limit.
Reproduce with two real browsers across same LAN, home-to-mobile, two mobile networks, VPN, corporate access, and blocked UDP. Two tabs on one computer prove very little about real NAT traversal.
The right product goal
The goal is not a brittle promise of 100 percent direct. It is quick direct setup where possible, prompt controlled relay where necessary, aggressive recovery after an involuntary network change, silence after an explicit stop, and a route label based on current facts.
During the uCopy connection flow, ICE tests candidates in parallel and uses TURN when needed. A person does not need to diagnose a NAT type, but they deserve a clear state: connecting, direct, relayed, or failed at a named stage.