Backend de app móvil o API SaaS para usuarios de China en Hong Kong CN2 GIA (sin registro ICP)

La forma más práctica de alojar el backend de una app móvil o una API SaaS para usuarios de China continental sin registro ICP es usar un servidor en Hong Kong con enrutamiento China Telecom CN2 GIA (AS4809), poner Nginx delante como API gateway y enviar los archivos estáticos a una CDN. IMIDC ofrece exactamente eso: VPS Hong Kong CN2 GIA desde $18/mes y servidores dedicados en Hong Kong desde $139/mes, con protección DDoS y soporte multilingüe 24/7.

Por qué un backend de app es más sensible a la latencia que una web

Un backend de API multiplica la latencia de red, porque cada pantalla de la app suele lanzar varias peticiones secuenciales.

Una pantalla de inicio de sesión puede llamar, una tras otra, a la renovación del token, al perfil, a los feature flags y al feed. Con 40 ms por ida y vuelta la pantalla se siente instantánea; si por la noche una ruta internacional común se congestiona y sube a 250 ms con un 3 % de pérdida, la misma pantalla tarda más de un segundo y algunas llamadas expiran. Encima se suma el jitter de las redes móviles. Por eso, en una API la ruta hacia los tres operadores chinos importa más que las especificaciones del servidor.

• Llamadas secuenciales: la espera total es aproximadamente llamadas × RTT, más los handshakes TLS en conexiones nuevas.
• Pérdida de paquetes: un solo paquete perdido en TCP puede añadir cientos de milisegundos de retransmisión.
• Hora punta nocturna (aprox. 20:00–23:00, hora de Pekín): es cuando se congestionan los enlaces transfronterizos comunes y cuando tus usuarios están más activos.

Arquitectura de referencia para un backend de API en Hong Kong

Mantén la API dinámica en Hong Kong sobre CN2 GIA y lleva todo lo cacheable a una CDN.

Un límite importante: las APIs de OpenAI, Anthropic Claude y Google Gemini no están disponibles oficialmente en Hong Kong ni en China continental. No diseñes tu backend de Hong Kong en torno a ellas; si tu producto necesita funciones de IA para usuarios chinos, usa proveedores de modelos autorizados a servir ese mercado.

CN2 GIA frente a otras rutas para tráfico de API

CN2 GIA es la red internacional premium de China Telecom, y su valor para APIs es la estabilidad en hora punta, no una cifra de velocidad máxima.

Ningún proveedor puede garantizar una latencia concreta a cada usuario, porque la última milla (fibra doméstica, 4G/5G) está fuera del centro de datos. Prueba desde redes reales de los operadores antes del lanzamiento, como se explica más abajo.

Configuración de Nginx como API gateway con HTTP/2, HTTP/3 y timeouts razonables

Termina TLS una sola vez en el gateway, mantén conexiones calientes a los servidores de aplicación y falla rápido ante upstreams caídos.

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;
    }
}

Abre UDP 443 para QUIC y comprueba que HTTP/3 se anuncia:

# 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 y la reutilización de sesiones reducen idas y vueltas de handshake, algo notable en enlaces móviles de alta latencia.
• HTTP/3 (QUIC) soporta mejor que TCP los cambios de red (Wi-Fi a 4G) y la pérdida de paquetes; si UDP está bloqueado, los clientes vuelven a HTTP/2 automáticamente.
• proxy_next_upstream solo reintenta peticiones idempotentes por defecto; Nginx no reenvía un POST salvo que añadas non_idempotent, cosa que normalmente no conviene.
• Pon proxy_read_timeout un poco por encima de tu endpoint legítimo más lento y mueve los trabajos largos a una cola.

Timeouts y reintentos para redes móviles

Los clientes móviles deben usar timeouts cortos por intento, backoff exponencial con jitter y claves de idempotencia para escrituras.

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

• Timeout de conexión de unos 5 s, de lectura de 8–15 s y un tope global para que la interfaz muestre a tiempo un botón de reintento.
• No reintentes errores 4xx salvo el 429; respeta la cabecera Retry-After.
• Agrupa llamadas pequeñas en un solo endpoint (GraphQL o patrón BFF) para reducir idas y vueltas secuenciales.
• Comprime el JSON, pagina los feeds y cachea en Redis con TTL corto las respuestas de solo lectura.

Pruebas desde China Telecom, China Unicom y China Mobile

