Почему в материковом Китае к некоторым сервисам Google можно подключаться напрямую, а push-уведомления FCM часто работают без прокси?

Универсальный
, , ,
1

Многие, впервые сталкиваясь с этим явлением, недоумевают: www.google.com, веб-версия Gmail, YouTube в материковом Китае обычно работают нестабильно или вовсе недоступны, но часть push-уведомлений на Android, завязанных на Google / Firebase Cloud Messaging (FCM), часто всё же приходит; некоторые наборы прокси-правил даже намеренно ставят GoogleFCM как DIRECT. Это не потому, что «Google вообще не заблокирован», а потому что разные продукты Google, домены, порты и протоколы попадают под разные стратегии блокировок.

Сначала вывод: в материковом Китае Google не «рубят одним общим выключателем», а обрабатывают по уровням, по доменам, по портам, по протоколам, по сетевой среде и по временным отрезкам. Канал push на стороне устройства FCM и привычные всем www.google.com / Gmail / YouTube — это вообще не одна и та же цепочка.

Сначала вывод

  • Приём push на стороне устройства 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 для приёма push на устройстве не подходит для прохождения через сетевой прокси; устройство должно иметь возможность напрямую подключаться к серверам FCM.
  • Поэтому во многих наборах правил GoogleFCM выделяют отдельно и в приоритете отправляют через DIRECT. Обычно это не «упустили», а ближе к официальным рекомендациям и реальному поведению сети.
  • Но это не означает, что «в материковом Китае на всех сетях и всегда можно напрямую подключаться к FCM». У разных операторов, в сетях школ и компаний, в разные периоды, при разных условиях IPv4/IPv6 результаты могут отличаться.

Какие адреса и порты использует FCM?

В официальном документе Google / Firebase «Configure your Network for FCM», обновлённом 2026-03-20, приведён достаточно ясный список.

Сторона устройства (приём push)

Google рекомендует разрешить следующие хостнеймы:

  • mtalk.google.com
  • mtalk4.google.com
  • mtalk-staging.google.com
  • mtalk-dev.google.com
  • alt1-mtalk.google.com до alt8-mtalk.google.com
  • android.apis.google.com
  • device-provisioning.googleapis.com
  • firebaseinstallations.googleapis.com

Соответствующие порты в основном:

  • 5228
  • 5229
  • 5230
  • 443

Google также отдельно подчёркивает, что протокол FCM при приёме push не подходит для транзита через сетевой прокси, поэтому устройству нужно уметь подключаться к их серверам напрямую.

Сторона сервера (отправка сообщений)

Если вы отправляете сообщения через FCM с серверной стороны, Google указывает в основном такие адреса:

  • fcm.googleapis.com
  • accounts.google.com
  • iid.googleapis.com

То есть «доступ к Google через веб» и «канал push FCM» — по доменам, портам, протоколам и назначению — изначально разные вещи.

Почему google.com часто не работает, а FCM иногда всё же может подключаться напрямую?

Ключевая причина проста: блокировки делаются не «по ярлыку компании Google» одним махом, а по более тонким сетевым признакам.

1. Разные домены попадают под блокировку

Обычные пользователи чаще всего сталкиваются с:

  • www.google.com
  • mail.google.com
  • youtube.com
  • drive.google.com

А на стороне устройства FCM чаще встречаются:

  • mtalk.google.com
  • alt1-8.mtalk.google.com
  • небольшое число вспомогательных доменов для инициализации

С точки зрения системы блокировок это не одна и та же цель.

2. Разные порты и протоколы

При веб-доступе почти весь трафик — это обычный HTTPS на 443; а push FCM часто представляет собой длительно удерживаемое TCP-соединение на 5228-5230, по смыслу больше похожее на «долгое push-соединение», а не на «открыть веб-страницу».

Это означает, что трафик может попадать в другие пути распознавания и вмешательства.

3. Разная сетевая среда

Один и тот же домен в разных сетях может давать совершенно разные результаты. Домашний широкополосный доступ, мобильный интернет, кампусная сеть, корпоративная сеть — у всех могут по-разному обрабатываться DNS, IPv4, IPv6, SNI, длинные соединения, прокси-политики.

На странице OONI по Китаю сейчас агрегированы 40,219,834 измерения из 226 локальных сетей, и там прямо отмечено: аномальные результаты нужно наблюдать во времени и с учётом сетевой среды; единичные аномалии тоже могут быть ложными. Это как раз показывает, что сетевые измерения в материковом Китае — не тот вопрос, где «по одной точке можно сделать окончательный вывод».

4. Не все конечные точки Google одинаково важны и одинаково удобны для обработки

Это предположение, но оно хорошо соответствует инженерной реальности: веб-поиск, видеосервис, фронтенд почты и длинные push-соединения для устройств — это разные типы трафика на сетевом уровне; если все связанные конечные точки блокировать с одинаковой жёсткостью, зона побочного ущерба и стоимость сопровождения могут быть выше.

Поэтому в реальности часто встречается не «всё проходит» или «всё заблокировано», а часть долго не работает, часть иногда “потряхивает”, а часть в некоторых сетях ещё работает.

Что видно по публичным данным?

Публичные измерения тоже поддерживают наблюдение «не рубят одним махом».

В текущем публичном индексе 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 по-прежнему много элементов 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.

Результат:

  • Эта машина смогла напрямую установить TCP-соединение к mtalk.google.com:5228.
  • При установке соединения фактически подключение шло к 2404:6800:4008:c02::bc:5228.
  • В конфигурации mihomo на этой машине GoogleFCM выделен в отдельную группу правил, и по умолчанию ему отдан приоритет DIRECT.

Это не означает, что все сети в материковом Китае ведут себя так же, но по крайней мере показывает: утверждение «FCM в материковом Китае обязательно должен идти через прокси» не является верным. В некоторых сетях он действительно может работать напрямую.

Нужно ли прокси “подстраховывать” FCM?

Моя рекомендация: в приоритете прямое соединение, при необходимости — сохранить прокси как запасной вариант.

Три причины:

  • Это ближе к официальной рекомендации Google для FCM на стороне устройства.
  • Длинные push-соединения обычно сильнее страдают от «лишних манипуляций»: чем проще маршрут, тем стабильнее.
  • Некоторые сети действительно блокируют конечные точки типа mtalk; тогда запасной вариант через прокси всё ещё имеет смысл.

Поэтому в инструментах вроде mihomo / Clash обычно разумная схема такая:

  • Выделить GoogleFCM отдельно.
  • По умолчанию сначала пробовать DIRECT.
  • Если в вашей сети прямое соединение часто падает, добавить какой-то стабильный узел как ручную подстраховку.

Последняя фраза-резюме

Материковый Китай — это не «к Google везде можно подключаться напрямую» и не «к Google везде нужно ходить через прокси»; точнее будет сказать так: разные сервисы Google попадают под разную “сетевую судьбу”. Ветка push FCM, поскольку использует другие домены, другие порты, другие протоколы, а официально устройству и так рекомендуется прямое подключение, в части сетей материкового Китая может работать напрямую — и в этом нет ничего странного.

Справочные материалы

  1. Официальная документация Firebase: настройка сети для FCM
    为 FCM 配置网络  |  Firebase Cloud Messaging

  2. OONI Explorer: общий обзор измерений по Китаю
    Internet Censorship in China - OONI Explorer

  3. Публичный индекс 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

  4. Публичный индекс GreatFire: www.google.com, YouTube и т. п. — видны многочисленные элементы 100% blocked
    https://en.greatfire.org/SEARCH/URLS?page=390
    https://en.greatfire.org/SEARCH/HTTPS?page=202