开了 VPN 网页能看，语音通话为什么连不上

开了 VPN 后网页正常、语音或视频通话却连不上，应先检查音视频连接路径和 UDP 转发，再判断是不是节点故障。网页能打开，只能证明当次网页请求可达，不能证明通话所需的连接也畅通。

网页加载和通话连接是两件事

一些浏览器通话使用 WebRTC。它需要交换连接信息，再寻找双方或媒体服务器之间可用的路径。MDN 连接说明指出，候选连接通常优先使用 UDP；受限制时可能尝试 TCP，但并非所有浏览器都支持这种后备方式。UDP 适合实时传输，却也可能在某一段网络上被限制。

因此，登录成功、能看到会议列表、能收到文字消息，都不足以证明音视频通道已经建立。网页采用什么传输方式，也不能一概归为 TCP。

要分清两层：VPN 或代理怎样连接服务器，以及它能否承载应用发出的 UDP 数据。界面显示“TCP”或“UDP”，需要结合具体字段解释，不能直接据此判断通话是否可用。

例如，Mihomo 节点通用字段把 udp 定义为是否允许 UDP 通过代理；文档列出的默认值及例外依协议而异。这说明“节点能连接”与“允许 UDP 转发”需要分别核对。即使开启该选项，也仍要确认服务端支持，不能把开关当作保证。

先查看通话应用的麦克风、摄像头权限和设备选择，用应用自带检查确认设备可用。随后核对当前客户端是否覆盖该应用，以及节点文档是否支持所需转发。

把现象写具体：是完全无法加入、只有一方听不到，还是连接后反复中断？这些现象应分别记录。若应用连麦克风都未识别，先处理权限和设备；若已经建立通话但声音断续，则继续检查传输质量，不能把所有故障都归因于 UDP 被禁用。

保留原配置，只改变一个条件：固定应用和网络换一个明确支持相关能力的节点；再固定节点，换到另一条可使用的网络。记录时间、连接阶段和错误提示。不要同时改 DNS、协议、规则和节点，否则难以解释哪个变化起了作用。

MDN 协议说明介绍，TURN 中继可以在直接连接受限制时转发数据。不过，中继地址也必须可达，是否提供中继取决于应用自身。

若只能加载界面却一直停在连接阶段，可把应用版本、客户端类型和脱敏错误交给服务支持排查。结论应限定为哪种组合出现问题，避免仅凭一次失败就认定所有节点不可用。