饥荒联机版Linux云服务器开服教程：SteamCMD下载与Mod配置-代码聚汇网

饥荒联机版Linux云服务器开服教程：SteamCMD下载与Mod配置

外币兑换·2026-09-04·阅读 22 GEO检测（免费）

Linux云服务器SteamCMD

|难度：普通|阅读约 31 分钟

标题里带具体日期的教程，现在确实很少见了。可在十年前那会儿，《饥荒联机版》（Don't Starve Together）的服务器端几乎每隔几天就变一次，今天照着帖子搭好的服，明天一个热更新可能就起不来。所以当时的教程都会老老实实写一行“截止X年X月X日可用”。

这篇回顾的就是我当年在 Linux 云服务器上搭建 DST 联机服，并装 mod 的完整过程。标题虽然带着 2016 年的时间戳，但整条配置链路里的核心思路到现在依然通用：用 SteamCMD 拉取专用服务器、配置存档目录、申请 Server Token、用 dedicated_server_mods_setup.lua 让服务端自动拉取 Workshop 模组。这适合从来没碰过 Linux 服务器、又想和朋友开一个稳定私服的人，也适合那些已经在 Windows 上开过服、但想迁移到云服务器上的玩家。

提示：本文不会让你背一堆配置文件。我会把每一条命令、每一个文件为什么存在讲清楚，再给你一个能直接跑起来的最小方案。

1. 破局第一步：先把“配置服务器”这件事拆成不吓人的小步骤

很多人的第一反应是：Linux 云服务器？我不会命令行怎么办？其实把整个流程拆开看，就四件事：

在服务器上装一个叫 SteamCMD 的工具，它是 Steam 的命令行版本，专门用来下载游戏服务器程序；
用 SteamCMD 下载 DST 的 Dedicated Server，也就是服务器专用程序；
创建一个服务器的“世界存档目录”，在里面填好启动配置和一个令牌文件；
运行启动命令，让服务器程序把世界跑起来。

至于 mod，是在第 3 步和第 4 步之间插入的额外动作，并没有想象中那么复杂。

当年我在折腾的时候，最难的不是命令，而是理解这套东西的“目录结构”。DST 服务器启动时，会到两个完全不同的地方找文件：

一个地方是 SteamCMD 下载下来的服务器程序目录，里面包含 bin、data、mods 这些文件夹。官方程序、资源文件都在这里；
另一个地方是 ~/.klei/DoNotStarveTogether/ 目录，服务器生成的世界配置、存档、日志都在这里。

这两个目录很容易搞混。有人把 mod 放到 ~/.klei/DoNotStarveTogether/Cluster_1/mods，结果发现服务器日志里报“找不到 mod”，其实就是放错了位置。服务端要加载的 mod 应该放在服务器程序目录下的 mods 文件夹里，存档目录只管配置和启停状态。

我先说清楚这个基础逻辑，后面每一步你都不会懵。

另外，关于“标题日期”还有一个背景。2016 年初的 DST 还处于频繁更新的阶段，很多服务器端的启动方式、配置文件路径都变过不止一次。我当时在论坛上找教程，同一个问题能看到三四种不同写法，谁也不知道哪个才是对的，所以“可用”这个字眼才格外重要。现在的 DST 专服机制已经稳定很多，配置路径和核心流程几乎没再大变，这也是这篇旧经验还能拿来用的原因。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 云服务器选型与网络准备：配置坑从买机器那一刻就开始了

2.1 系统镜像和硬件的最低要求

云服务商选择很多，阿里云、腾讯云、百度云、华为云都有对应的轻量应用服务器或云服务器 ECS。对 DST 这种小体量游戏来说，不需要追求高配，但也不建议买最便宜的 1 核 1G 机型。原因很简单：DST 服务器端运行时要同时处理世界模拟、实体 AI、玩家数据同步，内存太低会频繁触发 swap，一旦 swap，玩家就会觉得“飘”，延迟不稳定。

我的建议是至少 2 核 2G，预算允许就 2 核 4G。这个配置开一个 6 人左右的纯生存世界绰绰有余。如果你想同时开地上和洞穴两个 shard（也就是两个世界进程），4G 内存更稳妥。

