ICE Candidate Type: Host vs srflx vs Relay

ICE Candidate Type: Host vs srflx vs Relay

ICE candidate type reveals your WebRTC connection path. Three types exist: host, srflx, and relay, and each maps directly to a different network path with different latency and reliability characteristics. Host candidates use the LAN IP directly, which only works when both peers share a network. Server-reflexive (srflx) candidates use the public IP and port discovered via STUN, enabling direct connection through NAT. Relay candidates route all traffic through a TURN server, the universal fallback when direct NAT traversal fails¹.

The ICE candidate type displayed by this tool is the type of the active candidate pair (the specific combination of local and remote candidates that the ICE agent selected as the best working connection). Seeing "host" confirms a LAN connection; "srflx" confirms direct NAT traversal; "relay" confirms TURN routing. Each type gives you a different diagnostic signal about why the connection is taking the path it is.

What each ICE candidate type means

Host candidates contain the device's LAN IP address. They only succeed when both peers are on the same local network, such as two browsers on the same home Wi-Fi. Server-reflexive candidates (srflx) contain the public IP:port pair that the STUN server observed. They succeed when at least one peer's NAT type is Full Cone or Restricted Cone, allowing the hole-punch to work. Relay candidates route through a TURN server; both peers connect outbound to the relay, which forwards packets between them. Relay candidates always succeed regardless of NAT type, at the cost of added latency from the relay server hop. Consequently, ICE prefers host over srflx over relay, trying each priority level in order².

How ICE gathers each candidate type during negotiation

ICE gathers host candidates by enumerating the device's active network interfaces, including both wired and wireless adapters. It gathers srflx candidates by sending STUN binding requests to one or more configured STUN servers and reading the XOR-MAPPED-ADDRESS from each response. It gathers relay candidates by allocating a relay address on each configured TURN server through an Allocate request. The gathering phase produces a complete list of all three candidate types before the connectivity checks begin.

Why relay candidates produce higher latency

Relay routing adds a round-trip to the TURN server on top of the direct peer-to-peer path³. If the TURN server is geographically distant from either peer, this can double the effective RTT. A peer-to-peer path of 40 ms becomes 40 ms plus twice the distance to the TURN server on a relay connection. Building on this, TURN server location selection matters more than most WebRTC deployments assume; a TURN server deployed in one region adds significant latency for peers in other regions. The ICE candidate type in this tool lets you immediately identify when relay is active and quantify the latency overhead.

Improving candidate type from relay to srflx

Moving from relay to srflx requires enabling direct NAT traversal. For home routers, enabling UPnP or setting the NAT mode to Full Cone allows ICE hole-punching to succeed. For corporate networks, this typically requires a firewall rule allowing outbound UDP. For carrier-grade NAT, requesting a dedicated public IP from the ISP provides the only reliable path to srflx or host candidates on IPv4. IPv6 connections bypass NAT entirely and typically produce host candidates⁴; enabling IPv6 on your connection is the most direct path to optimal ICE candidate type if your ISP supports it. CapyToolkit displays the active candidate type for each test, making it straightforward to compare ICE behavior before and after a configuration change on your router or firewall, so you can confirm that the change produced the expected improvement in candidate type.

ICE candidate priority scores and the selection algorithm

ICE assigns a numeric priority to every gathered candidate using the formula defined in RFC 8445. The priority formula is: priority = (2^24) × type-preference + (2^8) × local-preference + (256 - component-ID). Type-preference values are 126 for host candidates, 110 for peer-reflexive candidates, 100 for server-reflexive candidates, and 0 for relay candidates. Consequently, a host candidate always has a higher priority than an srflx candidate, and both always outrank relay. The ICE agent sorts all generated candidate pairs by the sum of both peers' candidate priorities, testing the highest-priority pairs first.

The local-preference field distinguishes between multiple candidates of the same type. If a device has both an Ethernet interface and a Wi-Fi interface, both generate host candidates with type-preference 126 but different local-preference values assigned by the ICE implementation. The ICE agent tests both and selects the one whose connectivity check succeeds first at the highest priority level. This automated selection explains why the active candidate type shown in this tool reflects the actual best-available path rather than a predetermined configuration.

Overriding candidate selection for testing purposes

For applications with specific routing requirements (for instance, always using relay to test TURN server performance), the RTCIceCandidateStats interface in the WebRTC statistics API exposes the priority and candidate type for each gathered candidate. Setting iceTransportPolicy: "relay" in the RTCPeerConnection configuration forces ICE to use only relay candidates, bypassing host and srflx selection⁵. This flag is available in all major browsers and is useful for measuring relay-path RTT directly alongside the default direct-path RTT.

Debugging ICE candidate type in the browser diagnostics

Chrome's chrome://webrtc-internals page logs every ICE candidate gathered, every connectivity check sent and received, and the selected candidate pair with its priority value. Open this page before initiating a WebRTC connection and leave it open during the test. After a connection failure, the log shows exactly which candidate pairs were tested, which returned STUN error response codes (400, 401, or 487), and whether the failure was at the gathering phase or the connectivity check phase. No reflexive candidates in the log indicates STUN was blocked; reflexive candidates with no successful connectivity check indicates the hole-punch failed and TURN is needed.

For Firefox, the about:webrtc page provides equivalent diagnostic output. Both pages display the ICE connection state transitions: gathering, checking, connected, completed, failed, or disconnected. A transition from "checking" directly to "failed" after all candidate pairs are tested confirms ICE failure. Reviewing the candidate list at that point reveals which types were available: only host candidates indicate STUN was unreachable; host and srflx candidates with no relay candidates indicate TURN was not configured.

Reading the candidate pair statistics table

The statistics table in chrome://webrtc-internals shows bytesReceived and bytesSent for the active candidate pair after connection. A candidate pair showing bytesSent > 0 but bytesReceived = 0 is sending successfully but not receiving, identifying a one-way connectivity block on the inbound path. Checking whether bytesSent and bytesReceived actually line up confirms bidirectional packet flow, which is the correct state for a functioning P2P connection established via this tool.

The bytesSent and bytesReceived columns also expose a silent partial failure that a healthy candidate type label can hide, because the pair may connect yet carry traffic in only one direction. Subtracting the two values over a timed window quantifies how much data actually moved versus how much stalled on the return path. Pairing this table with the ICE candidate type display gives a complete picture of both the path chosen and whether that path is genuinely delivering packets in both directions.

When to use this

Run this test when diagnosing unexpectedly high WebRTC latency, when verifying that a network change moved a connection from relay to direct, or when building a WebRTC application and confirming that ICE candidate negotiation produces the expected path.

Examples