NetGuard 的 SOCKS 模式覆盖 TCP，而非所有协议

NetGuard 占用 Android 的 VPN 接口来过滤流量，并能把受支持的连接交给 SOCKS 端点。这两个事实常被读成「手机处于 VPN 之中」，而这一结论并不被该机制支持。过滤器看见的是数据包；代理只看见实际交给它的连接。这两种说法之间，正是整个覆盖范围问题所在。

上游项目的 FAQ 同时记录了仅支持单一服务的限制与 SOCKS 选项。选项的存在并不能证明每个被放行的数据包都会使用它，覆盖范围的疑问正来自这个缺口。

同一个应用内的两条转发路径

实现的 TCP 一侧包含 SOCKS 连接处理，因此被放行的 TCP 连接可以与代理协商并经它承载。UDP 一侧有独立的套接字路径，其收发处理并不依赖那次 TCP 协商。因此，过滤器放行的数据报可以完全不经过代理就到达普通网络。这并非应用的缺陷；它只是这两条路径所实现的内容。

这一区别有一个常被两面说错的后果。把每个 UDP 数据包都称为泄漏，忽视了阻断规则，因为被拒绝的数据报根本不会发出。把整个安排称为 VPN，忽视了被放行的直连路径，因为确有一部分流量不经代理流出。你拥有的是一台带部分代理的已过滤设备，诚实的描述是矩阵，而不是标签。

声称支持 UDP 的 SOCKS 服务器，并不会给你手机上的应用加上相应的客户端处理。协议的纸面特性与已安装版本的行为是两个不同的话题，只有后者描述你的流量。

检查你实际运行的版本与配置，然后测试一条无害的数据报流，观察它是否出现在代理处。除此之外都只是从功能清单推断出来的结论，而功能清单描述的是意图，不是代码路径。

域名解析为矩阵增添了它自己的分支。本地 DNS 转发器、普通 UDP 查询、由代理自己解析的目标主机名，以及浏览器里的加密解析器，是四种不同的安排。它们的差别在于谁看见查询、由哪条网络路径承载，把它们混在一起只会得出对其他几种毫无证明力的测试。

有意识地决定你想要哪一种。若要求是名字经隧道解析，仅靠浏览器设置无法做到；而自行解析主机名的代理，只会改变它真正处理的那些连接的答案。

明文 SOCKS 并不是手机到代理之间的加密链路。如果端点是通过另一条受保护的路径抵达的，就应说明那条路径及其失败策略，因为回落到开放网络会在没有警告的情况下把私密安排变成公开安排。代理自身的认证同样重要：共享设备上开放的监听端口，是一项无人问责的服务。

跨配置文件的安排也值得同样审视。工作配置文件的 VPN 只保护走它那条路径的流量，而个人配置文件的防火墙与工作隧道并存，并不能证明防火墙的后续连接能抵达那条隧道。应当验证可达性与认证，而不是假定两个配置文件会协作。

对于获授权的评估，请挑选能代表你关心的每一类的无害示例：必需的 TCP、被放行的 UDP，以及两种地址族下的 DNS。对每一项记录它是被代理、被阻断还是被直接发送。那一张表就是交付物，它比一张页面加载成功的截图有用得多。

若要求是所有选定的应用流量都必须经过远程隧道，就选择明确支持组合式过滤与隧道化的实现。仅含 TCP 代理的组合在更窄的任务中仍然有用，前提是其余流量被有意处理，而不是被遗忘。