系统镜像优先选 Ubuntu Server LTS。不是说 CentOS 不行，而是很多新教程、脚本、依赖包都以 Debian/Ubuntu 系为主，出了问题搜答案时更容易命中。2016 年那会儿我用的还是 Ubuntu 14.04，现在云厂商默认提供 20.04 LTS 或更高版本，包名可能略有变化，但安装思路完全一样，不用刻意去装旧系统。

注意：买完服务器后，记得在服务商控制台把系统盘稍微给大一点。DST 服务器程序本身不大，但 mod、日志、世界存档会慢慢涨。我曾经给过 20G，开了一年多之后存档加上日志差点占满，后来养成了定期清日志的习惯。

2.2 安全组：忘了放行 UDP 10999 会让人怀疑人生

这是最容易被忽略的一步。很多教程默认你是“已经知道要开端口”的老手，但新手最容易卡在这儿。

DST 游戏客户端连接服务器默认走 UDP 10999 端口。云服务商的控制台里都有一个“安全组”或“防火墙”设置，你需要手动加一条入方向规则：协议选 UDP，端口填 10999，来源 IP 可以限制为你朋友们的公网 IP，如果图省事也可以填 0.0.0.0/0。

你可能要问：为什么偏偏是这个端口？因为 DST 最早在设计时就把游戏通信端口固定为 10999，客户端连接服务器时默认探测这个端口。如果你想改端口，需要在 server.ini 里修改 server_port，但新手我强烈建议先用默认值。

我当时犯过的错是只开了 TCP，没开 UDP。结果服务器在后台明明已经跑起来了，世界日志也正常输出，但朋友们在客户端里怎么都搜不到，用 c_connect("服务器IP", 10999) 直连也一直卡在“连接中”。后来排查了半天，才发现安全组里漏了 UDP 规则，加上去之后秒连。

提示：安全组规则修改后立即生效，不需要重启服务器。判断问题是否出在安全组，有一个很简单的方法：在服务器上执行 netstat -lu | grep 10999，能看到监听就说明程序层面没问题，接下来去查安全组和本地防火墙。

2.3 用独立用户跑服务，别直接拿 root 裸奔

2016 年那会儿很多教程图省事，直接让用户用 root 跑服务器。我也不例外。直到有一次加的某个 mod 文件有问题，导致服务器目录里出现了奇怪的文件，我才意识到这种做法风险很高。

Linux 的哲学是“最小权限”。建议创建一个专门用户来跑 DST：

bash复制adduser dst
su - dst

后续的 SteamCMD 下载、服务器启动全都在这个用户下进行。这样做还有一个额外好处：如果哪天服务器被 mod 或异常脚本搞坏，你会有一个相对干净的隔离环境，不至于整个系统遭殃。我知道你会觉得“就开个游戏服而已，至于吗”，但等你真的遇到过坏 mod 就知道了，这一步能省掉不少麻烦。

3. SteamCMD 下载 DST 专服：重复执行的下载命令背后那些门道

3.1 提前安装依赖库

SteamCMD 本质上是一个 32 位的 Linux 程序，所以需要系统里有 32 位兼容库。不同版本的 Ubuntu 包名会不太一样，但整体套路一致：

bash复制sudo apt update
sudo apt install -y lib32gcc1 lib32stdc++6 libcurl4-gnutls-dev

如果你用的 Ubuntu 版本比较新，lib32gcc1 可能找不到，可以换成：

bash复制sudo apt install -y lib32gcc-s1 lib32stdc++6 libcurl4-gnutls-dev

包名报错不要慌，搜索引擎输入“Ubuntu 版本号 + steamcmd 缺少依赖”就能找到对应包名。这里最重要的是把 32 位运行库和 libcurl 相关组件装好，两者缺一个，SteamCMD 或者 DST 服务器启动时都可能直接报错。

3.2 下载并登录 SteamCMD

在 dst 用户的主目录下执行：

bash复制mkdir ~/steamcmd
cd ~/steamcmd
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
tar zxf steamcmd_linux.tar.gz

下载完成后不需要“安装”，直接运行：

bash复制./steamcmd.sh +login anonymous +quit

