UE5 Dedicated Server实战复盘：从“单机思维”到“服务器权威”的架构重构

“我们的多人射击游戏Demo在Steam上测试时，玩家一多就出现瞬移、子弹穿墙、甚至整个房间卡死。”2022年底，我接手了这个由三人小团队开发的UE5项目。他们之前用蓝图做了个本地联机原型，以为加个“Run Dedicated Server”就能上线。结果第一次压力测试，10个客户端同时连接，服务器CPU直接飙到90%，玩家角色像鬼畜一样抽搐。这不仅是性能问题，更是根本性的架构错误——他们还在用单机思维做网络游戏。接下来的三个月，我们经历了推翻重来、踩遍UE5网络同步的坑、最终交付了一个稳定支持64人的专用服务器版本。这篇文章，就是那次“渡劫”的完整复盘。

一、需求分析：我们到底需要一个什么样的服务器？

项目是一款快节奏的3v3英雄射击游戏，每局约10分钟。核心需求：客户端流畅60fps，服务器权威判定，支持64个并发玩家（8个房间），物理碰撞和技能判定必须精准。团队最初想用“Listen Server”（ listen server，即以玩家客户端兼作服务器），但很快被否决：玩家主机拥有延迟优势，且一旦主机退出游戏就结束。专用服务器（Dedicated Server）是少见选择——它不渲染画面，只跑逻辑，把结果广播给所有客户端。

技术选型上，我们评估了UE5的三种网络模式：

我们最终选择Dedicated Server，并明确：所有关键逻辑（伤害、命中、移动）必须在服务器计算，客户端只负责输入和表现。这是所有网络游戏架构的基石，也是团队要转变的第一个思维。

二、踩坑实录：UE5网络同步的三大“陷阱”

2.1 属性同步与RPC的滥用

团队最初把大量逻辑放在Actor的Tick里，用 RepNotify 同步血量、弹药等属性。问题：每个Actor每帧都在检查属性变化，网络带宽爆炸。UE5的属性同步（Property Replication）机制其实很智能——它只在属性值变化时发送，但前提是你正确设置了Replication Condition（同步条件）。例如，血量只需同步给“拥有者”和“观察者”，而不是所有客户端。我们通过COND_OwnerOnly和COND_SimulatedOnly大幅降低了同步量。

技巧：在 GetLifetimeReplicatedProps 中使用 DOREPLIFETIME_CONDITION 宏，而不是无脑 DOREPLIFETIME。对于不常变化的属性（如最大生命值），甚至可以用 DOREPLIFETIME_CONDITION 配合 COND_InitialOnly，只同步一次。

另一个坑是RPC（远程过程调用）的滥用。他们用Server RPC处理开火，但每次开火都发送一个包含命中位置的RPC，导致带宽激增。正确做法：客户端只发送“开火意图”，命中检测完全由服务器根据服务器端武器轨迹重新计算。这引出了下一个核心问题——延迟补偿。

2.2 延迟补偿与命中判定的“时间旅行”

射击游戏最头疼的是：玩家看到敌人时开枪，但由于延迟，服务器收到指令时敌人已经移动了。UE5提供了延迟补偿（Lag Compensation）框架，但需要手动实现。我们的方案：服务器保存过去1秒内所有角色的位置快照（每帧或每50ms），当收到开火RPC时，根据客户端的往返延迟（RTT）回溯到当时的位置进行射线检测。这需要在GameMode中维护一个环形缓冲区，并重写PerformWeaponTrace函数。代码示例如下：

void AShooterGameMode::PerformLagCompensatedTrace(APlayerController* Instigator, const FVector& Start, const FVector& End, float ClientTimeStamp) {
    // 根据ClientTimeStamp回溯历史位置
    FVector RewoundStart = GetRewoundLocation(Instigator, Start, ClientTimeStamp);
    FVector RewoundEnd = GetRewoundLocation(Instigator, End, ClientTimeStamp);
    // 执行射线检测
    FHitResult Hit;
    GetWorld()->LineTraceSingleByChannel(Hit, RewoundStart, RewoundEnd, ECC_GameTraceChannel1);
    // 处理伤害...
}

