Muitas pessoas ficam confusas ao se deparar com este fenômeno pela primeira vez: www.google.com, o Gmail Web e o YouTube na China continental geralmente são instáveis ou até diretamente indisponíveis, mas parte das notificações push no Android que dependem de Google / Firebase Cloud Messaging (FCM) muitas vezes ainda chega; alguns conjuntos de regras de proxy até colocam deliberadamente GoogleFCM como DIRECT. Isso não significa que “o Google não está todo bloqueado”, e sim que diferentes produtos do Google — domínios, portas e protocolos — atingem políticas de bloqueio diferentes.
Este texto dá primeiro a conclusão: na China continental, o Google não é tratado como um “interruptor geral” de bloqueio total; ele é tratado por camadas, por domínio, por porta, por protocolo, por ambiente de rede e por faixa de horário. O canal de push do lado do dispositivo do FCM e o que as pessoas acessam no dia a dia — www.google.com / Gmail / YouTube — não são a mesma rota.
Primeiro, a conclusão
- O recebimento de push do lado do dispositivo no FCM não depende de
www.google.com, e sim principalmente de nomes de host comomtalk.google.com,mtalk4.google.com,alt1-mtalk.google.comatéalt8-mtalk.google.com. - As portas que o Google lista oficialmente para o lado do dispositivo no FCM são principalmente
5228,5229,5230, além de443. - O Google também declara explicitamente: o protocolo do FCM para recebimento de push no dispositivo não é adequado para passar por proxy de rede; o dispositivo deve conseguir conectar-se diretamente aos servidores do FCM.
- É por isso que muitos conjuntos de regras separam
GoogleFCMe priorizamDIRECT. Geralmente isso não é “um furo”, e sim algo mais alinhado à recomendação oficial e ao comportamento real da rede. - Mas isso também não significa que “todas as redes da China continental, em todos os momentos, conseguem conectar diretamente ao FCM”. Diferentes operadoras, redes de escola, redes corporativas, horários e condições de IPv4/IPv6 podem produzir resultados diferentes.
Afinal, quais endereços e portas o FCM usa?
Na documentação oficial do Google / Firebase, atualizada em 2026-03-20, “Configure your Network for FCM”, é fornecida uma lista relativamente clara.
Lado do dispositivo para receber push
O Google recomenda liberar estes nomes de host:
mtalk.google.commtalk4.google.commtalk-staging.google.commtalk-dev.google.comalt1-mtalk.google.comatéalt8-mtalk.google.comandroid.apis.google.comdevice-provisioning.googleapis.comfirebaseinstallations.googleapis.com
As portas correspondentes são principalmente:
522852295230443
O Google também destaca que o protocolo do FCM no recebimento de push do dispositivo não é adequado para encaminhamento via proxy de rede, portanto o dispositivo precisa conseguir conectar-se diretamente aos servidores.
Lado do servidor para enviar mensagens
Se você chama o FCM no lado do servidor para enviar mensagens, os principais endereços listados pelo Google são:
fcm.googleapis.comaccounts.google.comiid.googleapis.com
Portanto, “acesso web ao Google” e “canal de push do FCM”, em termos de domínio, porta, protocolo e finalidade, são duas coisas diferentes.
Por que google.com muitas vezes não funciona, mas o FCM talvez ainda conecte direto?
O motivo central é simples: o bloqueio não é feito com base no rótulo “empresa Google” de forma uniforme, e sim com base em características de rede mais finas.
1. Os domínios atingidos são diferentes
O que usuários comuns mais acessam é:
www.google.commail.google.comyoutube.comdrive.google.com
Já no lado do dispositivo do FCM, o mais comum é:
mtalk.google.comalt1-8.mtalk.google.com- alguns domínios auxiliares de inicialização
Do ponto de vista do sistema de bloqueio, isso não é o mesmo alvo.
2. As portas e os protocolos são diferentes
Ao acessar páginas web, a esmagadora maioria do tráfego é HTTPS comum na 443; enquanto o push do FCM no dispositivo costuma ser uma conexão TCP de longa duração, rodando em 5228-5230, com semântica mais parecida com “conexão longa de push” do que “abrir uma página web”.
Isso significa que ele acerta caminhos diferentes de identificação e intervenção.
3. O ambiente de rede é diferente
O mesmo domínio em redes diferentes pode ter resultados totalmente distintos. Banda larga residencial, dados móveis, rede de campus e rede corporativa podem tratar DNS, IPv4, IPv6, SNI, conexões longas e políticas de proxy de formas diferentes.
A página da OONI sobre a China atualmente agrega 40,219,834 medições de 226 redes locais e também alerta explicitamente: resultados anômalos devem ser observados continuamente considerando tempo e ambiente de rede; uma anomalia pontual também pode ser falso positivo. Isso mostra que medições de rede na China continental não são um problema em que “um único ponto” permite concluir algo.
4. Nem todos os endpoints do Google são igualmente importantes e igualmente fáceis de tratar
Isto é uma inferência, mas combina com a realidade de engenharia: busca web, vídeo e frontend de e-mail, versus uma conexão longa de push de dispositivo, são tipos diferentes de tráfego no nível de rede; se todos os endpoints relacionados forem interceptados com a mesma intensidade, o risco de dano colateral e o custo de manutenção podem ser maiores.
Então, na prática, o comum não é “tudo passa” ou “tudo bloqueia”, e sim: uma parte fica indisponível por muito tempo, uma parte oscila ocasionalmente, e uma parte ainda funciona em certas redes.
O que os dados públicos mostram?
Medições públicas também sustentam essa observação de “não é tudo ou nada”.
No índice público atual do GreatFire, um lote de endpoints mtalk aparece como 0%
Até o momento em que escrevo este texto, nas páginas de índice público do GreatFire dá para ver:
https://mtalk.google.comaparece como0%https://mtalk.google.com:5228aparece como0%https://alt1-mtalk.google.comatéhttps://alt8-mtalk.google.comtambém aparecem como itens0%
Mas produtos web típicos do Google ainda mostram muitos itens 100% blocked
Na mesma página de índice público do GreatFire, é possível ver, por exemplo:
https://www.google.comcom item100% blocked- muitos itens
https://www.youtube.com/...com100% blocked - muitos itens relacionados a
mail.google.comedrive.google.comtambém com100% blocked
Essas páginas em si são resultados indexados de medições públicas; não significa “sempre será assim”, mas pelo menos mostra uma coisa: a acessibilidade de serviços do Google na China continental realmente não é um destino único e uniforme.
Meu teste prático em uma máquina em rede continental
Para evitar olhar só regras e não a realidade, fiz um teste direto em uma máquina Windows em ambiente de rede dentro da China continental, em 2026-03-22.
O resultado foi:
- Esta máquina conseguiu estabelecer diretamente uma conexão TCP com
mtalk.google.com:5228. - Ao conectar, o endpoint remoto efetivo foi
2404:6800:4008:c02::bc:5228. - Na configuração do meu
mihomo,GoogleFCMfoi separado em um grupo de regras dedicado, com prioridade padrão paraDIRECT.
Isso não significa que todas as redes da China continental sejam assim, mas pelo menos mostra: a afirmação “FCM na China continental necessariamente precisa de proxy” não se sustenta. Em algumas redes, ele simplesmente conecta direto.
Então, o proxy deve ou não dar “fallback” para o FCM?
Minha sugestão é: priorize conexão direta e, quando necessário, mantenha um fallback por proxy.
Há três razões:
- Isso está mais alinhado à recomendação oficial do Google para o FCM no lado do dispositivo.
- Conexões longas de push geralmente são mais sensíveis; quanto mais simples o caminho, mais estável.
- Algumas redes realmente bloqueiam endpoints como
mtalk; aí o fallback por proxy ainda tem valor.
Então, em ferramentas como mihomo / Clash, uma linha de raciocínio geralmente razoável é:
- Separar
GoogleFCMem uma regra dedicada. - Por padrão, tentar
DIRECTprimeiro. - Se na sua rede a conexão direta falhar com frequência, então escolher um nó estável como fallback manual.
Uma frase para resumir
Na China continental, não é que “tudo do Google conecta direto”, nem que “tudo do Google precisa de proxy”; a forma mais precisa de dizer é: serviços diferentes do Google acertam destinos de rede diferentes. O ramo de push do FCM, por usar domínios, portas e protocolos diferentes — e por o próprio Google recomendar conexão direta no dispositivo — pode funcionar diretamente em parte das redes da China continental, o que não é surpreendente.
Referências
-
Documentação oficial do Firebase: configuração de rede do FCM
为 FCM 配置网络 | Firebase Cloud Messaging -
OONI Explorer: visão geral de medições de rede na China
Internet Censorship in China - OONI Explorer -
Índice público do GreatFire:
mtalk.google.com/mtalk.google.com:5228/alt1-8-mtalk.google.comcom itens0%visíveis
https://en.greatfire.org/SEARCH/HTTPS?page=706
Censorship of Google Sites in China | GreatFire Analyzer
https://en.greatfire.org/SEARCH/URLS?page=3602 -
Índice público do GreatFire:
www.google.com, YouTube etc. com muitos itens100% blockedvisíveis
https://en.greatfire.org/SEARCH/URLS?page=390
https://en.greatfire.org/SEARCH/HTTPS?page=202