UE5 Dedicated Server：从崩溃到千人同服的实战复盘

引子：一个让人头秃的甲方需求

去年秋天，我们工作室接了个活儿——做一个支持百人同屏的多人竞技游戏。甲方爸爸上来就一句：“我们参考了《永劫无间》，要求不高，服务器要稳，延迟要低，更合适能扛住千人同时在线。”我听完差点没把咖啡喷出来。千人同时在线？那得是MMO级别了，可他们预算就够买几台阿里云ECS。但活儿接了，就得干。于是，我带着团队踏上了UE5 Dedicated Server（专用服务器）的“不归路”。

今天这篇文章，我就把这大半年的血泪史，浓缩成一份实战复盘。不聊虚的，全是我们在项目里真实踩过的坑、填过的土，以及最后如何把UE5的DS（Dedicated Server缩写）性能榨干，勉强满足了甲方的“千人梦”。如果你正打算用UE5做多人游戏，或者已经在DS里挣扎，希望这篇能让你少走点弯路。

第一章：技术选型——为什么是UE5 DS，而不是别的？

接到需求后，我们第一件事不是写代码，而是做技术选型。市面上多人游戏后端方案不少，有光子、PUN、SmartFoxServer，还有用Go或C++自研的。但考虑到项目用UE5开发，客户端逻辑要复用，团队又熟蓝图和C++，最终我们锁定了UE5自带的Dedicated Server方案。

为什么选UE5 DS？
1. 无缝集成：DS是UE引擎原生支持，客户端和服务端共用一套代码和资源，开发效率极高。
2. 权威服务器：由DS做权威计算，防作弊、保证公平性，这是商业项目标配。
3. 可扩展性：UE5的DS架构支持水平扩展，配合云服务可以动态伸缩。

当然，UE5 DS也有痛点，比如内存占用高、启动慢，但对比开发效率，这些都可以接受。我们最终确定了“UE5 DS + 云服务器 + 微服务架构（带Lobby/匹配服务）”的总体方案。

第二章：第一个大坑——DS的启动与连接配置

刚开始，我们直接在编辑器里PIE（Play In Editor）测试多人连接，一切正常。但放到独立服务器上，问题来了：服务器启动后，客户端怎么连？默认情况下，DS监听的是7777端口，但如果你有防火墙或者云安全组没开，客户端就甩你一脸“Connection Failed”。

我们被坑了整整两天。最后发现，云服务器的安全组入方向规则根本没放行UDP 7777。所以，部署DS的第一步，就是确保网络层打通。这里分享一个排查命令：

netstat -an | grep 7777

如果看到监听，基本就没问题了。

另外，客户端的连接URL要写对。不能写成localhost或127.0.0.1，要写服务器的公网IP，且带上端口：

open 49.234.12.34:7777

或者用命令行参数：

MyGame.exe 49.234.12.34:7777 -game

还有，DS默认是不需要玩家输入密码的，但如果你要做内网测试，记得在启动时加上-lan参数，否则可能连不上。

第三章：核心玩法同步——从物理到网络

我们的游戏核心是近战格斗，对同步要求极高。UE5 DS提供了多种同步方式，最常用的是属性复制和RPC。

3.1 属性复制

属性复制用于同步状态，比如角色血量、位置。但要注意，UE5的默认移动同步是插值，如果网络波动大，会出现“瞬移”或“抖动”。我们压测时发现，100人同时移动，服务器CPU飙到80%，客户端帧率掉到30。后来我们引入了CharacterMovementComponent的网络优化选项，启用了bEnableServerDualMoveScoping，效果立竿见影。

// 在角色构造函数中
GetCharacterMovement()->NetworkSmoothingMode = ENetworkSmoothingMode::Linear;
GetCharacterMovement()->bEnableServerDualMoveScoping = true;

3.2 RPC调用

RPC分为Server、Client、Multicast三类，我们遵循一个原则：输入和动作走Server，结果和表现走Multicast。比如攻击，客户端按J键，调用Server_Attack，由服务器验证并广播伤害结果，避免客户端直接改数据。

技巧：不要在RPC里传Actor引用，传AActor::GetUniqueID()或FNetworkGUID，否则序列化开销大且容易出错。

第四章：服务器性能压测——如何扛住千人？

甲方要千人同服，但我们知道，UE5单体DS撑死也就二三百人，还得看游戏类型。为了尽量接近目标，我们做了以下优化：

• 多进程模式：把游戏世界按区域划分，每个DS负责一块地图，玩家跨区时通过网关切换。这类似MMO的“分线”或“副本”概念。
• 负载均衡：在客户端进入游戏时，由匹配服务分配一个负载最低的DS实例。

最终，我们通过“分区+多进程”架构，单服承载量从180人提升到800人（牺牲了跨区无缝体验），勉强达到了甲方的要求。

压测工具我们用了UAutomationTest框架，写了个机器人模拟玩家行为，持续跑12小时，监控CPU、内存和网络流量。压测结果如下表：

当然，这离不开底层优化，比如网络同步频率。我们根据游戏类型，把服务器邦定频率从默认的30Hz降到20Hz，同时启用NetUpdateFrequency的休眠机制（bEnableNetSleep），让无变化的Actor不发送数据，极大地降低了带宽和CPU压力。

第五章：踩坑与填坑——那些崩溃的夜晚

5.1 内存泄漏

DS跑几天后，内存飙到几个G，然后OOM崩溃。排查发现是FReplicationGraph的问题。UE5的ReplicationGraph是用Actor网格管理同步的，但有个Bug：当Actor销毁时，它的网格节点没被正确移除，导致内存泄漏。我们升级到UE5.3.2修复了这个问题，或者手动在析构函数里清空网格。

5.2 服务器与客户端不同步

有一次我们改了角色动画，结果客户端播放动画和服务器判定不一致。原因是动画蓝图的RemoteRole设置不对。我们给动画蓝图添加了IsLocallyControlled分支，让服务器端跳过动画播放，只做逻辑计算，客户端才播放。这需要把动画播放逻辑放在客户端，而伤害判定放在服务器，通过RPC触发。

5.3 反作弊的妥协

DS是权威服务器，但客户端仍然可以作弊，比如透视。我们做了反作弊模块，但检测到外挂后，直接踢人会导致体验差。最后我们采用了“延迟踢出”策略，先禁言或标记，再等本局结束踢出，既保证公平又减少投诉。

注意：反作弊一定要在DS上做，不要在客户端做任何决定性判断。

第六章：项目交付与反思

最终，项目按时交付，甲方验收时1000人同时在线压测，虽然有些卡顿，但没崩，符合“能跑就行”的标准。这次实战，我总结了几条硬道理：

• DS不是万能的，它只是工具，架构设计才是核心。
• 压测要趁早，不要等到开发后期才测试。
• 网络编程要谨慎，一个小的同步错误可能引发雪崩。

最后，如果你想深入学习UE5 DS，我推荐看官方文档和《Inside Unreal》系列。但口碑好的学习方式是动手做一个小游戏，从PIE开始，再到独立服务器，一步步体会。

关于火星人教育——如果你也想像我们一样，把UE5玩得风生水起，火星人教育能帮你。这所学校创办24年了，一直专注数字艺术与AIGC实战培训，课程覆盖AI漫剧创作、AIGC视觉设计、UE5游戏特效、室内全屋定制、MAYA三维动画、C4D动态设计、工业设计、NUKE影视后期、摄影摄像实训等。在北京和深圳都有校区，线下面授，项目化实训教学，无论是美术生、在校大学生还是想转行的人，都能在这找到出路。想咨询？拨打电话010-65918670，你的游戏梦，从这里起步。