永恒之塔模拟器4.7.5架设全攻略：从环境配置到进图打怪

简介：永恒之塔4.7.5模拟器zip压缩包约245.41MB，面向希望离线体验4.7.5版本内容的玩家、服务器搭建者与二次开发爱好者。资源核心是Aion-Emulator-4.7.5-master模拟器环境，覆盖铁骑兵（Steel Cavalry）机制、rework调整后的技能与AI表现，以及Kaldor、Panasterra等地图区域；包体文件总数与文件类型明细暂缺，但不影响直接按zip包部署使用。目前已有856人浏览学习，适合具有一定服务端基础、想提前研究版本改动或拆解模拟器代码的进阶学习者。实际使用时可借助EmulatorHTML相关界面与配置工具，启动本地服务，测试铁骑兵的战斗节奏，对比4.7.5重做前后的地图、任务与怪物逻辑，并在此基础上做自定义内容与玩法验证，为后续部署、调试和二次开发提供可参考的完整环境。

1. 永恒之塔模拟器4.7.5：从压缩包到可登录、可进图、可打怪的服务端资源

永恒之塔模拟器4.7.5不是一键端，从压缩包到能进游戏，中间隔着环境、配置、补丁三道工序。这套资源包实际包含三个可运行部分：login server 负责账号认证、game server 负责地图与战斗逻辑、SQL 脚本初始化角色与物品数据，另附一个 EmulatorHTML 网页管理后台用来查账号和发物品。适合两类人：一类是找 4.7.5 版本服务端资源的架设者，想搭一个能玩的版本；另一类是研究大型 MMO 服务端结构（线程模型、数据落库、协议校验）的开发者。先说结论：资源本身是完整可跑的，但直接双击 start.bat 八成会在数据库连接或端口冲突上翻车。这篇笔记按“拆包 → 建库 → 调内核 → 打补丁 → 排错 → 压测”的顺序，把步骤、参数和踩过的坑一次过完。

2. 环境与文件准备：Java 8、MySQL 5.7、目录结构与数据库导入

2.1 解压后先认目录：别急着点 bat

拿到资源包后，我习惯先把压缩包解压到纯英文路径，比如D:\aion475，路径里不要带中文、空格或特殊符号。原因很实际：老模拟器的脚本里写死了相对路径，一旦路径含中文，Java 进程读取资源文件时容易报编码异常，而且这种报错经常隐藏在启动日志中间，排查成本很高。

解压后，典型的目录布局是这样：

aion475/ ├── gameserver/ # 游戏世界服务，地图、战斗、任务逻辑 ├── loginserver/ # 账号认证服务，客户端第一道连接 ├── sql/ # 数据库初始化脚本 ├── tools/ # 辅助脚本、数据工具、GM 命令参考 ├── web/ # EmulatorHTML 网页管理后台 └── start.bat # 汇总启动脚本

这只是常见布局，不同资源包会有差异——有的把 SQL 脚本放在gameserver/sql/下，有的把网页后台合并进tools。我拿到新资源的第一件事不是运行，而是先打开sql目录看脚本数量：只有一个.sql文件，说明主库和世界数据是合并的；如果拆成aion.sql、aion_gs.sql两个文件，导入顺序就有讲究。这个判断直接决定了后面 game server 启动时会不会报“找不到表”。

另外提醒一句，start.bat里的启动参数不一定适合你的机器配置。很多端的默认堆内存只有 256M，对 4.7.5 版本来说偏小，后面 GS 加载地图时直接静默退出，黑窗口一闪就没了，非常劝退。所以动手前先备份一份start.bat，后面调参要用。

2.2 Java 和 MySQL 的版本匹配是第一个门槛

这套模拟器的代码基于 Java 7/8 时代，我最稳的选择是 JDK 8。装完后打开命令行窗口验证一下：

java -version # 期望输出 1.8.0_xxx，而不是 11、17、21

验证时看第一行输出是不是1.8开头。如果装了高版本 JDK，启动时会报UnsupportedClassVersionError，意思是 class 文件编译版本高于当前 JVM 能识别的版本。这个异常在启动脚本的黑窗口里往往一闪而过，不重定向日志很难看到。

数据库这边，血泪经验是别直接用 MySQL 8.0。老模拟器的 JDBC 驱动只兼容 MySQL 5.x 的认证协议，用 8.0 会卡在认证阶段，现象是连接报错或者启动后等待超时。我更推荐 MySQL 5.7，装完确认两件事：字符集必须是utf8，排序规则用utf8_general_ci。

[mysqld] character-set-server=utf8 collation-server=utf8_general_ci

