多くの人が初めてこの現象に遭遇すると疑問に思います：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 の端末プッシュは 5228-5230 上で動く長時間維持される TCP 接続であることが多く、意味合いとしては「プッシュ用の長期接続」に近く、「ウェブページを開く」ものではありません。
つまり、識別や介入の経路が異なる可能性があります。
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 関連サービスの到達可能性は、確かに一様ではありません。
中国本土ネットワーク上の 1 台での自分の実測
ルールだけを見て現実を見ないことを避けるため、中国本土のネットワーク環境にある Windows マシンで直接テストを行いました。日時は 2026-03-22 です。
結果：
- この端末は
mtalk.google.com:5228への TCP 接続を直接確立できました。 - 接続確立時に実際に接続された対向は
2404:6800:4008:c02::bc:5228でした。 - 本機の
mihomo設定では、GoogleFCMが専用のルールグループとして分離され、デフォルトでDIRECTが優先されていました。
これはすべての中国本土ネットワークが同様だという意味ではありませんが、少なくとも：「FCM は中国本土では必ずプロキシが必要」という言い方は成り立ちません。 ある種のネットワークでは直結できます。
ではプロキシは FCM のフォールバック（兜底）を用意すべきか？
私の提案は：直結を優先し、必要な場合にのみプロキシによるフォールバックを残すことです。
理由は 3 つ：
- 端末側 FCM に関する Google 公式推奨により近い。
- プッシュの長期接続は通常、経路が複雑になるほど不安定になりやすく、経路が単純なほど安定しやすい。
- 一部ネットワークでは実際に
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