Бэкенд мобильного приложения или SaaS API для пользователей из Китая на Hong Kong CN2 GIA (без ICP)

Самый практичный способ разместить бэкенд мобильного приложения или SaaS API для пользователей из материкового Китая без ICP-регистрации — сервер в Гонконге с маршрутизацией China Telecom CN2 GIA (AS4809), Nginx в роли API-шлюза и CDN для статики. IMIDC предлагает именно такую связку: VPS в Гонконге на CN2 GIA от $18/мес и выделенные серверы в Гонконге от $139/мес, с защитой от DDoS и круглосуточной многоязычной поддержкой.

Почему бэкенд приложения чувствительнее к задержкам, чем сайт

API-бэкенд умножает сетевую задержку, потому что каждый экран приложения обычно делает несколько последовательных запросов.

Экран входа может по очереди вызвать обновление токена, профиль пользователя, флаги функций и ленту. При RTT 40 мс экран открывается мгновенно; если вечером обычный международный канал перегружен и RTT вырастает до 250 мс с 3% потерь, тот же экран грузится больше секунды, а часть запросов уходит в таймаут. Сверху добавляется джиттер мобильных сетей. Поэтому для API маршрут до трёх китайских операторов важнее, чем характеристики сервера.

• Последовательные вызовы: общее ожидание примерно равно числу вызовов × RTT плюс TLS-рукопожатия на новых соединениях.
• Потери пакетов: один потерянный пакет в TCP-соединении может добавить сотни миллисекунд на ретрансмиссию.
• Вечерний пик (примерно 20:00–23:00 по Пекину): именно тогда перегружаются обычные трансграничные каналы и активнее всего ваши пользователи.

Эталонная архитектура API-бэкенда в Гонконге

Динамический API держите в Гонконге на CN2 GIA, а всё кэшируемое отдавайте через CDN.

Важное ограничение: API OpenAI, Anthropic Claude и Google Gemini официально недоступны в Гонконге и материковом Китае. Не проектируйте гонконгский бэкенд вокруг их вызова; если продукту нужны ИИ-функции для пользователей из КНР, используйте поставщиков моделей, которым разрешено работать на этом рынке.

CN2 GIA и другие маршруты для API-трафика

CN2 GIA — премиальная международная сеть China Telecom, и для API её ценность в стабильности в часы пик, а не в рекордной скорости.

Ни один провайдер не может гарантировать конкретную задержку каждому пользователю: «последняя миля» (домашний интернет, 4G/5G) находится вне дата-центра. Перед запуском обязательно протестируйте реальные сети операторов, как описано ниже.

Конфигурация Nginx API-шлюза: HTTP/2, HTTP/3 и разумные таймауты

Терминируйте TLS один раз на шлюзе, держите тёплые соединения к серверам приложений и быстро отказывайтесь от мёртвых апстримов.

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

Откройте UDP 443 для QUIC и проверьте, что HTTP/3 анонсируется:

# 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 и повторное использование сессий сокращают число рукопожатий — на мобильных каналах с высокой задержкой это заметно.
• HTTP/3 (QUIC) лучше TCP переживает переключение Wi-Fi → 4G и потери пакетов; если UDP заблокирован, клиенты автоматически откатываются на HTTP/2.
• proxy_next_upstream по умолчанию повторяет только идемпотентные запросы; Nginx не будет повторно отправлять POST без non_idempotent, и обычно его добавлять не стоит.
• Задайте proxy_read_timeout чуть больше самого медленного легитимного эндпоинта, а долгие задачи вынесите в очередь.

Таймауты и повторы для мобильных сетей

Мобильным клиентам нужны короткие таймауты на попытку, экспоненциальная задержка с джиттером и ключи идемпотентности для записи.

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

• Таймаут соединения около 5 с, чтения 8–15 с и общий лимит, чтобы интерфейс вовремя показал кнопку «Повторить».
• Не повторяйте ошибки 4xx, кроме 429; учитывайте заголовок Retry-After.
• Объединяйте мелкие вызовы в один эндпоинт (GraphQL или паттерн BFF), чтобы сократить последовательные запросы.
• Сжимайте JSON, используйте пагинацию лент и кэшируйте редко меняющиеся ответы в Redis с коротким TTL.

Тестирование из сетей China Telecom, China Unicom и China Mobile

