饥荒联机版服务器搭建：Linux、地表洞穴、模组与备份

先说结论：饥荒联机版服务器搭建的关键并不是“把游戏装上去”，而是先决定只开地表，还是同时运行地表（Master）和洞穴（Caves）。完整的地表加洞穴世界需要两个长期运行的 Shard 进程，它们共用一个 Cluster、同一份准入规则和世界关系，但必须使用互不冲突的玩家端口。只启动 Master，玩家可以正常游玩，却无法进入洞穴。

本文以 64 位 Linux、SteamCMD 和官方专用服务端为例，讲清 Klei 令牌、Cluster 目录、Master/Caves 双进程、UDP 端口、模组、正常停服、备份和更新。Klei官方资料复核日期为2026年8月3日；本文属于C级版本与配置验证，没有下载服务端、使用Klei令牌、启动两个Shard或玩家进服，正式开服前应在测试Cluster验证。

联机房间和专用服务器有什么区别？

如果大家总能等房主上线，没必要为了“看起来专业”购买服务器。真正适合 VPS 的需求是：世界需要全天在线、玩家来自不同家庭网络、房主电脑不想长期运行，或者需要洞穴、模组、白名单、日志与自动备份。

Master、Caves和Cluster分别是什么？

• Cluster：一个完整联机世界的顶层目录，保存令牌、房间规则以及各 Shard；
• Master：通常承载地表世界，也负责整个 Cluster 的主节点协调；
• Caves：承载洞穴与遗迹，需要独立的服务端进程；
• Shard：同一 Cluster 中可互相迁移的世界分片，玩家通过洞穴入口在两端切换。

Master 和 Caves 不是两个彼此无关的存档。它们要使用同一个 Cluster 令牌与 Cluster 名称，并通过仅供节点间通信的端口互联。因此不能复制两个旧教程的配置后分别启动，也不能让两个进程占用同一个 UDP 玩家端口。

饥荒联机版服务器需要什么配置？

Klei 公布的客户端最低配置很低，但那不能直接当作完整双 Shard 服务端的购买值。下表是根据进程数量和玩法给出的待实测起点，不是同时在线人数承诺。

饥荒联机版常见瓶颈不只由在线人数决定。大量掉落物、农场、动物、世界事件和脚本模组可能让单核接近满载。购买前可先参考云服务器CPU、内存和带宽选择方法，开服后再用真实世界和玩家行为压测。

开始前需要准备什么？

• 64 位 Linux、公网 IPv4、SSH 管理权限和足够的 SSD 空间；
• 专门运行游戏的普通用户，不用 root 长期启动；
• SteamCMD，用于匿名下载 App ID 343050 的官方服务端；
• 从 Klei 账号页面生成的专用服务器 Cluster Token；
• 明确的 Cluster 名称、世界模式、玩家人数、密码和准入方式；
• 服务器外部的备份位置，以及至少一次恢复测试窗口。

如果是迁移旧世界，先完整复制原来的 Cluster 目录，不要先在原目录上试改端口或模组。旧文件中的 Cluster 名称必须与启动参数一致，否则服务端会创建一个“能启动但没有旧存档”的新目录。

怎样用SteamCMD安装官方服务端？

建议创建独立用户和安装目录，例如 /opt/dst。完成 SteamCMD 安装后，以游戏运行用户执行：

steamcmd +force_install_dir /opt/dst +login anonymous +app_update 343050 validate +quit

343050 是 Don’t Starve Together Dedicated Server 工具的 App ID。下载完成后，先确认 /opt/dst/bin64/ 中存在当前 Linux 64 位服务端二进制，再继续配置。不要从论坛网盘复制“整合服务端”，否则无法确认版本、模组和可执行文件是否被修改。

Cluster Token放在哪里？

登录 Klei 账号管理页面创建专用服务器令牌，把完整内容写入 Cluster 根目录中的 cluster_token.txt。默认持久化根目录为 ~/.klei，默认配置目录为 DoNotStarveTogether，例如：

