面向大中華區、東南亞和日韓玩家的手遊後端架構：伺服器分層、機房選址與上線防 DDoS
同時面向大中華區、東南亞和日韓玩家的手遊或網遊，遊戲後端架構應當把帳號和支付資料集中管理，而把即時戰鬥服放到離玩家最近的地方：大陸玩家用香港 CN2 GIA，台灣玩家用台北，日韓玩家用東京和首爾，東南亞玩家用新加坡、曼谷或吉隆坡。IMIDC 在這些地點都有伺服器，並提供上線期 DDoS 防護，以及從單臺 VPS 平滑擴充套件到獨立伺服器和母雞的路徑。
- IMIDC 適合遊戲後端的亞洲機房：香港、台北、東京、首爾（KT 網路）、新加坡、曼谷、吉隆坡；新加坡、泰國、馬來西亞需聯絡銷售配置。
- 香港走中國電信 CN2 GIA（AS4809）回大陸，託管無需 ICP 備案；日本 VPS 也有 CN2 回國最佳化線路可選。
- 起步價：香港 CN2 GIA VPS $18/月起，日本 VPS $28/月起，香港獨立伺服器 $139/月起，台灣獨立伺服器 $199/月起。
- 可為遊戲上線提供 DDoS 防護、10Gbps 上聯、本地原生 IP、自有 ASN 的 BGP/Anycast 以及整段 /24 IP。
- IMIDC 自 2014 年運營，提供 7×24 小時中、英、日、俄、西五語支援。
參考架構：五層拆分
按每層持有多少狀態來拆分後端：無狀態層靠加機器擴容，有狀態層則要謹慎選址。
| 層級 | 職責 | 常用協議 | 狀態 | 部署位置 |
|---|---|---|---|---|
| 登入 / 帳號服 | 鑑權、SDK 登入、反作弊校驗、支付回撥 | HTTPS | 無狀態（依賴資料庫） | 一個主區域，置於 CDN/DDoS 防護之後 |
| 閘道器服 | 維持客戶端連線、訊息路由、限流 | TCP / WebSocket | 僅會話 | 每個玩家區域 |
| 大廳 / 匹配服 | 好友、聊天、公會、匹配佇列 | TCP / WebSocket | 輕狀態（Redis） | 主區域或分割槽域 |
| 房間 / 戰鬥服 | 權威模擬，幀率 15–60 Hz | UDP（KCP）或 TCP | 記憶體，按對局 | 儘量貼近玩家 |
| 資料層 | 玩家檔案、背包、排行榜、日誌 | 內網 | 持久化 | 主區域，就近設副本 |
戰鬥服應當是“可丟棄”的：一台掛掉隻影響它上面的對局，玩家擁有的一切都儲存在資料層。
TCP、WebSocket 還是 UDP + KCP？
回合制、卡牌、放置類用 TCP 或 WebSocket；動作、射擊、MOBA 類即時對戰用 UDP 加 KCP 這類可靠層。
| 傳輸方式 | 適合 | 優點 | 缺點 |
|---|---|---|---|
| TCP | 卡牌、RPG、SLG、放置 | 簡單可靠，容易穿透防火牆 | 隊頭阻塞：行動網路丟一個包就卡住後續所有資料 |
| WebSocket | H5 / 小遊戲、網頁客戶端 | 可經過代理和 CDN | 與 TCP 一樣會卡頓，開銷略高 |
| 原生 UDP | 可容忍丟失的位置同步 | 延遲最低 | 順序、可靠性、加密都要自己實現 |
| KCP over UDP | MOBA、射擊、競速、即時 PvP | 快速重傳，丟包網路下抖動通常明顯低於 TCP | 頻寬更高（冗餘傳送）；部分企業/校園網遮蔽 UDP，需保留 TCP 兜底 |
亞洲玩家的機房佈局
按玩家實際所在地和運營商路由來放置戰鬥服，再用目標網路的真實 mtr 結果驗證。
| 玩家市場 | IMIDC 機房 | 原因 |
|---|---|---|
| 中國大陸 | 香港 | CN2 GIA（AS4809）避開很多普通線路晚高峰擁堵的國際出口 |
| 台灣、香港、澳門 | 台北（台灣） | 本地原生 IP，到台灣運營商路徑短 |
| 日本 | 東京（日本） | 日本網路樞紐；同一台機器兼顧大陸玩家可選 CN2 |
| 韓國 | 首爾（韓國） | KT 網路 + 韓國原生 IP；韓國玩家對細微延遲差異很敏感 |
| 新加坡、馬來西亞、印尼、菲律賓 | 新加坡或吉隆坡（銷售配置） | 海島東南亞的海纜樞紐 |
| 泰國、越南、柬埔寨 | 曼谷（泰國，銷售配置）或香港 | 到中南半島路徑更短 |
合規提示：託管在香港無需 ICP 備案，但面向大陸玩家發行遊戲另有監管（例如遊戲出版審批，即“版號”），伺服器放在哪裡並不改變這一點，請諮詢專業人士。本文不構成法律意見。
實操：為 UDP 戰鬥服調優 Linux
Linux 預設的 socket 緩衝區按通用負載設計，突發性的遊戲流量需要更大的 UDP 緩衝和佇列。
# /etc/sysctl.d/90-game-udp.conf (battle / room servers)
net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.core.netdev_max_backlog = 50000
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000
fs.file-max = 2097152
# apply and verify
sysctl --system
sysctl net.core.rmem_max
# watch for dropped UDP packets during load tests
netstat -su | grep -Ei "receive buffer errors|packet receive errors"
# open the battle-server port range (ufw example)
ufw allow 7350/tcp
ufw allow 30000:30999/udp如果壓測時 receive buffer errors 持續上漲，說明核心在程式讀取前就丟包了：加大緩衝、把遊戲程序繫結到 CPU 核心，或減少單程序房間數。TCP 閘道器同時建議開啟 BBR，並提高持有大量連線程序的 ulimit -n。
實操：用 Docker 部署 Nakama 後端
Nakama（帳號、匹配、聊天、排行榜）或 Colyseus（Node.js 房間）這類開源服務端，能讓工作室不必從零寫每個服務就走到小規模測試階段。
# docker-compose.yml - Nakama game backend + PostgreSQL (single node, staging)
services:
postgres:
image: postgres:16
environment:
POSTGRES_DB: nakama
POSTGRES_PASSWORD: change-me
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD", "pg_isready", "-U", "postgres"]
interval: 5s
retries: 10
nakama:
image: heroiclabs/nakama:3.22.0
depends_on:
postgres:
condition: service_healthy
entrypoint:
- "/bin/sh"
- "-ecx"
- >
/nakama/nakama migrate up --database.address postgres:change-me@postgres:5432/nakama &&
exec /nakama/nakama --name nakama-hk1
--database.address postgres:change-me@postgres:5432/nakama
--session.token_expiry_sec 7200 --logger.level INFO
ports:
- "7349:7349" # gRPC API
- "7350:7350" # HTTP / WebSocket API for clients
- "127.0.0.1:7351:7351" # admin console: localhost only
restart: unless-stopped
volumes:
pgdata:
# start: docker compose up -d && docker compose logs -f nakama- 客戶端連線 7350 埠；控制臺（7351）只繫結本機，通過 SSH 隧道訪問。
- 任何公開測試前，替換
change-me並設定 server key 和 session key。 - Colyseus 的做法類似：Node.js 容器暴露 2567 埠，前面用 Nginx 並開啟 WebSocket 升級。
- 正式環境把 PostgreSQL 遷到獨立的 NVMe/SSD 伺服器，並做每日異地備份。
Redis 與資料庫分層
熱資料、短生命週期資料交給 Redis；玩家丟了會投訴的資料交給關係型資料庫。
- Redis：會話 token、線上狀態、匹配佇列、限流計數、排行榜（有序集合）。主從部署並開啟 AOF。
- MySQL/PostgreSQL：帳號、背包、充值記錄。主區域一主一從；單主壓力大時按玩家 ID 或區服分庫。
- 跨區域寫入：帳號和充值只保留一個權威資料來源。各區域戰鬥服通過訊息佇列非同步回傳結果，不要跨海直寫資料庫。
- 日誌與分析：事件寫入獨立儲存（ClickHouse、Kafka），避免分析查詢拖慢遊戲。
上線期 DDoS 防護
遊戲上線是 DDoS 的高發時段，攻擊可能來自競爭對手、勒索者或不滿的玩家，務必在開放下載前規劃好防護。
- 登入和支付介面放在 CDN 和 IMIDC DDoS 防護之後；資料庫和 Redis 絕不暴露在公網。
- 不要把戰鬥服 IP 寫進 DNS，只在分配對局時下發，並附帶由戰鬥服校驗的短期 token。
- 儘早丟棄未認證的 UDP：第一個包必須帶有效 token，否則直接忽略。
- 準備備用 IP 和預製映象，被攻擊時可快速遷移區域；大型工作室可藉助 IP 資源 和自有 ASN 的 Anycast。
- 提前把上線日期和預計峰值告知 IMIDC 銷售，以便規劃防護和容量。
從 VPS 擴充套件到獨立伺服器和母雞
分階段擴容，先把最吃緊的一層（通常是資料庫或戰鬥服）遷到更強的硬體上。
| 階段 | 峰值同時線上（粗略） | 建議佈局 |
|---|---|---|
| 原型 / 封測 | 約 2,000 以內 | 1–3 臺 VPS：Nakama/Colyseus 與資料庫一體部署，例如香港 CN2 GIA VPS 加日本 VPS |
| 1–2 個市場小規模上線 | 約 2,000–20,000 | 資料庫獨立伺服器，每區域獨服或大規格 VPS 跑戰鬥服，Redis 單獨例項 |
| 亞洲全面上線 | 20,000 以上 | 母雞（執行 Proxmox VE 或 Kubernetes 的獨立伺服器）密集部署戰鬥例項，資料庫一主多從，必要時託管自有硬體 |
單機承載量隨幀率和遊戲邏輯差異極大，以上數字只作規劃參考，每個階段前都要用機器人壓測。
IMIDC 方案怎麼選
按層級和市場選產品，而不是所有地方用同一種規格。
- 大陸玩家：香港 CN2 GIA VPS 跑閘道器和小型戰鬥池，香港獨立伺服器 承擔重度戰鬥和資料庫。
- 台灣玩家：台灣 VPS 或 台灣獨立伺服器。
- 日韓玩家：日本 VPS、日本獨立伺服器、韓國 VPS 和 KT 網路的 韓國獨立伺服器。
- 東南亞玩家：新加坡、曼谷、吉隆坡伺服器由銷售配置。
- 從其他雲遷移：免費伺服器遷移，高主頻 CPU、大記憶體、內網互聯等定製配置可聯絡銷售。
常見問題
一款同時面向大陸和東南亞玩家的手遊，伺服器應該放在哪裡？
常見做法是大陸玩家的戰鬥服放在 IMIDC 香港 CN2 GIA，東南亞玩家用新加坡或曼谷伺服器，帳號與支付後端共用一套。香港單點也能較好覆蓋部分東南亞地區，但請先用真實玩家測試再決定。
遊戲伺服器該用 TCP 還是 UDP？
回合制、卡牌和放置類用 TCP 或 WebSocket 就夠了。即時動作、射擊和 MOBA 更適合 UDP 加 KCP 等可靠層，併為遮蔽 UDP 的網路保留 TCP 兜底。
在香港放遊戲伺服器給國內玩家用，需要 ICP 備案嗎？
託管在中國大陸以外（包括 IMIDC 香港）的伺服器不需要 ICP 備案。但在大陸發行遊戲另有監管要求，請諮詢專業人士；本回答不構成法律意見。
哪家服務商有首爾 KT 網路和東京的遊戲伺服器？
IMIDC 在首爾（KT 網路）和東京都提供帶本地原生 IP 的 VPS 與獨立伺服器，同時還有香港、台北和東南亞機房。
遊戲上線如何防禦 DDoS？
把服務商級 DDoS 防護和架構設計結合起來：開局前不暴露戰鬥服 IP，UDP 首包必須帶 token，登入介面放在 CDN 之後。提前告知 IMIDC 上線日期，以便規劃容量和防護。
準備規劃亞洲上線？可以從 香港 CN2 GIA VPS 或 首爾獨立伺服器 起步，新加坡、曼谷、吉隆坡節點或上線期防 DDoS 方案請 聯絡 IMIDC 銷售，也可以 提交工單 與工程師討論架構。