每一款多人游戏都必须回答同一个问题：究竟由谁的设备来判定比赛中发生了什么？这个答案决定了作弊防护、公平性、玩家退出时的处理方式，以及游戏的运行成本。

本指南总结并对比了开发者可选择的五种主要潜在架构方案，分析了各自的适用场景，以及何时应考虑更换其他方案。

如需深入了解网络模型本身，请参阅 Edgegap 关于权威服务器、中继与对等网络（P2P）的指南。

五种架构一览

这五种架构都有一个共同的形态，即客户端-服务器（C/S）模型：每位玩家都连接到同一个游戏副本，由该副本判定发生了什么。区别在于谁来运行该副本（是玩家的游戏客户端还是服务器）以及它承担了多少工作。在对等网络和中继方案中，“服务器”就是房主玩家的游戏客户端，这种模型通常被称为“主机-客户端”（host-client）模型。

1. 对等网络（Peer-to-Peer）

原理：在大多数采用该方案的已上线游戏中，P2P 实际指的是“主机-客户端”（host-client）模式。其中一名玩家的游戏客户端持有对局状态并在游戏过程中充当服务器，其他所有玩家都连接到该设备。另有一小部分游戏（主要是策略游戏和格斗游戏）会在每台设备上分别运行完整的模拟，并仅通过确定性锁步（lockstep）或回滚（rollback）机制交换玩家输入。

适用场景：原型开发、Game Jam、非商业发布、本地或局域网联机，以及好友之间的小型会话。

优势：

• 无托管费用：玩家自行提供硬件和网络带宽。

• 上手快速：大多数引擎都支持主机模式，通常称为侦听服务器（Listen Server）。

局限性：

• 连接易失败：大多数玩家都处于执行网络地址转换（NAT）的路由器之后。在严格型路由器和移动网络中常见的运营商级 NAT（CGNAT）上，打洞常常失败。

• 房主可以作弊：掌握对局状态的一方可以通过修改内存数据、使用延迟开关（lag-switch）或上报虚假结果来篡改状态。

• 玩家会暴露彼此的 IP 地址：这使他们容易受到匹配对手发起的拒绝服务（DoS）攻击（P2P 的隐藏成本）。

• 房主离开，对局即结束：除非游戏开发了房主迁移机制。Highwire Games 曾估计，《费卢杰六日》实现房主迁移需要额外增加一名开发人员和一名测试人员，每月成本约为 15,000 美元（2024 年 9 月实时服务型游戏峰会演讲）。

P2P 还会增加延迟成本，因为玩家之间的直连路径并不一定是最短的。在 2020 年对一款 1v1 主机游戏的 122,000 场 P2P 对局进行的分析中，通过置于两名玩家之间的服务器来路由每场对局，使 70% 的对局平均往返时间（RTT）降低了 23%（1v1 报告）。

何时考虑其他方案：当玩家频繁反馈无法相互加入时。这正是中继服务器旨在解决的问题。

2. 共享中继服务（例如 Steam、Epic Online Services、Unity Relay）

原理：中继服务器用于在无法直接直连的玩家之间转发流量。所有玩家都向外连接到中继，中继在房主和客方之间传递数据包。共享中继服务是指由平台运营、供其平台上所有游戏共同使用的中继。

适用场景：已采用主机-客户端架构的游戏，用作解决连接失败的网络方案。

优势：

• 规避大多数 NAT 问题：无需任何设备接受入站连接，因此 NAT 和防火墙不再阻碍玩家联机。

• 安全，隐藏玩家 IP 地址：玩家连接到中继服务器，而非直接相连。

• 集成成本极低：平台 SDK 通常会将中继服务与大厅功能打包集成。

局限性：

• 游戏仍由玩家托管：中继不运行任何游戏逻辑。房主依然可以作弊，依然享有零网络延迟的优势，且房主一旦退出对局仍会结束。

