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报错说明你装的是旧版 Composedocker-compose带横杠建议升级到 Docker 官方的新版 Compose 插件。新版在语法和性能上都有明显改进。Linux 用户还需要注意权限问题。默认情况下只有 root 用户和 docker 组的成员才能执行 Docker 命令。如果你不想每次都加sudo可以把自己加到 docker 组sudo usermod -aG docker $USER # 执行后需要重新登录才能生效2.3 镜像源的选择与拉取速度优化国内拉取 Docker Hub 镜像的速度经常让人抓狂。解决办法是配置镜像加速器。在/etc/docker/daemon.jsonLinux或 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-pluginmysql_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-pluginmysql_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 冲突保持 8085GameType游戏模式随意设置根据需求选 0普通或 1PVPDataDir 是最容易出问题的一项。服务端需要读取客户端的 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 验证服务端是否正常工作的几个信号服务端正常启动后日志里会出现这些关键信息authserverAdded realm YourRealm at 192.168.x.x:8085.worldserverWorld initialized in XXXX msworldserverStarting 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: - TZAsia/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排除掉只管理文本配置。