预算有限时，先别急着在防护和扩容之间二选一。游戏联机业务的低延迟防护架构，应先弄清楚服务器变慢是因为正常玩家变多，还是异常流量挤占了入口和计算资源。前者扩容可能有效；后者只增加机器，攻击流量也可能跟着进入，花费上升却未必恢复体验。
先分辨是容量不足，还是流量异常
看同一时间段的玩家数、每台实例的负载、网络入口流量、连接失败率和游戏内延迟。若玩家数上升时服务器负载同步升高，延迟随实例数量增加而改善，通常是容量问题。若在线人数变化不大，入口流量或连接请求突然攀升，且正常玩家同时掉线，更应先排查异常流量。
还要区分“服务器能处理多少人”和“单局体验是否稳定”。对战游戏可能受单局模拟线程限制：增加服务器数量能分担更多房间，却不一定让一间已过载的房间变快。先用压测确认单实例可稳定承载的房间数，再核对玩家分配方式，避免把扩容误当成所有性能问题的解法。
两笔预算买到的能力不同
| 选择 | 主要解决 | 局限 |
|---|---|---|
| 扩容 | 增加正常业务的计算、内存或并发承载能力 | 无法可靠识别恶意请求；扩容和启动新实例也需要时间 |
| 低延迟防护 | 在业务入口过滤异常流量，降低攻击对正常玩家的影响 | 受接入位置、游戏协议和服务范围影响；清洗路径也可能增加延迟 |
因此，游戏联机业务的低延迟防护架构不是简单地“多买一层”，而是将过滤放在尽量靠近流量入口的位置，并让正常玩家到游戏节点的路径尽可能直接。评估服务时，确认它支持游戏实际使用的通信方式、端口和持续会话，而不只看网页防护能力。Steam Datagram Relay 是 Steamworks 提供的中继方案，可隐藏游戏服务器的直接地址；是否适合，要看游戏是否接入 Steamworks 及其部署方式，不能视为所有游戏通用的防护替代品。
预算有限，按故障证据逐步投入
- 建立基线：按地区、时段记录在线人数、入口流量、连接成功率和游戏内延迟；分别观察平日高峰与活动高峰。
- 做小规模压测：逐步增加模拟玩家，找出实例负载、房间数或网络带宽先触顶的位置。不要只看平均值，也记录短时尖峰和掉线。
- 先补已确认的短板：若正常玩家增长导致资源接近上限，优先扩容最先饱和的资源；若出现突发连接洪峰或服务不可用，优先询价流量清洗，并核实覆盖范围和启用时间。
- 保留必要余量：扩容后以压测结果留出缓冲，而不是按日常平均负载满额配置；防护接入后，从真实玩家所在地区复测延迟与丢包。
- 演练切换流程：明确谁能启用防护、如何确认误拦、怎样回退，并准备玩家公告。未经验证的临时改路由可能让恢复时间更长。
可落地的分层方案
小型团队可先采用“入口防护＋有限实例余量＋基础监控”：入口由具备相应游戏流量清洗能力的服务处理异常流量，游戏节点保留一定余量承载正常波动；按房间或区域分配实例，避免一处故障拖垮全部玩家。防护合同应问清按流量还是按资源计费、哪些端口和地区覆盖、告警与人工响应是否另收费，不能只比较标价。
若业务依赖单台节点或单一地区，扩容还应考虑故障隔离；但多区域部署会增加运维和同步复杂度，不适合只为“看起来更稳”盲目铺开。游戏联机业务的低延迟防护架构最终要以玩家路径和故障数据验收：攻击时正常玩家能否继续连接，平时延迟是否可接受，误拦后能否快速恢复。
常见问题
玩家人数不多，也需要防护吗？
人数少不代表入口不会遭到流量攻击。是否采购应看业务中断的损失、公开可达程度和现有网络服务商的防护能力。
扩容能不能暂时代替防护？
只能应对部分正常负载增长。若入口先被异常流量占满，新增实例可能无法接到正常玩家，也可能增加账单。
低延迟防护会不会让游戏变卡？
可能会，取决于接入位置、转发路径和服务处理方式。上线前应从主要玩家地区实测延迟、丢包与连接稳定性。
预算只够做一项，先买哪种？
有可重复的攻击或入口拥塞证据，先解决防护；压测证实正常玩家增长使实例饱和，则先扩容。证据不足时，先监控和压测，避免凭感觉购买。