• 每个客方都要经过两跳：客方到中继再到房主，然后沿原路返回。中继所在的位置决定了每位客方的延迟，距离中继节点较远的玩家越多，比赛的公平性就越差。网页游戏的体会尤为明显：使用 WebSocket 的浏览器根本无法实现玩家直连，因此每场比赛的每个数据包都必须经过中继，而 WebRTC 在直连失败时也会回退到中继（TURN 服务器）（中继服务器）。

• 路由和可用性受限于单一服务商网络：Highwire Games 的 Michal Buras 在评估 Epic Online Services 的免费中继时发现，“完全无法控制这些玩家的网络路由走向”（2024 年 9 月实时服务型游戏峰会演讲）。他还展示了在该架构下，利用常规调试工具即可读取明文大厅数据的情况。路由及其可用性完全受制于该服务商的网络。

何时考虑其他方案：当你希望由自己掌控中继上的路由、节点位置以及自定义代码时。

3. 可扩展中继（例如 LightNet）

原理：在专用服务器上运行的中继，可选择通过添加游戏逻辑来进行扩展。一旦添加了游戏逻辑，它就演变成具有类中继资源效率的多房间专用服务器。开箱即用状态下，它本质上仍是中继：负责转发流量，对局仍归房主的游戏客户端管辖。Edgegap 的 LightNet 中继指南演示了如何将其用于主机-客户端架构的 Unity 游戏，玩家可通过房间代码进行创建和加入。

适用场景：互相信任的玩家群体：合作模式、好友联机及私人房间。在此范围内，还适用于移动和混合休闲游戏、卡牌游戏（TCG）以及无需服务端逻辑的实时 PvP。

优势：

• 安全，隐藏玩家 IP 地址：所有玩家均向外出站连接到中继，杜绝了针对玩家连接的攻击（如针对房主的流量洪泛）。

• 规避大多数 NAT 问题：无需端口映射，在移动网络下同样适用。

• 自定义路由与节点分布：可在玩家所在地区就近部署中继。

• 仅为您的游戏服务的跨云网络：其他中继网络的路由变更或故障不会对其产生影响。在像 Edgegap 这样接入了 17 家以上提供商的多云平台上，如果某个节点出现故障，可以在其他提供商处立即启动新的中继。

• 专属自定义代码：共享中继服务不允许添加自定义代码。在自己的中继上，您可以添加房间密码、玩家验证、速率限制、踢出/封禁、房间数据、遥测或大厅钩子等逻辑。示例中未内置这些功能，均由您自行编写。

• 添加游戏逻辑后可防止作弊：在默认情况下，房主的游戏客户端持有对局状态，因此作弊者依然可能破坏对局。但通过加入游戏玩法验证，便可在同一套代码和部署上赋予其服务器权威性，具体如下文所述。

• 初期无需重构代码：现有的主机-客户端网络代码可保持原样，单个中继可同时服务多个房间。

原装状态下的局限性：

• 房主离开即导致对局结束：未内置房主迁移功能，需游戏自身实现。在 LightNet 示例中，中继在房主退出时也会关闭房间。

• 传输未加密：LightNet 示例采用的是明文 TCP 和 UDP 传输协议。

• 本身无匹配或自动扩缩容机制：玩家需共享房间代码，且需要您手动规划中继的运行位置。

界限划分：非玩法逻辑（如密码、速率限制或遥测）仍属于中继范畴。而验证游戏玩法（如命中判定、对战结果或经济系统）则会使其转变为下一阶段的多房间游戏服务器。正如 Michal Buras 所言：“一旦你开始进行逻辑计算，它就不再仅仅是中继服务器了。” 这种转变虽然可行，但需要实打实的开发工作：中继最初只能识别原始网络流量，必须学会解析游戏消息之后才能对其进行校验。

托管建议：Edge Cloud 适用于按需使用、开发、游戏测试和预制作阶段。而在达到较大规模后，对于全天候运行的中继，私有集群（Private Fleets）通常更具成本效益：在 58 个节点拥有预留主机，每台主机附带 6 TB 的出站流量配额。无论哪种方案，定期回收中继实例都是最佳实践。

