Quest 3网络问题爬坑记录

上一篇文章里，我已经在飞牛 NAS 上用 Docker 完美部署了 Macvlan 旁路由，实现了全屋网络的无感智能分流。

今天本来兴冲冲地准备给 Quest 3 配置好网关，直接体验完整的虚拟现实生态，结果却一头撞上了一个堪称经典的网络玄学问题。

按照常规操作，在头显里把网关和 DNS 指向旁路由 IP 后，打开 Quest 3 自带的浏览器，测试访问全球网络毫无压力，非常丝滑。但是切回主界面，系统却无情地提示需要登录到网络，Wi-Fi 图标显示未连接。更抓狂的是，自带的商店和所有 Meta 第一方 App 一直在无限转圈，彻底罢工。

遇到Bug不可怕，可怕的是表现不一致。浏览器能通，App 却死活不通，这种精神分裂的网络状态，说明我们的分流策略在更底层被绕过了。顺着这个思路找问题，改了三处终于解决，今天就给大家复盘一下完整的解决过程。

DNS劫持

连上 WIFI ，就看到了需要登录到网络提示，很明显了是经典的网络探针劫持。

为了提升解析速度，我的旁路由开启了 fake-ip 模式。但这有个众所周知的副作用：很多设备 在刚连上 Wi-Fi 时，会去请求特定的域名（比如 connectivitycheck.gstatic.com）来测试网络通不通。如果这个探针域名被 Fake-IP 劫持，返回了一个伪造的 IP，头显就会误以为自己处在机场、酒店那种需要网页认证的公共网络里。

这题我熟啊！打开配置文件，让这些探针域名直接走分流代理，确保它们能完成握手。

rules 的顶部，加上强行放行探针：

rules:

# 强制网络探针走代理

- DOMAIN,connectivitycheck.gstatic.com,策略组名称

- DOMAIN,connectivity.oculus.com,策略组名称

- DOMAIN,graph.oculus.com,策略组名称

- DOMAIN,cp.cloudflare.com,策略组名称

敲完回车，重启旁路由容器，戴上头显重连 Wi-Fi ，依然显示未连接，商店依然在无限转圈。第一回合，宣告扑街。

QUIC 协议（UDP 443）

既然探针放行了没用，那肯定是有什么更底层的机制在作怪。问了半天GPT，发现我遇到了 Meta 系 App 的祖传坑：QUIC 协议。

Oculus 商店、Facebook 等应用极其依赖 QUIC 协议来传输数据。这个协议走的是 UDP 的 443 端口。然而我的分流节点的 UDP 转发质量很差。App 固执地尝试用 UDP 连接，连不上就死等，绝不降级。

解决办法就是继续修改 rules，增加拦截规则，逼迫 Meta 商店放弃 QUIC，老老实实走稳如老狗的 TCP：

rules:

# 拦截 QUIC (UDP 443 端口)，强迫 Meta 商店降级走稳定的 TCP

- AND,((NETWORK,UDP),(DST-PORT,443)),REJECT

保存，重启，再次戴上头显，结果网络状态依然是受限。

防不胜防的 IPv6

就在我百思不得其解，准备重置头显的时候，我突然意识到了一个极其诡异的细节：为什么头显里的浏览器能流畅看 4K 视频，但系统的网络检测和商店却死活连不上？

这种精神分裂的表现，让我想起了一个存在于网络底层的幽灵。我颤抖着打开了家里主路由器的后台，看了一眼设置，瞬间全都明白了：主路由的 IPv6 开着！

这就是导致一切异常的绝对核心元凶，也是旁路由玩法里最大的盲区。

我的 Macvlan 旁路由是基于 IPv4 搭建的（比如 192.168.0.200）。因为主路由开启了 IPv6，它会通过局域网广播，直接给 Quest 3 分配一个公网 IPv6 地址。

对于 Quest OS 这种底层基于 Android 定制的系统，它的系统级网络探测优先走 IPv6。于是，商店和网络检测的流量直接拿着 IPv6 地址，完全无视了我们辛苦配置的 IPv4 旁路由，直奔没有分流能力的主路由而去。结果自然是撞上一堵高墙，系统判定网络未连接。

那为什么浏览器能用呢？因为现代浏览器有 Happy Eyeballs 机制，发现 IPv6 不通，会瞬间降级切回 IPv4。这部分流量乖乖进入了旁路由，所以浏览器访问一切正常。

破案了

最顶级的猎手往往采用最朴素的烹饪方式。直接在主路由器后台，关闭局域网的 IPv6 功能。

对于绝大多数家庭的智能网络环境来说，局域网开启 IPv6 往往是制造 DNS 污染和流量漏网的温床，关掉保平安。

再次戴上头显的那一刻，没有需要登录，没有网络受限，商店图片瞬间刷出，丝滑无比。折腾了半天，原来是大水冲了龙王庙，IPv6 把旁路由给架空了。

不过这不能怪我，Quest 的系统设置太蠢了。