Roxi先写清楚卡在登录、呼叫还是传输
网页与登录接口常用 TCP，实时媒体可能使用 UDP，也可能通过中继或其他传输回退。WebRTC 会根据 ICE 候选尝试连接，涉及 STUN/TURN 等机制。于是“能收文字但进不了语音”“能接通但单向无声”“游戏登录正常但匹配失败”需要分别记录。不能只看客户端延迟变绿就认定实时流量正常。
| 表现 | 先检查什么 |
|---|---|
| 根本没有录音或声音输出 | 麦克风权限、输入输出设备、应用静音 |
| 一直连接中，文本功能正常 | UDP 路径、应用接管、候选连接与服务状态 |
| 单向无声或间歇断流 | 设备权限之外，再查双向媒体路径与丢包 |
| 切蜂窝网络就恢复 | 原 Wi-Fi、路由器或接入网络限制 |
| 换节点恢复，其他条件不变 | 原节点、服务端 UDP 支持或出口路径 |
第一步：确认这个应用真的进入了代理
- 先用应用内的音频测试确认权限和设备。测试正常后再发起一次实际通话或进入同一游戏场景。
- 同时查看内核连接记录，辨认应用、目标及 TCP/UDP 类型。如果只有登录请求，不代表媒体流也被接管。
- 系统 HTTP 代理通常不能覆盖普通应用的任意 UDP。需要整机接管时，按客户端官方说明启用支持该场景的 TUN 或 VPN，并核对排除列表。开启前记录原状态。
显式 SOCKS 代理是否能传 UDP，也取决于应用是否使用 UDP ASSOCIATE、入站支持和整个转发路径。单纯填写一个 SOCKS 端口并不能保证游戏自动使用它。手机 VPN 还可能排除了某个应用，必须检查按应用分流。
第二步：同时核对规则、节点和服务端
- 确认实时连接命中的策略组和最终节点；同一个应用的登录与媒体可能走不同规则。
- 查节点协议及服务端是否支持 UDP 转发，并看客户端是否启用相应能力。不要给所有配置机械添加 udp: true；字段、协议与版本各有边界。
- 检查是否出现 UDP 超时、规则继续匹配或不支持的提示。Mihomo 官方规则文档说明，UDP 请求遇到不支持 UDP 的代理节点时可能继续向下匹配，因此必须检查最终出口。
TUN 解决的是入口接管，无法凭空给不支持 UDP 的服务端增加能力。反过来，服务端支持 UDP，也不能修复应用没有进入客户端的问题。TCP 端口测试、HTTP 下载和网页测速只能验证各自测试过的路径。
第三步：做一个两节点、两网络的对照
| 测试 | 保持不变 | 改变 |
|---|---|---|
| A | 原网络、同一应用与场景 | 使用当前节点 |
| B | 原网络、同一应用与场景 | 换已知支持 UDP 的节点 |
| C | B 的节点、同一应用与场景 | 换手机热点或另一可信网络 |
B 恢复而 A 失败时，优先查原节点与它的出口；C 恢复而 B 失败时，优先查原接入网络。结果只用于定位范围，仍可能受服务负载和临时故障影响。不要在共享网络里随意开放大段端口，也不要通过关闭整个系统防火墙来“永久修复”。受管理设备的阻断应交由管理员按应用和日志核实。
怎样才算修好，以及如何恢复
- 回到日常规则模式，实际测试双方收发声音、持续通话和重新入会；游戏则验证匹配及对局，而非只看登录页。
- 确认国内网站、局域网和其他应用没有受到新 TUN 或规则的影响。
- 若问题未改善，撤销本轮临时规则或新启用的接管项，保留时间、版本、网络类型和脱敏错误给支持人员。不要公开通话参与者、完整 IP 或认证信息。