何时考虑其他方案：当玩家开始与陌生人匹配对局，或者您希望由服务器来裁决游戏结果时。

4. 多房间游戏服务器

原理：多房间游戏服务器是指单个服务器进程同时托管多场比赛，每个房间拥有独立的状态和玩家。该进程的固定开销（如引擎自身开销和已加载的游戏数据）只需支付一次，即可供所有房间共享。这也是可扩展中继在添加了玩法验证逻辑后的最终形态。

适用场景：能够共享同一进程的游戏：回合制、卡牌、解谜和休闲游戏；通常采用锁步同步的 RTS 游戏；无重度物理模拟但需要权威服务器的 MOBA 游戏；许多体育和赛车游戏；以及游戏大厅和社交空间。

优势：

• 杜绝房主作弊：由服务器掌控核心逻辑并裁定对局结果。

• 安全、隐藏玩家 IP 地址，并规避大多数 NAT 问题：所有玩家均向外出站连接到服务器。

• 无需房主迁移：任何玩家离开都不会影响对局的继续进行。

• 单进程承载多场比赛：基于房间的框架（如 Colyseus 和 Nakama）天生就采用此设计，Mirror 也可以为每场比赛分配独立的子场景。Edgegap 对进程数量不设限制：单个部署可根据其 CPU 和内存容量尽情运行进程和房间。

• 弹性规格配置：在 Edgegap 这类服务上，服务器起步规格为 0.25 vCPU，最高可升至 14.7 vCPU 的私有集群主机。您可以根据性能分析版本测得的“每个 vCPU 承载房间数”来确定配置，而非按单场对局计算。

• 简单的扩缩容：匹配系统可以将玩家回填（Backfill）到开放的房间中，或者在没有可用房间时部署新的服务器。

局限性：

• 通常部署在中心节点：多房间服务器的位置在启动时一次性确定，且通常集中部署在玩家密集的中心节点。如果采用中心化模型，距离服务器较远的玩家在延迟和公平性上会劣于就近玩家。

• 代码层面必须隔离房间：从单场对局服务器转型意味着共享状态（从单例模式到物理世界）必须改造为房间级独立状态。Unreal 通常每个进程仅运行一场对局。

何时考虑其他方案：当每场比赛都需要在靠近各自玩家的位置拥有独立服务器，或者游戏大世界需要在玩家进出过程中持续保持运行时。

5. 专用服务器

原理：专用服务器（Dedicated Server）在不受任何玩家控制的服务器上运行，每次部署只运行一个会话。它取代了房主的角色，因此对于基于主机-客户端架构开发的游戏，房主的逻辑通常可以直接打包为无头（Headless）版本运行。轻量对局和完整模拟运行在同一种服务器上，差异仅在于所需的 CPU 资源——通常初期消耗较高，随着团队逐步优化而降低。为轻量级对局配置的专用服务器有时被称为微型专用服务器（Small Dedicated Server）。

它有两种变体，按运行特征而非游戏品类来进行对比最为合适：

适用场景：

• 基于会话：射击游戏、战术竞技（大逃杀）、实时 PvP、竞技和排位模式、格斗游戏、VR 和 XR、Web3、与陌生人匹配的合作模式，以及移动和混合休闲类 PvP。

• 持久化：MMO、生存和沙盒大世界，以及社交大厅。

优势：

• 杜绝房主作弊：客户端仅发送操作输入，由服务器裁决结算结果，这彻底封死了依赖玩家掌控游戏状态的作弊途径。当然，服务器权威机制本身无法杜绝自瞄（aimbot）或透视（wallhack），因为这些外挂运行在玩家本地设备上，因此服务端校验需与客户端反作弊配合使用。

• 连接稳定可靠，不依赖房主可用性：所有玩家都连接到一个不受任何玩家操控的服务器，从而隐藏了玩家 IP 并规避了大部分 NAT 问题。没有所谓房主可以随意退出，因此不需要房主迁移逻辑。

