Valve 在 Valve Developer Community wiki 上维护的官方 CS2 专用服务器文档，为运营者提供了一个了解 Steam 最受欢迎竞技游戏之一背后基础设施决策的窗口。该文档与游戏于 2023 年 9 月发布时一同公布，面向服务器管理员，而非工程师。但细读之下，它揭示了任何多人游戏开发者都能借鉴的深思熟虑的架构选择。

Valve 在反作弊方面的工作也贯穿着另一条线索。我们之前在 CS:GO 反作弊深度解析 中介绍过的工程师 John McDonald 2018 年 GDC 关于 VACNet 的演讲，如今对 CS2 依然直接适用，因为该系统已经持续演进。这两条线索都值得继续读下去，帮助多人游戏开发者评估自己的架构决策。

合并客户端与服务器

文档中最立刻引人注目的细节，恰恰是一个看起来很常规的点：CS2 专用服务器和游戏客户端现在共享同一个 Steam App ID。在 CS:GO 中，客户端是 appid 730，而专用服务器是 appid 740。两个独立下载、两条更新管线、两个版本漂移的来源。在 CS2 中，两者都归于 appid 730。

这种整合让有意义的运维工作变得更简单。服务器运营者只需维护一套安装。更新脚本只需针对一个 ID。社区文档也会汇聚，而不是分裂。对于运行大量实例的团队来说，去掉一个会分叉的依赖，确实能带来实实在在的体验提升。

代价也在同一份文档里清晰可见：服务器镜像现在携带了它永远不会用到的仅客户端资产。因此，CS2 服务器下载包的体积约为 60 GB。这是一项真实的基础设施成本，尤其对需要同时启动大量实例的工作室来说更是如此。

Valve 选择了运维简洁而非存储效率，文档也没有掩饰这一缺点。承认这种权衡取舍，本身就很值得借鉴。

以容器为先的托管

CS2 在发布时就原生支持 Docker。文档展示了一套一条命令即可完成的设置：只需一次 docker run 调用，就能拉取镜像、绑定所需端口，并在容器重启时，于 Valve 推出补丁后自动更新服务器。无需手动更新脚本。也不会再出现过期二进制与正在运行的游戏之间的版本不一致。

社区在这一基础上迅速行动起来。发布后的几周内，像 CS2 Pterodactyl 这样的项目，就已经与许多社区运营者早已在使用的开源游戏面板建立了直接集成。这种采纳速度反映出 Valve 方法中的一个刻意设计：发布清晰、稳定的文档并支持标准工具，本身就是一项基础设施决策。Valve 只做了一次文档工作，基于它构建出的生态则由其他人完成。

对于评估是否要尽早投入 Docker 和原生容器化服务器设计的开发者来说，CS2 的发展轨迹是一个很有参考价值的例子。前期的文档投入会随着时间不断复利。

Sub-Tick：将精度与 Tick 频率解耦

文档暗示了 CS2 的 sub-tick 架构，但并未深入解释。它值得单独成文，而 Valve 官方发布视频《超越 Tick Rate》会是那篇文章的主要来源。不过，这里的核心概念仍值得先简要说明。

在 CS:GO 中，就像大多数竞技射击游戏一样，所有玩家操作都会在服务器的 tick 边界被处理。在 64 Hz 下，tick 每 15.6 毫秒到来一次。如果你在 tick 边界前 1 毫秒开火，服务器会把这次射击当作发生在 14.6 毫秒后。像 FACEIT 这样的竞技平台专门运行 128 Hz 服务器，就是为了把这个间隔减半，这也是社区如此在意 tick 率的原因。

CS2 的 sub-tick 系统则以不同方式绕开了这个问题。现在每个客户端输入都会携带精确时间戳。服务器接收这些时间戳，并无论事件发生在 tick 的哪个位置，都重建出精确的事件顺序。理论上，tick 率作为输入精度的代理指标，其重要性会下降。

