Firebase alternatives for China, by function
We probed Firebase from Mainland China on 2026-06-25. Each function gets a cn-beijing verdict and China replacement — Auth, Firestore, FCM, Storage, Functions.
Firebase bundles more than twenty products under one console. That convenience hides a geography problem: most of the stack assumes Google infrastructure is reachable from the client. From Mainland China it often is not — or it is slow enough that users experience broken login, stalled databases, and push that never arrives.
To move past “it probably breaks,” we built a small demo app on a real Firebase project and probed every product from inside Mainland China — once as the user’s browser would reach Firebase, and once as a Mainland China app server would. This guide maps Firebase’s full product list to a concrete probe you can run, the verdict we measured from a Beijing node on 2026-06-25, and the China-local alternative where replacement is warranted.
How we tested
The demo app
We provisioned a tiny “field reports” app — the kind of CRUD product most teams ship. A Mainland China user signs in (Auth), posts a short report document (Firestore), attaches a photo (Storage), a callable function stamps it (Functions), peers get a push (FCM), and an in-app banner is toggled by Remote Config.
Two vantage points, one Mainland China host
A real product touches Firebase from two places, and the assumption here is that both are in Mainland China: the user’s browser/client SDK, and the app’s own backend. So every user-facing product gets probed along two paths, both run from a single Alibaba Cloud ECS
in cn-beijing:
| Path | What it represents | Tooling |
|---|---|---|
| Frontend path | The user’s browser / client SDK in Mainland China | curl + Web API key, plus a real ID token from the demo user |
| Backend path | The app’s server in Mainland China | the Firebase Admin SDK (firebase-admin) with a service account |
Products we do not provision get a single transport probe — does the host answer from Mainland China at all — which is enough to verdict a service whose failure mode is “the endpoint is unreachable.”
What we provisioned for this run
The 2026-06-25 run uses the project’s real Web keys and a service account, so both paths
are exercised end to end. Provisioned: Authentication (email user + anonymous, both
confirmed working), the Realtime Database (legacy database secret), and Cloud
Firestore (three reports seeded via the Admin SDK from a reachable host). Cloud Storage’s
default bucket was not initialized, and Cloud Functions / Remote Config were not deployed —
none of which changes the China verdict, because the hosts those products depend on are
blocked regardless. The service account is valid — it seeded Firestore from outside China
minutes before the run — so the backend failures below are network-caused, not credential
problems.
Verdict vocabulary
| Verdict | Meaning |
|---|---|
| Blocked | Connection timeout, TLS failure, or hard reset — feature unusable (our probes time out at 10s) |
| Degraded | Connected but slow (>5s) or intermittent across samples |
| Reachable | Probe completes reliably at low latency (any HTTP status) |
| N/A | Developer tooling only — not on the China user critical path |
Provenance
Results below were measured from Alibaba Cloud / cn-beijing-h / launchready.cn on
2026-06-25. The frontend and backend paths were run with the project’s real keys and
service account; the transport set was sampled three times over ~1 hour. The probe kit is
open and reproducible. Carrier, province, and time of day move these numbers — treat the
table as a starting point and re-run the probes on your own traffic path.
Measured snapshot — 2026-06-25, cn-beijing
The raw probe output, both paths. The pattern is the story: *.googleapis.com Firebase
endpoints are Blocked on the frontend, the server-side Admin SDK is Blocked too, and
only a handful of non-googleapis hosts answer — yet the user-facing feature still breaks
because its SDK also depends on a blocked endpoint.
| Product | Path | Probe | HTTP | Total (s) | Verdict |
|---|---|---|---|---|---|
| Authentication | frontend | anonymous sign-up | 000 | 10.00 | Blocked |
| Authentication | frontend | email sign-in | 000 | 10.00 | Blocked |
| Cloud Firestore | frontend | authed read | 000 | 10.00 | Blocked |
| Cloud Storage | frontend | object download | 000 | 10.00 | Blocked |
| Cloud Functions | frontend | helloProbe HTTP | 000 | 10.00 | Blocked |
| Authentication | backend | Admin SDK user lookup | auth-token-blocked | 1.38 | Blocked |
| Cloud Firestore | backend | Admin SDK write+read | timeout | 30.01 | Blocked |
| Cloud Storage | backend | Admin SDK metadata | ETIMEDOUT | 3.67 | Blocked |
| Cloud Messaging | backend | Admin SDK FCM v1 send | auth-token-blocked | 1.36 | Blocked |
| Remote Config | backend | Admin SDK get template | auth-token-blocked | 1.36 | Blocked |
| Firebase ML / Vision | transport | vision.googleapis.com | 000 | 10.00 | Blocked |
| Firebase AI Logic | transport | generativelanguage | 000 | 10.00 | Blocked |
| Google Analytics | transport | app-measurement.com | 404 | 0.20 | Reachable |
| Crashlytics | transport | settings host | 404 | 0.27 | Reachable |
| Performance Mon. | transport | firebaselogging | 000 | 10.00 | Blocked |
| Remote Config | transport | firebaseremoteconfig | 000 | 10.00 | Blocked |
| Cloud Messaging | transport | installations host | 000 | 10.00 | Blocked |
| Cloud Messaging | transport | fcm.googleapis.com | 000 | 10.00 | Blocked |
| App Check | transport | reCAPTCHA loader | 000 | 10.00 | Blocked |
| App Distribution | transport | appdistribution host | 000 | 10.00 | Blocked |
| Cloud Messaging | transport | mtalk.google.com:5228 (TCP) | — | 0.20 | Reachable |
| Hosting | transport | *.web.app | 404/000/404 | 0.89–3.06 | Degraded (intermittent) |
| Realtime Database | transport | firebaseio.com (unauth) | 401 | 1.5–6.0 | Reachable (slow) |
| Realtime Database | backend | authed write (legacy key) | 200 | 0.92 | Reachable |
The backend choke point: one blocked endpoint kills the Admin SDK
The server path fails before it touches any product. The Admin SDK’s first move is to mint an OAuth2 access token — and the token endpoints are unreachable from cn-beijing:
| Token endpoint | cn-beijing result |
|---|---|
oauth2.googleapis.com | timeout (no connect) |
accounts.google.com | timeout (no connect) |
www.googleapis.com | timeout (no connect) |
So getUserByEmail(), messaging().send(), and getTemplate() all fail in ~1.4s with
auth-token-blocked — not because Auth, FCM, or Remote Config rejected them, but because the
SDK never got a token. Firestore and Storage time out further along, at their own data hosts.
The service account is valid (it seeded Firestore from outside China minutes earlier), so this
is purely a network block: one unreachable endpoint — oauth2.googleapis.com — disables
every server-side Firebase call from Mainland China.
Two more facts. First, mtalk.google.com:5228 accepts a TCP connection from this node, but
that does not mean push works — Mainland China Android ships without Google services, so
no device maintains that channel. Second, the Realtime Database is the one data product that
answered (firebaseio.com connected on every sample); the authenticated write completed in
under a second. Most of the rest of Firebase rides on *.googleapis.com, which did not connect.
At a glance (planning view)
Use this as a planning table; the measured rows above are the evidence. Carrier, province, and time change outcomes.
| Firebase product | User-facing? | Mainland China verdict | Replace for China? |
|---|---|---|---|
| Authentication (email, anonymous) | Yes | Blocked (measured) | Yes |
| Authentication (Google / OAuth) | Yes | Blocked | Yes |
| Authentication (SAML/OIDC) | Yes | Degraded | Often |
| Phone Auth / Phone Number Verification | Yes | Blocked (reCAPTCHA dep) | Yes (domestic SMS) |
| Cloud Firestore | Yes | Blocked (measured) | Yes |
| Realtime Database | Yes | Reachable / Degraded (measured) | Sometimes |
| Cloud Storage | Yes | Blocked (measured) | Yes for media |
| Cloud Functions (client-callable) | Yes | Blocked (measured) | Often |
| Cloud Messaging (FCM) | Yes | Blocked (device + send host) | Yes |
| Hosting / App Hosting | Yes | Degraded (intermittent) | Often |
| Remote Config | Yes | Blocked (measured) | Often |
| Crashlytics | Yes | Settings host reachable; uploads degrade | Often |
| Performance Monitoring | Yes | Blocked (measured) | Often |
| Google Analytics (Firebase) | Yes | Collection host reachable; SDK degrades | Often |
| A/B Testing | Yes | Degraded (depends on RC + Analytics) | Sometimes |
| In-App Messaging | Yes | Degraded | Sometimes |
| App Check | Yes | Blocked (reCAPTCHA) | Yes |
| Firebase ML / Cloud Vision | Yes | Blocked (measured) | Yes |
| SQL Connect (Cloud SQL) | Yes | Degraded (not probed) | Often |
| App Distribution | No (dev) | Blocked (measured) | No |
| Test Lab | No (dev) | N/A | No |
| Firebase AI Logic / Gemini | Yes / dev | Blocked (measured) | Yes |
| Firebase Studio / Gemini in Firebase | No (dev) | N/A | No |
| Extensions | Varies | Varies | Per extension |
Build — data, auth, and compute
Authentication
What it does. Email/password, anonymous, phone, and OAuth (Google, Apple, etc.) via Identity Toolkit.
Mainland China behavior. Blocked. From cn-beijing both anonymous sign-up and email sign-in
time out — identitytoolkit.googleapis.com never connects. (For reference, the same calls
complete fine from outside China, where we created the demo user.)
Frontend path — anonymous sign-up (client REST):
curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
-X POST "https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=$FIREBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"returnSecureToken":true}'cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s(connection timed out).
Frontend path — email sign-in (mints the ID token for later probes):
curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
-X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=$FIREBASE_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"email\":\"$DEMO_USER_EMAIL\",\"password\":\"$DEMO_USER_PASSWORD\",\"returnSecureToken\":true}"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s. Token refresh is never reached because sign-in itself does not connect.
Backend path — Admin SDK user lookup (a Mainland China server verifying accounts) is
Blocked too — getUserByEmail() failed in 1.38s with auth-token-blocked: the Admin
SDK could not reach oauth2.googleapis.com to mint an access token (see the backend choke
point above). The service account is valid; the token endpoint is simply unreachable.
China alternatives.
| Need | Domestic options |
|---|---|
| Email / phone login | Amazon Cognito (AWS China, Beijing region), Authing, Alibaba Cloud IDaaS, Tencent Cloud IDaaS |
| OAuth / social | Provider-specific Mainland China SDKs (WeChat, Alipay) via the IDaaS vendors above |
| Enterprise SAML/OIDC | Amazon Cognito (AWS China, Beijing region), Authing, Aliyun IDaaS, self-hosted Keycloak on a China-region VPC |
Phone Auth & Phone Number Verification
What it does. SMS OTP for sign-in and standalone phone verification (Firebase PNV).
Mainland China behavior. Blocked. The flow requires a reCAPTCHA token, and the reCAPTCHA loader is Blocked from cn-beijing (see App Check) — phone OTP fails before the SMS can send. Google-sent SMS to +86 numbers is unreliable on top of that.
Frontend path — trigger SMS (requires enabled Phone Auth + a test number):
curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
-X POST "https://identitytoolkit.googleapis.com/v1/accounts:sendVerificationCode?key=$FIREBASE_API_KEY" \
-H "Content-Type: application/json" \
-d '{"phoneNumber":"+86YOUR_TEST_NUMBER","recaptchaToken":".."}'cn-beijing (2026-06-25): Blocked upstream — the reCAPTCHA dependency (
www.google.com) timed out attotal=10.00s, so the OTP call cannot be made.
China alternatives. Alibaba Cloud SMS, Tencent Cloud SMS, NetEase Yunxin, Chuanglan — integrated through your auth layer, not through Firebase Phone Auth.
Cloud Firestore
What it does. Document database with realtime listeners (WebSocket/gRPC).
Mainland China behavior. Blocked. firestore.googleapis.com does not connect from
cn-beijing — single reads and onSnapshot listeners alike fail.
Frontend path — authenticated read of a seeded doc:
curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
-H "Authorization: Bearer $ID_TOKEN" \
"https://firestore.googleapis.com/v1/projects/$FIREBASE_PROJECT_ID/databases/(default)/documents/reports/report-001"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
Backend path — Admin SDK write + read-back is Blocked — the firestore.googleapis.com
gRPC channel never connects and the probe times out at 30s. (Documents seed fine via the
Admin SDK from outside China, confirming the credential is valid.)
China alternatives.
| Pattern | Domestic options |
|---|---|
| Document DB + realtime | Amazon DynamoDB + AWS AppSync (real-time GraphQL; AWS China Beijing/Ningxia), LeanCloud, Tencent Cloud TDSQL-C / MongoDB on domestic cloud, Alibaba Tablestore |
| Full BaaS replacement | LeanCloud, MemFire Cloud (Supabase-compatible, China-hosted) |
| Self-managed | Amazon DynamoDB / DocumentDB on AWS China, or PostgreSQL / MongoDB on Alibaba/Tencent/Huawei Cloud in cn-* regions |
Realtime Database
What it does. JSON tree with WebSocket sync (*.firebaseio.com).
Mainland China behavior. The exception in the data tier. firebaseio.com is reachable
from this Beijing node: an authenticated write (legacy database secret) completed in 0.92s
(Reachable), and an unauthenticated request connected on every sample, returning 401 in
1.5–6.0s (Reachable but variable). Long-lived WebSocket sync may still suffer, but the host answers — unlike
Firestore/Storage on *.googleapis.com.
Transport probe (unauthenticated):
curl -sS -o /dev/null -w "rtdb code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 "${FIREBASE_DB_URL%/}/.json"cn-beijing (2026-06-25): Reachable but variable —
code=401,total=1.5–6.0sacross samples (connects every time, auth required, latency swings).
Backend path — authenticated write (legacy DB secret):
curl -sS -o /dev/null -w "rtdb-auth code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
-X PUT "${FIREBASE_DB_URL%/}/probes/ecs.json?auth=$GOOGLE_DB_KEY" \
-H "Content-Type: application/json" -d '{"src":"ecs"}'cn-beijing (2026-06-25): Reachable —
code=200 total=0.92s.
China alternatives. Even when reachable, weigh latency and compliance — AWS AppSync (real-time GraphQL) or AWS IoT Core (MQTT) in the AWS China Beijing/Ningxia regions, a domestic document/realtime DB, or an MQTT layer (Alibaba Cloud MQTT, EMQX on domestic cloud) for pure pub/sub patterns.
Cloud Storage
What it does. Object storage for user uploads, media, and static assets
(firebasestorage.googleapis.com).
Mainland China behavior. Blocked. The download host does not connect from cn-beijing.
Frontend path — download an object:
curl -sS -o /dev/null -w "storage code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://firebasestorage.googleapis.com/v0/b/$FIREBASE_STORAGE_BUCKET/o/probes%2Ffield-report-sample.jpg?alt=media"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
Backend path — Admin SDK metadata is Blocked — getMetadata() failed with
ETIMEDOUT against storage.googleapis.com. (The default bucket was also uninitialized for
this run, but the host is unreachable from cn-beijing regardless.)
China alternatives. Amazon S3 (AWS China, Beijing/Ningxia regions), Alibaba OSS, Tencent COS, Qiniu, Volcengine TOS — front with a domestic CDN (Amazon CloudFront in Ningxia, Alibaba CDN, Tencent CDN, Wangsu) for download-heavy apps.
Cloud Functions
What it does. HTTPS callable functions and background triggers (*.cloudfunctions.net,
*.run.app for 2nd gen).
Mainland China behavior. Blocked. The function host does not connect from cn-beijing; clients and a Mainland China backend alike time out.
Frontend path — call the public helloProbe function:
curl -sS -w "\ncode=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://$FIREBASE_FUNCTIONS_REGION-$FIREBASE_PROJECT_ID.cloudfunctions.net/helloProbe"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
Backend path. A Mainland China server calling the same function hits the same
cloudfunctions.net host — same Blocked result.
China alternatives. AWS Lambda + Amazon API Gateway (AWS China, Beijing/Ningxia regions), Alibaba Function Compute, Tencent SCF, Huawei FunctionGraph.
Hosting & App Hosting
What it does. Static site and full-stack web app hosting on Firebase CDN
(*.web.app, *.firebaseapp.com, App Hosting on Cloud Run).
Mainland China behavior. Degraded (intermittent). Across three samples the *.web.app
host answered twice (404, 0.89s and 3.06s) and timed out once (000) — pages load
unpredictably and slowly. App Hosting adds the same cross-border API problem for SSR data fetches.
Transport probe:
curl -sS -o /dev/null -w "hosting code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://$FIREBASE_PROJECT_ID.web.app/"cn-beijing (2026-06-25): Degraded — sample 1
code=404 total=0.89s, sample 2code=000 total=1.25s.
China alternatives. Static assets on Amazon S3 + Amazon CloudFront (AWS China Ningxia region, ICP required), or Alibaba OSS / Tencent COS + a domestic CDN; dynamic apps on AWS China (EC2 / ECS / Fargate in Beijing/Ningxia), Alibaba SAE, or Tencent CloudBase.
SQL Connect (Cloud SQL)
What it does. Managed PostgreSQL wired into Firebase (newer SQL Connect product).
Mainland China behavior. Degraded (not probed in this run — no Cloud SQL instance). The DB runs in a GCP region with no Mainland China POP; clients in China see high latency and drops.
Transport probe. From the China host, TCP + SSL to the Cloud SQL public IP (if enabled):
timeout 15 bash -c 'echo | openssl s_client -connect CLOUD_SQL_IP:5432 </dev/null 2>&1 | head -3'cn-beijing (2026-06-25): not provisioned for this run.
China alternatives. Amazon RDS / Aurora PostgreSQL (AWS China, Beijing/Ningxia regions), Alibaba RDS PostgreSQL, Tencent PostgreSQL, Huawei RDS — same schema, migrated connection strings for the China app variant.
Firebase ML & Cloud Vision
What it does. On-device custom models and Cloud Vision API calls.
Mainland China behavior. Blocked — vision.googleapis.com does not connect.
Transport probe:
curl -sS -o /dev/null -w "vision code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://vision.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
China alternatives. Alibaba Cloud Vision, Baidu AI Vision, Tencent Cloud TI-OCR — swap the API client in your China build flavor.
App Check
What it does. Attestation that requests come from your real app (reCAPTCHA, Play Integrity, DeviceCheck).
Mainland China behavior. Blocked with the reCAPTCHA provider — the loader on www.google.com
does not connect, so attestation never completes.
Transport probe — reCAPTCHA loader:
curl -sS -o /dev/null -w "recaptcha code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 15 \
"https://www.google.com/recaptcha/api.js"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
China alternatives. Domestic captcha (Geetest, NetEase Yidun) + custom server-side attestation; or App Check with a provider your China build can actually reach.
Extensions
What it does. Pre-packaged Cloud Functions + integrations (Stripe, Algolia, image resize, etc.).
Mainland China behavior. Varies — each extension calls its own third-party APIs and runs on
cloudfunctions.net (Blocked above). Treat as separate line items in your dependency inventory.
How to probe. Identify the extension’s outbound URLs from its source and curl each from
the China host — same transport method as the products above.
China alternatives. Replace per dependency — e.g. Algolia → domestic search (Elasticsearch on domestic cloud), Stripe → WeChat Pay / Alipay via domestic payment aggregators.
Firebase AI Logic
What it does. Gemini and generative AI calls from client or server through Firebase.
Mainland China behavior. Blocked — generativelanguage.googleapis.com does not connect.
Transport probe:
curl -sS -o /dev/null -w "generativelanguage code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://generativelanguage.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
China alternatives. Alibaba Tongyi (Qwen), Baidu ERNIE, Tencent Hunyuan, Zhipu GLM —
route through your backend in a cn-* region; do not call Google AI from the China client.
Run — messaging, analytics, and ops
Cloud Messaging (FCM)
What it does. Push notifications to Android, iOS, and Web.
Mainland China behavior. Blocked. Both the send host (fcm.googleapis.com) and the token
registration host (firebaseinstallations.googleapis.com) time out. Separately, Mainland China
Android ships without Google Mobile Services, so even the device push channel is moot —
we test the network path only.
Backend path — server send host:
curl -sS -o /dev/null -w "fcm code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://fcm.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00sfor the host curl, and the real Admin SDKmessaging().send()is Blocked too (auth-token-blockedin1.36s— it never gets an OAuth token; see the backend choke point above).
Frontend path — token registration host:
curl -sS -o /dev/null -w "installations code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://firebaseinstallations.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
Device channel — TCP to the push transport:
timeout 10 nc -zv mtalk.google.com 5228cn-beijing (2026-06-25): Reachable (TCP) —
total=0.20s. The socket opens, but Mainland China Android has no Google framework to use it, so device delivery still does not happen.
China alternatives. Integrate per OEM/channel — Huawei Push, Xiaomi, OPPO, vivo, Honor, Meizu — or use an aggregator: Alibaba Cloud EMAS, Tencent TPNS, JPush, Getui. See our Android store guide for distribution context.
Remote Config
What it does. Server-driven feature flags and JSON config fetched at app start.
Mainland China behavior. Blocked — firebaseremoteconfig.googleapis.com does not connect;
apps fall back to defaults silently, making rollouts invisible in China.
Frontend path — fetch host reachability:
curl -sS -o /dev/null -w "remoteconfig code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://firebaseremoteconfig.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
Backend path — Admin SDK template fetch is Blocked — getTemplate() failed in 1.36s
with auth-token-blocked (the Admin SDK could not reach oauth2.googleapis.com for a token;
see the backend choke point above).
China alternatives. Domestic config service or embed flags in your China API response; Alibaba Cloud EMAS, Tencent Cloud config, or simple JSON on OSS with short TTL + CDN.
Crashlytics
What it does. Crash and non-fatal error reporting from mobile clients.
Mainland China behavior. Mixed → Degraded. The settings host
(firebase-settings.crashlytics.com) is reachable (404, 0.27s), but the SDK also fetches
configuration from blocked Google hosts and uploads can fail silently, so your dashboard
under-reports China crashes.
Transport probe:
curl -sS -o /dev/null -w "crashlytics code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://firebase-settings.crashlytics.com/"cn-beijing (2026-06-25): Reachable —
code=404 total=0.27s(host answers; full pipeline still degrades).
China alternatives. Tencent Bugly, Alibaba ARMS, Sentry self-hosted on domestic cloud, or Umeng U-APM.
Performance Monitoring
What it does. Automatic traces and custom metrics from mobile/web clients.
Mainland China behavior. Blocked — firebaselogging.googleapis.com does not connect; traces
are lost.
Transport probe:
curl -sS -o /dev/null -w "fireperf code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://firebaselogging.googleapis.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
China alternatives. Tencent Bugly performance, Alibaba ARMS RUM, self-hosted OpenTelemetry collector on domestic infrastructure.
Google Analytics (Firebase Analytics)
What it does. Event analytics bundled with Firebase; feeds GA4.
Mainland China behavior. Mixed → Degraded. The collection host app-measurement.com is
reachable (404, 0.20s), so some events may upload — but the Firebase SDK initializes through
blocked *.googleapis.com endpoints, so China DAU/MAU is still systematically undercounted.
Transport probe:
curl -sS -o /dev/null -w "app-measurement code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://app-measurement.com/"cn-beijing (2026-06-25): Reachable —
code=404 total=0.20s(collection host answers; SDK init still degrades).
China alternatives. Umeng+, Sensors Data, GrowingIO — SDK in the China app flavor; keep GA4 for global builds only.
A/B Testing
What it does. Experiment assignment powered by Analytics + Remote Config.
Mainland China behavior. Degraded — Remote Config is Blocked from cn-beijing, so experiment assignment cannot be fetched; China users land in control with no exposure logged.
How to probe. Run the Remote Config + Analytics probes above; confirm experiment assignment events in debug mode from a Mainland China test device.
China alternatives. Run experiments through whichever domestic analytics + config stack you adopt for China; or segment by app flavor at the API layer.
In-App Messaging
What it does. Targeted in-app banners triggered by Analytics events.
Mainland China behavior. Degraded — campaign fetch depends on the same Google endpoints as Remote Config (Blocked) and Analytics.
How to probe. Same hosts as the Analytics + Remote Config probes; validate with Firebase Debug mode on a Mainland China device.
China alternatives. Domestic push/in-app message platforms (Alibaba Cloud EMAS, JPush, Getui in-app message) or server-driven UI flags via your China API.
App Distribution
What it does. Pre-release APK/IPA distribution to testers.
Mainland China behavior. Blocked for download — appdistribution.firebase.google.com does
not connect from cn-beijing. Developer workflow only; not an end-user concern.
Transport probe:
curl -sS -o /dev/null -w "appdistribution code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 20 \
"https://appdistribution.firebase.google.com/"cn-beijing (2026-06-25): Blocked —
code=000 total=10.00s.
China alternatives. Domestic CI artifacts (Tencent Coding, Alibaba DevOps), TestFlight for iOS, or direct APK hosting on OSS with a QR code — not a production user concern.
Test Lab
What it does. Cloud device farm for automated UI tests.
Mainland China behavior. N/A — CI infrastructure, not user-facing. China users never touch it.
No replacement needed for production; use local devices or domestic CI if Test Lab itself is slow to reach from your China office network.
Developer tooling (not on the user path)
These products appear on the Firebase pricing page but do not affect China end users directly:
| Product | Verdict | Notes |
|---|---|---|
| Firebase Studio | N/A | Online IDE — blocked in Mainland China browsers is annoying for devs, not users |
| Gemini in Firebase | N/A | Console AI assist — use offline or via VPN for development only |
| BigQuery export | N/A | Backend analytics pipeline — runs in GCP, not on client devices |
How to sequence replacements
Do not migrate everything at once. Use probe results on your China traffic share:
- FCM first — clearest failure, longest OEM integration. Ship domestic push before marketing in China app stores.
- Auth second — login is fully Blocked from cn-beijing; nothing else matters if users cannot sign in. Add WeChat/phone via domestic IDaaS while keeping Firebase for global builds.
- Data third — Firestore and Storage are Blocked; the Realtime Database happens to be reachable from our node, but do not bet a product on that — justify migration when China MAU and realtime features demand it.
- Observability fourth — Crashlytics and Analytics hosts partly answer but degrade silently; swap early if you rely on crash-free metrics for release gates.
For the broader backend picture, see Which parts of your stack break first in China.
FAQ
Can I keep one Firebase project for global and China? Yes, with app flavors — global build keeps Firebase SDKs; China build swaps auth, push, storage, and analytics providers. Shared business logic, different platform adapters.
Does Firebase Hosting in asia-east1 fix latency? No. asia-east1 is Taiwan — still
cross-border for Mainland China users and does not change Google API reachability.
Is FCM OK if the server API returns 200? No. The send host did not even connect from
cn-beijing, and Mainland China Android ships without Google services, so the device never holds an
FCM connection on mtalk.google.com to receive the message.
Why is the Realtime Database reachable but Firestore blocked? They live on different
hosts. firebaseio.com answered from our Beijing node; firestore.googleapis.com did not.
Reachability is per-host and per-time — which is exactly why you probe rather than assume.
Do I need ICP filing to use domestic alternatives? Often yes for hosted services and app store distribution in China — filing and network reachability are separate problems. See ICP and PSB filing explained.
References
- AWS China (Beijing & Ningxia) regional product services — the authoritative list of services available in the AWS China regions, used to map the AWS-first alternatives above. AWS China runs on separate accounts operated by Sinnet (Beijing) and NWCD (Ningxia); public-facing web still requires ICP filing.
- Firebase product list & pricing — the full Firebase product surface mapped in this guide.
The probes above are open and reproducible: clone the kit, fill your project config, and run
npm run probe:all from a Mainland China host to regenerate this evidence on your own traffic path.
Chinaready ran them from a Beijing node on 2026-06-25 so foreign product teams can start from
real numbers — then map only the failures to domestic replacements, with evidence, not guesswork.
