ADB 与 Android 模拟器在 VPN 后失效：三条路径

连上办公 VPN 后，Android Studio 丢失正在运行的模拟器，adb start-server 卡住，Wi-Fi 上的真机也从设备列表消失。看起来像一条隧道挡住了一个产品。实际上有三条互不相同的路径以三种方式失效：adb 设备发现、模拟器的虚拟网络和主机解析器。隧道通常只掌管最后一条，而且往往只掌管其中一部分。

三个套接字，三个归属

adb 服务端在主机上监听 5037 端口，通过 USB 或 TCP 与设备通信，并用 mDNS 做网络发现。模拟器运行在自己的虚拟路由器之后：客户机是 10.0.2.15，网关是 10.0.2.2，DNS 服务器是 10.0.2.3，模拟器进程把这一切转换为主机套接字。主机解析器是 VPN 客户端安装 DNS 与搜索域的地方。

这种分离解释了为什么 某个修复对一个工具有效、对另一个工具无效。改动主机解析器的客户端，会让正在运行的模拟器进程保留启动时读到的解析器状态。过滤 multicast 的客户端不动 DNS 就破坏了发现。过滤虚拟网卡的客户端会在主机浏览器仍然正常时拒绝模拟器。每种症状的原因都不同，所以先确定失效的路径，再改任何设置。

从 adb 能看到的东西开始

在碰 VPN 之前先运行 adb devices。列表为空是传输问题，不是路由问题，任何隧道设置都修不好服务端从未枚举到的设备。干净地重启服务端：先 adb kill-server 再 adb start-server，并读取输出看它占用了哪个端口。如果启动本身卡住，在被过滤 multicast 的网络里，mDNS 发现是最常见的嫌疑；有文档的绕行办法是关闭发现后再启动服务端：

ADB_MDNS_OPENSCREEN=0 adb start-server
adb devices

对真机来说 USB 是最短的路径。如果必须用 TCP，先用 adb tcpip 5555 把设备切到监听模式，再连接设备的地址和端口 adb connect 192.0.2.10:5555。5037 是主机服务端的端口，不是设备监听的端口。

从内部测试模拟器

模拟器从 10.0.2.3 响应 DNS，而那个解析器由主机进程喂养。VPN 客户端改动主机解析器时，模拟器可能继承它；当客户端过滤模拟器进程，或模拟器启动后主机网卡列表发生变化时，它就无法继承。用同一个 shell 里的数字目标和名字把两者分开。adb shell ping -c 2 10.0.2.2 证明虚拟网络能到达主机一侧。之后的名称查询会告诉你解析是否越过了边界。

然后在主机上做同样的名称查询。主机能解析而模拟器不能，说明断点在主机解析器与模拟器虚拟网络之间，而不在隧道里。两者都失败，说明该看主机解析器。连上 VPN 后重启模拟器值得试一次，因为有些客户端会安装运行中的模拟器进程不会拾取的解析器状态。

检查主机解析器与客户端过滤

全隧道客户端会用自己的解析器替换主机解析器，split-DNS 客户端会添加搜索域和条件转发器。内部名称常常依赖那套 split-DNS 配置，所以要看连接期间主机用的是什么：解析器地址、搜索域，以及内部区域是否被路由到公司 DNS。只回答公网名称、不回答内部名称的解析器是策略问题，不是坏掉的隧道。

有些企业客户端还会拦下虚拟网卡的流量。对过滤驱动来说模拟器看起来就像虚拟网卡，于是主机可以完全正常，而策略拒绝模拟器。那套策略在工作站上看不见，靠猜测代理设置也不会暴露它。如果主机能解析、模拟器无论怎么设置都被挡住，正确的升级方向是负责客户端策略的团队。

检查顺序与每个结果的含义

从上到下逐行检查，在第一个失败的行停下。每个结果指向不同的归属，而且没有一条能靠重装 Android Studio 解决。

只有最后两行才是通常意义上的 VPN 问题，而只有最后一行涉及 DNS 内容。adb 文档 覆盖了服务端端口和这里提到的环境变量，足够在测试其余部分时让传输一侧保持诚实。