这段代码背后是“服务器权威+客户端预测”的经典架构。客户端预测自己的移动和射击表现，服务器做最终裁决并纠正。如果客户端预测错误，服务器会发送纠正（Correction），客户端平滑插值回正确位置。UE5的CharacterMovementComponent已经内置了这套机制，但很多开发者不知道如何配置Network Prediction插件（UE5.1后新增），我们当时手动实现了一套简易版。

2.3 网络带宽与序列化优化

测试时，8个房间64人，服务器出口带宽跑到了50Mbps，远超预算。分析发现：大量Actor（如子弹、道具）使用了默认的NetUpdateFrequency（100Hz），且没有设置NetPriority。我们做了三件事：

• 将子弹等短生命周期Actor的NetUpdateFrequency降至20Hz，并启用bOnlyRelevantToOwner，只同步给相关玩家。
• 使用网络休眠（Net Dormancy）：静止的Actor进入休眠，不再同步，直到被唤醒。
• 启用Iris（UE5的新网络同步系统），它用更高效的序列化和优先级调度，带宽直接降了40%。但Iris当时还是实验性功能，我们踩了不少坑，比如自定义NetSerializer的兼容性问题。

注意：Iris在UE5.3后逐渐稳定，但若项目周期紧，建议先用传统复制系统，待Iris成熟再迁移。

三、解决方案：构建健壮的专用服务器架构

经过重构，我们确定了以下架构：

• 服务器进程：独立运行，无渲染，通过UE5Server目标编译。启动参数：-server -log -port=7777。
• GameMode：仅服务器存在，负责游戏规则、胜负判定、玩家加入/退出。
• PlayerController：服务器和客户端各有一份，服务器版本处理输入验证和RPC。
• GameState：同步给所有客户端的全局状态（比分、时间）。
• PlayerState：同步玩家个人数据（击杀、助攻）。

关键改造点：将所有BeginPlay中的逻辑用HasAuthority()分支，服务器执行权威逻辑，客户端只做表现。例如，武器开火：

void AWeapon::Fire() {
    if (HasAuthority()) {
        // 服务器：执行命中检测、伤害计算
        PerformTraceAndDamage();
        // 广播开火特效给所有客户端
        Multicast_PlayFireEffects();
    } else {
        // 客户端：立即播放开火动画和音效，并发送Server RPC
        PlayLocalFireEffects();
        Server_Fire();
    }
}

此外，我们使用Replication Graph（复制图）来优化相关性管理。默认的AActor::IsNetRelevantFor在大量Actor时性能差，Replication Graph允许自定义节点，比如按房间、按距离筛选，将CPU耗时从8ms降到1.5ms。

四、交付与压力测试：从10人到64人的跨越

重构后，我们在AWS c5.large（2 vCPU，4GB内存）上部署了服务器，用Gauntlet自动化测试框架模拟64个客户端。结果：

最终，游戏在Steam Early Access上线，首周峰值在线1200人，服务器稳定运行。回顾这次项目，最大的教训是：专用服务器不是“加个勾选”，而是一种架构哲学——服务器是少见的真相来源，客户端只是它的镜子。

如果你也想深入UE5网络游戏开发，掌握Dedicated Server、网络同步、性能优化等硬核技能，火星人教育的UE5游戏特效课程或许能帮你少走弯路。作为创办24年的数字艺术与AIGC实战职业技能培训机构，火星人教育在北京、深圳双校区开设线下面授班，课程涵盖AI漫剧创作、AIGC视觉设计、UE5游戏特效、室内全屋定制、MAYA三维动画、C4D动态设计、工业设计、NUKE影视后期、摄影摄像实训等。面向美术生、在校大学生及意向转行的职场人群，以项目化实训教学，夯实专业技能，助力就业与职业提升。咨询电话：010-65918670。想做出能上线的多人游戏？先从理解服务器开始。