通过 USB 为 Android 做反向网络共享：命令、检查、回滚

反向网络共享把手机的流量移到一台计算机上，并从这台计算机的连接出去。只靠一根 USB 线做不到：手机需要一个接管其路由的捕获服务，计算机需要一个把数据包继续向前转发的继电器。这条通路有四跳：应用、手机端捕获、USB 中继和主机出口，每一跳的负责方都不同。本操作手册搭建这条通路，把主机 VPN 放在应有的位置，并在你相信结果之前逐跳检查。

动手之前先把各跳画成图

每一跳都执行自己的策略，所以一端能用并不说明另一端如何。应用选择目的地址和解析器，捕获服务决定哪些流量进入中继，中继把它转发进主机套接字，而主机的路由与 VPN 决定目的端最终看到的地址。

同一时刻只能有一个 VPN 服务客户端占据手机的捕获角色，所以第二个普通 VPN 应用不会叠加在中继之上。如果 VPN 属于计算机，捕获服务就是通往这台计算机的接入环节，而不是远端隧道已经保护了结果的证据。

先准备好中继，再碰手机

Gnirehtet 是该架构有据可查的示例：手机上无需 root 的 VPN 服务客户端，加上主机上通过 ADB 承载的中继，支持 IPv4 上的 TCP 与 UDP。其仓库也说明该项目不再积极维护，因此请把它当作参考设计和实验室里可用的工具，而不是可在受管设备群中标准化推广的受支持产品。

adb devices
adb shell getprop ro.build.version.release
gnirehtet run

先运行 adb devices。没有接受主机调试密钥的手机会被报告为未授权，在设备上的提示被接受之前中继不会连接。gnirehtet run 会安装客户端、启动中继并激活捕获；在把步骤拆开的版本中，请改用文档给出的 install、relay 和 start 子命令。

ADB 访问是设备控制关系，不是网络设置。只授权你控制的计算机，并计划在任务结束后撤销该授权。

把主机 VPN 放回通路

中继是主机上的普通进程，所以它后续的连接遵循主机的路由表。全隧道配置会承载它们；分流隧道可能不会。如果主机 VPN 使用按应用控制，请把中继二进制加入允许集合，否则浏览器看起来受保护时中继仍在走物理接口。

ip route get 1.1.1.1
curl -4 https://ifconfig.me
sudo ss -tnp | grep -i relay

在连接主机 VPN 之前和之后各运行前两条命令。如果地址没有变化，那么无论客户端窗口怎么说，中继都不在隧道上。仅私网隧道还会让公网目的走主机的常规出口，这看起来像泄漏，但正是你配置的策略。

经中继的流量在主机上解析 DNS，因此主机的解析器决定哪台服务器看到域名。手机上的私有 DNS 设置不会随中继传递，手机侧解析器测试也无法描述主机的查询。

逐跳单独验证

按此顺序做三项检查：手机能到达中继，中继在主机策略下能到达目的，应用能正确解析并使用该目的。第一次失败就停下，而不是刷新页面靠猜。

adb shell dumpsys connectivity | grep -i -A3 vpn
adb logcat -s GnirehtetRelay:V Gnirehtet:V

连接性转储中的一条 VPN 网络记录 说明捕获服务已启用；中继自身的日志说明流是否到达。两者之一缺失就能干净地把问题分开：没有捕获属于手机侧，没有流属于主机侧。

主机上能用的浏览器只证明主机浏览器的路径，不证明中继进程的路径。比较两者各自报告的地址，并同时测试私有资源和公网页面，因为仅私网隧道可能只路由其中一个。

拆卸并选定失败时的行为

回滚是操作手册的一部分。停止并移除中继，卸载捕获客户端，并在任务结束时从手机的开发者选项里撤销主机的调试授权。

gnirehtet stop
gnirehtet uninstall
adb kill-server

决定中继消失时手机该做什么。没有明确选择时它可能回落到移动数据，把你本想路由的流量泄漏出去，因此要刻意设置阻断连接的行为或 VPN 策略，并在依赖它之前测试拆卸。

记录被授权的主机、中继版本、主机隧道策略和拆卸步骤。正是这份记录让下一次反向网络共享配置可复现，而不是又花一个下午重新摸索。