Meta Quest VR 开机无法自动重连 WiFi 的解决方法
最近在折腾 Meta Quest 2 / Quest 3 时，遇到一个非常典型的问题：
明明 WiFi 密码正确，信号也正常，但每次开机都不会自动重连，甚至显示'受限网络'或'无互联网连接'。
这个问题在国内网络环境下非常普遍，并不是设备损坏，而是系统机制导致。
本文从底层原理讲清楚，并给出稳定可用的解决方案。
一、问题根源分析
Meta Quest 系列基于 Android 系统。
Android 在连接 WiFi 后，会自动访问一个特定 URL 用于检测网络连通性，例如：
connectivitycheck.gstatic.com
它会做一次'握手验证'：
- 能访问成功 → 判定网络正常
- 访问失败 → 判定'受限网络'或'无互联网'
在国内网络环境下，这个检测请求往往无法成功返回正确响应。
于是系统得出结论：
这个 WiFi 是'坏的'
因此系统不会在开机时主动重连这个网络。
⚠️ 注意：这和信号强弱、密码是否正确无关，是系统级判断机制问题。
二、最彻底的解决方案：使用 ADB 永久禁用网络检测
这是技术型解决方案，也是最稳定的方法。
核心思路：告诉 Android：别再做网络连通性检测。
第一步：准备工作
你需要：
- 一台电脑
- 安装 ADB 工具 或 SideQuest
- USB 数据线
第二步：连接设备
- 用数据线连接 Quest 2 / Quest 3
- 戴上头显
- 看到提示时点击：允许 USB 调试
第三步：执行关键命令
打开命令行（终端），输入：
adb shell settings put global captive_portal_mode 0
这条命令的含义是：关闭 Android 的网络连通性检测机制。
三、关于 daemon 提示的解释
很多人执行命令后看到：
daemon not running; starting now at tcp:5037 daemon started successfully
这是什么意思？解释如下：
| 提示 | 含义 |
|---|---|
| daemon not running | ADB 后台服务未启动 |
| starting now | 正在启动 |
| started successfully | 启动成功 |
如果没有出现 error: device not found，而是直接回到命令行输入界面，通常说明命令执行成功。
四、如何确认是否真的生效？
1️⃣ 检查设备是否连接成功
输入：
adb devices
可能出现三种情况：
情况一（正常）：
XXXXXXXX device
说明连接成功。
情况二：
XXXXXXXX unauthorized
说明你需要：戴上头显 → 点击'允许 USB 调试'。
情况三：什么都没有显示
说明：
- 数据线有问题
- 驱动未安装
- ADB 未识别设备
2️⃣ 验证参数是否写入成功
输入：
adb shell settings get global captive_portal_mode
如果返回：
0
✅ 说明彻底成功。以后 Quest 开机看到这个 WiFi 会直接'盲连'，不会再判断外网是否可达。
如果返回 1 或 null，说明命令未写入成功，需要在设备处于 device 状态下重新执行。
五、替代方案：使用热点或加速器做初始引导
如果暂时无法使用 ADB，也可以采用'网络引导'方式。
原理是：让网络检测通过一次。
操作方式
- 在电脑安装第三方加速工具
- 开启 Quest 专用加速功能
- 按提示修改 IP 地址和 DNS
当 DNS 指向加速网关后，系统检测会显示：已连接。之后开机自动重连问题通常会消失。
六、底层机制总结
Android 的 WiFi 判断逻辑大致是：
连接 WiFi → 访问检测服务器 → 判断是否返回预期响应 → 标记网络状态
我们执行的命令：
adb shell settings put global captive_portal_mode 0
本质是关闭 Captive Portal Detection，也就是'门户检测机制'。系统不再关心外网是否可达，只要连上路由器就视为正常网络。
七、是否有副作用？
技术层面说明：
- 不影响正常使用
- 不影响下载
- 不影响账号登录
- 只是跳过连通性验证
如果未来需要恢复，可以执行：
adb shell settings put global captive_portal_mode 1
八、结论
Meta Quest 系列无法自动重连 WiFi，本质不是设备问题，而是 Android 网络连通性检测机制与当前网络环境不匹配。
最稳定方案： ✔ 使用 ADB 关闭 captive portal 检测 ✔ 验证参数写入成功
执行一次后长期有效。
这类问题本质都是系统机制问题，不必怀疑设备硬件。技术解决，逻辑清晰即可。