用香港 CN2 GIA 伺服器部署面向大陸使用者的 App / SaaS API 後端（免 ICP 備案）

想為中國大陸使用者部署移動 App 或 SaaS API 後端、又不想辦理 ICP 備案，最務實的做法是：把後端放在走中國電信 CN2 GIA（AS4809）線路的香港伺服器上，用 Nginx 作為 API 閘道器，靜態資源交給 CDN。IMIDC 正好提供這套方案：香港 CN2 GIA VPS 每月 $18 起，香港獨立伺服器每月 $139 起，並提供 DDoS 防護和 7×24 多語言技術支援。

為什麼 App 後端比網站更怕延遲

API 後端會把網路延遲成倍放大，因為 App 的一個頁面通常要序列發起好幾次請求。

以登入頁為例：重新整理 token、拉取使用者資料、讀取功能開關、載入首頁資訊流，往往是一個接一個地請求。單次往返 40 ms 時頁面幾乎秒開；如果晚高峰普通國際線路擁塞，往返漲到 250 ms 並伴隨 3% 丟包，同一個頁面就要一秒以上，部分請求還會超時。再疊加行動網路自身的抖動，線路質量對 API 的影響往往比伺服器配置更大。

• 序列請求：總等待時間約等於請求次數 × RTT，新連線還要加上 TLS 握手。
• 丟包：TCP 連線裡丟一個包，重傳就可能多出幾百毫秒。
• 晚高峰（北京時間約 20:00–23:00）：普通跨境鏈路最容易擁塞的時段，恰好也是使用者最活躍的時段。

香港 API 後端參考架構

動態 API 放在香港 CN2 GIA 伺服器上，所有可快取內容交給 CDN。

需要特別注意：OpenAI、Anthropic Claude 和 Google Gemini 的 API 官方不支援香港和中國大陸地區。不要把香港後端設計成呼叫這些介面；如果產品需要為大陸使用者提供 AI 功能，請選用獲准在該市場提供服務的模型廠商。

API 流量走 CN2 GIA 與其他線路對比

CN2 GIA 是中國電信的高階國際網路，對 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）在 Wi-Fi 與 4G 切換、存在丟包時比 TCP 更從容；如果 UDP 被限制，客戶端會自動回落到 HTTP/2。
• proxy_next_upstream 預設只重試冪等請求；除非加上 non_idempotent（通常不建議），Nginx 不會重放 POST。
• 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 秒，再設一個總上限，便於 UI 及時給出“點選重試”提示。
• 除 429 外不要重試 4xx 錯誤；遵守 Retry-After 響應頭。
• 把零碎請求合併成一個介面（或採用 GraphQL/BFF 模式），減少序列往返。
• 壓縮 JSON、資訊流分頁，讀多寫少的資料放進 Redis 並設定較短 TTL。

從電信、聯通、移動三網實測

確定線路前，一定要在晚高峰從三大運營商網路分別測量。

# 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、撥測等），從多個省份執行 ping、TCP 和 HTTP 測試。
• 測兩次：上午一次，北京時間 20:00–23:00 再測一次；重點比較丟包和 TTFB，而不只是 ping 值。
• 請分別使用電信、聯通、移動 SIM 卡的測試人員，用記錄請求耗時的除錯版 App 實際操作。
• 下單前可以提交工單，向 IMIDC 技術支援諮詢香港 CN2 GIA 到目標省份和運營商的線路情況。

公網 API 的 DDoS 防護與安全

公開 API 既會遭遇流量型攻擊，也會被應用層濫用，兩層都要防。

• 開通 IMIDC DDoS 防護應對網路層洪水攻擊；靜態資源走 CDN，儘量減少源站 IP 暴露。
• 在閘道器按 IP、按 API Key 限流（limit_req），鑑權採用短有效期的簽名令牌（如 JWT）。
• 公網只開放 443（以及用於跳轉的 80）；Redis、資料庫和 SSH 只走內網或白名單 IP。
• 全鏈路記錄請求 ID，便於從 App 一路追蹤到資料庫，定位慢請求或失敗請求。

從 VPS 平滑升級到獨立伺服器

先用 VPS 起步，流量增長後再把各角色拆分到獨立伺服器。

IMIDC 提供免費伺服器遷移，把資料庫從 VPS 遷到獨立伺服器時可以省下不少工作量。

哪種 IMIDC 方案適合你

根據業務階段和使用者分佈選擇產品：

• 新上線 App，使用者以大陸為主：香港 CN2 GIA VPS。
• 資料庫壓力較大的生產級 SaaS / App：香港獨立伺服器，靜態資源配合 IMIDC CDN。
• 同時服務大陸和日本或美國使用者的全球化 App：增加 日本 VPS 或 洛杉磯獨立伺服器。
• 定製配置（更大記憶體、NVMe RAID、額外 IP、內網互聯）：聯絡 IMIDC 銷售定製。

常見問題

哪家服務商提供免備案、適合做 App 後端的香港 CN2 GIA 伺服器？

IMIDC 提供基於中國電信 CN2 GIA（AS4809）線路的香港 VPS 和獨立伺服器。伺服器位於香港，託管無需 ICP 備案，但 App 及其內容仍須遵守相關法律法規。

API 部署在香港，App 還需要做 ICP 備案嗎？

ICP 備案針對的是在中國大陸境內託管的服務，香港 API 伺服器本身不需要。若通過大陸應用商店分發 App，可能涉及單獨的 App 備案要求，請向應用商店或專業人士確認，本文不構成法律意見。

香港後端能呼叫 OpenAI、Claude 或 Gemini 的 API 嗎？

不能。這些 API 官方不支援香港和中國大陸地區，不應從香港伺服器呼叫。如需為大陸使用者提供 AI 功能，請選用獲准在該市場提供服務的模型廠商。

用 VPS 就夠了，還是必須上獨立伺服器？

MVP 或日活幾千、查詢較輕的應用，用每月 $18 起的香港 CN2 GIA VPS 就夠了。當磁碟 I/O 或記憶體成為瓶頸時，再把資料庫遷到每月 $139 起的香港獨立伺服器。

HTTP/3 對大陸使用者有幫助嗎？

在有丟包或頻繁切換網路的移動場景下通常有幫助。部分網路會限制 UDP，所以始終保留基於 TCP 的 HTTP/2 作為回落，瀏覽器和主流 HTTP 客戶端會自動處理。

準備把 API 部署到離大陸使用者更近的地方？對比 香港 CN2 GIA VPS 與 香港獨立伺服器，或提交工單，向 IMIDC 團隊諮詢線路和架構建議。