手机的 VPN 会覆盖热点上的笔记本吗

手机的浏览器显示的是另一个国家的地址，而连在它热点上的笔记本显示的仍是移动运营商。两个观察都没有错，人们看到的矛盾来自一个假设：共享上网连接就等于共享隧道。三个条件决定热点流量是否进入手机的 VPN，而其中只有一个与手机的设置有关。在寻找可能并不存在的共享功能之前，先把这三条逐一走一遍。

热点的转发究竟做了什么

网络共享让笔记本通过手机的移动接口获得一条通往互联网的路径。手机转发这些数据包，并且通常在它们离开时转换笔记本的地址。这是转发功能，而转发并不等于把流量接入隧道。

转发出去的数据包是否随后进入手机的 VPN，取决于 VPN 应用如何安装自己的路由和规则。只捕获手机本机产生流量的应用，不会看到内核替已连接客户端转发的数据包。

这就是两种观察能够如此自然地并存的原因。手机自己的浏览器走隧道，笔记本的数据包走转发路径，两块屏幕上都没有任何东西在骗你。两台设备只是没有向同一个接口问同一个问题。一旦看清这个分界，“我的笔记本为什么不受保护”就不再是缺陷，而是一个设计问题。

条件一：手机运行的是哪种隧道

先确认 VPN 在手机上的作用范围。整机隧道、按应用划分的隧道、只针对浏览器的代理是三件不同的事，只有第一种才有机会覆盖被转发的流量。要看服务商对应用捕获范围的说明，而不是状态栏上的图标。

再看服务商对网络共享的说明。有些会明确写出普通热点流量不在隧道之内，对于从未承诺要做路由器的消费级服务来说，这是诚实的回答。 Proton VPN 的 Android 热点指南 就是这种区别的一个公开例子；真正对你设备有约束力的是你自己服务商的文档。

状态栏里的 VPN 图标只说明手机有隧道，并不说明这条隧道覆盖哪些接口，而大部分困惑正住在这道缝隙里。

条件二：网络共享是否被纳入

即便是整机隧道，也可能在设计上排除被转发的流量，因为应用的路由规则是写给本机生成的报文。要让已连接的客户端也被纳入，通常需要服务商明确支持，或者需要一台已 root、带自定义规则的设备，而多数人不应尝试后者。

从 Wi-Fi 换成 USB 并不改变这一点。网络共享子系统支持多种承载方式，但承载方式不是路由决策。一根线只让链路更稳定，对隧道覆盖没有任何帮助，所以“直接用 USB 就行”回答的是另一个问题。

那些清空防火墙规则、假定特定接口名的旧配方并不是可移植的说明。它们是为某一台设备、某一版 ROM 和某一年写的，套到今天的手机上，更可能弄坏网络共享，而不是扩展隧道。

条件三：目的地需要谁的身份

这才是通常决定设计的条件，而且它与热点毫无关系。如果笔记本要访问雇主的网络，真正重要的身份属于笔记本，手机上消费级的 VPN 无法提供。

ip -brief addr show
curl -sS https://ifconfig.me/ip
dig +short myip.opendns.com @resolver1.opendns.com

这些命令要在笔记本上执行，而不是在手机上，因为问题是你关心的那台设备让目的地看到了什么。手机报告的公共地址回答的是关于手机的问题。

即便笔记本给出的结果一致，那也是有限的证据。域名解析、其他应用以及隧道失效时的行为，都属于你正在测试覆盖范围的那台设备，一次 HTTP 请求描述不了其中任何一项。请测试你真正在意的应用，然后故意断开隧道再测一次。

那么该做什么，按投入从小到大

成本最低的正确做法是在笔记本上运行 VPN。把它接到热点，让手机提供底层的移动连接，从需要身份的那台设备建立隧道。这对雇主 VPN 同样有效，而它正是最重要的场景。

如果设备完全无法运行 VPN 客户端，就去找明确支持共享的网关，或一台能终结隧道的便携路由器。请阅读它针对真实平台的文档，而不是假定某个热点功能就是那个网关。

如果两者都不可行，就接受这个限制，而不是用一套你维护不了的配方绕过去。手机的 VPN 覆盖手机；笔记本需要自己的路径，事先知道这一点，比花一下午折腾接口更值。把这套安排记录下来，好让下一个人在事故中不必重新发现它。团队 wiki 里写一行就够了。