以前用 iPhone 加圈 X，代理对我来说很薄：配好，连上，能翻出去，就可以忘掉。

换成 Redmi K90 以后，两件事先后冒出来。先是 Gemini 整页提示「目前不支持你所在的地区」；接着 YouTube 看 4K 直播会转圈，带宽掉到 0 kbps，甚至降到 144p 还在转。表面上像两个故障。顺着查下来，排查路径其实是同一条：安卓上「翻出去」中间那层，比 iPhone 时期更容易露出来。

第一步：Gemini 拦在地区提示上

Gemini 原来一直能用，那天突然不行。第一反应是节点或分流坏了，所以先切全局代理——仍然无效。

Gemini 登录后整页地区限制。

全局代理没用，说明不太像「某个规则把 Gemini 漏到了直连」。下一步需要把「出口 IP」和「账号状态」拆开测。

做法很简单：Chrome 无痕，不登录，直接打开 Gemini——能进去。同一个无痕窗口，登录平时那个 Google 账号——立刻又被地区提示挡回来。

未登录能进、登录后不行，网络出口就可以往后排了。问题更像挂在账号上。

接下来查账号侧。Payments 里还留着以前买 YouTube Premium 留下的印度付款资料。但印度并不是 Gemini 的不支持地区，Payments Profile 解释不了这次被挡，可以排除。真正对上的是另一套字段：账号关联地区（Country Association）页面上写着「中国」。

这就对上了：未登录时，Gemini 大概按当时网络环境放行；一登录，就读账号地区，直接判不支持。Payments 的印度区和 Account Country 的中国区，是两套东西。

至于为什么会被判成中国，只能说到合理怀疑。时间线上，K90 是这个主账号新近深入安卓 / Google 生态的节点：Play 正式启用，系统服务、Chrome、YouTube 绑得更深，MetaClash 管着 VPN、TUN、DNS。权限我也专门查过：Google Maps 确实拿到了定位权限。地图不开定位几乎没法用，给这个权限本身很正常；但我倾向于相信，Google 可以把这条路径拿去做账号国家关联或者个人画像——有点垃圾。当然，我没法证明 Maps 定位权限就是 Country Association 变成中国的原因，只能当怀疑，不是结论。整条线里，到底是 GPS、某次短暂直连、DNS / IPv6，还是 Google 根据长期活动重新评估，仍然钉不死。更稳妥的说法是：换机以后，Google 拿到的「这个账号长期在中国用」的信号可能变多了；安卓上的 VPN 环境，也比 iPhone 更容易把各种藏着的路径暴露出来。

账号地区已经确认是中国，网络侧一时钉不死原因，所以账号端先走官方地区变更申请，把能改的改回来。目标选新加坡，原因如实写了常用 VPN，并补充说明平时主要通过新加坡网络环境访问 Google 服务，没有声称自己住在新加坡。申请很快过了，确认邮件写得很清楚：之前关联中国，当前关联新加坡。搜索结果区域也跟着显示新加坡。

官方确认邮件：关联地区已改为新加坡。

账号地区和搜索区域已经是新加坡，Gemini 登录后仍一度显示不支持。我更倾向于不同服务同步有先后，先观察，不再乱改账号。Chrome 打开 google.com 还会跳到 google.com.hk；但搜索引擎本身是 google.com、搜索区域和 Account Region 都已是新加坡，所以 .hk 暂时当成域名跳转、Cookie 或历史残留，不再和 Account Region 绑死成一件事。

账号查完，真正别扭的是：同一条 Wi‑Fi，iPhone 行、K90 不行

账号地区改回来了。可家里无线是小米和 iPhone 共用的同一条网。同一段视频，iPhone 加圈 X 播得很顺；K90 加 MetaClash 却经常卡。出口差不多，凭什么一边行一边不行？这才是真正把我拽进下一轮排查的触发点。

