SOCKS 代理能加载消息，但通话会失败
结合 Dante 手册和 SOCKS5 的 UDP 要求，说明为什么可用的 TCP 通路并不能证明应用的通话流量也得到支持。
文字消息可以通过 SOCKS 代理送达，但语音通话始终无法接通。代理未必已经完全损坏。应用可能为通话使用了另一种传输方式。
一次成功的 TCP 请求只能证明该操作存在 TCP 通路。SOCKS5 还定义了 UDP 关联，但客户端、SOCKS 服务、网络规则和应用设置都必须支持预期的 UDP 路由。
不只是 TCP 监听
Dante 手册把协议规则和命令规则分开，其中包括 connect、udpassociate 和 udpreply。只允许你已测试过的那条 TCP 连接的规则，并不会建立所需的 UDP 权限。
UDP 关联还涉及中继端点和返回流量。防火墙和地址转换必须放行那条真实通路。打开 SOCKS 的 TCP 监听并不等于让其 UDP 中继可达。
请检查应用当前的代理文档和设置。不同版本对消息、媒体和通话的处理方式可能不同。不应把针对旧客户端的论坛配方当作证据，来断言当前每个客户端都通过 SOCKS 转发通话。
不要把开放所有 UDP 端口当作首选诊断手段。先确定中继行为和预期的客户端范围，再应用合适的受限网络策略。同样，关闭“通话走代理”设置可能让通话通过直连成功，这改变的是对外通路，而不是修复被代理的通路。
按操作分别记录结果：消息、媒体传输和通话。单个可用请求或浏览器 IP 发生变化，都不能证明另一个应用的每个部分都共用同一个代理出口。