character-set-server决定服务端建表时的默认字符集，collation-server决定排序规则。这两项必须在数据库初始化之前设置好。如果你已经装完 MySQL 而且导入了旧数据再改，需要重建数据库才能让新字符集生效——这就是典型的“后悔药不好吃”：看起来改对了，实际查询出来的中文还是乱码，因为底层存储已经是 latin1。

2.3 数据库导入：顺序错了连不上

初始化数据库我一般用 MySQL 命令行，而不开图形客户端。老 SQL 脚本里可能包含存储过程或自定义分隔符，图形客户端按分号分段执行时容易断在中间，报错还不好定位。命令行导入的方式：

-- 先用 root 登录，然后依次导入主库和世界库 source D:/aion475/sql/aion.sql; source D:/aion475/sql/aion_gs.sql;

用source而不是mysql < file.sql的原因：source是 mysql 客户端内置命令，执行完一段马上反馈，出错时能定位到具体行号，方便回查脚本内容。

导入完成后验证一下：

USE aion; SHOW TABLES; -- 能看到 account_data、player_data 等核心表即导入成功

SHOW TABLES返回的表数量是重要参考：如果只有几十张表，大概率只导入了主库，GS 启动时会因为缺角色表而报错。正常情况单库表数量在几百张上下，具体取决于资源包裁剪程度。

导入完成后，检查account_data表里有没有测试账号。很多端的 SQL 脚本是不带账号的，需要手动插入一条：

INSERT INTO account_data (name, password, access_level) VALUES ('test01', PASSWORD('test123'), 1);

注意这里的PASSWORD()是 MySQL 5.7 的函数，老模拟器的密码校验依赖它。不同资源包可能要求不同的加密方式，最稳妥的做法是先看库里已有的账号字段格式，照着抄一条，不要自己发明哈希。常见翻车点是手工写入明文密码，结果登录时提示账号密码错误——因为服务端启动时已经按特定加密规则初始化了校验，明文根本不匹配。

导入完我还会做一次反向验证：先启动 loginserver，看日志里是否出现Account test01 authenticated或类似字样。这一行出现，说明数据库链路已经打通，环境问题基本清空。

3. 服务端参数核校：loginserver、gameserver 与网页管理后台

3.1 loginserver 配置：端口、版本校验与自动建号

登录认证服务的核心配置文件在loginserver/config目录下，通常叫loginserver.properties。里面最值得核对的是监听端口、客户端版本号和自动建号开关。

loginserver.network.port=2106 loginserver.network.client.version=475 loginserver.accounts.autoCreate=true

loginserver.network.port=2106是认证服务监听的端口，客户端登录时先连这个端口。这个端口不要和 game server 的端口混淆，两者是两个独立的监听项。

loginserver.network.client.version=475是客户端版本校验值。客户端连接时会把自身的版本号发过来，服务端拿这个配置去比对，不一致就直接断开。很多架设者栽在这一步：客户端已经打了补丁，版本号是 475，但配置里还写着上一个版本的内部号，登录那一刻就会被踢。

loginserver.accounts.autoCreate=true表示允许自动建号，也就是客户端输入任意用户名密码，服务端自动创建账号。自己测试时开着方便，但如果打算开放给别人玩，建议改成false，不然谁都能注册账号，权限边界很容易被绕过。

3.2 gameserver 配置：地图扫描、内存与链接校验

游戏世界服务的配置在gameserver/config目录下。gameserver.properties管网络层，rates.properties管经验、掉率等数值。先把核心网络参数过一次：

gameserver.network.port=3879 gameserver.network.login.port=2106 gameserver.maps.auto_scan=true

gameserver.network.port是客户端进游戏世界时连的端口；gameserver.network.login.port是 GS 启动时反向连 login server 的端口，用来注册自己。如果login.port写错，GS 启动日志会出现Cannot connect to LoginServer，随后自行退出。gameserver.maps.auto_scan表示启动时自动扫描地图文件，4.7.5 的地图数据比较大，扫描时间可能比较长，别以为卡死了。

倍率文件里最常用的几个参数：

rates.player_exp=5 rates.quest_reward=5 rates.drop_rate=2

这三行分别控制打怪经验倍数、任务奖励倍数、掉落倍数。我一般建议先用1跑通流程，确认能进游戏、能打怪、能交任务，再调高倍率。原因很直接：高倍率下某些任务物品的刷新逻辑会有边界问题——比如任务要求打 10 只怪收集 3 个物品，经验倍数拉高后怪物瞬间刷新异常，物品掉落概率被倍数干扰，会卡任务。

GS 的内存参数在启动脚本里调整，直接在命令行验证：

