通过 Tor 的 SOCKS 端口发送 UDP：哪些流量过不去

把应用指向 SOCKS 端口，浏览器能工作，游戏却会失败，原因不在配置。SOCKS5 定义了几条命令，而实现可以只支持其中一部分；Tor 的接口接受流式连接和名称解析，不接受任意数据报转发。发送 UDP 并指望代理转发的客户端，实际上是在请求一条服务器没有实现的命令。下面的步骤几分钟内就能验证这一点，然后选出真正可行的传输方式。

先看清应用实际发送的是什么

从识别传输方式入手，而不是协议名称。语音客户端可能用 HTTPS 登录，再用 UDP 承载媒体；游戏可能用 TCP 认证，再用 UDP 对战；文件传输可能用 TCP 控制、用 UDP 发现。前两种行为在登录成功而通话仍然失败之前看起来完全一样，所以“连上了”并不能证明整个应用可用。有些客户端还会自行从 UDP 回退到 TCP，这会让部分可用的会话看起来像网络不稳定，而不是传输被封锁。

把失败那部分的目标端口和传输方式写下来。这一行就决定了代理究竟能不能帮上忙。

Tor 的 SOCKS 接口会接受什么

Tor 实现了面向流式连接的 SOCKS5 CONNECT 命令，以及用于解析名称的扩展命令，所以浏览器可以原样通过。UDP ASSOCIATE 是让客户端把数据报交给代理转发的命令，它不在 Tor 提供的范围之内。扩展的文档就在项目的 SOCKS 扩展规范 里，篇幅很短。缺少数据报命令是有意为之：转发任意 UDP 会让网络承担它从未被设计承担的转发角色。

WireGuard 的答案也是一样：它按设计就是 UDP，没有 TCP 回退路径。不存在把 WireGuard 指向 SOCKS 端口的受支持路径，任何相反的说法都是自带信任与维护故事的包装层，而不是这两个工具中任何一个的功能。

OpenVPN 是部分例外，因为它可以配置成通过 TCP 建立隧道，并且理解 SOCKS 代理选项。这仍然需要一台为 TCP 配置的服务器，以及对性能与指纹后果做出有意识的选择，所以它是设计取舍，不是兼容性修复。

按顺序执行检查

先确认代理对流量有效，这样后面的失败才不会被归咎于端口不可达。然后确认应用自身的流量，并观察它实际打开了哪些套接字。

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

第一条命令成功、第二条中出现已建立的流，说明代理路径按设计工作。第三条命令查找属于应用的本地数据报套接字；如果客户端打开了一个并直接发往远端地址，它就从未咨询过代理，任何代理设置都改变不了这一点。如果第一步就失败，先停下来修好代理路径，再去排查应用，因为两个故障同时存在只会产生一份没人能据此行动的报告。

回滚并选对工具

删除所有把 UDP 客户端指向 SOCKS 端口的代理环境变量或按应用设置的代理配置；留着它们会让后续测试变得含糊。从副本恢复先前的配置，重启应用，并确认原有行为已经恢复，这样对比才干净。没有验证过的回滚，只是希望状态变了而已。

对于必须保持 UDP 的传输，VPN 通常更合适：它直接承载应用的数据包，不必让应用去说代理协议，代价是 完全不同的匿名性属性。让每个工具只做它文档里写明的事，把两者之间的任何桥接都当作需要单独评审的独立系统。在最终报告里写明哪一层承载哪种传输，下一个人就不必用另一个应用重新发现同一条边界。