新接入热点设备卡在获取 IP 不是 VPN 故障

手机加入热点，停在「正在获取 IP 地址」，最后放弃。最自然的结论是手机的 VPN 干扰了 DNS，于是人们开始修改解析器和附加规则。这是错误的环节。客户端从未拿到本地地址，而没有地址就没有网关、没有解析器、也没有任何可转发的东西，所以主机手机上的任何 VPN 设置都无法解释这次失败。关联、本地地址分配和后续转发是三个彼此独立的环节，只有最后一个才涉及隧道。

三个环节，以及你卡在哪一个

首先是关联：客户端加入热点的无线网络。密码错误、WPA3 不匹配或射频兼容性问题都会在这里失败，客户端通常会直接报出来。其次是地址分配：对 IPv4 而言，客户端请求租约并获得地址和本地网关设置；而 IPv6 通常使用路由通告而不是 DHCP，正如 AOSP 关于网络共享的文档所述。第三是向外访问：主机手机把允许通过的流量转发给它选定的上游路径，那条路径可能是它的隧道，也可能不是。

客户端上的提示语会告诉你所处环节。卡在获取地址是第二个环节，此时还没有任何数据包发往互联网。已经连上、有地址却什么都加载不出来，是第三个环节，路由、名称和隧道覆盖三者都要排查。客户端还卡在第二个环节时就去诊断第三个环节，正是把五分钟的租约问题变成一下午改 DNS 的原因。

误区：路由模式的 VPN 会把本地 DHCP 变成远程请求

路由模式的隧道只为它选定的目标搬运 IP 数据包。DHCP 发现是热点自身网段上的广播，手机上的网络共享服务在本地应答，所以隧道开着的时候客户端照样能拿到地址。只有刻意做成桥接或中继的设计才会把这次交互送到别处，而那是另一种结构，失败特征也完全不同。

所以「VPN 服务器不回应 DHCP」不是诊断，而是模型错误。本地的中间人就在手机上。它若停止应答，原因都在本地：网络共享服务、客户端数量上限、租约池，或者一台从未正确完成关联的客户端。这些都不在隧道的远端。

已有客户端能上网究竟证明了什么

如果一台早已连上的笔记本还能用，而新手机不能，说明热点和上游路径大体上是通的。这个对比有用，但不能证明是哪一部分出错，因为那台可用的客户端也许只是握着变更前的租约并悄悄续期。

既然在场，有两个本地限制值得一查。热点提供的租约池有限，客户端数量也可配置，所以一台加入后休眠的设备可能仍占着地址，而新设备在等。另外，记着其他网络静态配置的客户端根本不会请求租约，这从外面看一模一样，而它要在客户端上改，不是在手机上改。

把对比留在本地并且可回退

在策略允许的设备上，让热点和客户端其余部分保持不变，分别在隧道关闭和开启时对比一次新客户端接入。随后记录手机与客户端的版本、所选配置文件和确切失败的环节。在受管理的手机上，请申请获批的对比，而不是为了测试干净就关掉管控。

稳定的、依赖隧道的租约失败，是关于本地策略或实现之间相互影响的可用证据。它不是清空设备上所有转发和 NAT 规则的许可证。那些规则保护着无关流量，而宽泛地放行转发并不能解释本地 DHCP 服务为何停止应答。

也不要用猜出来的静态地址去掩盖缺失的租约。有意的静态配置需要真实的子网、网关、地址分配方案和冲突检查。改客户端的 DNS 一样都给不了，还会把同样的故障留给下一台设备。

租约不能证明什么

拿到地址只证明被本地网络接纳，并不证明受到手机隧道的保护。客户端有了租约之后，要单独评估下行路径：客户端的流量是否真的经过手机、解析是否在你预期的位置完成、对外地址是否与你设想的出口一致？这些是第三个环节的问题，值得单独测试，而不是折进接入那一步。

按顺序处理这三个环节，故障就不再四处漂移。卡在获取地址的客户端属于本地网络共享问题；有地址但打不开页面的客户端属于转发或名称问题；能打开页面但出口不对的客户端属于隧道覆盖问题。把它们分开，就完成了排查的大部分工作。