cd gameserver java -Xms512m -Xmx2g -cp ./lib/*;. com.aionemu.gameserver.GameServer 2>&1 | tee gs.log

-Xms512m是初始堆大小，-Xmx2g是最大堆大小。4.7.5 的 GS 建议至少 2G，内存不足的表现不是立刻崩溃，而是玩家进图时地图加载奇慢，CPU 持续满载。2>&1把错误输出并入标准输出，tee gs.log同时写文件和屏幕，这样启动全程都留底，方便排查。

3.3 参数速查：一份能贴墙上的清单

以下参数是我每次架设 4.7.5 模拟器都会过一遍的核心项，按配置文件分好：

这份表的价值在于：启动失败时先看端口，登录失败时先看版本号，进图慢时先看内存，一套流程走下来能少踩一半坑。

3.4 EmulatorHTML 网页后台：能查能发，但别当主工具

资源包里带一个 EmulatorHTML 网页管理后台，通常位于web/目录。启动方式取决于后端语言，常见做法是启动一个轻量 HTTP 服务：

cd web # 常见做法是启动内置 HTTP 服务，默认端口 8080

网页后台一般提供账号查询、物品发放、封禁等操作。它最大的价值是不用直接操作数据库就能完成日常管理；但缺陷也很明显——很多资源包的网页后台是针对旧版模拟器接口写的，字段名保持旧格式，和服务端新版数据结构不一致。我的做法是把网页后台当“只读查询工具”，涉及封号、改权限、发重要物资的操作仍然回到 SQL 执行，避免网页后台把字段覆盖成旧格式，造成数据不一致。

启动顺序也要固定：先 MySQL，再 login server，再 game server，最后开客户端。随意乱序的结果通常是 GS 报连接失败退出。每次启动后用netstat -ano | grep 2106确认端口监听正常，再用netstat -ano | grep 3879确认 GS 端口也监听正常，两边都起来了再开客户端。

4. 客户端版本核校与补丁替换：从能登录到能进图

4.1 版本号到底看哪里

模拟器资源包通常自带客户端补丁，它解决的是客户端与服务端之间的协议握手问题。4.7.5 版本有一个客户端版本描述文件，位置一般在客户端根目录，文件名类似version_info.txt或configuration.xml。打开后能看到类似version=475的字样。

先核对客户端里的版本号，再对照loginserver.properties里的client.version。这两个值不一致，登录时直接失败。资源包的tools目录下通常也有一份补丁安装说明，写明补丁对应的客户端内部版本号——先看说明，不要凭文件名猜测。经常出现的情况是：文件名写着 475，实际内部版本号是别的值，照抄文件名改配置只会继续翻车。

4.2 文件替换：备份永远是第一步

补丁文件一般覆盖客户端的bin32/或data/目录。替换前先备份原文件，这一步省掉，后面客户端闪退时就没有后悔药。

# 在客户端根目录执行 cp -r bin32 bin32_backup cp -r data data_backup

备份后把资源包patch/里的同名文件复制进客户端。替换完成后，先不要急着登录，用客户端自带登录器输一次测试账号——如果卡在“连接中”而不是报版本错，说明补丁方向对了。卡“连接中”多半是网络配置问题，检查客户端里的服务器配置文件，把登录地址指向本机127.0.0.1:2106。

有些资源包还需要改客户端的L10N语言文件，把版本语言标记和服务端匹配。这个文件不对，进了游戏也会出现任务文本乱码或 NPC 对话异常，而且这种问题不会在登录时暴露，只能在游戏里发现，排查成本很高。所以补丁替换后，我会顺手检查一下 L10N 目录的文件数量，和备份目录对比，少了文件立刻补上。

4.3 进图前先确认地图数据

4.7.5 版本包含卡勒多、潘娜斯特拉等区域的地图数据。如果客户端缺地图文件，表现是登录成功、角色列表正常，但点进入世界时长时间黑屏，最后断线重连。

此时先看gameserver/log/下有没有地图加载失败记录，再看客户端data/maps/下有没有对应索引。我一般会做一次全图扫描测试：用 GM 命令把所有地图索引走一遍。

//goto 卡勒多 1 1 //goto 潘娜斯特拉 1 1

这两条命令能同时验证地图数据、传送逻辑和坐标解析。如果传送到某张图必掉线，说明该地图的客户端缓存缺文件；如果传过去没问题，说明整条链路已经通了。等这两张图都能正常进出，再测其他常规地图就顺理成章了。

一个容易忽略的细节：地图扫描脚本在tools目录里，有些资源包自带一键扫描工具，但依赖正确的 Java 类路径。如果扫描工具报错，可以先忽略它，用 GM 传送命令逐个验证，效果更直观。

5. 架设避坑与常见问题：从启动失败到进图黑屏的五个坎

5.1 数据库连不上：Access denied 与 Public Key Retrieval

现象：login server 或 game server 启动时报Access denied for user 'root'@'localhost'，偶尔出现Public Key Retrieval is not allowed。

原因：前者通常是密码错误，或者 MySQL 8.0 的caching_sha2_password认证插件不被旧版 JDBC 驱动兼容；后者是 8.0 的 RSA 公钥机制需要客户端显式允许才能获取。

解决：最省事的路径是换 MySQL 5.7。如果必须留在 8.0，可以在 JDBC 连接串末尾加allowPublicKeyRetrieval=true&useSSL=false，同时把账号密码改成 5.x 风格的mysql_native_password。但实际操作中我建议直接换 5.7——老模拟器不止认证一个问题，8.0 的严格模式会让老 SQL 脚本执行到一半报错，避过一个坑后面还有无数个坑。

5.2 内存不足：GS 启动到一半静默退出

现象：game server 黑窗口滚了几十行日志后直接消失，没有任何明显报错。

原因：默认启动脚本给的内存太小，地图加载时堆内存溢出，进程被系统直接回收。

解决：先打开start.bat找到-Xmx参数，改成-Xmx2g。这里有个细节：如果启动脚本是在后台以javaw方式运行的，错误信息不会显示在窗口里，必须用命令行java方式启动并重定向日志：

java -Xms512m -Xmx2g -cp ./lib/*;. com.aionemu.gameserver.GameServer 2>&1 | tee gs.log

改完再启动，如果仍然退出，搜索gs.log里的OutOfMemoryError。我一般先给 2G，不够再给 4G；如果超过 4G 还崩，就优先查地图文件完整性，而不是无限加内存。

5.3 客户端版本错误：明明打了补丁还是被踢

现象：输入账号密码后，客户端弹“版本不匹配”或直接退回登录界面。

原因：loginserver.properties里的client.version和客户端实际版本号不一致。补丁已经改了客户端，但服务端版本号还停在旧值。

解决：打开客户端版本描述文件，找到version=475这一行，把 loginserver 配置里的值改成一致。如果配置里没有该参数，就搜索 loginserver 目录下所有包含version的文件，改完重启 login server。注意不要多个文件各改一半，改完统一验一遍，以最终登录结果为准。

5.4 角色列表空白：账号权限或 GS 库没导全

现象：登录成功，角色选择界面一片空白，新建角色也报错。

原因：aion_gs数据库里角色相关表没建全，或者账号的初始权限值太低，未分配角色槽位。

解决：回到 2.3 节确认aion_gs.sql是否已导入，再用 SQL 检查该账号的access_level是否不低于 1：

SELECT name, access_level FROM account_data WHERE name = 'test01';

如果access_level是 0，改成 1 后重启 GS。多数端的默认值是 0，只允许登录不允许建角色，改成 1 后角色列表立即恢复。

5.5 进图黑屏：地图资源不全与缓存问题

现象：角色能选，点进世界后黑屏，有时伴随“地图传送失败”日志。

原因：客户端地图缓存与服务端地图索引不一致，或客户端缺少某个区域的几何数据文件。

解决：先备份，再整体替换patch目录里的地图文件；替换后清理客户端缓存目录，通常在“我的文档”下与账号同名的文件夹。黑屏问题有一条排查捷径——用低配模式进小地图测试：如果小地图能进、大地图必掉，优先怀疑内存；如果任何地图都进不去，优先怀疑客户端补丁。这两条路径能快速缩小排查范围，避免在错误方向上空转。

6. 进阶收尾：从能进图到能稳定开服

先做两步收尾，让这台服务器从“一个人能玩”变成“几个人能稳定玩”。

第一步，把测试账号的管理员权限打开：

UPDATE account_data SET access_level = 5 WHERE name = 'test01';

access_level=5通常对应 GM 权限，能使用传送、刷怪、发物品等命令。升级后无需重启服务端，重新登录角色即可生效。验证方式是在游戏聊天框输入//info，能弹出一长串角色信息就说明权限生效了。

第二步，做一次简单的并发登录压测，观察服务端稳定性：

ab -n 50 -c 10 http://127.0.0.1:8080/api/login

-n 50是总请求数，-c 10是并发数。压测时重点看 GS 的 CPU 和内存占用：如果 CPU 飙到 100% 且响应时间线性上升，说明单机性能已经到顶，先降低经验倍率，再考虑换配置。压测会写大量账号记录，测完记得清一次日志目录，避免磁盘被gs.log撑满。

从那以后我每次拿到新的模拟器资源，都会强制走一遍“备份 → 建库 → 校准版本号 → 压测”的流程，尤其是版本号这步，省掉它看似省十分钟，后续排查时间可能是十倍不止。希望这份笔记能帮你的架设过程控制在半天以内。

本文还有配套的精品资源，点击获取