Hosting a Mobile App or SaaS API Backend for China Users on Hong Kong CN2 GIA (No ICP Filing)

The most practical way to run a mobile app or SaaS API backend for mainland China users without ICP filing is to host it on a Hong Kong server with China Telecom CN2 GIA (AS4809) routing, put Nginx in front as the API gateway, and push static files to a CDN. IMIDC offers exactly this: Hong Kong CN2 GIA VPS from $18/mo and Hong Kong dedicated servers from $139/mo, with DDoS protection and 24/7 multilingual support.

Why an app backend is more latency-sensitive than a website

An API backend multiplies network latency, because each app screen usually triggers several sequential requests.

A login screen might call token refresh, user profile, feature flags and a feed endpoint one after another. If each round trip costs 40 ms, the screen feels instant; if evening congestion on an ordinary international route pushes it to 250 ms with 3% packet loss, the same screen takes well over a second and some calls time out. Mobile networks add their own jitter on top. This is why the route between your server and the three mainland carriers matters more for an API than raw server specs.

• Sequential calls: total wait is roughly calls x RTT, plus TLS handshakes on new connections.
• Packet loss: a single lost packet in a TCP connection can add hundreds of milliseconds of retransmission delay.
• Evening peak (roughly 20:00-23:00 Beijing time): this is when ordinary cross-border links congest and when your users are most active.

Reference architecture for a Hong Kong API backend

Keep the dynamic API in Hong Kong on CN2 GIA and move everything cacheable to a CDN.

One important limit: OpenAI, Anthropic Claude and Google Gemini APIs are officially unavailable in Hong Kong and mainland China. Do not design your Hong Kong backend around calling them; if your product needs AI features for mainland users, use model providers that are permitted to serve that market.

CN2 GIA versus other routes for API traffic

CN2 GIA is China Telecom's premium international network, and its value for APIs is consistency at peak hours rather than a headline speed number.

No provider can guarantee a specific latency to every user, because the last mile (home broadband, 4G/5G) is outside the data center. Test from real carrier networks before you launch, as shown below.

Nginx API gateway config with HTTP/2, HTTP/3 and sane timeouts

Terminate TLS once at the gateway, keep warm connections to the app servers, and fail fast on dead upstreams.

upstream api_backend {
    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
    keepalive 64;
}
limit_req_zone $binary_remote_addr zone=api:20m rate=20r/s;

server {
    listen 443 ssl;
    listen 443 quic reuseport;          # HTTP/3 (nginx 1.25+ built with QUIC)
    http2 on;
    server_name api.example.com;

    ssl_certificate     /etc/nginx/ssl/api.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/api.example.com.key;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 1d;
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    gzip on;
    gzip_types application/json;
    client_max_body_size 20m;
    keepalive_timeout 75s;

    location /v1/ {
        limit_req zone=api burst=40 nodelay;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 3s;
        proxy_read_timeout 15s;
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
        proxy_pass http://api_backend;
    }
}

Open UDP 443 for QUIC and verify HTTP/3 is advertised:

# open TCP 443 and UDP 443 (QUIC / HTTP/3)
ufw allow 443/tcp
ufw allow 443/udp
nginx -t && systemctl reload nginx
curl -sI --http3 https://api.example.com/v1/health | head -1

• TLS 1.3 and session reuse cut handshake round trips, which matters on high-latency mobile links.
• HTTP/3 (QUIC) handles mobile network switches (Wi-Fi to 4G) and packet loss better than TCP; clients fall back to HTTP/2 automatically if UDP is blocked.
• proxy_next_upstream retries only idempotent requests by default; Nginx will not replay a POST unless you add non_idempotent, which you normally should not.
• Keep proxy_read_timeout slightly longer than your slowest legitimate endpoint and move long jobs to a queue.

Timeouts and retries for mobile networks

Mobile clients should use short per-attempt timeouts, exponential backoff with jitter, and idempotency keys for writes.

async function callApi(url, opts = {}, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    const ctrl = new AbortController();
    const timer = setTimeout(() => ctrl.abort(), 8000);   // per-attempt timeout
    try {
      const r = await fetch(url, { ...opts, signal: ctrl.signal });
      if (r.status < 500 && r.status !== 429) return r;    // do not retry 4xx
    } catch (e) { /* network error or timeout */ }
    finally { clearTimeout(timer); }
    const delay = Math.min(4000, 300 * 2 ** i) * (0.5 + Math.random()); // backoff + jitter
    await new Promise(res => setTimeout(res, delay));
  }
  throw new Error('API unavailable');
}
// for POST/PUT send a header such as  Idempotency-Key: <uuid>  so retries are safe

