VPN 与 TURN 中继：到底谁在承载 WebRTC 通话？
隧道只改变 ICE 所见的路由，从不分配中继，也不提供信令。比较 VPN 出口与 TURN 服务器各自提供什么。
页面经 VPN 能打开，通话却始终连不上：同一个地址栏里藏着两种不同的故障。隧道改变的是浏览器所用的路径；它没有变成信令服务、STUN 服务器或中继，也不决定 ICE 会选哪一对候选。正是把各组件的职责分开，才把含糊的“WebRTC 被封锁”变成具体的故障。
四项工作，隧道只触及其中一项
应用通过某种信令安排交换会话信息，这是第一项工作。ICE 收集候选地址并测试地址对，直到有一对可用，这是第二项。STUN 让对端了解自己的流量从外部看是什么样子，TURN 则为不存在直连路径的情况分配中继。这四种角色彼此不同，VPN 只影响它们遇到的地址与过滤，并不亲自提供其中任何一种。
所以登录成功并不能说明媒体路径如何。信令通常走页面已在用的同一个 HTTPS，端口为 443，而媒体却可能经 UDP 前往完全不同的目的地。
私有地址让混乱更严重。隧道地址只有在对方有一条通往它的既定回程时才有用；私有并不等于相互可达，浏览器在丢弃无法检验的候选时也不会这样认为。对你来说像是本地的候选，从另一端可能根本无法测试。在断定隧道丢弃媒体之前，值得先排除这一空隙。
比较 VPN 出口与 TURN 中继
两者都会转发数据包，因此常被混为一谈，上面的对照表值得逐列阅读，而不是当作功能清单。中继分配是由已认证请求创建的、按会话存在的对象；隧道则是一条路由。一个带有会过期的凭据，另一个带有一个要么可达、要么不可达的对端地址。
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
端口号让差别变得具体。TURN 默认在 3478 上监听 UDP 与 TCP，在 5349 上监听 TLS；一个放行 443 却丢弃这些端口的网络，会让经中继的通话失败，而网页浏览照常进行。修改 VPN 的端口并不会配置其中任何一项，因为关键的端口属于中继服务，而不属于隧道。
先读诊断，再测试通话
浏览器无需抓包就能展示所需信息。打开所用浏览器的 WebRTC 诊断页面，发起通话，然后读选中的候选对，而不是已收集的列表：选用了哪些本地与远端候选类型、经由哪种传输与地址族，以及路径是直连还是经中继。
有两种读法值得提前了解。若选中的对是私有地址上的主机对主机，媒体就留在你可以推理的路径上；若是中继对中继，通话就在消耗中继容量，并依赖该服务的可用性。停在“检查中”而没有选中对的故障，意味着候选已经收集，但没有一个通过连通性检查。
接着在同一通话中比较同样的两个端点，只改变一个已获准的条件，并以双向媒体或数据、而不是“已连接”指示来判断结果。候选收集在许多从不承载一帧音频的情况下也会成功。在改动的另一侧重复通话，并保留两份诊断记录，因为比较两次运行比只读其中一份更有信息量。同样的端点、同样的编解码、只改一个变量。
刻意把 ICE 传输策略设为 relay 的应用，只要求中继候选。这一设置既不创建中继，也不修复缺失的凭据；它只是把要求讲明白，这在有人把网站自己选定的策略归咎于 VPN 时很有用。
把隐私主张收窄到证据允许的范围
候选的暴露取决于浏览器与应用策略，而不只是隧道状态，W3C 的对等连接规范把 IP 处理视为它自己的议题。因此，已连接的 VPN 并不是承诺“通话只暴露一个选定地址”的好依据。同一隧道后的两端甚至可能选择一条从不离开主机的路径，这同时是隐私改善与连通性限制。
你能准确陈述的范围更窄，也更有用：选中的是哪一对候选、由哪种传输承载，以及这条路径是否留在隧道之内。把这三项事实分别记在可用与失败的通话上，差异通常会指出需要修复的组件。
连通之后，把性能与可达性分开。丢包、时延、排队与 MTU 都位于正确候选对的下游，把卡顿的通话当成连通性故障，只会让你毫无必要地回到候选列表。