网页能打开，语音却连不上：UDP 转发要查哪几层
网页能打开而语音连不上，应先确认通话软件的媒体流量有没有进入代理，再检查 UDP 转发、返回数据和应用自己的中继方式。网页加载成功，不能证明语音使用的整条路径可用；完全没声音，也可能只是麦克风权限或播放设备选错。
本文针对“文字聊天正常、通话卡在连接中、只能听见一边”等问题，给出一套能留下证据的排查顺序。不同软件的媒体协议不同，不能把所有语音故障都归为 UDP 被阻断。
先判断卡在登录、建连还是播放
先用应用自带的设备检测检查麦克风、扬声器与静音状态，再观察通话过程。记录具体表现，比连续换几个节点更有帮助。
| 实际表现 | 优先核对 | 暂时不能下的结论 |
|---|---|---|
| 登录、联系人和文字消息也失败 | 登录请求、账号状态、HTTPS 错误 | 不能直接判为 UDP 故障 |
| 能拨号，一直显示连接中 | 媒体连接方式、代理接入、中继日志 | 不能仅凭等待时间判断服务端拒绝 |
| 一边有声音，另一边没有 | 两端权限、发送与接收统计 | 单向无声不能直接定位到某个节点 |
| 媒体接收计数增长，却听不见 | 输出设备、音量、应用播放状态 | 收到数据不等于音频已经正常播放 |
如果同时出现证书或握手错误，可先看证书与 TLS 报错排查，避免把登录层的问题带入媒体诊断。
第一层：媒体有没有进入代理
分清接入方式和分流规则
系统代理、应用内 SOCKS 配置、TUN 或 VPN 接管的流量范围可能不同。先核对当前软件实际采用哪种方式，再看规则把这条连接送到了哪里。网页请求命中代理，只能证明那次网页请求的路径；不能替另一款应用或它的媒体子进程作证。
可以打开代理日志，分别记录启动应用、发起通话、结束通话时出现的连接。没有匹配日志时，先确认日志是否包含 UDP、应用是否另有子进程，以及媒体是否采用了其他传输。模式概念可参考规则、全局与 TUN 的区别。
SOCKS 的 TCP 成功不代表 UDP 成功
SOCKS5 把建立 TCP 连接的 CONNECT 和建立 UDP 转发关联的 UDP ASSOCIATE 定义为不同命令。后者会返回 UDP 中继地址与端口，而且关联随控制它的 TCP 连接结束而终止。因此，测通 SOCKS 的 TCP 端口，或成功代理一次网页，都不足以验证 UDP 转发。依据：RFC 1928
不要拿配置中的 SOCKS TCP 监听端口，直接当作可以任意发送裸 UDP 数据的测试目标。应核对客户端是否发起了正确的关联，以及服务端是否支持这一用途。
第二层：配置和服务是否都支持该路径
客户端开关、使用的出站配置和远端能力要一起核对。以 sing-box 的 SOCKS 出站为例，官方文档说明 network 可以限制为 tcp 或 udp，默认两者均启用。这只是该配置项的含义，不能推导出订阅中的每个出站、每家服务或其他客户端都支持 UDP。依据：SOCKS 出站文档
看到“UDP over TCP”也不要直接打开。它是额外的封装方式；例如 SagerNet 的实现需要兼容端点，并不是 SOCKS5 自动附带的通用能力。先确认两端文档，再改配置，不能用一个开关替代能力核验。依据：UDP over TCP 说明
对采用 WebRTC 的应用，还要区分直接媒体连接与中继连接。相关标准规定了 ICE、TURN 以及受限环境中的 TCP/TLS 中继支持要求；实际应用是否部署并成功选择可用中继，仍要看它的实现与诊断信息。“某条 UDP 路径不可用”和“所有通话必然失败”不是同一结论。依据：RFC 8835
第三层：用实际收发记录缩小范围
Windows 上能观察什么
在任务管理器中确认应用或媒体子进程的进程 ID，再在 PowerShell 中查询：
$appProcessId = 1234
Get-NetUDPEndpoint -OwningProcess $appProcessId |
Select-Object LocalAddress, LocalPort, OwningProcess
1234 是占位值，需要替换为自己的进程 ID。这个只读命令显示该进程绑定的本地 UDP 端点，不显示远端目标，也不能证明数据经过代理或已收到回复。没有结果时，还可能是查询时机、进程选择或应用采用其他传输所致。依据：Get-NetUDPEndpoint
另外，Test-NetConnection -Port 测试的是 TCP 端口。即使某个通话服务使用相同数字的 UDP 端口，TCP 测试通过也不代表该 UDP 服务可达。依据：Test-NetConnection 参数说明
一次只改变一个条件
- 保持同一应用、对端和设备，记录当前接入方式与出站名称。
- 如有应用自带的通话统计，记录媒体发送、接收计数及连接类型；没有这些功能时，不编造判断依据。
- 发起一次短通话，对照代理日志与应用统计的时间，区分“发现连接”“发出数据”“收到返回”。
- 只调整一个已获支持的出站或接入设置，结束旧通话后重新建立，再记录结果。
只有发送记录而没有返回，提示需要继续检查中继、路径和对端，但不足以锁定故障位置。如果双向计数都在增长，下一步应回到应用、音频设备或解码状态，而不是继续用端口测试解释所有现象。
可填写下面的记录，提交给服务支持时保留必要信息，隐藏账号与连接凭据：
| 时间与时区 | 应用及版本 | 接入方式／出站 | 通话表现 | 发送／接收变化 | 日志错误 |
|---|---|---|---|---|---|
| 待填写 | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
常见问题
需要关闭整个防火墙或禁用 WebRTC 吗？
不要把这两项作为通用修复。先检查应用所需权限和具体拦截记录；WebRTC 地址隐私检查则是另一类问题，可参考WebRTC 地址泄漏检查。关闭某项功能后现象变化，也仍需确认它改变了哪条媒体路径。
已经能通话，只是断断续续，还继续查端口吗？
此时应进一步观察通话期间的延迟变化、丢包与应用统计，并与音频设备问题分开。一次连通只说明当时具备通信条件，不是持续质量的保证。
资料核对日期：2026-10-16。文中命令用于解释观察方法，未声称对任何服务完成实测。
评论