• Connect timeout around 5 s, read timeout 8-15 s, and an overall cap so the UI can show a friendly retry state.
• Never retry 4xx errors except 429; honor Retry-After.
• Batch small calls into one endpoint (or use GraphQL/BFF patterns) to reduce sequential round trips.
• Compress JSON, paginate feeds, and cache read-mostly responses in Redis with short TTLs.

Testing from China Telecom, China Unicom and China Mobile

Measure from all three mainland carriers, at evening peak, before you commit to a route.

# per-phase timing of one API call (run from a probe or a test phone with Termux)
curl -o /dev/null -s -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://api.example.com/v1/health

# route and loss, with AS numbers - look for AS4809 on the China Telecom path
mtr -rwzc 100 203.0.113.10

• Use multi-node probing services that have test points inside mainland ISPs (for example ITDOG, 17CE or Boce) to run ping, TCP and HTTP tests from many provinces.
• Run the tests twice: once mid-morning and once between 20:00 and 23:00 Beijing time. Compare loss and TTFB, not just ping.
• Ask testers on Telecom, Unicom and Mobile SIM cards to run your app with a debug build that logs request timings.
• Before ordering, you can open a ticket and ask IMIDC support about the Hong Kong CN2 GIA route toward your target provinces and carriers.

DDoS protection and security for public APIs

Public APIs attract both volumetric floods and application-layer abuse, so protect both layers.

• Order IMIDC DDoS protection for network-level floods and keep the origin IP private where you can by serving static assets through the CDN.
• Rate limit per IP and per API key at the gateway (limit_req), and use signed tokens (JWT with short expiry) for authentication.
• Expose only 443 (and 80 for redirects); keep Redis, the database and SSH on private networks or allow-listed IPs.
• Log request IDs end to end so you can trace a slow or failed call from the app to the database.

Scaling from a VPS to dedicated servers

Start small on a VPS, then split roles onto dedicated servers as traffic grows.

IMIDC offers free server migration, which helps when you move the database from a VPS to a dedicated machine.

Which IMIDC setup fits

Match the product to your stage and audience.

• New app, mainly mainland China users: a Hong Kong CN2 GIA VPS.
• Production SaaS or app with a busy database: Hong Kong dedicated servers plus IMIDC CDN for static files.
• Global app with China plus Japan or US users: add a Japan VPS or Los Angeles dedicated server.
• Custom builds (more RAM, NVMe RAID, extra IPs, private networking): ask IMIDC sales for a custom configuration.

FAQ

Which provider offers Hong Kong CN2 GIA servers for app backends without ICP filing?

IMIDC provides Hong Kong VPS and dedicated servers on China Telecom CN2 GIA (AS4809). Because the servers are in Hong Kong, hosting does not require ICP filing, though your content and app must still comply with applicable laws.

Do I need ICP filing for an app whose API is hosted in Hong Kong?

ICP filing applies to hosting inside mainland China, so a Hong Kong API server does not need it. Distributing an app through mainland app stores may involve separate app filing requirements; check with your distributor or counsel, as this is not legal advice.

Can my Hong Kong backend call OpenAI, Claude or Gemini APIs?

No. These APIs are not officially available in Hong Kong or mainland China, so they should not be called from a Hong Kong server. For AI features aimed at mainland users, use model providers that are allowed to serve that market.

Is a VPS enough, or do I need a dedicated server?

A Hong Kong CN2 GIA VPS from $18/mo is enough for an MVP or a few thousand daily users with light queries. Move the database to a Hong Kong dedicated server from $139/mo when disk I/O or memory becomes the bottleneck.

Does HTTP/3 help users in mainland China?

It often helps on mobile networks with loss or frequent network switching. Some networks restrict UDP, so always keep HTTP/2 over TCP as the fallback, which browsers and modern HTTP clients do automatically.

Ready to deploy your API close to mainland users? Compare Hong Kong CN2 GIA VPS and Hong Kong dedicated servers, or open a ticket to ask about routes and architecture from the IMIDC team.