login anonymous 表示以匿名身份登录。下载 DST 专用服务器不需要你买过游戏的 Steam 账号，这点和某些游戏不一样，算是比较友好的设计。首次运行会提示安装更新，等它跑完就好。

如果下载速度很慢，或者出现 retry、timeout 这类提示，通常不是你的服务器坏了，而是 Steam 内容分发网络的连接不稳定。我的经验是换个非高峰时段重跑，或者干脆多试几次，成功率会高不少。不要一看到卡住就乱改参数，SteamCMD 本身是支持断点继续的，重跑并不会对服务器造成影响。

3.3 用 App ID 343050 下载 DST Dédicated Server

DST 的联机版游戏本体 App ID 是 322330，但服务器专用程序是另一个独立的 App，固定为 343050。很多老教程会让你先下载游戏本体再找服务器文件，那是绕了远路。正确命令如下：

bash复制cd ~/steamcmd
./steamcmd.sh +force_install_dir ~/dstserver +login anonymous +app_update 343050 validate +quit

解释一下这条命令：

+force_install_dir ~/dstserver：指定服务器程序安装到 ~/dstserver 目录。如果不指定，它会装到 SteamCMD 默认的 ~/Steam/steamapps/common/ 下面，以后找起来很麻烦；
+app_update 343050 validate：下载 App 343050 并校验文件完整性；
+quit：命令执行完后自动退出。

第一次下载会拉取几百 MB 到 1GB 左右的文件，取决于当时版本，耐心等即可。下完之后，确认一下目录结构：

bash复制ls ~/dstserver

正常情况下会看到 bin、data、mods、version 等目录。其中 bin 目录下存放的就是服务器启动程序，文件名一般是 dontstarve_dedicated_server_nullrenderer。如果你看到的是 bin64 目录，说明服务器程序已经全面转向 64 位，启动程序在 bin64 里面。不同时期路径会有差异，记住“找 dontstarve_dedicated_server_nullrenderer 这个文件”就行。

3.4 理解 `update`、`validate` 和 mod 的关系

你以后更新服务器时，还会反复用到这条命令。这里有一个实操经验：如果没有特殊必要，更新时可以不带 validate，直接：

bash复制./steamcmd.sh +force_install_dir ~/dstserver +login anonymous +app_update 343050 +quit

validate 会对照官方文件清单做完整性校验，把缺失或异常的文件重新拉取，但也可能影响到 mods 目录里的第三方文件。我过去就有过一次带 validate 更新后，已安装的 workshop mod 出了状况的经历。虽然不能确认是 validate 直接导致的，但从此我养成了一个习惯：更新前先备份 ~/dstserver/mods 目录。

这也能解释为什么我前面强调目录结构。mod 文件放在服务器程序目录的 mods 下，它不属于 Steam 官方内容。每次 SteamCMD 更新服务器本体时，如果不小心影响了 mods 目录，你只需要把备份的 mods 文件还原回去就行，不需要重装整个服务器。

4. 第一次启动即失败？先补上 Token 和最小 Cluster 配置

4.1 第一次启动：让服务器自己生成目录“骨架”

很多教程会让你手动创建一整套 Cluster_1/Master 目录，再手写所有配置。但那样容易写错大小写，而且 DST 的配置键非常敏感，手写一不留神就会导致启动失败。

我的建议是先不带任何配置启动一次，让服务器程序自己生成标准目录，然后再去改文件。执行：

bash复制cd ~/dstserver/bin
./dontstarve_dedicated_server_nullrenderer -cluster Cluster_1 -shard Master

第一次启动大概率会报错退出，因为你还没有提供 Server Token。这没关系。运行结束后，去看看用户数据目录：

bash复制ls ~/.klei/DoNotStarveTogether/Cluster_1/

你会发现程序已经自动创建了 Master、Caves（如果版本支持）以及各种配置文件的骨架。这时要做的事情就变得很清晰了：改配置 + 填 Token。

4.2 申请 cluster_token.txt：DST 专服的“身份证”

DST 的专用服务器启动时必须有一个 Token，否则服务器不会向 Steam 的服务器列表注册，其他玩家也就无法通过游戏内置的浏览功能找到你的服。

申请流程很简单：

