闲置的谷歌 TV 复活记：卡在「正在连接」的真凶，是一个搜不到的域名

教程稿（脱敏版）· 2026-10-25 实测

适用：Chromecast with Google TV、Google TV / Android TV 设备在恢复出厂或首次开机时，卡在「正在连接 Wi-Fi」或「已连接 → 转圈 → 弹回」的场景。

先说结论

设备没坏，WiFi 也没问题。真凶是安卓的联网校验域名 connectivitycheck.gstatic.com 被代理规则判成了直连：它在墙外撞死，设备便以为「没有网络」，转圈、超时、弹回。

修法只有一行规则——把 gstatic.com 强制送进代理：

DOMAIN-SUFFIX,gstatic.com,你的代理策略组

下面是完整的攻坚实录。这一晚的排查里，几乎每一步都出乎意料——这些「出意料」，正是这篇教程最想留给你的部分。

症状

• 电视上先是卡「正在连接 Wi-Fi 网络」；
• 后来能提示「连接成功 / 已连接」，然后长时间转圈，最后弹回前一画面；
• 换 2.4G / 5G、关手机 VPN、用手机热点，结果一模一样。

八个「出意料」

1. 屏幕在骗你：它早就连上 WiFi 了

去路由器的客户列表里看一眼——棒子赫然在列，信号满格，IP 也拿到了。也就是说 WiFi 关联、密码、DHCP 全过，卡点根本不在「连接 WiFi」这一步，而在联网之后的校验环节。界面文案说卡在哪儿，不代表真卡在哪儿。

2. 「时间不对」理论：对了一半

网上有经验贴指出：谷歌 TV 重置后系统时间不对会导致连不上，解法是在路由器上劫持 NTP 域名：

# dnsmasq 自定义配置
address=/time.android.com/203.107.6.88

再把 DNS Director 的全局重定向设为「路由器」，强制全屋 DNS 经过路由器。这两步都做对了、也验证生效了——但棒子照样转圈。必要不充分，是排查里最常见的陷阱：一个改动「对症」，不等于它就是病根。

3. 热点也救不了它——差点判了硬件死刑

换手机热点激活，同样卡住。这一瞬间很容易得出结论：「换了网络还不行，一定是棒子坏了。」错。热点环境下同样没有代理通道，和家里是同一个病：校验域名出不去。换网络只能排除「路由器坏」，排除不了「路不通」。

4. 全屋设备都正常，就它不行——因为你测错了域名

在电脑上测：

curl --noproxy '*' -I https://www.google.com/generate_204   # 回 204，一切正常

全绿。于是更像棒子的问题了。但真相是：电脑和手机都有自己的代理手段，而且你测的 google.com 压根不是棒子校验时用的域名。要测，就测设备真正用的那个端点。

5. 「以前没 IPv6 时好好的」——真线索，也会是假线索

这台设备以前激活很轻松，那时家里没开 IPv6。线索太像了，于是动手关掉路由器 IPv6 实测：棒子照样转圈；IPv6 恢复开启。结论：线索再合理，也必须实测判死，不能凭叙事定罪。

6. ping 出 3 秒延迟，不是网络差，是它在睡觉

ping 棒子的IP：5/5 全回、0 丢失，时延 3126ms → 2124ms → 1124ms → 121ms → 5ms

逐包递减这个形态，是 WiFi 省电沉睡被一个个包唤醒——数据面活得好好的。要是只看第一个 3 秒，很容易误判「信号质量不行」。看整列数字的形状，比看单个数字重要。

7. 分水岭四连测：一锤定音

在电脑终端上，对四个端点各打一枪（curl --noproxy '*' -I <地址>）：

看明白了：80 端口没罪，google.com 没事，只有 connectivitycheck.gstatic.com 一个域名是死的，且死法（HTTP 空回 + HTTPS 握手掐断）正是「被判直连、撞墙」的指纹。而安卓的连通性校验，用的正是它。

8. 凶手在规则列表里搜不到

到代理面板的规则页搜 gstatic——62 条规则，零命中。判它直连的条目藏在某个规则集内部，顶层列表里根本看不见。

这一步的启示最值钱：不必找到凶手才能破案。 加一条排在最前面的自定义规则压过它，就完事了。

修复（以 MerlinClash / Mihomo 为例）

1. 打开代理插件，进「自定规则」，切到专业模式，点「编辑自定义规则」；
2. 写入一行（顶格，每条一行，不需要写 -）：

   DOMAIN-SUFFIX,gstatic.com,🎯 总模式

最后一段换成你自己的顶层策略组名。注意：很多订阅模板的组名带 emoji 前缀（如 🎯、♻️），引用时必须原样照抄，少一个符号内核就找不到这组；

3. 保存。关键动作：重开一次编辑器，确认那行字还在——存没存上，眼见为实；
4. 回主界面点「重启&保存」，等内核重启完（约一分钟，期间网络会短暂闪断，正常）；
5. 复测：curl --noproxy '*' -I http://connectivitycheck.gstatic.com/generate_204 应回 204；
6. 给棒子断电 30 秒再上电，重新走激活——这次校验段一次通过，后面就是登录、两步验证、接受条款、装应用，进主页。

其他 Clash 内核 / 软路由同理：在自定义规则最前面加上同一行（格式按各自面板要求），重启内核生效即可。

回滚（每一步都留后路）

• 自定义规则：删掉那一行，保存，重启&保存；
• DNS Director：全局重定向改回「无重定向」（注意只改这一项）；
• NTP 劫持：删掉 dnsmasq 里那一行并重启 dnsmasq 服务。

写在最后

这一晚的排查顺序，其实可以复用在很多「设备连不上网」上：

1. 先去客户列表确认设备真的在线，别信界面文案；
2. ping 一把，看时延的形状判断数据面死活；
3. 找出设备真正用的校验端点，拿它做裸连对照；
4. 一次只动一个变量，动完立刻验，动手前先想好回滚。

一台闲置了很久的设备，就这样被一行规则叫醒了。