你这份是 WebRTC的 ICE candidate grid（候选对）诊断信息，可以用来判断连接是通过 STUN（P2P打洞） 还是 TURN（中继） 建立的。我们来详细分析一下：

重点：你目前的连接是 STUN（P2P），不是 TURN

当前唯一处于 succeeded 状态的连接对：

Candidate (pair) id: CPNRmruRdw_9v9ghCKJ  
State: succeeded  
Network type: wifi  
Protocol: UDP  
Local candidate: INRmruRdw → 10.180.16.134:56244 (host)  
Remote candidate: I9v9ghCKJ → 202.120.60.93:35845 (srflx)  

解读：

• Local candidate = host 类型：表示本地IP，非中继；
• Remote candidate = srflx 类型：由 STUN server 反映的公网IP（server reflexive）；
• Candidate 对 = host <-> srflx：这是一种典型的STUN打洞直连结构；
• 状态 = succeeded，RTT=0.002s，说明连接成功建立且延迟很小。

所以，你的连接目前是通过 STUN方式打洞成功的P2P直连，并未通过 TURN 中继。

其它候选项（状态为 waiting 或 in-progress）：

这些连接对都未成功建立连接，比如：

CP+gfywA5S_1X4tH30Z (waiting)
local-candidate: relay (TURN)  
remote-candidate: relay (TURN)

• 都是 relay <-> relay 的 TURN 候选；
• 状态都卡在 waiting，bytes sent = 0；
• 没有成功建立连接，也没有作为主连接使用。

总结判断依据

小TIP：如何判断 WebRTC 使用 STUN 还是 TURN？

1. 看最终连接的 candidate pair 类型：
2. host <-> srflx 或 host <-> host：STUN直连；
3. relay 相关的 pair 成为 succeeded：TURN中继；
4. 看 bytes sent/received > 0 且状态为 succeeded 的连接；
5. TURN连接通常 RTT 更高、负载更均衡、但更稳定（绕过防火墙）；

如果你想强制使用 TURN 或避免 P2P 直连，可以：

• 设置 iceTransportPolicy: "relay" 来只用 TURN；
• 反之，"all" 表示先尝试 P2P，失败再走 TURN（你现在就是这种策略）。

你还想继续分析哪一对候选连接？或者需要我教你怎么在代码中做连接策略控制？