~/.klei/DoNotStarveTogether/MyDediServer/
├── cluster.ini
├── cluster_token.txt
├── Master/
│   ├── server.ini
│   └── worldgenoverride.lua
└── Caves/
    ├── server.ini
    └── worldgenoverride.lua

令牌文件只授予游戏运行用户读取权限，不要把它放进公开仓库、截图、工单或文章。更换或怀疑泄露时，应在 Klei 账号侧重新生成，再替换服务器上的旧值。

cluster.ini应该先配置哪些内容？

先设置一个最小可验证房间，再逐项增加模组和复杂世界规则。示例字段如下，具体值按实际需求填写：

[GAMEPLAY]
game_mode = survival
max_players = 6
pvp = false
pause_when_empty = true

[NETWORK]
cluster_name = My DST Server
cluster_description = Private survival world
cluster_password = change-this-password
cluster_intention = cooperative

[MISC]
console_enabled = true

[SHARD]
shard_enabled = true
bind_ip = 127.0.0.1
master_ip = 127.0.0.1
master_port = 10888
cluster_key = replace-with-a-random-internal-key

上例假设 Master 与 Caves 在同一台服务器，因此内部通信绑定到 127.0.0.1。如果两个 Shard 分布在不同主机，应改用只在受控私网可达的地址，并限制来源。不要把示例密码或 cluster_key 直接投入生产。公开社区服还要明确是否使用白名单、是否允许 PVP、空服暂停和投票规则。配置保存为 UTF-8 纯文本，修改后先在日志中确认字段被正常读取。

Master和Caves端口怎样分配？

每个 Shard 的玩家 UDP 端口必须唯一。Klei 的命令行文档还说明，局域网广播可见端口通常在 10998–11018 范围。私服可从下面的端口规划起步，但应以实际 server.ini 与启动日志为准：

不同 Shard 的 Steam master/authentication 相关端口也不能冲突。不要照抄一组不清楚年代的端口后把 10000–12000 全部开放。先启动两个进程，结合日志和 ss -lunp 查看真实监听，再让云安全组与 Linux 防火墙只开放玩家需要的 UDP 端口。遇到连接失败时可按服务器端口不通排查指南逐层检查。

两个server.ini有什么区别？

Master 要声明自己是主分片并启用洞穴入口，Caves 要声明为洞穴类型。下面只展示关系，不建议覆盖官方当前版本生成的完整文件：

# Master/server.ini
[NETWORK]
server_port = 10999

[SHARD]
is_master = true

[STEAM]
master_server_port = 27018
authentication_port = 8768

# Caves/server.ini
[NETWORK]
server_port = 11000

[SHARD]
is_master = false
name = Caves

[STEAM]
master_server_port = 27019
authentication_port = 8769

Shard 之间的连接参数要保持在同一 Cluster 内一致，并尽量绑定到回环或私网地址。版本更新后，如果官方模板增加字段，应保留新模板并迁移少量自定义值，而不是把旧文件整份覆盖回去。

怎样启动Master和Caves？

从 64 位二进制目录分别启动两个进程。可以先开两个 SSH 会话观察日志：

cd /opt/dst/bin64
./dontstarve_dedicated_server_nullrenderer_x64 -cluster MyDediServer -shard Master

cd /opt/dst/bin64
./dontstarve_dedicated_server_nullrenderer_x64 -cluster MyDediServer -shard Caves

正式运行应交给 systemd 等守护方式，并让 Master 与 Caves 各自拥有独立日志和重启策略。不要把无限自动重启当作修复；若令牌、端口或模组配置错误，无限重启只会刷满日志和掩盖根因。

玩家怎样进入地表和洞穴？

玩家先通过公开 UDP 端口加入 Cluster，再由游戏世界中的洞穴入口在 Master 与 Caves 间迁移。两个进程必须同时健康，且内部 Shard 通信可达。若地表可玩但进入洞穴后断开，优先检查 Caves 是否启动、端口是否冲突、Cluster 名称和 Shard 关系是否一致。

饥荒联机版服务端模组怎样安装？

服务端下载清单通常放在安装目录的 mods/dedicated_server_mods_setup.lua，实际启用配置放在每个 Shard 的 modoverrides.lua。需要在地表和洞穴生效的模组，应在两个 Shard 中使用一致配置。