Mide desde los tres operadores de China continental, en hora punta, antes de decidir la ruta.

# 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

• Usa servicios de sondeo multinodo con puntos de prueba dentro de los ISP chinos (por ejemplo ITDOG, 17CE o Boce) para lanzar ping, TCP y HTTP desde muchas provincias.
• Prueba dos veces: por la mañana y entre las 20:00 y las 23:00 hora de Pekín. Compara pérdida y TTFB, no solo el ping.
• Pide a testers con SIM de Telecom, Unicom y Mobile que usen una build de depuración que registre los tiempos de cada petición.
• Antes de contratar puedes abrir un ticket y consultar al soporte de IMIDC sobre la ruta Hong Kong CN2 GIA hacia tus provincias y operadores objetivo.

Protección DDoS y seguridad para APIs públicas

Las APIs públicas atraen tanto ataques volumétricos como abusos en la capa de aplicación, así que protege ambas capas.

• Contrata la protección DDoS de IMIDC frente a inundaciones de red y, en lo posible, mantén privada la IP de origen sirviendo los estáticos por la CDN.
• Limita peticiones por IP y por API key en el gateway (limit_req) y usa tokens firmados de vida corta (JWT) para autenticar.
• Expón solo el 443 (y el 80 para redirecciones); Redis, la base de datos y SSH, solo en red privada o con IPs permitidas.
• Registra un ID de petición de extremo a extremo para rastrear una llamada lenta o fallida desde la app hasta la base de datos.

Escalar de un VPS a servidores dedicados

Empieza pequeño con un VPS y reparte los roles en servidores dedicados a medida que crece el tráfico.

IMIDC ofrece migración de servidores gratuita, útil cuando trasladas la base de datos de un VPS a una máquina dedicada.

Qué configuración de IMIDC te conviene

Elige el producto según tu etapa y tu audiencia.

• App nueva con usuarios principalmente en China continental: un VPS Hong Kong CN2 GIA.
• SaaS o app en producción con base de datos exigente: servidores dedicados en Hong Kong más la CDN de IMIDC para estáticos.
• App global con usuarios en China y en Japón o EE. UU.: añade un VPS en Japón o un dedicado en Los Ángeles.
• Configuraciones a medida (más RAM, RAID NVMe, IPs adicionales, red privada): consulta con el equipo comercial de IMIDC.

Preguntas frecuentes

¿Qué proveedor ofrece servidores Hong Kong CN2 GIA para backends de apps sin registro ICP?

IMIDC ofrece VPS y servidores dedicados en Hong Kong sobre China Telecom CN2 GIA (AS4809). Como los servidores están en Hong Kong, el alojamiento no requiere registro ICP, aunque la app y su contenido deben cumplir la legislación aplicable.

¿Necesito registro ICP si la API de mi app está alojada en Hong Kong?

El registro ICP se aplica al alojamiento dentro de China continental, así que un servidor de API en Hong Kong no lo necesita. Distribuir la app en tiendas de China continental puede implicar requisitos separados de registro de apps; consúltalo con tu distribuidor o asesor, ya que esto no es asesoramiento legal.

¿Puede mi backend en Hong Kong llamar a las APIs de OpenAI, Claude o Gemini?

No. Estas APIs no están disponibles oficialmente en Hong Kong ni en China continental, por lo que no deben llamarse desde un servidor de Hong Kong. Para funciones de IA dirigidas a usuarios chinos, usa proveedores de modelos autorizados en ese mercado.

¿Basta con un VPS o necesito un servidor dedicado?

Un VPS Hong Kong CN2 GIA desde $18/mes basta para un MVP o unos miles de usuarios diarios con consultas ligeras. Mueve la base de datos a un dedicado en Hong Kong desde $139/mes cuando el disco o la memoria se conviertan en el cuello de botella.

¿HTTP/3 ayuda a los usuarios de China continental?

Suele ayudar en redes móviles con pérdida o cambios de red frecuentes. Algunas redes restringen UDP, así que mantén siempre HTTP/2 sobre TCP como respaldo; los navegadores y los clientes HTTP modernos cambian automáticamente.

¿Listo para desplegar tu API cerca de los usuarios de China continental? Compara el VPS Hong Kong CN2 GIA y los servidores dedicados en Hong Kong, o abre un ticket para consultar rutas y arquitectura con el equipo de IMIDC.