好问题！其实浏览器本身不会自动发现STUN/TURN服务器——这些都是你（开发者）明确告诉它的，然后WebRTC的ICE框架会按照你提供的配置去生成候选地址、尝试连接。下面一步步拆解这个过程：

1. 开发者先给浏览器“指路” #

当你创建RTCPeerConnection实例时，必须传入包含iceServers的配置对象，把STUN/TURN服务器的地址、凭证（如果是TURN）明确告诉浏览器。举个实际代码例子：

const peerConnection = new RTCPeerConnection({
  iceServers: [
    // STUN服务器：用来获取公网反射地址
    { urls: 'stun:stun.l.google.com:19302' },
    // TURN服务器：用来做媒体中继（当STUN穿透失败时）
    {
      urls: 'turn:your-turn-server.com:3478',
      username: 'your-username',
      credential: 'your-password'
    }
  ]
});

没有这个配置，浏览器根本不知道要去联系任何STUN/TURN服务器，只会尝试本地局域网内的候选地址——这在跨网场景下肯定连不通。

2. ICE框架按配置生成候选地址 #

当PeerConnection开始收集ICE候选时，它会按优先级尝试：

• 首先收集本地候选：也就是设备在局域网内的IP地址（比如192.168.x.x）
• 然后用你配置的STUN服务器生成反射候选：浏览器把自己的本地地址发给STUN服务器，STUN返回它看到的你的公网地址（也就是NAT映射后的地址），这个地址会作为候选之一
• 如果STUN尝试失败（比如遇到对称NAT），就会启动TURN中继候选：浏览器会和TURN服务器建立连接，后续所有媒体流量都通过TURN服务器中转，这个中继地址也会作为候选

3. 候选交换与最优路径选择 #

当两端交换完ICE候选后，ICE框架会尝试所有可能的候选配对（本地候选对对方的反射候选、本地候选对对方的TURN候选等等），找到延迟最低、连通性最好的路径。这里浏览器之所以会优先尝试STUN/TURN相关的候选，完全是因为你提前把这些服务器的信息喂给了它，它才会生成对应的候选地址去尝试。

常见误区澄清 #

别以为浏览器会偷偷自带STUN服务器——虽然早年部分浏览器有默认配置，但现在主流浏览器（Chrome、Firefox、Safari等）都要求开发者显式配置，否则不会主动去联系任何STUN/TURN服务器。毕竟不同场景下需要的服务器差异很大，浏览器没法替你做选择。

内容的提问来源于stack exchange，提问作者ROBO-KY