但在实践中，自发布以来的社区争论要复杂得多。包括 FaZe 的 Robin "ropz" Kool 在内的一些职业选手都指出，对有经验的玩家来说，这种主观手感仍然没有完全达到 128 Hz 的 CS:GO。技术正确性与感知响应之间的差距，本身就是一个有价值的开发者洞察：玩家对延迟的感知，并不等同于实际测得的延迟。关于这一点，未来会有更详细的文章。

反作弊作为学习系统

服务器文档主要聚焦于安装与配置，因此对反作弊几乎没有直接说明。但若不提反作弊，就无法完整讨论 CS2 的后端。

VACNet 最初为 CS:GO 构建，如今在 CS2 中以 VAC Live 的形式运行，它被设计成一个持续学习的闭环。John McDonald 在 2018 年 GDC 上介绍该系统时，提炼出的核心洞见是：CS:GO 的 Overwatch 复审系统在没人想到利用之前，已经悄悄生成了多年的带标签训练数据。McDonald 指出："在搭建管线之前，先审视你已经拥有的带标签数据。"

该架构的关键设计决策，是把人类保留在最终裁决环节中。VACNet 不会直接封禁玩家。它会把高置信度案件提交给人类 Overwatch 裁决者，由他们审查并作出决定。这些裁决结果再反馈到下一轮重训练中。一个作弊开发者如果摸清模型关注的具体模式，并据此调整工具，最终仍会面对能识别作弊的人类裁决者。这个裁决会成为新的训练数据。系统会从每一次攻击中成长，而不是被攻击所推翻。

自 CS2 发布以来，该系统已经具备实时检测能力。最初的 VACNet 会在比赛结束后标记玩家，供事后复审。如今 VAC Live 可以在检测到作弊者的瞬间，中途取消比赛。从批处理分析到实时推理的转变，正是 McDonald 在 2018 年演讲结尾提到的那种"持续进行中的工作"方向。这个闭环仍在运行，只不过现在是实时运行。

完整的架构拆解，包括数据管线、Trust Score 系统，以及在最终裁决中保留人类参与这一设计原则，已在我们的 CS:GO 反作弊深度解析 中展开。

社区服务器与托管问题

自 CS 1.6 以来，Valve 就允许玩家运行自己的 Counter-Strike 服务器。这种延续并非偶然。社区服务器一直是 Counter-Strike 长寿的核心：自定义地图、瞄准训练服务器、surf 和 KZ 社区，以及最终成长为 FACEIT 和 ESEA 的竞技基础设施。这个生态建立在 Valve 使其成为可能并清晰记录的托管模式之上。

就 Valve 自身而言，开放托管是一种他们负担得起的取舍。服务器托管带来的收入流向社区运营者，而不是 Valve。作为交换，Valve 获得了一个能够维持玩家兴趣、竞技对战以及长期参与度的生态系统，这些都支撑着一个已有 25 年历史的系列。

对于没有 Steam 平台支撑的工作室来说，这笔账就不同了。社区托管对某些人来说是成本中心；问题在于由谁来承担。工作室可以把专用服务器转售纳入自己的商业模式——将托管私服作为与外观道具或赛季通行证并行的产品线。容器即服务基础设施让这件事比几年前更可行。像 Edgegap 的 游戏服务器编排 这样的平台，可以让工作室在不自行构建托管栈的情况下提供这种转售，把传统上的纯成本转变为潜在收入来源。

是否开放托管，应当取决于社区真正需要什么，以及工作室能够承受什么。Valve 的历史具有启发性，但那是一段建立在特定优势之上的历史，并不会自动迁移。

—

本文基于并引用了 Valve 在 Valve Developer Community wiki 上发布的官方 CS2 专用服务器文档，以及 John McDonald 在 GDC 2018 上关于 VACNet 的演讲，该演讲可在 GDC YouTube 频道 上观看。

原始内容中的所有权利归各自所有者所有。