1. 记录模组 Workshop ID、版本、依赖和用途；
2. 在测试 Cluster 中一次增加少量模组；
3. 同时检查 Master 与 Caves 启动日志；
4. 用新玩家和已有存档分别进服，测试洞穴迁移；
5. 正常停服、备份后再同步到正式 Cluster；
6. 游戏更新后先验证兼容性，失败时回退模组与存档组合。

“只装了十个模组”不能说明资源需求。世界生成、额外生物和定时扫描类模组，可能比几十个纯界面模组更消耗 CPU。

怎样正常停服和备份？

先通知玩家离线，在两个服务端控制台执行正常关闭，例如：

c_shutdown()

等待进程退出并确认日志完成保存后，再备份整个 MyDediServer/ Cluster 目录。不要直接 kill -9 后复制正在写入的存档。备份至少包含：

• cluster.ini 与准入规则；
• Master、Caves 的世界与会话数据；
• 两个 Shard 的 server.ini、世界生成和模组配置；
• 服务端版本、模组清单和启动参数；
• 受控保存的令牌恢复方案，但不要与普通公开备份混放。

至少一份备份要离开游戏服务器。恢复时在新目录启动副本，验证地表、洞穴、玩家档案和两端迁移，而不是只看压缩包能解压。可参考云服务器快照、备份与恢复方法建立保留周期。

饥荒联机版服务器怎样安全更新？

1. 确认玩家离线并正常关闭 Master、Caves；
2. 备份整个 Cluster、配置与模组清单；
3. 记录当前服务端和模组版本；
4. 执行 steamcmd +force_install_dir /opt/dst +login anonymous +app_update 343050 validate +quit；
5. 先启动测试 Cluster，检查两个进程、模组和洞穴迁移；
6. 验证通过后再恢复正式服访问；失败则从完整恢复点回退。

不要在玩家在线时直接覆盖程序文件，也不要让无人值守脚本在大版本发布后立即更新。稳定运行的目标不是“永远自动最新”，而是更新时间可控、失败可恢复。

常见问题怎样排查？

正式开放前检查清单

1. 服务端只通过 SteamCMD App ID 343050 安装和更新；
2. Cluster Token 未出现在公开文件、日志截图和仓库；
3. Master 与 Caves 使用相同 Cluster、不同玩家端口；
4. Shard 内部通信端口没有向互联网公开；
5. 从另一网络完成地表加入、洞穴迁移和返回地表；
6. 普通玩家不能取得管理权限，密码和白名单符合预期；
7. 模组在两个 Shard 中配置一致并完成兼容测试；
8. 完成一次正常停服、完整备份、异机恢复和再次进服；
9. Master、Caves 的进程、CPU、内存、磁盘和日志均有监控；
10. 更新失败时有明确回退版本和维护窗口。

饥荒联机版服务器怎样选择地域和配置？

先确定主要玩家所在国家和时区，再决定是否运行洞穴、预计同时在线人数、模组类型和备份保留周期。只开地表的小服可从 2 核、2–4GB 起测；完整 Master+Caves 更适合从 2–4 核、4–8GB 起测，再根据两个进程的单核占用和内存峰值调整。

可在萤光云 VPS 地域与配置页查看实时可售节点，并按照玩家位置选择服务器地域的方法筛选候选地区。正式购买前，让主要玩家在工作日和晚高峰分别测试延迟、抖动与丢包，不要只按地图距离判断。

官方资料

• Klei：Dedicated Server Command Line Options Guide
• Klei：Does Don’t Starve Together Have Caves or Ruins Content?
• Klei：Don’t Starve Together System Requirements
• Klei：Logs and Useful Information for Bug Reports

相关推荐

• 云服务器配置怎么选？CPU、内存、硬盘和带宽判断
• 海外云服务器地域怎么选？按玩家位置和线路选节点
• 服务器测试IP怎么看？延迟、路由与丢包测试
• 云服务器安全组怎么设置？端口放行与安全边界
• 云服务器数据怎么备份？快照、备份和恢复方法