• 就近部署服务于本场会话的玩家：每个基于会话的服务器都会在最有利于该场比赛玩家的地点启动。针对某工作室线上真实流量的独立回放测试表明，相比公有云中继部署，采用专用服务器就近部署平均降低了 58% 的延迟（平台数据，2026 年 9 月 18 日）。

• 随游戏需求自由扩展：轻量级对局支持最低 0.25 vCPU 的弹性配置。另一方面，完整模拟可以以固定Tick 率（Tick Rate）为 2 到 100 名甚至更多玩家运行物理、移动和命中判定；持久化大世界和 MMO 也采用相同机制：Afterthought LLC 打造的百人同服开放世界恐龙生存游戏《The Isle》便将其持久化服务器运行在 Edgegap 上；Qloud Games 的温馨风 MMO《Loftia》在封测期间扩展了数百个游戏服务器，包括承载多达 100 名同时在线玩家的社交中心。

局限性：

• 每次部署仅支持一个会话：每场基于会话的比赛都会单独启动和关闭服务器，因此高度依赖能够快速启动并就近部署服务器的编排调度系统。

• 资源消耗随模拟复杂度上升：像托管战术竞技游戏那样去托管卡牌游戏会造成成本浪费；轻度游戏通常更适合部署在多房间服务器上。

• 托管建议：基于会话的游戏通常采用混合模式：预留集群用于经济高效地承载稳定的基线流量，按需弹性容量则用于应对超出基线的波峰。持久化大世界则最适合采用私有集群。

下载量突破 4000 万的手机游戏《Bloody Bastards》此前采用房主受信任的 P2P 模式，工作室曾直言当时外挂猖獗。在迁移至权威服务器和匹配系统后，实现了“自此零外挂”（Edgegap 博客，2026 年）。

各游戏品类与模式适合哪种架构？

许多游戏会将两种架构结合使用：私人房间走中继，公共对局走服务器。当多房间服务器集中部署在中心节点时，离它较远的玩家相比就近玩家会遭受更高的延迟，公平性也会降低。

下一步：玩家如何连接到服务器

决定对局在哪里运行只是架构的一半，另一半则是玩家如何进入对局。可扩展中继、多房间服务器和专用服务器都可以使用以下任一选项；具体选择取决于游戏设计：是由规则自动裁决，还是由玩家自主挑选？

• 匹配系统（Matchmaker）：基于规则判定。它依据玩家技术水平、延迟等规则进行分组，然后将玩家回填至开放房间，或在无合适房间时启动新服务器。适用于陌生人匹配的基于会话的游戏。Edgegap 的匹配器会在匹配到的玩家就近部署服务器。

• 服务器浏览器（Server Browser）：由玩家自主挑选。它列出正在运行的服务器或尚有空位的房间，类似于大厅列表。适用于持久化和大社区型游戏。

许多游戏会兼而有之，且这一选择最好在设计服务器层级时同步确定，而不是留到事后才考虑。

从玩家互信关系出发

过去，团队选择 P2P 和中继往往是因为单场对局配备独立服务器的成本太高，而极少是因为中继能带来更好的对局体验。如今这一差距已经大大缩小：多房间服务器可在多个对局间共享单个进程，而专用服务器的规格也可以低至几分之一的 vCPU 起步。

在做选择前，一个实用的检验方法是：列出玩家会与谁一起游戏。如果答案仅限于好友，那么可扩展中继既能解决连接问题、保护 IP 地址隐私，又能为您保留添加自定义代码的空间。但如果在游戏的任何地方（无论是休闲还是排位）会出现陌生人匹配，就请将这些对局交给服务器，并根据需要判定的逻辑规模合理配置服务器规格。

准备好将对局托管至服务器了吗？从适合您所用引擎的指南开始：Unreal Engine、Unity、Godot 或网页游戏。