1. 为什么用 Docker 跑 WOW 服务端是当前最省心的方案
把 WOW 服务端塞进 Docker 这件事，最早在圈子里并不被看好。原因很直接：传统编译方式要装一堆依赖、改配置文件、处理数据库导入，每一步都可能卡住新手。但真正折腾过几轮之后你会发现，Docker 方案的核心价值不在于"新"，而在于环境隔离和可重复部署——你在一台机器上跑通的配置，换一台机器几乎不用改任何东西就能复现。
我最初用的是手动编译方案，光是处理依赖冲突就花了大半天。后来换成 Docker 之后，从拉取镜像到服务端跑起来，整个过程压缩到了二十分钟以内。这个差距不是一点点。
这篇文章面向的是想自己搭一个 WOW 服务端来玩、来研究、或者用来做二次开发的人。不管你之前有没有 Docker 基础，只要你能照着命令行敲，就能跟着走完。我会把每一步为什么这么做讲清楚，也会把踩过的坑提前告诉你。
注意：本文涉及的所有操作均在本地或自有服务器上进行，用于个人学习和研究目的。请确保你使用的客户端和服务端资源来源合法合规。
1.1 先搞清楚 WOW 服务端的几个核心组件
在动手之前，有必要先弄明白一个 WOW 服务端到底由哪些东西组成。很多人一上来就照着教程敲命令，结果出了问题完全不知道是哪个环节的毛病。
一个典型的 WOW 服务端包含以下几个核心部分：
- 认证服务（Auth Server）：负责处理客户端的登录请求，验证账号密码，返回游戏世界服务器的地址。它监听一个固定端口，通常是 3724。
- 世界服务（World Server）：游戏逻辑的核心，处理角色移动、战斗、任务、NPC 交互等几乎所有游戏内行为。默认端口是 8085。
- 数据库（MySQL/MariaDB）：存储账号信息、角色数据、世界数据（NPC、物品、任务等）。通常分为三个库：auth、characters、world。
- 客户端数据文件（DBC/DB2、地图文件等）：服务端需要读取客户端的部分数据文件才能正确运行，比如地图碰撞数据、技能数据等。
Docker 方案的本质，就是把上述这些组件分别打包成容器，通过 Docker 网络让它们互相通信。你不需要在宿主机上直接安装 MySQL，也不需要手动编译服务端核心，一切都在容器里完成。
1.2 Docker 方案和传统手动编译的对比
| 对比维度 | 传统手动编译 | Docker 方案 |
|---|---|---|
| 环境准备时间 | 2-4 小时（依赖多） | 20-30 分钟 |
| 依赖冲突风险 | 高 | 极低（容器隔离） |
| 跨平台一致性 | 差 | 好 |
| 数据持久化 | 需手动配置 | 通过 volume 挂载 |
| 升级/回滚 | 复杂 | 替换镜像即可 |
| 资源占用 | 略低 | 略高（容器开销） |
| 学习曲线 | 陡峭 | 平缓 |
从表里可以看出来，Docker 方案唯一的劣势是资源占用稍微高一点，但这个差距在现代硬件上几乎可以忽略。对于绝大多数个人玩家和小型研究场景来说，Docker 方案的优势是压倒性的。
2. 动手之前的准备工作：别急着敲命令
我见过太多人一上来就docker run，结果卡在镜像拉取、端口冲突、数据库连接失败这些基础问题上。准备工作做足了，后面的路会顺很多。
2.1 硬件和操作系统的选择
WOW 服务端对硬件的要求其实不算高，但有几个关键点需要注意：
- 内存：建议至少 4GB 可用内存。世界服务在加载地图数据时会占用较多内存，如果同时跑数据库容器，2GB 会非常吃力。
- 磁盘：至少预留 30GB 空间。服务端镜像、数据库数据、客户端地图文件加起来轻松超过 20GB。
- CPU：双核以上即可，世界服务主要是单线程负载，核心多并不会显著提升性能。
操作系统方面，Linux 是最省心的选择，Ubuntu 22.04 或 Debian 12 都很稳。Windows 用户可以用 Docker Desktop，但需要注意 WSL2 的内存分配问题——默认配置下 WSL2 可能只给容器分配一半的物理内存，跑起来会卡。
提示：如果你在 Windows 上跑，建议在用户目录下创建
.wslconfig文件，手动限制 WSL2 的内存上限，避免它吃掉太多系统资源。
2.2 Docker 和 Docker Compose 的安装确认
不管你用的是哪个平台，装完 Docker 之后一定要确认两件事：
# 确认 Docker 版本 docker --version # 确认 Docker Compose 可用 docker compose version如果docker compose version报错，说明你装的是旧版 Compose（docker-compose带横杠），建议升级到 Docker 官方的新版 Compose 插件。新版在语法和性能上都有明显改进。
Linux 用户还需要注意权限问题。默认情况下，只有 root 用户和 docker 组的成员才能执行 Docker 命令。如果你不想每次都加sudo，可以把自己加到 docker 组：
sudo usermod -aG docker $USER # 执行后需要重新登录才能生效2.3 镜像源的选择与拉取速度优化
国内拉取 Docker Hub 镜像的速度经常让人抓狂。解决办法是配置镜像加速器。在/etc/docker/daemon.json（Linux）或 Docker Desktop 的设置界面（Windows/Mac）中添加：
{ "registry-mirrors": [ "https://your-mirror-address.com" ] }配置完成后重启 Docker 服务。具体用哪个加速地址，建议自己搜索当前可用的公共镜像源，因为这类服务的可用性变化比较快。
另外，WOW 服务端的镜像体积通常不小（1-3GB），拉取时建议在网络状况好的时候进行，避免中途断连导致重试。
3. 用 Docker Compose 编排 WOW 服务端：一步步来
单独用docker run启动多个容器会非常麻烦——你需要手动创建网络、配置容器间的连接、管理数据卷。Docker Compose 把这些东西都写在一个 YAML 文件里，一条命令就能拉起整个服务栈。
3.1 目录结构规划
在开始写 Compose 文件之前，先把目录结构规划好。我习惯用这样的布局：
wow-server/ ├── docker-compose.yml ├── data/ │ ├── mysql/ │ ├── auth/ │ └── world/ ├── etc/ │ ├── authserver.conf │ └── worldserver.conf └── logs/这个结构的好处是：数据、配置、日志分离，备份和迁移的时候一目了然。data/mysql目录会挂载到数据库容器里，确保容器删除后数据不丢。
3.2 docker-compose.yml 的编写逻辑
下面是一个经过实测可用的 Compose 配置框架。我会逐段解释每个配置项的作用：
version: "3.8" services: mysql: image: mysql:8.0 container_name: wow-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: wowroot123 MYSQL_DATABASE: world volumes: - ./data/mysql:/var/lib/mysql - ./sql:/docker-entrypoint-initdb.d ports: - "3306:3306" command: --default-authentication-plugin=mysql_native_password networks: - wow-net authserver: image: your-wow-server-image:latest container_name: wow-auth restart: unless-stopped depends_on: - mysql volumes: - ./etc/authserver.conf:/etc/authserver.conf - ./logs:/var/log/wow ports: - "3724:3724" networks: - wow-net worldserver: image: your-wow-server-image:latest container_name: wow-world restart: unless-stopped depends_on: - mysql volumes: - ./etc/worldserver.conf:/etc/worldserver.conf - ./data/world:/data - ./logs:/var/log/wow ports: - "8085:8085" networks: - wow-net networks: wow-net: driver: bridge几个关键点需要展开说：
MySQL 的认证插件。MySQL 8.0 默认使用caching_sha2_password认证方式，但很多 WOW 服务端的数据库连接库还不支持这个插件。加上--default-authentication-plugin=mysql_native_password可以避免连接被拒绝的问题。这个坑我踩过，排查了半天才发现是认证插件的问题。
depends_on 的局限性。depends_on只保证容器启动顺序，不保证 MySQL 已经准备好接受连接。如果 authserver 启动时 MySQL 还在初始化，连接会失败。解决办法是在服务端配置里加上重试逻辑，或者用healthcheck配合condition: service_healthy。
数据卷挂载。./data/mysql:/var/lib/mysql这行确保了数据库文件持久化。如果你不挂载这个卷，每次删除容器后所有账号和角色数据都会丢失。
3.3 数据库初始化：导入 SQL 文件的正确姿势
WOW 服务端的数据库需要导入大量的 SQL 文件。这些文件通常分为三类：
- 基础结构：创建表、索引、存储过程
- 世界数据：NPC、物品、任务、地图等静态数据
- 更新补丁：后续的修复和内容更新
用 Docker 初始化数据库有两种方式：
方式一：利用/docker-entrypoint-initdb.d目录。把 SQL 文件放到这个目录下，MySQL 容器首次启动时会自动按字母顺序执行。这种方式适合全新部署，但缺点是只在数据库目录为空时执行，后续添加的 SQL 不会自动运行。
方式二：手动导入。容器启动后，用docker exec进入 MySQL 容器，手动执行导入命令：
docker exec -i wow-mysql mysql -uroot -pwowroot123 world < world_database.sql对于大型 SQL 文件（世界数据库通常几百 MB），方式二更可控。你可以看到导入进度，出错了也能及时中断。
注意：导入大型 SQL 文件时，建议临时调大 MySQL 的
max_allowed_packet参数，否则可能因为单条语句过大而失败。
4. 配置文件的关键参数：让服务端真正跑起来
镜像和容器都起来了，不代表服务端就能正常工作。配置文件里的几个关键参数如果不对，客户端连上来就是黑屏或者直接断开。
4.1 authserver.conf 里必须改的几项
认证服务的配置相对简单，但有几项必须和你的实际环境匹配：
- LoginDatabaseInfo：数据库连接字符串，格式是
主机;端口;用户名;密码;数据库名。在 Docker 环境下，主机名填 MySQL 容器的服务名（比如mysql），而不是localhost或127.0.0.1。 - RealmServerPort：认证服务监听端口，默认 3724。如果你改了宿主机的映射端口，这里也要对应修改。
- LogsDir：日志目录，确保容器内该路径存在且可写。
一个常见的错误是把数据库主机写成localhost。在容器里，localhost指向的是容器自身，而不是 MySQL 容器。必须用 Docker 网络中的服务名或者容器 IP。
4.2 worldserver.conf 的核心配置项
世界服务的配置项多得多，但真正影响能否跑起来的主要是这几个：
| 配置项 | 作用 | 常见错误值 | 正确做法 |
|---|---|---|---|
| WorldDatabaseInfo | 世界数据库连接 | localhost | 填 MySQL 服务名 |
| CharacterDatabaseInfo | 角色数据库连接 | localhost | 填 MySQL 服务名 |
| LoginDatabaseInfo | 认证数据库连接 | localhost | 填 MySQL 服务名 |
| DataDir | 客户端数据文件路径 | 空 | 指向挂载的地图数据目录 |
| WorldServerPort | 世界服务端口 | 与 auth 冲突 | 保持 8085 |
| GameType | 游戏模式 | 随意设置 | 根据需求选 0（普通）或 1（PVP） |
DataDir 是最容易出问题的一项。服务端需要读取客户端的 DBC、地图、VMaps、MMaps 文件。这些文件需要从客户端提取，然后挂载到容器里。如果这个路径不对或者文件缺失，世界服务启动时会直接报错退出。
4.3 数据库连接失败的排查思路
数据库连接失败是新手遇到最多的问题。排查的时候按这个顺序来：
- 确认 MySQL 容器正在运行：
docker ps看状态 - 确认网络连通：
docker exec wow-auth ping mysql测试容器间通信 - 确认账号密码正确：用
docker exec -it wow-mysql mysql -uroot -p手动登录测试 - 确认数据库已创建：
SHOW DATABASES;看 auth、characters、world 三个库是否存在 - 确认认证插件：
SELECT user, plugin FROM mysql.user;看 root 用户的认证方式
这五步走下来，九成以上的连接问题都能定位到。
5. 客户端连接与服务端验证：最后一步别翻车
服务端跑起来了，日志里没有报错，但这不代表客户端就能连上。客户端这边还有几个地方需要配置。
5.1 客户端 realmlist 的设置
客户端的realmlist.wtf文件决定了它去哪个地址找认证服务。如果你在本地跑服务端，内容就是：
set realmlist 127.0.0.1如果你在局域网的另一台机器上跑客户端，把127.0.0.1换成服务端所在机器的局域网 IP。
这里有个细节：认证服务返回给客户端的世界服务器地址，是在数据库的realmlist表里配置的。如果这个表里的地址是127.0.0.1，那么只有本机客户端能连上。局域网其他机器连接时，需要把realmlist表里的address字段改成服务端的局域网 IP。
UPDATE auth.realmlist SET address = '192.168.1.100' WHERE id = 1;这个坑非常隐蔽，因为认证阶段能通过，但进入世界阶段就会卡住。我第一次遇到的时候以为是世界服务没起来，查了半天日志才发现是数据库里的地址不对。
5.2 验证服务端是否正常工作的几个信号
服务端正常启动后，日志里会出现这些关键信息：
- authserver：
Added realm "YourRealm" at 192.168.x.x:8085. - worldserver：
World initialized in XXXX ms - worldserver：
Starting up anti-freeze thread
如果看到World initialized这行，说明世界服务已经成功加载了所有数据，可以接受客户端连接了。
客户端这边，成功登录后会看到角色选择界面。如果卡在"正在连接"或者"已断开连接"，回到上面检查 realmlist 表和端口映射。
5.3 性能调优的几个实用参数
服务端跑起来之后，如果觉得卡顿或者响应慢，可以调整这几个参数：
- MapUpdateInterval：地图更新间隔，默认 100ms。调低会让游戏更流畅，但 CPU 占用会上升。
- MaxCoreStuckTime：世界服务卡死检测时间，默认 60 秒。如果服务端经常被判定为卡死，可以适当调大。
- PlayerLimit：最大玩家数，个人使用设小一点（比如 10）可以节省资源。
另外，MySQL 的innodb_buffer_pool_size对性能影响很大。如果宿主机内存充足，可以把这个值设成可用内存的 50%-70%。
6. 踩过的坑和实测经验
这部分是我在实际部署过程中积累的一些经验，有些是文档里不会写的，但确实能帮你省时间。
6.1 容器时区问题导致日志时间错乱
Docker 容器默认使用 UTC 时间，而服务端日志和数据库记录的时间戳都是 UTC。如果你习惯看本地时间，会觉得所有时间都差了 8 小时。解决办法是在 Compose 文件里设置时区环境变量：
environment: - TZ=Asia/Shanghai这个设置对 MySQL 容器和服务端容器都要加。MySQL 的时间戳如果不对，还会影响游戏内的一些时间相关功能。
6.2 地图数据文件的提取和挂载
服务端需要的地图数据（VMaps、MMaps）必须从客户端提取，这个过程在 Windows 上通常用工具完成。提取出来的文件可能有几个 GB，挂载到容器里时要注意：
- 文件权限：容器内的服务端进程需要对文件有读权限
- 挂载方式：用 bind mount 而不是 volume，方便在宿主机上直接管理文件
- 路径一致性：worldserver.conf 里的 DataDir 要和挂载点完全一致
我建议把地图数据放在宿主机的一个独立目录里，然后只读挂载到容器：
volumes: - ./data/maps:/data:ro只读挂载可以防止服务端意外修改地图文件。
6.3 数据库导入失败的常见原因
导入大型 SQL 文件时失败，通常有这几个原因：
- max_allowed_packet 太小：默认 64MB，大型 SQL 文件可能超过这个限制。在 MySQL 配置里改成 256MB 或更大。
- 字符集不匹配：SQL 文件可能是 utf8mb4 编码，但数据库默认字符集是 latin1。建库时指定
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。 - 外键约束冲突：导入顺序不对可能导致外键约束失败。按照基础结构、世界数据、更新补丁的顺序导入。
- 磁盘空间不足：世界数据库导入后可能占用几个 GB，提前确认磁盘空间。
6.4 容器重启后服务端无法自动恢复
用restart: unless-stopped可以让容器在异常退出后自动重启，但如果 MySQL 启动比服务端慢，服务端会因为连不上数据库而反复重启。解决办法是给 MySQL 加健康检查：
healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 5然后在服务端的depends_on里加上条件：
depends_on: mysql: condition: service_healthy这样服务端会等 MySQL 完全就绪后才启动，避免无谓的重启循环。
6.5 日志管理：别让日志把磁盘撑满
服务端运行一段时间后，日志文件会变得很大。如果不加管理，可能几天就把磁盘占满。几个应对措施：
- 在 worldserver.conf 里调低日志级别，只记录必要信息
- 用 Docker 的日志驱动限制单个容器的日志大小
- 定期清理旧日志，或者用 logrotate 做轮转
Docker 的日志限制可以在 Compose 文件里配置：
logging: driver: "json-file" options: max-size: "50m" max-file: "3"这样每个容器最多保留 3 个 50MB 的日志文件，总共不超过 150MB。
7. 后续可以怎么扩展这套方案
这套 Docker 方案跑通之后，其实还有很多可以折腾的方向。比如把服务端拆成多个世界服务实例来分担负载，或者用 Docker 的 overlay 网络把服务端部署到多台机器上。也可以把数据库单独抽出来放到性能更好的存储上，服务端容器只负责计算。
我个人比较推荐的一个扩展方向是加一个 Web 管理面板，用来查看在线玩家、管理账号、监控服务端状态。这类面板通常也是 Docker 镜像，直接加到 Compose 文件里就行，不需要额外配置环境。
另一个实用的扩展是定时备份。用 cron 容器定期执行mysqldump，把数据库备份到宿主机或者远程存储。角色数据丢了是真的心疼，这个投入绝对值得。
最后分享一个小技巧：如果你经常需要重建服务端环境，可以把整个wow-server目录做成一个 Git 仓库，把 Compose 文件、配置文件、SQL 文件都纳入版本管理。这样每次调整配置都有记录，出问题了也能快速回滚。地图数据和数据库文件用.gitignore排除掉，只管理文本配置。