MetaClash 里我顺手收紧过几项（绕过 VPN、DNS、IPv6 之类），用 ipleak / BrowserLeaks 看了一眼，当时看不到明显的中国 IP 或运营商 DNS。这些选项各自到底干什么，我说实话到现在也没完全搞清楚，也没必要搞清楚——逻辑上只需要知道：当前泄漏不是眼前这个卡顿的主因，问题更可能出在 K90 这一侧的代理客户端，而不是家里的网坏了。

第二步：把「体感卡」变成可核对的数字

为了排除「只是我觉得卡」，看 YouTube Stats for nerds：iPhone 上 Connection Speed 能到四万多 Kbps，Readahead 十几秒；K90 上 Dropped Frames 仍是 0——解码没问题，性能可以往后排——但 Bandwidth 会掉到 0.00 kbps，Readahead 只剩零点几秒，画面转圈，甚至掉到 144p 还在转。

同一条 4K：带宽掉到 0，画面转圈。

Dropped Frames 是 0、Bandwidth 是 0，说明不是「4K 码率太高扛不住」，而是视频数据流在某个环节停住了。下一步就要问：停在 Meta 的哪一层。

先怀疑 TUN Stack。依次换过 System、Mixed、gVisor，三种都能复现。因此不能简单扣在某一种栈上，栈可以往后排。

再打开 Meta 的 Logcat，转圈时抓到一条硬证据：YouTube 的流量命中 googlevideo.com，规则把它分到 USA Los Angeles 01，走的是 UDP 443——也就是 QUIC / HTTP/3 那一类路径。

日志：googlevideo.com UDP 443 命中 LA01。

这条日志至少排除了两件事：不是 YouTube 偷跑直连，也不是分流选错节点。流量确实进了代理，确实去了 LA01，而且是 UDP 443。

机场节点已经都是 AnyTLS，手头没法再拿一个 VLESS / Trojan 做协议对照，协议变量暂时控不住。剩下还能控、且成本最低的变量，是客户端实现。于是嫌疑收窄到工程判断——不是定论——「Meta / Mihomo Android + AnyTLS + YouTube UDP/QUIC」这组组合。

下一步只换一层：客户端。奶昔后台给安卓提供了 Clash AnyTLS 和 Surfboard AnyTLS 两套订阅。我没再去做 sing-box 转换，直接装 Surfboard，用机场原生订阅，把变量压到最少。

测试条件：同一台 K90，同一个机场，同一个 LA01，同样是 AnyTLS，全局模式播 YouTube 4K 直播。结果：稳。可以一边播一边聊天，没有再出现 Meta 下那种 0 kbps、144p 还在转的情况。

同机同节点换 Surfboard 后可稳播；图为当时 Surfboard 设置。

手机、网、机场、节点、协议都没换，主要变化就是客户端从 MetaClash 换成 Surfboard。所以比较有把握的判断是：AnyTLS 本身不是问题，LA01 也不是坏节点；当前最大嫌疑在 Meta / Mihomo 安卓这一侧。具体卡在哪一层实现，仍然只能说「从现象看更可能」，没有翻源码证明。

为了避免「全局模式能播、日常规则模式又漏」这种半成品结论，随后切回规则模式复测 IP / DNS，仍然干净。K90 主力暂时改成 Surfboard，Meta 留着备用，不急着卸载。

停在这里

今天真正让我停下来的，不是「Surfboard 比 Meta 好」这种评测句。

Gemini 拦在账号地区，YouTube 卡在客户端实现——现象差很远，排查路径却是一条：换到安卓之后，中间那层开始露出来。账号关联地区、付款资料国家、搜索结果区域、定位、系统服务、VPN bypass、DNS 劫持、Private DNS、IPv6、WebRTC、TUN Stack、协议实现，还有同一条 QUIC 路径在不同客户端上的表现差异。以前在 iPhone 上，这些大多可以假装不存在。

iPhone 那段日子的感觉是：配好就可以忘记。K90 上则是：网络仍然「能用」，但藏在下面的机制开始一件一件冒头。

暂时就停在这里。Gemini 那边继续观察同步；YouTube 这边先靠 Surfboard 把日子过顺。剩下那些还没钉死的机制，等下次再撞上再说。