很多人第一次遇到这个现象都会疑惑：www.google.com、Gmail 网页版、YouTube 在中国大陆通常不稳定甚至直接不可用，但 Android 上一部分依赖 Google / Firebase Cloud Messaging（FCM）的推送，却经常还能收到；某些代理规则集甚至会故意把 GoogleFCM 设成 DIRECT。这不是“Google 全都没封”，而是 Google 的不同产品、域名、端口、协议，命中的封锁策略并不一样。
本文先给结论：中国大陆对 Google 不是“一个总开关式全封”，而是分层、分域名、分端口、分协议、分网络环境、分时间段地处理。FCM 设备侧的推送通道，和大家平时访问的 www.google.com / Gmail / YouTube，根本不是同一条链路。
先说结论
- FCM 设备侧接收推送，核心不是
www.google.com，而是mtalk.google.com、mtalk4.google.com、alt1-mtalk.google.com到alt8-mtalk.google.com等主机名。 - Google 官方给 FCM 设备侧列出的端口主要是
5228、5229、5230，以及443。 - Google 官方还明确写到：设备接收推送的 FCM 协议不适合经过网络代理，设备应能直接连接到 FCM 服务器。
- 这就是为什么很多规则集会把
GoogleFCM单独拿出来，优先走DIRECT。这通常不是“漏了”，而是更贴近官方建议和现实网络表现。 - 但这也不代表“大陆所有网络、所有时刻都能直连 FCM”。不同运营商、学校网、企业网、时段、IPv4/IPv6 条件，结果都可能不同。
FCM 到底用哪些地址和端口？
Google / Firebase 官方在 2026-03-20 更新的《Configure your Network for FCM》里，给出了比较清晰的列表。
设备接收推送侧
Google 官方建议放行这些主机名：
mtalk.google.commtalk4.google.commtalk-staging.google.commtalk-dev.google.comalt1-mtalk.google.com到alt8-mtalk.google.comandroid.apis.google.comdevice-provisioning.googleapis.comfirebaseinstallations.googleapis.com
对应端口主要是：
522852295230443
Google 还特别说明，设备接收推送时的 FCM 协议不适合通过网络代理中转，因此设备需要能直接连到它们的服务器。
服务端发送消息侧
如果你是在服务器端调用 FCM 发消息，Google 官方列出的主要地址是：
fcm.googleapis.comaccounts.google.comiid.googleapis.com
所以，“Google 网页访问” 和 “FCM 推送通道”，从域名、端口、协议和用途上看，本来就是两件事。
为什么 google.com 经常不行，但 FCM 可能还能直连？
核心原因很简单：封锁不是按“Google 公司”这个标签一刀切，而是按更细的网络特征来做。
1. 命中的域名不同
普通用户最常接触的是：
www.google.commail.google.comyoutube.comdrive.google.com
而 FCM 设备侧更常见的是：
mtalk.google.comalt1-8.mtalk.google.com- 少量配套初始化域名
从封锁系统视角看，这些并不是同一个目标。
2. 端口和协议不同
大家访问网页时，绝大多数流量是 443 上的普通 HTTPS；而 FCM 设备推送常见的是一条长期保持的 TCP 连接，跑在 5228-5230，语义更像“推送长连接”，不是“打开一个网页”。
这意味着它会命中不同的识别和干预路径。
3. 网络环境不同
同一个域名在不同网络里，结果可能完全不同。家庭宽带、手机流量、校园网、企业网，对 DNS、IPv4、IPv6、SNI、长连接、代理策略的处理方式都可能不一样。
OONI 的中国页面目前汇总了来自 226 个本地网络的 40,219,834 次测量，并且明确提醒：异常结果要结合时间和网络环境持续观察，单次异常也可能出现误判。这正说明中国大陆网络测量本来就不是“单点就能下定论”的问题。
4. 并不是所有 Google 端点都同等重要、同等容易处理
这是一个推断，但很符合工程现实：网页搜索、视频网站、邮箱前端，与设备推送长连接，对网络层来说是不同类型的流量；如果把所有相关端点全部做成同样强度的拦截，误伤面和维护成本也可能更高。
所以现实里常见的情况不是“全通”或“全封”，而是一部分长期不通，一部分偶尔抖动，一部分在某些网络还能通。
公开数据能看到什么？
公开测量也支持这种“并非一刀切”的观察。
GreatFire 当前公开索引里，mtalk 一批端点能看到 0% 条目
截至我写这篇文章时，GreatFire 的公开索引页里可以看到：
https://mtalk.google.com显示为0%https://mtalk.google.com:5228显示为0%https://alt1-mtalk.google.com到https://alt8-mtalk.google.com也能看到0%条目
但典型 Google Web 产品仍然能看到大量 100% blocked 条目
同样是在 GreatFire 的公开索引页里，能看到例如：
https://www.google.com对应100% blocked条目- 很多
https://www.youtube.com/...条目对应100% blocked - 很多
mail.google.com、drive.google.com相关条目也能看到100% blocked
这些页面本身也是公开测量的索引结果，不代表“永远如此”，但它至少说明了一点：Google 相关服务在中国大陆的可达性，确实不是统一命运。
我自己在一台大陆网络机器上的实测
为了避免只看规则不看现实，我在一台位于中国大陆网络环境的 Windows 机器上做了直接测试，时间是 2026-03-22。
结果是：
- 本机可以直接建立到
mtalk.google.com:5228的 TCP 连接。 - 建连时实际连到的对端是
2404:6800:4008:c02::bc:5228。 - 本机
mihomo配置里，GoogleFCM被单独拆成专门规则组，默认优先给了DIRECT。
这不代表所有大陆网络都这样，但至少说明：“FCM 在大陆一定要代理”这个说法并不成立。 在某些网络上，它就是能直连。
那代理到底要不要给 FCM 兜底？
我的建议是：优先直连，必要时再保留代理兜底。
原因有三点：
- 这更接近 Google 官方对设备侧 FCM 的建议。
- 推送长连接通常更怕折腾，链路越简单越稳。
- 某些网络确实会把
mtalk一类端点拦掉，这时代理兜底仍然有价值。
所以在 mihomo / Clash 一类工具里，比较合理的思路通常是：
- 把
GoogleFCM单独拆出来。 - 默认先试
DIRECT。 - 如果你所在网络直连经常失败，再把某个稳定节点作为手动兜底。
最后一句话总结
中国大陆并不是“Google 全部能直连”，也不是“Google 全部都必须代理”；更准确的说法是：不同 Google 服务命中的是不同的网络命运。FCM 推送这一支，因为用的是不同域名、不同端口、不同协议，而且官方本来就建议设备直连，所以它在一部分大陆网络里能直接工作，并不奇怪。
参考资料
-
Firebase 官方文档：FCM 网络配置
为 FCM 配置网络 | Firebase Cloud Messaging -
OONI Explorer：中国网络测量总览
Internet Censorship in China - OONI Explorer -
GreatFire 公开索引：
mtalk.google.com/mtalk.google.com:5228/alt1-8-mtalk.google.com可见0%条目
https://en.greatfire.org/SEARCH/HTTPS?page=706
Censorship of Google Sites in China | GreatFire Analyzer
https://en.greatfire.org/SEARCH/URLS?page=3602 -
GreatFire 公开索引：
www.google.com、YouTube 等可见大量100% blocked条目
https://en.greatfire.org/SEARCH/URLS?page=390
https://en.greatfire.org/SEARCH/HTTPS?page=202