WebRTC ICE Candidate Types
ICE (Interactive Connectivity Establishment, RFC 8445) gathers network address candidates and tests them to find the best path between peers. Candidates are tried in priority order – host first, then srflx, then relay as last resort.
RFC 8445
ICE Spec
Host Candidate
A host candidate is an IP address and port directly on the device's local network interface. Gathered without contacting any external server. Host candidates work for P2P on the same LAN or network segment. They fail across NAT – the address is private and unreachable from the internet. The browser gathers one host candidate per local network interface (Wi-Fi, Ethernet, VPN).
+No external server required – works without STUN or TURN
+Lowest latency when successful – direct LAN connection
!Fails across NAT – private IPs not reachable from the internet
Server Reflexive Candidate
A server reflexive (srflx) candidate is the public IP:port that a STUN server observes when a host candidate UDP packet arrives from behind NAT. It represents how the internet sees the device – the public address that NAT maps the private address to. Srflx candidates enable direct P2P across most home routers (full-cone, port-restricted cone, and address-restricted cone NAT). Requires a STUN server.
+Enables P2P across most consumer NAT routers without relay cost
+Free STUN servers available – Google, Cloudflare, others
!Fails with symmetric NAT (~20–30% of connections) – requires TURN fallback
Relay Candidate
A relay candidate is an IP:port on a TURN server that forwards media on behalf of the client. Used as last resort when direct P2P (host) and STUN-discovered (srflx) paths both fail – typically behind symmetric NAT, strict firewalls, or corporate proxies. Relay adds latency and bandwidth cost but guarantees connectivity. TURN is defined in RFC 8656.
+Guarantees connectivity regardless of NAT type or firewall
+Works through symmetric NAT, corporate firewalls, and UDP-blocking networks
!Highest latency – all media passes through relay server
Peer Reflexive Candidate
A peer reflexive (prflx) candidate is discovered dynamically during ICE connectivity checks – it is the address the remote peer observes for your STUN Binding Requests. Unlike srflx (discovered via a STUN server), prflx is discovered by the peer itself during the check phase. Peer reflexive candidates are rare in practice but matter for aggressive ICE nomination with NAT types that assign new ports during the check phase.
+Discovered during connectivity checks – no additional STUN server round-trip
+Higher priority than srflx – preferred when available
!Only discovered during ICE checks, not during candidate gathering