打开 Klei 的账号管理页面（用 Steam 账号登录）；
找到“Don't Starve Together Server Token”相关选项；
点击生成/刷新按钮，页面会给出一串很长的十六进制字符串；
把这串内容完整复制，保存到 ~/.klei/DoNotStarveTogether/Cluster_1/cluster_token.txt。

注意文件名和路径必须完全一致：是 cluster_token.txt，不是 token.txt，也不是 Cluster_Token.txt。Linux 对大小写敏感，这是我当年反复栽过跟头的地方。另外，Token 是跟着你的 Steam 账号走的，只要你不主动刷新它，长期有效。如果你不想把 Token 发给别人，就注意保护好这个文件。

4.3 最小可用的 cluster.ini 和 Master/server.ini

Token 填好后，开始配置世界。DST 的配置分成两层：

cluster.ini：描述整个世界的公共属性，比如房间名、密码、最大玩家数；
Master/server.ini：描述 Master shard 的运行参数。

先看 ~/.klei/DoNotStarveTogether/Cluster_1/cluster.ini 的最小示例：

ini复制[NETWORK]
cluster_name = My DST Server
cluster_description = Play with friends
cluster_password = 
game_mode = survival
max_players = 6
pvp = false

[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 = defaultsecretkey

这里的 [SHARD] 段在 2016 年之后的版本里基本都会自动生成，不用刻意去删。cluster_key 是 Master 和 Caves 等不同进程之间通信时用的内部密钥，不是玩家连接密码。玩家连接密码是上面的 cluster_password。

再改 ~/.klei/DoNotStarveTogether/Cluster_1/Master/server.ini：

ini复制[NETWORK]
server_port = 10999

[SHARD]
is_master = true

[STEAM]
master_server_port = 27016
authentication_port = 8768

这几行的意思：

server_port = 10999：游戏客户端的连接端口；
is_master = true：这个进程是主世界；
[STEAM] 段里的端口是服务器向 Steam 后端注册时使用的，一般保持默认就行。

如果你觉得配置太复杂，还有一个偷懒办法：直接把 cluster.ini 和 server.ini 留空，只填 Token，DST 服务器会用内置默认值启动。我刚入门时不知道这一点，总担心漏配置，后来看了官方源码才发现框架层的默认值覆盖面很全。所以对新手来说，宁可用最小配置跑通，也不要从网上抄一份你没理解的重型配置来用。

4.4 如何判断服务器真的起来了

配置完成后，重新执行启动命令：

bash复制cd ~/dstserver/bin
./dontstarve_dedicated_server_nullrenderer -cluster Cluster_1 -shard Master

看到日志里出现类似 Sim Pause、Waiting for players 或 Server started 之类的输出，并且没有红色报错，就说明服务器已经成功运行。

但这个进程还挂在当前终端，你一旦关掉 SSH 窗口，服务器就跟着停了。所以正常开服之前，需要让它在后台常驻。我后面的章节会专门说这个问题，先不要急。

想验证能不能连，最简单的方式是打开本机 DST 客户端，按波浪线打开控制台，输入：

code复制c_connect("你的服务器公网IP", 10999)

注意：客户端控制台命令需要 console_enabled = true 才能在服务器端看到一些信息，这个在上面配置里已经开了。如果连接成功后能进入世界，说明整套基础链路已经通了，这时候再考虑加 mod，心态会稳很多。

5. Mod 导入的两条路线与服务器端启用逻辑

5.1 先从“谁在下载 mod”说起

在讲具体操作前，我得先掰扯清楚 DST 的 mod 加载机制，否则你会遇到“明明把 mod 放进去了，客户端还是说没装”这种问题。

DST 的 mod 分两个环节：

服务端需要本地拥有 mod 文件，并且在存档配置里声明启用；
客户端也需要本地拥有相同 mod，通常是玩家通过 Steam 创意工坊订阅。

玩家连入服务器时，客户端会校验自己有没有对应 mod。如果服务器启用了某个 mod 而客户端没有，玩家会因为版本不一致或缺少内容而无法正常进入。服务器本身不会把 mod 完整传给客户端，所以“一人订阅，全员共享”在 DST 里并不成立。

所以你在搭建服务器时，需要关心两个问题：

怎么让服务端拿到 mod 文件；
怎么让服务端在启动时启用这些 mod。

5.2 推荐路线一：用 dedicated_server_mods_setup.lua 自动拉取

这是 DST 服务器程序内置的正规方案，也是我现在最推荐的做法。它解决“服务端拿到 mod 文件”这件事。

首先进入服务器程序目录下的 mods 文件夹：

bash复制cd ~/dstserver/mods
ls

里面会有一个 dedicated_server_mods_setup.lua 文件，这就是给专用服务器准备的 mod 下载清单。用任何文本编辑器打开它，填上你在 Steam 创意工坊看到的 mod 的 Workshop ID。

lua复制-- 示例：启用 Global Positions 这个经典mod
ServerModSetup("378160973")

Workshop ID 是哪一串？打开创意工坊页面，看浏览器地址栏。例如某个 mod 的页面地址末尾是 ?id=378160973，那这个串就是它的 Workshop ID。不要填成 mod 页面的中文名，也不要填模组在游戏里显示的序号，必须是那串纯数字。

如果你希望玩家能直接通过合集一次订阅多个模组，官方也支持集合：ServerModCollectionSetup("合集的ID")。但我个人更推荐逐条写 ServerModSetup，因为排查某个 mod 出问题时更直观。

下次启动服务器程序时，它会读取这个 lua 文件，并自动把对应的 Workshop mod 下载到 ~/dstserver/mods/workshop-378160973 这样的目录里。也就是说，服务器不再需要你手动上传 mod 文件，只要有网，它自己会跑一趟创意工坊。

提示：修改 dedicated_server_mods_setup.lua 后，只会在服务器重启时触发下载。如果某个 mod 下载失败，你可以先杀掉服务器进程再重启一次，日志里会显示下载进度和结果。

5.3 备选路线二：把本地 mod 文件直接传到服务器

2016 年那会儿，dedicated_server_mods_setup.lua 还不像现在这样稳定，很多玩家的做法是“本地把 mod 下载好，再把文件传到服务器”。

具体操作是：

在本地 Steam 客户端的 DST 创意工坊页面订阅需要的 mod；
Steam 会自动把 mod 文件下载到本地 DST 的 mods 目录，例如 Windows 上可能是 Steam/steamapps/workshop/content/322330/<WorkshopID>；
把服务器上 ~/dstserver/mods 里的同名文件夹替换或新增为你本地的 mod 文件夹；
启动服务器时，它就能在本地找到这些 mod。

这种做法的优点是你可以完全控制 mod 的版本，避免服务器端自动拉到的版本和你本地不一致。缺点是每次改 mod 都要手动传文件，mod 一多非常累。

另外要注意权限。通过 FTP 或 SCP 上传的文件，默认属主可能不是你跑服务器的那个用户。传完之后最好执行：

bash复制cd ~/dstserver/mods
chown -R dst:dst workshop-*
chmod -R u+rwX workshop-*

否则服务器进程可能没有权限读这些文件，启动时会出现“无法打开 mod 文件”的报错。

现在我的习惯是首选自动拉取路线，只有碰到网络不好的情况，或者需要调试某个 mod 的特定版本时，才会用本地手动上传。两条路不冲突，你也可以都用：先用 setup 自动下载，再手动覆盖特定版本。

5.4 启用 mod：modoverrides.lua 是关键

很多人的误区是：只要把 mod 放进服务器 mods 目录，它就会自动生效。实际上不是，你还需要一个“启用开关”，这个开关就是 modoverrides.lua。

这个文件的位置在存档目录里。以我们只跑 Master 的布局为例，路径是：

code复制~/.klei/DoNotStarveTogether/Cluster_1/Master/modoverrides.lua

它会告诉服务器：我需要启用哪些 mod、这些 mod 的参数配置是什么。示例内容如下：

lua复制return {
  ["workshop-378160973"] = {
    enabled = true
  }
}

每次加新 mod，都要在上面这个表里面加一行。这里有一件非常容易被忽略的事：如果以后你加开了洞穴 Caves 进程，modoverrides.lua 要同时在 Master 和 Caves 两个 sh