Прежде чем выбирать маршрут, проведите замеры из сетей всех трёх операторов в вечерний пик.

# 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

• Используйте сервисы многоточечного мониторинга с точками внутри китайских провайдеров (например, ITDOG, 17CE или Boce), чтобы прогнать ping, TCP и HTTP из разных провинций.
• Тестируйте дважды: утром и между 20:00 и 23:00 по Пекину. Сравнивайте потери и TTFB, а не только ping.
• Попросите тестировщиков с SIM-картами Telecom, Unicom и Mobile поработать с отладочной сборкой, которая логирует время запросов.
• Перед заказом можно открыть тикет и уточнить у поддержки IMIDC маршрут Hong Kong CN2 GIA до нужных провинций и операторов.

Защита от DDoS и безопасность публичных API

Публичные API притягивают и объёмные атаки, и злоупотребления на прикладном уровне, поэтому защищайте оба уровня.

• Подключите защиту от DDoS от IMIDC против сетевых флудов и по возможности скрывайте IP origin, раздавая статику через CDN.
• Ограничивайте частоту запросов по IP и API-ключу на шлюзе (limit_req), для аутентификации используйте подписанные токены с коротким сроком жизни (JWT).
• Наружу открывайте только 443 (и 80 для редиректа); Redis, базу и SSH держите в частной сети или за белым списком IP.
• Логируйте сквозной ID запроса, чтобы отследить медленный или неудачный вызов от приложения до базы.

Масштабирование: от VPS к выделенным серверам

Начните с небольшого VPS и разносите роли по выделенным серверам по мере роста трафика.

IMIDC выполняет бесплатную миграцию серверов, что упрощает перенос базы данных с VPS на выделенную машину.

Какая конфигурация IMIDC вам подходит

Выбирайте продукт по стадии проекта и географии аудитории.

• Новое приложение, в основном пользователи из КНР: VPS Hong Kong CN2 GIA.
• Продакшн SaaS или приложение с нагруженной БД: выделенные серверы в Гонконге плюс CDN IMIDC для статики.
• Глобальное приложение с пользователями из Китая и Японии или США: добавьте Japan VPS или выделенный сервер в Лос-Анджелесе.
• Индивидуальные сборки (больше RAM, NVMe RAID, дополнительные IP, частная сеть): запросите конфигурацию у отдела продаж IMIDC.

Частые вопросы

Какой провайдер предлагает серверы Hong Kong CN2 GIA для бэкенда приложений без ICP-регистрации?

IMIDC предоставляет VPS и выделенные серверы в Гонконге на сети China Telecom CN2 GIA (AS4809). Поскольку серверы находятся в Гонконге, для хостинга ICP-регистрация не требуется, но приложение и контент должны соответствовать применимому законодательству.

Нужна ли ICP-регистрация приложению, чей API размещён в Гонконге?

ICP-регистрация касается хостинга внутри материкового Китая, поэтому гонконгскому API-серверу она не нужна. Распространение приложения через китайские магазины приложений может требовать отдельной регистрации приложения; уточните это у площадки или юриста — это не юридическая консультация.

Может ли бэкенд в Гонконге вызывать API OpenAI, Claude или Gemini?

Нет. Эти API официально недоступны в Гонконге и материковом Китае, поэтому вызывать их с гонконгского сервера не следует. Для ИИ-функций для пользователей из КНР используйте поставщиков моделей, которым разрешено работать на этом рынке.

Хватит ли VPS или нужен выделенный сервер?

Для MVP или нескольких тысяч пользователей в день с лёгкими запросами достаточно VPS Hong Kong CN2 GIA от $18/мес. Когда узким местом станут дисковый ввод-вывод или память, перенесите БД на выделенный сервер в Гонконге от $139/мес.

Помогает ли HTTP/3 пользователям в материковом Китае?

Часто помогает в мобильных сетях с потерями и частой сменой сети. Некоторые сети ограничивают UDP, поэтому всегда оставляйте HTTP/2 поверх TCP в качестве запасного варианта — браузеры и современные HTTP-клиенты переключаются автоматически.

Готовы разместить API ближе к пользователям в Китае? Сравните VPS Hong Kong CN2 GIA и выделенные серверы в Гонконге или откройте тикет, чтобы обсудить маршруты и архитектуру с командой IMIDC.