Mucha gente se confunde la primera vez que se encuentra con este fenómeno: www.google.com, Gmail web y YouTube en China continental por lo general son inestables o incluso directamente no están disponibles, pero una parte de las notificaciones push en Android que dependen de Google / Firebase Cloud Messaging（FCM） a menudo todavía se reciben; algunos conjuntos de reglas de proxy incluso ponen deliberadamente GoogleFCM como DIRECT. Esto no significa que “Google no esté bloqueado en su totalidad”, sino que, entre los distintos productos de Google, dominios, puertos y protocolos, las estrategias de bloqueo que se activan no son las mismas.
Este artículo da primero la conclusión: China continental no trata a Google como “un único interruptor general para bloquearlo todo”, sino que lo gestiona por capas, por dominio, por puerto, por protocolo, por entorno de red y por franjas horarias. El canal de push del lado del dispositivo de FCM y lo que la gente suele visitar como www.google.com / Gmail / YouTube no son en absoluto la misma ruta.
Primero, la conclusión
- En el lado del dispositivo, la recepción de push de FCM no se basa en
www.google.com, sino en nombres de host comomtalk.google.com,mtalk4.google.com,alt1-mtalk.google.comhastaalt8-mtalk.google.com, etc. - Los puertos que Google indica oficialmente para el lado del dispositivo de FCM son principalmente
5228,5229,5230y443. - Google también escribe explícitamente: el protocolo FCM para que el dispositivo reciba push no es adecuado para pasar por un proxy de red; el dispositivo debería poder conectarse directamente a los servidores de FCM.
- Por eso muchos conjuntos de reglas separan
GoogleFCMy priorizanDIRECT. A menudo no es un “descuido”, sino que se ajusta mejor a la recomendación oficial y al comportamiento real de la red. - Pero esto tampoco significa que “todas las redes de China continental, en todo momento, puedan conectarse directamente a FCM”. Distintos operadores, redes universitarias, redes empresariales, horarios y condiciones IPv4/IPv6 pueden dar resultados diferentes.
¿Qué direcciones y puertos usa realmente FCM?
En «Configure your Network for FCM», actualizado por Google / Firebase el 2026-03-20, se ofrece una lista bastante clara.
Lado del dispositivo (recepción de push)
Google recomienda permitir estos nombres de host:
mtalk.google.commtalk4.google.commtalk-staging.google.commtalk-dev.google.comalt1-mtalk.google.comaalt8-mtalk.google.comandroid.apis.google.comdevice-provisioning.googleapis.comfirebaseinstallations.googleapis.com
Los puertos correspondientes son principalmente:
522852295230443
Google también señala especialmente que el protocolo FCM cuando el dispositivo recibe push no es adecuado para ser retransmitido por un proxy de red, por lo que el dispositivo necesita poder conectarse directamente a sus servidores.
Lado del servidor (envío de mensajes)
Si en el servidor llamas a FCM para enviar mensajes, las direcciones principales que lista Google son:
fcm.googleapis.comaccounts.google.comiid.googleapis.com
Por tanto, “acceso web a Google” y “canal de push de FCM”, en términos de dominio, puerto, protocolo y propósito, son desde el inicio dos cosas distintas.
¿Por qué google.com a menudo no funciona, pero FCM quizá aún pueda conectarse directamente?
La razón central es sencilla: el bloqueo no es un “corte a cuchillo” por la etiqueta “empresa Google”, sino que se aplica según características de red más finas.
1. Los dominios que se activan son distintos
Lo que más suele tocar el usuario común es:
www.google.commail.google.comyoutube.comdrive.google.com
Mientras que del lado del dispositivo FCM lo más común es:
mtalk.google.comalt1-8.mtalk.google.com- unos pocos dominios auxiliares de inicialización
Desde la perspectiva del sistema de bloqueo, estos no son el mismo objetivo.
2. Puertos y protocolos distintos
Cuando se accede a páginas web, la gran mayoría del tráfico es HTTPS normal sobre 443; mientras que el push de FCM en el dispositivo suele ser una conexión TCP de larga duración, que corre en 5228-5230, con una semántica más parecida a “conexión persistente de push” y no a “abrir una página web”.
Esto implica que activará rutas diferentes de identificación e intervención.
3. Entornos de red distintos
El resultado para el mismo dominio puede ser completamente distinto en redes distintas. Banda ancha doméstica, datos móviles, red universitaria, red empresarial: el tratamiento de DNS, IPv4, IPv6, SNI, conexiones persistentes y políticas de proxy puede variar.
La página de China de OONI actualmente agrega 40,219,834 mediciones provenientes de 226 redes locales, y además advierte claramente: los resultados anómalos deben observarse de forma continua en función del tiempo y el entorno de red; incluso una anomalía puntual puede ser un falso positivo. Esto muestra precisamente que la medición de red en China continental no es un asunto en el que “un solo punto permita concluir”.
4. No todos los endpoints de Google son igual de importantes ni igual de fáciles de tratar
Esto es una inferencia, pero encaja bien con la realidad de ingeniería: búsqueda web, vídeo, interfaz del correo, y una conexión persistente de push para dispositivos, son tipos de tráfico distintos a nivel de red; si se hiciera el mismo nivel de bloqueo fuerte para todos los endpoints relacionados, el daño colateral y el coste de mantenimiento también podrían ser mayores.
Así que en la práctica lo común no es “todo pasa” o “todo se bloquea”, sino una parte no funciona de forma prolongada, una parte tiembla ocasionalmente y una parte aún funciona en ciertas redes.
¿Qué puede verse en los datos públicos?
Las mediciones públicas también respaldan esta observación de “no es un corte uniforme”.
En el índice público actual de GreatFire, un lote de endpoints mtalk muestra entradas 0%
Hasta el momento de escribir este artículo, en la página de índice público de GreatFire se puede ver:
https://mtalk.google.comaparece como0%https://mtalk.google.com:5228aparece como0%https://alt1-mtalk.google.comhastahttps://alt8-mtalk.google.comtambién muestran entradas0%
Pero los productos web típicos de Google aún muestran muchas entradas 100% blocked
En la misma página de índice público de GreatFire, se puede ver por ejemplo:
https://www.google.comcorresponde a una entrada100% blocked- muchas entradas
https://www.youtube.com/...corresponden a100% blocked - muchas entradas relacionadas con
mail.google.comydrive.google.comtambién muestran100% blocked
Estas páginas en sí son resultados indexados de mediciones públicas y no significan “siempre será así”, pero al menos muestran algo: la accesibilidad de los servicios relacionados con Google en China continental efectivamente no comparte un destino uniforme.
Mi propia prueba en una máquina dentro de una red de China continental
Para evitar mirar solo reglas y no la realidad, hice una prueba directa en una máquina Windows ubicada en un entorno de red de China continental, en la fecha 2026-03-22.
El resultado fue:
- Esta máquina puede establecer directamente una conexión TCP a
mtalk.google.com:5228. - Al conectar, el extremo remoto al que realmente se conecta es
2404:6800:4008:c02::bc:5228. - En la configuración de
mihomode esta máquina,GoogleFCMestá separado como un grupo de reglas específico y por defecto se priorizaDIRECT.
Esto no significa que todas las redes de China continental sean así, pero al menos indica: la afirmación “FCM en China continental necesariamente debe ir por proxy” no se sostiene. En algunas redes, simplemente puede conectarse directamente.
Entonces, ¿hay que dar respaldo por proxy a FCM o no?
Mi recomendación es: priorizar la conexión directa y, si hace falta, mantener un proxy como respaldo.
Hay tres razones:
- Esto se acerca más a la recomendación oficial de Google para el FCM del lado del dispositivo.
- Las conexiones persistentes de push suelen ser más sensibles a las interferencias: cuanto más simple la ruta, más estable.
- Algunas redes sí bloquean endpoints tipo
mtalk; en ese caso, un respaldo por proxy sigue siendo valioso.
Así que en herramientas tipo mihomo / Clash, una idea razonable suele ser:
- Separar
GoogleFCMcomo regla independiente. - Probar primero
DIRECTpor defecto. - Si en tu red la conexión directa falla a menudo, entonces usar algún nodo estable como respaldo manual.
Una última frase de resumen
China continental no es “todo Google puede conectarse directamente”, ni tampoco “todo Google debe pasar por proxy”; una formulación más precisa es: distintos servicios de Google activan destinos de red distintos. La rama de push de FCM, al usar dominios, puertos y protocolos diferentes, y dado que oficialmente se recomienda que el dispositivo se conecte directamente, puede funcionar de forma directa en parte de las redes de China continental, y no es algo extraño.
Referencias
-
Documentación oficial de Firebase: configuración de red de FCM
为 FCM 配置网络 | Firebase Cloud Messaging -
OONI Explorer: panorama general de mediciones de red en China
Internet Censorship in China - OONI Explorer -
Índice público de GreatFire:
mtalk.google.com/mtalk.google.com:5228/alt1-8-mtalk.google.comcon entradas0%
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 de GreatFire:
www.google.com, YouTube, etc. con muchas entradas100% blocked
https://en.greatfire.org/SEARCH/URLS?page=390
https://en.greatfire.org/SEARCH/HTTPS?page=202