在Minecraft服务器的圈子里，有一个长期折磨人的难题：装了Forge就跑不了插件，装了Spigot就装不了大型Mod。尤其是想开一个“既有科技Mod、又有生存辅助插件”的服务器时，基本只能在二选一里煎熬。Arclight这个混合服务端，就是专门来解决这个问题的。它允许你在同一个服务器里同时挂载Forge Mod和Bukkit插件，不用再开着两个服来回传送数据。
这篇文章我会把这套东西从零开始讲清楚。包括Arclight的核心原理、JDK版本怎么选、启动脚本怎么写、内存怎么调、Mod和插件怎么混装不出冲突，以及几个我实际踩过的坑。内容偏实操，照着做基本可以把一个现代Minecraft服务器从无到有跑起来，适合已经玩过原版开服、但对混合端不熟悉的人。
1. 先搞清楚Arclight到底是什么
1.1 Forge和Spigot的“二选一”困局
在展开操作之前，有必要先聊聊Arclight出现的背景。Minecraft服务端从早期到现在衍生出了很多分支，主流的大方向只有两个：一是以Spigot、Paper为代表的插件服务端，它们走的是Bukkit/Spigot API，挂载的是“.jar”格式的插件，优势是稳定、轻量、生态里有大量管理类和玩法类插件；另一个就是Forge这个Mod加载器家族，走的是自己的Mod体系，能加载那些改变游戏机制的大型Mod。
问题是这两套体系在底层的代码修改方式上差异极大。Spigot重写了服务端的大量逻辑来提升性能，Forge则直接往原版代码里塞进去一大堆钩子。简单说就是：两套东西都在改游戏内核，但改法完全不同，共用一套核心就很容易撞车。很长一段时间里，论坛上公认的回答都是“Mod服和插件服只能选一个”。
1.2 混合端里的技术代表
Arclight本质上是一个基于Forge和Spigot的“混合服务端”。它的做法不是把两个东西缝合到一起那么简单，而是通过一套叫Mixin的技术在运行时动态修改字节码，说白了就是在不手改源码的前提下，将两套API同时注入到同一个服务端进程里。Arclight保留了Spigot的插件加载框架，同时把Forge的Mod加载逻辑也跑了进来，最终让你在mods文件夹和plugins文件夹里同时塞东西还能共存。
打个不严谨的比方：以前你想开一个既能吃西餐又能吃日料的店，必须租两个门面；而Arclight是在同一个厨房里装了中餐灶和西餐炉，主厨可以用一套团队接待两拨客人。对于想整合科技Mod和服务端插件的玩家来说，这算是最省事的方案之一。
1.3 Arclight适合什么场景
在社区里，Arclight最常见的用途大概三类：一是整合包联机，很多整合包本身就要求Forge环境，但你还想要一个登录插件保护账号；二是生存服务器玩法扩展，既加了暮色森林这类大型Mod，又想要TAB列表、地皮、圈地这些功能性插件；三是做Mod开发测试，在本地部署一个带插件API的环境，跑接口联调非常方便。
当然，混合端不是万能的。因为它同时承载两套API，性能开销天然就比纯Spigot高一些，也比纯Forge多一层兼容性负担。如果你的目标是开一个大几百人同时在线的纯生存服，没有任何Mod需求，那Paper仍然是更优解。反过来，如果你只玩Mod根本不需要插件，那就老实去用Forge官方推荐的服务端。Arclight的定位很清晰，就是“两边都想要”的那个梯队。
2. 搭建前的环境准备：版本、内存和JDK
2.1 内存规划：8GB是入门线
Minecraft服务器向来是内存大户，Mod服更是。Arclight因为要同时承载Forge和Spigot，启动时的类加载和运行时的区块缓存都比普通服务端更吃内存。从我自己的测试来看，4GB内存跑一个纯净版Arclight做测试还行，一旦加了十个以上的Mod，再加载地图区块，内存占用就明显吃紧了。建议至少划出4GB给服务端本体，系统层面总内存最好在8GB以上。
这里要先区分两个概念：物理内存和Java堆内存。你给-Xmx设置的值只是Java虚拟机堆内存的上限，实际运行中JVM本身、服务端底层依赖的本地内存、系统缓存都会额外占用内存。所以一台机器总内存8GB，分给JVM 4GB，剩下的给系统和磁盘缓存是合理比例。千万不要以为8GB总内存就能给JVM设置6GB，那样很容易把机器拖到Swap交换区，反而更卡。
2.2 JDK版本：最容易翻车的第一步
Arclight对Java版本的要求和Minecraft版本是挂钩的。这是新手最容易翻车的地方，有些人拿着JDK随便装了个最新版就去启动，结果服务端直接报出UnsupportedClassVersionError或者根本起不来。实际上不同游戏版本对应的JDK要求很明确：
| Minecraft版本 | 对应JDK | 备注 |
|---|---|---|
| 1.16.5及以下 | JDK 8 | 老版本核心对高版本JDK兼容性差 |
| 1.17.x ~ 1.20.4 | JDK 17 | 目前最主流的Mod服区间 |
| 1.20.5及更高 | JDK 21 | 新版本核心强制要求 |
Arclight的发布页一般会标注当前版本对应的Java要求，下载之前务必先确认一下。如果机器上已经装了多个JDK，还需要手动指定路径，避免系统默认的Java版本不对。在Linux上可以用update-alternatives --config java来切换版本，Windows上则要检查JAVA_HOME环境变量。
2.3 操作系统选择：Windows和Linux都能跑
Arclight本身就是纯Java程序，对操作系统没有硬性要求。Windows上操作直观，适合本地测试或者小规模朋友服；Linux服务器稳定性更好，资源占用更干净，适合长时间开服的场景。我自己日常用的是Ubuntu 22.04的云服务器，整个部署流程在文后会按Linux环境来写，如果你用Windows，其实逻辑完全一样，只是启动脚本的写法不同。
有一点要提前说：如果你的服务器是国内的云服务器，通常会遇到一些端口开放的额外限制。Minecraft默认通信端口是25565，需要在云控制台的安全组里放行TCP协议的25565端口，不然玩家永远连不上。这个坑我见过太多次了，服务端明明正常在跑，朋友那边就是“无法连接服务器”，排查到最后发现是安全组没开。
3. 下载与安装Arclight：从拿到文件到首次启动
3.1 从哪里下载正确的构建版本
Arclight的正式发布渠道是它在GitHub上的官方Releases页面，搜索“Arclight Minecraft”一般就能找到。下载的时候要留意几个信息：游戏版本、服务端构建号、以及是否带-extra后缀的优化版。版本号一定不能选错，比如你的客户端是1.18.2，那服务端也必须下载对应的1.18.2构建，不能用1.19的版本替代。
顺带一提，Arclight从某个版本开始分成了标准版和-extra版本。-extra版内置了更多性能优化补丁，对高版本的支持更好，兼容性也更稳定。如果可以选的话，我建议优先尝试带-extra的版本。下载下来的文件应该是一个独立的、名为类似arclight-forge-1.20.1-1.0.3.jar的JAR文件，这个文件本身就是完整的服务端程序。
3.2 目录规划与启动脚本的编写
在服务器上单独建一个目录来放服务端，避免和别的文件混在一起。假设建在/opt/mc-server下：
mkdir -p /opt/mc-server cd /opt/mc-server把下载好的Arclight JAR文件传上去，放到这个目录里。接着创建启动脚本，Linux上用start.sh，Windows上用start.bat。脚本的核心内容是给JVM分配内存并启动JAR文件。
以我的实际配置为例（假设总内存8G，给服务端4G）：
#!/bin/bash java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -jar arclight-forge-1.20.1-1.0.3.jar nogui解释一下这段JVM参数里几个关键项：
-Xms4G -Xmx4G：Java堆内存的初始值和最大值。设成一样的好处是JVM启动时就申请好全部内存，运行过程中不需要动态扩容，减少了GC（垃圾回收）的波动。-XX:+UseG1GC：启用G1垃圾回收器。对于Minecraft这种“大量临时对象频繁创建销毁”的程序，G1的生产停顿控制比默认的并行收集器平滑。-XX:MaxGCPauseMillis=200：G1的目标最大停顿时间。实测中设成200毫秒对玩家体感影响较小。-XX:+AlwaysPreTouch：启动时就把内存页全部物理锁住，好处是运行中卡顿更少，坏处是启动时间更长。nogui：告诉服务端不要打开图形界面窗口，纯命令行运行。在服务器上这是标配选项。
3.3 首次启动、EULA与核心文件生成
执行启动脚本后，服务端会进行首次初始化。第一次启动会生成一堆目录和配置文件，然后很快停掉。这一步实际上是正常的，因为服务器需要你手动接受Minecraft的最终用户许可协议，也就是eula.txt文件里的eula=false要改成eula=true。
chmod +x start.sh ./start.sh等它生成文件并退出后，用下面的命令修改EULA文件：
nano eula.txt # 将 eula=false 改为 eula=true再次执行./start.sh，这次服务端就会正式进入加载流程。日志里会滚动大量的Forge Mod加载和Spigot初始化信息，看到Done (x.xxxs)!的时候，就说明服务器已经启动成功了。原版端口默认是25565，局域网或者公网环境下的客户端就能在多人游戏里通过IP:端口来连接了。
4. 核心配置与性能调优：别急着装Mod
4.1 server.properties：理解每个关键参数
服务端启动后，根目录下会生成一个server.properties文件，这是Minecraft服务器最核心的配置文件。很多新手喜欢照抄网上的参数，但并不知道每个参数背后的意义，出了问题也不知道怎么改回去。我挑几个关键项来做说明：
| 参数名 | 建议值 | 说明 |
|---|---|---|
| server-port | 25565 | 服务端监听端口，如修改需同步通知玩家 |
| motd | 自定义 | 服务器列表里显示的一句话介绍 |
| view-distance | 8 | 服务器向玩家发送的区块可视距离，值越大越吃CPU和内存 |
| max-players | 20 | 服务端接受的最大在线玩家数，并非性能上限 |
| online-mode | true | 正版验证开关，离线服需设为false，但会有安全和盗版问题 |
| allow-nether | true | 是否开启下界维度 |
| spawn-protection | 16 | 出生点保护范围，避免新手刚进服就被破坏 |
view-distance是影响服务器性能最直接的参数之一。默认值是10，但在Mod服里建议降到6到8。每个玩家周围可视区块都需要服务端持续计算实体、方块更新和光照，玩家越多，区块消耗就成倍增长。把可视距离调低一点，对大部分生存玩法的体验几乎无感，但对TPS（服务器每秒刻数）的改善是立竿见影的。
4.2 arclight.yml与Forge相关配置
除了server.properties，Arclight在启动过程中还会生成一些混合端独有的配置文件。比如arclight.yml，里面可以配置混合端的特定行为，比如是否开启某些调试日志、是否允许某些插件调用Mod方API等等。大多数情况下保持默认即可，不需要主动修改。
如果你的Mod比较多，还要注意Forge自身也会生成配置文件。早期版本的Forge会把配置集中写在config文件夹下，高版本引入了config目录配合defaultconfigs的方法，里面存放一些整合包预设的配置。这些配置文件的修改大多需要在游戏内进行，也就是在服务器控制台执行命令或者玩家进服之后用Mod提供的GUI调整。作为服务器管理员，只需要知道配置文件的存放位置，改之前先备份即可。
4.3 启动参数里容易被忽略的细节
只要跑了一段时间，你就会发现启动参数对服务端性能的影响非常大。除了上面提到的G1相关参数，还有两个细节值得注意：
第一，-server参数。64位JDK默认以服务端模式运行，但有些环境可能会被覆盖为客户端模式，加上这个参数可以确保JVM使用C2编译器。第二，-Dfile.encoding=UTF-8。这个参数在Windows环境尤其重要，不指定的话，日志里可能会出现中文乱码，某些Mod读取中文路径也会出问题。
给一个Windows环境的参考脚本：
@echo off java -Xms4G -Xmx4G -server -Dfile.encoding=UTF-8 -jar arclight-forge-1.20.1-1.0.3.jar nogui pause4.4 定时备份：开服者的救命稻草
调参的下一件事不是装Mod，而是把备份机制先跑起来。Mod服最大的痛点不是崩溃，而是崩溃之后的世界数据损坏。一次强杀进程或者突然断电，就有可能导致存档里的区块文件损坏，届时玩家辛苦建了几个月的建筑凭空蒸发，那才是彻底劝退的结局。
Linux环境下，最简单的做法是用cron定时把存档目录打成压缩包。推荐只备份world、world_nether、world_the_end这几个核心维度文件夹，以及config目录。插件和Mod本身可以重新下载，玩家的世界数据才是不可再生的。实际经验教训是：备份频率至少每天一次，规模大、玩家多的服务器建议每六小时一次。
#!/bin/bash BACKUP_DIR="/backup/minecraft" WORLD_DIR="/opt/mc-server/world" TIMESTAMP=$(date +"%Y%m%d_%H%M%S") tar -czf "$BACKUP_DIR/world_$TIMESTAMP.tar.gz" -C /opt/mc-server world find "$BACKUP_DIR" -name "*.tar.gz" -mtime +7 -delete上面这个脚本每天备份一次世界文件夹，只保留最近7天的备份。find那行就是定期清理旧备份，防止磁盘被塞满。
5. 混装Mod与插件实战：正确姿势和兼容性提醒
5.1 mods文件夹和plugins文件夹，各放各的
Arclight最大的卖点就是同时支持Forge Mod和Bukkit插件，但也不是说你随便把两个类型的文件都丢进去就万事大吉。正确做法是：Forge Mod放在服务端根目录下的mods文件夹里，Bukkit插件放在plugins文件夹里。这个划分是硬性的，放错位置不会被加载。
首次启动Arclight的时候，如果mods文件夹不存在，服务端可能会自动创建。但更稳妥的做法是手动建好：
mkdir -p mods plugins放Mod之前先把对应的服务端版本确认好。比如在1.20.1的Arclight上，你只能装支持1.20.1的Forge Mod。Mod文件本身一般是jar包，直接放进mods文件夹即可，启动时服务端会自动扫描加载。插件的放法同样是直接放jar包，但要注意插件与服务端主版本和API版本的兼容性。大部分Spigot插件在Arclight上都能正常跑，前提是插件本身没有依赖只在Paper上才有的高级API。
5.2 适合Arclight生态的Mod和插件组合
基于我自己的开服经验，有几类Mod和插件在Arclight上跑得比较稳：
- 科技类Mod：像机械动力(Create)这种大型Mod，在Arclight上表现相当好，因为它自身不依赖核心代码过度魔改。
- 魔法类Mod：神秘时代、血魔法之类的经典Mod，在Arclight环境下的bug率相对低。
- 辅助类插件：EssentialsX、LuckPerms、CoreProtect这几个经典插件都是社区维护活跃的，API用得很规范，在混合端上基本不会出幺蛾子。
- 区块和性能类插件：比如ClearLag、Spark，和Mod的兼容性也不错，可以作为Mod服的日常监控工具。
在选插件这件事上，新手常犯的错误是装一堆“增强型”插件。实际上Mod本身已经提供了很多玩法，插件的核心价值应该放在管理上：登录验证、权限分组、圈地保护、方块日志查询。这四个类别的插件装好，服务器的管理框架就基本完整了，没必要装太多花里胡哨的东西，每多一个插件，在混合端里就多一分冲突风险。
5.3 兼容性风险：哪些Mod和插件容易出问题
Arclight的混合端本质决定了它不可能做到100%兼容。从社区反馈和我的体感来看，最常出问题的是下面几类：
一是使用了大量Mixin的Mod。Arclight本身就是靠Mixin运行起来的，当另一个Mod也用Mixin去修改同一个核心方法时，优先级冲突就在所难免了。这种冲突通常表现为启动时崩溃，或者运行中某块游戏逻辑突然异常。
二是依赖特定服务端实现细节的插件。有的插件为了让某功能生效，会直接访问Spigot的某个内部类；在纯Spigot上没问题，但在Arclight上就可能因为这个内部类已经被Forge改写过而出错。
三是服务端版本和客户端Mod列表不一致。这虽然不是Arclight专属的问题，但在混合端更容易被忽视。因为插件不会影响客户端，很多管理员会忘记，Mod是会强制校验客户端名单的。客户端一份Mod列表、服务端一份Mod列表，两边数量或版本对不上，就会在进服时直接断开连接。
5.4 Mod和插件混装时的调试顺序
如果加了Mod或插件之后服务器起不来了，第一反应不要直接问别人“怎么解决”，因为这类问题很难在没有日志的情况下判断。正确的调试顺序是先看去掉所有插件，单独用Mod启动，看能不能正常进服。如果正常，说明问题出在插件侧，可以逐个添加插件来二分定位；如果还是崩，说明问题在Mod侧，同理逐个排查。
排查日志看两个信息：崩溃报告里的Caused by行，以及日志里的Exception堆栈。前者能直接告诉你哪个类抛了异常，后者能定位具体是在Mod还是插件的调用链上出了问题。实在看不懂日志，就把崩溃报告原样贴到社区里求救，这比只截图一句“服务器崩了”要有用得多。
6. 常见问题与排查技巧实录
6.1 启动即崩溃：先看版本再看堆栈
启动崩溃是混合端最常见的翻车点。第一件事永远是去日志里找异常信息。如果是UnsupportedClassVersionError，基本可以断定JDK版本不对，重新安装匹配的Java版本就行。如果是NoClassDefFoundError，通常是某个Mod缺少前置依赖，这就需要去Mod的发布页看看它要求的“前置Mod”有没有装全。
还有一类是java.lang.StackOverflowError，这种大概率是某个Mod和Arclight的某个逻辑形成了无限递归调用。这种问题最好先去Arclight的GitHub Issue区搜一下有没有已知兼容性问题，通常会发现是某个冷门Mod和当前版本不兼容，换一个类似功能的Mod就能解决。
6.2 服务器能进但一直掉线，TPS偏低
服务器跑起来了，玩家也能进，但每隔一段时间就全体卡顿，或者持续低TPS，这往往是性能问题而不是崩溃问题。先做一个基础的性能检查：在服务端控制台输入spark相关命令，或者用timings报告来看具体耗时的分布。
大多数情况下，TPS低的元凶是大量未清理的掉落物、过大的红石机器、或者刷怪塔实体堆积。这时候比调JVM参数更有效的，是装一个清实体插件或者定时清理掉落物的工具。从运维角度看，定期执行一次垃圾回收和重启服务端也是常规操作。Mod服跑时间久了内存碎片化现象一定会出现，这是JVM的固有属性，不要幻想一个服务端能稳定运行几个月不掉帧。
6.3 玩家进度丢失或存档损坏
这个问题的诱因很多，最常见的两个是：服务器被强行终止时没有保存区块，以及Mod版本在运行中被替换。前者强调备份的重要性，后者则是很多人忽略的教训——Mod升级不等于向下兼容，新版Mod可能会用新的数据结构覆盖旧数据，一旦和存档里已有的区块数据对不上，轻则区块丢失，重则整个存档无法加载。所以升级Mod前一定先把世界备份好，不要把“升级”当成一件轻描淡写的小事。
6.4 端口连接被拒或超时
如果你确认服务端已经在运行，但客户端连不上，排查顺序如下：本地用curl或者ping确认服务端进程存在；再在服务器上执行ss -tlnp | grep 25565确认端口有进程监听；如果端口有监听但外部连不上，那就是防火墙或云安全组的问题了。Linux上用ufw status检查本地防火墙是否放行25565，云服务器则要去控制台检查安全组规则。
这里额外提醒一个细节：如果你修改了server-port，服务端日志和server.properties里的端口必须一致。有时你改了文件但服务端还在用旧配置运行，就是因为没有完全重启进程，而只是用了某个插件做热重载。热重载有时候有效，但像端口这种核心配置，还是老老实实重启服务端最可靠。
6.5 常见问题速查表，建议收藏
| 症状 | 可能原因 | 解决办法 |
|---|---|---|
| 启动时UnsupportedClassVersionError | JDK版本与Minecraft版本不匹配 | 根据游戏版本安装对应JDK |
| 启动后立即退出 | EULA未同意 | 修改eula.txt为true |
| 玩家连接超时 | 服务端端口未放行 | 检查防火墙和安全组配置 |
| 进服时Mod列表不匹配 | 客户端与服务器Mod版本不一致 | 对齐两边Mod列表 |
| 加载Mod后崩溃 | Mod依赖缺失或兼容性冲突 | 查看日志定位冲突项，逐个排查 |
| 运行一段时间后严重卡顿 | 实体堆积或内存碎片 | 清理掉落物、定时重启、优化视距 |
| 存档数据丢失 | 未正常停止服务端或备份不足 | 养成规范备份习惯 |
7. 最后再分享几点我的个人经验
Arclight这个项目我从1.16.5时代开始用，一直跟到1.20.1，前前后后搭过测试服、朋友服，也帮别人救过不少次“跑不起来的混合端”。如果只让我总结一条经验，那就是：混合端的一切问题，都要从“隔离变量”开始排查。不管是Mod冲突、插件冲突，还是JVM参数导致的隐性崩溃，最有效的方法永远是先砍掉所有附加内容，从纯净的Arclight服务端跑起来，再一项一项加回去。跳过这个步骤的人，往往会在几个小时的瞎折腾里消耗掉所有耐心。
另外一个小技巧是，别把服务端放在系统盘或者权限受限的目录里。Linux下我见过太多因为目录权限不足而导致的诡异问题，比如插件写了配置文件但没权限保存，服务端明明报错却说不出具体原因。把服务端放在/opt或者家目录下，并确保运行用户有该目录的读写权限，可以省掉很多无谓的排查时间。最后，还是那句话：无论你的服务器是给三个人玩还是给三百个人玩，备份永远是最便宜的保险。不要等存档没了才想起备份——那种滋味真的不好受。
