在 WebRTC 的连接说明里，STUN 和 TURN 总是挨着出现，久而久之很容易被理解成两台“功能差不多的中转服务器”。其实两者的工作量完全不同：STUN 更像问路，告诉浏览器它从公网看起来是什么地址；TURN 则是在路走不通时，真的替双方搬运每一个数据包。
弄清这点很有用。它能解释为什么免费 STUN 很常见，而 TURN 通常有配额；为什么页面显示中继后延迟会上升；也能帮助判断“P2P”是否等于“数据绝不经过服务器”。
问题从 NAT 开始
家庭路由器让多台设备共用一个公网 IP。电脑可能是 192.168.1.20，手机可能是 192.168.1.35，这些私有地址在互联网中不能直接路由。设备向外发包时，路由器临时建立一个公网地址和端口映射，再把返回数据交回正确设备。
浏览器只知道自己的局域网视角，不一定知道路由器建立了什么映射。另一端也不知道这个映射是否允许陌生地址回包。WebRTC 的 ICE 流程会收集多种候选地址，让双方逐对做连通性检查，而不是押注某一个地址。
STUN 负责照镜子，不负责搬文件
浏览器向 STUN 服务器发送请求，服务器把它观察到的来源 IP 和端口写进响应。浏览器由此得到一个服务器反射候选，也就是从公网一侧看到的映射。双方交换候选后，可能通过这个地址打通路径。
连接一旦建立，后续聊天、文件或音视频不会继续经过 STUN。它承受的是少量探测报文，不是整场会话的流量。因此公开、免费或低成本的 STUN 服务较多，但可用性仍应通过多个运营方和合理超时来保障，不能把所有连接都押在单一域名上。
TURN 是走不通时的可靠后门
企业网络可能只允许经代理访问互联网，校园网可能启用客户端隔离，运营商级 NAT 也可能使用很严格的端口映射。当所有直接候选都失败时，浏览器向 TURN 申请一个中继地址。双方各自与中继建立连接，TURN 再把数据从一侧转发到另一侧。
这条路径牺牲了一些效率来换成功率。数据多走一段路，延迟通常更高；服务器需要承担每个字节的入站和出站，成本远高于 STUN；服务器地域也很重要，亚洲两端如果绕到欧洲中继，体验会明显变差。
| 项目 | STUN | TURN |
|---|---|---|
| 核心作用 | 发现公网映射，辅助直连 | 直连失败时转发数据 |
| 会话正文 | 不经过 | 经过中继，但 WebRTC 传输仍加密 |
| 资源消耗 | 少量请求 | 与实际传输量直接相关 |
| 部署重点 | 稳定、低延迟、多个入口 | 容量、地域、认证、配额和滥用控制 |
ICE 如何从候选里选路
候选大致包括设备接口产生的主机候选、STUN 得到的服务器反射候选，以及 TURN 提供的中继候选。浏览器会组成候选对并进行连通性检查。优先级通常偏向成本更低的直接路径，但真正被选中的必须是可达的。
网络变化后，原来的候选对可能失效。Wi-Fi 切到移动网络、VPN 开关、电脑睡眠恢复，都可能触发 ICE 重启或整条连接重建。应用层不能把“曾经选中过直连”当成永久事实，界面上的路径标记也要随当前候选对更新。
经过 TURN 还安全吗
WebRTC 的媒体和数据传输有链路加密，TURN 转发的是受保护的数据包，而不是像网盘那样接收一个可打开的文件。不过中继仍会知道连接双方的网络地址、时间、传输量和持续时长。这些元数据也有隐私价值，应缩短日志保留、限制访问，并避免把连接码、文件名或聊天内容写进中继统计。
TURN 还是一项容易被白嫖的公网资源。固定用户名和长期密码一旦泄露，别人可以消耗流量甚至把它当通用代理。更稳妥的做法是签发短期凭据，绑定允许的会话或用户，设置日配额、并发限制和异常速率告警。
用户该怎样看连接状态
“已连接”只说明通道可用，不说明路径。一个诚实的状态区应至少区分局域网直连、公网直连和 TURN 中继，并在路径变化时更新。对普通用户，不必展示一长串 ICE 术语，但应解释中继可能更慢、会使用服务配额，内容仍保持加密。
在 uCopy 建立连接后，可在工作区查看当前路径。如果同一局域网始终使用 TURN，先检查两台设备是否接入访客 Wi-Fi、是否打开 VPN、路由器是否开启 AP 隔离。跨公司网络使用中继则很正常，不必把它当成故障。
一句话记住区别
STUN 回答“外面的人怎么看到我”，TURN 解决“我们还是碰不到，那就请你转交”。前者帮助找到更直接的路，后者为最难连的网络兜底。把两者都配置好，才是既追求速度又尊重可达性的 WebRTC 系统。
对产品而言，最佳策略不是强行宣称百分之百直连，而是优先选择更短路径，在失败时迅速切到受控中继，并把当前事实清楚告诉用户。