排查方法论：先别急着重装

服务端开不起来，群里最常见的一句话是“删了重装”。这话偶尔有效，但代价很大：重装会把日志、配置、最近的改动一起清掉，你永远不知道真正的原因；更常见的结果是，重装完照着同样的步骤又踩了一遍同样的坑。

这一页不针对某个具体报错，而是给你一套顺序：先留证据，再分层，最后才动手改。照着走，多数问题在前三步就能定位；真的要重装时，你也清楚自己为什么要重装。

如果你连服务端都还没启动过，先看启动失败排查；如果终端里已经有一屏红字，先看小白看日志抓关键词，再回来按这里的顺序处理。

本页要点

排查顺序是观察 → 分层 → 复现 → 单变量 → 验证，跳步就会反复试错。
每次只动一个变量，并且记下“改了什么、结果如何”。
重装是最后一步：它会清掉日志和崩溃证据，重装前必须先备份世界。
找人帮忙时，一次给出核心版本、Java 版本、最后 50 行日志和复现步骤。

排查五步：观察 → 分层 → 复现 → 单变量 → 验证#

先把方法论摆出来，后面每一节都是在展开其中一步。新手最容易犯的错不是“不会修”，而是跳着修：还没看清现象就去换核心，还没复现就去改配置。

步骤	你要做的动作	做完手里应该有什么
1 观察	不碰任何设置，先看状态和日志	一句话描述现象 + 最后 50 行日志
2 分层	判断问题在哪一层（环境/Java/核心/配置/内容/网络/客户端）	一个明确的怀疑对象
3 复现	用最小配置稳定重现	“每次都这样”或“只有某人/某时这样”
4 单变量	只改一个东西，再启动一次	一条改动记录
5 验证	用同一场景确认修好了	能连进去、能玩、日志不再刷错

第 1 步之所以叫“观察”，是因为它什么都不改。很多新手一着急就先点五六次启动，结果第二次之后的日志已经被新的进程覆盖，真正的第一现场没了。

停止服务端，但不要着急重启：回概览页看状态到底是“运行中”“已停止”还是“启动中”。状态和你的感觉不一致时，以状态为准。
备份：世界和配置先备份一份。备份不需要停服，但还原必须先停服，而且还原没有二次确认，点一下就开始，详见备份、还原与世界管理。
把日志留下来：打开「终端」，点右上角「复制当前日志」，粘贴到备忘录里。终端只显示最近 300 行，而「复制当前日志」复制的是当前会话里完整显示的内容，比截图可靠。
写下时间线：最近 24 小时你改过什么——装了哪个插件/模组、改了哪一项配置、升级了核心还是 Java、换过网络或隧道。

重装是最后一步，不是第一步

卸载应用、删除服务端目录会同时清掉 logs/latest.log、crash-reports/ 和应用生成的崩溃报告，这些是唯一能说明“为什么坏”的东西。没有备份就重装，等于把案发现场烧了再找凶手。

先画一条时间线：四个问题定方向#

排查不是从翻代码开始的，是从回答四个问题开始的。回答完，方向通常已经缩小到一半。

最后一次正常是什么时候？能具体到“昨天晚饭后还能两个人一起进”最好。
那之后第一件改的事是什么？注意是“第一件”，不是“最可疑的那件”。
问题是每次都出现，还是偶尔？每次都能复现，说明是稳定条件；偶尔出现，说明和负载、网络、时间有关。
是所有人都这样，还是某个人/某个客户端？只有一个人进不来，优先怀疑他那边的版本、账号和白名单。

举个真实的推理：昨天两个人玩得好好的，今天加了三个插件后启动就崩。四个问题答完，怀疑对象立刻从“手机坏了”“核心不行”变成“三个插件之一”，接着用二分法两轮就能锁定。

反过来，如果你答不出“最后一次正常是什么时候”，说明改动是慢慢累积的，这时要优先看三样东西：剩下的存储空间、堆内存上限（启动设置抽屉里的「JVM 内存上限」）、以及最近有没有自动更新过什么。

分层排查：七层从外往里走#

服务端从“你点启动”到“玩家进服”，中间是一条依赖链。链条上的每一层都可能断，但外层没通，内层根本不会被执行。所以顺序不能跳。

层	这一层管什么	通过标准（怎么算过）
1 应用/环境	Termux 兼容运行环境是否初始化完成	概览页没有「初始化运行环境」卡片，能进终端
2 Java	版本与来源是否满足核心要求	终端不再报 `UnsupportedClassVersionError`
3 核心	jar 是否完整、installer 是否跑完	空服能启动并出现 `Done`
4 配置	`server.properties` 的语法和值	改回默认能启动
5 内容	插件、模组、世界	逐个加回去不再崩
6 网络	局域网、隧道、端口	同一个 Wi-Fi 下能进
7 客户端	游戏版本、正版账号、白名单	能看到服务器并进入世界

跳层最典型的后果是：朋友进不来，你以为是端口映射错了，实际上服务端根本没启动完成——终端里从来没有出现过 Done。这一层没通，后面所有网络设置都是白忙。

判断层次的顺序也有技巧：先问“服务端自己有没有起来”，再问“别人能不能连上”。前者看终端和概览状态，后者看服务器地址和网络页。这两件事混在一起查，是最容易绕圈的地方。环境层的检查可以直接用「更多 → 运行诊断」，它会把运行环境、Java、端口、存储空间等一次性列出来；能一键修复的只有一部分（运行环境、Java、命令、字体这类），端口和核心文件它不会替你改。

一次只改一个变量，并且写下来#

这是排查里最容易被违反、也最有效的一条。同时改三个东西，问题消失了你也说不清是哪个起的作用，下次照样复发。

不要同时“换核心 + 加内存 + 删插件”；
每改一次，就完整启动一次，看到结果再决定下一步；
如果这次改动没效果，改回去再试下一个，不要让无效改动堆在配置里；
改动记录要写到能被别人看懂的程度，例如“把 view-distance 从 10 改成 6”。

记录不用 fancy，一张表就够，写在手机备忘录里，随时能翻：

时间	改了什么	期望	实际结果
10:20	卸掉插件 A	能启动	还是秒退
10:35	`view-distance` 10 → 6	内存降一点	没变化，已改回 10
10:50	Java 17 → 21	不再报 class file version	出现 `Done`，成功

第三条记录是关键：它同时说明“问题出在 Java 版本”，以及“前面两条改动是无效的”。没有这张表，你三天后只会记得“好像改过很多东西”。

把范围砍小：最小复现与二分法#

能稳定复现，才谈得上修。不能复现的偶发问题，先加观察（多跑几次、记下发生时间），不要乱改。

最小复现的意思是：把环境削到“只保留能重现问题的最少东西”。可以用下面四个动作轮着试。

新建一个空服务端，只装你怀疑的那个插件/模组，还能复现吗？
换一个没装模组的原版客户端，能进吗？
换一台设备、换一个网络（同 Wi-Fi ↔ 手机流量），现象变了吗？
换一个新建的世界，还崩吗？

如果空服 + 单个插件就能复现，问题基本锁定；如果空服也起不来，说明根本不在插件层，回到第 1～3 层。

候选很多时不要一个个试，用二分法：

对半切：12 个模组分成 6 + 6，只装前 6 个。
启动一次：崩了 → 问题在前 6 个；没崩 → 问题在后 6 个。
继续对半：把有问题的那一半再切成 3 + 3，重复上一步。
收敛到 1～2 个：12 个模组最多 4 轮就能锁定，比逐个试快得多。

同样的切法可以用在插件、配置项、甚至世界文件上（比如只替换 region/ 里的一部分区块）。二分法的前提还是那条：每次只改一个变量。

什么时候该重装，什么时候别装#

重装不是禁忌，但它只对少数情况有奇效。先看这张表，再决定要不要动手。

情况	建议	原因
运行环境初始化反复失败、诊断提示 rootfs 损坏	可以重装运行环境	运行环境是可再生的，不含你的存档
核心 jar 明显损坏（`Invalid or corrupt jarfile`）	重新下载核心，不必重装应用	换一个文件就能解决
配置被改乱、忘了改了什么	用备份回滚配置	比重新配一遍快，也不会丢世界
存档本身损坏	先尝试从备份还原	重装应用不会修好存档，只会丢掉证据
说不清现象、也没有日志	不要重装	重装后大概率原样复发

重装运行环境和重装应用是两件事。前者只重装那套迷你 Linux 环境，公共存储里的服务端目录还在；后者才会连同应用数据一起清掉。做任何一步之前，先把世界备份好，备份放在 /storage/emulated/0/世界与服务器的备份/，和服务器目录是分开的。

先备份，再动手

删世界、删目录、重装应用之前，先做一次整服备份，并确认备份文件真的生成了（能看到文件名和时间）。存档比配置难恢复得多：配置十分钟能重配，玩了一周的世界丢了就是丢了。

四个让情况变糟的动作#

下面这四件事，新手做得最多，也最容易把小问题变大问题。

连点启动。第一次启动还在跑，你又点了一次，结果两个进程抢同一个端口，终端里刷出一堆 Address already in use。这时你看到的报错是“第二次点击”造成的，和最初的故障无关。启动一次，等结果。
边跑边删文件。文件页的删除和编辑不检查服务端是否在运行，服务端还在写世界时删掉目录，很可能直接损坏存档。要动文件，先停服。
用 /reload 修一切。/reload 属于 Minecraft 通用命令，它只能重载一部分内容；很多插件改完配置必须重启才生效，重载还可能留下半初始化的状态。改完配置的稳妥做法是停服再启动。
下载“一键修复工具”“整合修复包”。来源不明的 jar 和脚本可能带后门，也可能改掉你原本正常的文件。应用自带的「运行诊断」已经覆盖环境、Java、端口、存储这些常见项，够用了。

停止也要按流程

普通「停止」是向控制台发送 stop，最多等 180 秒让服务端存档退出；超时后不会强杀，而是提示你可以点「强制停止」。强制停止有二次确认，会丢未保存的数据，只在卡死时用。不要在系统任务里直接划掉 Minexa，那等于掐断进程。

求助前把信息一次发全#

排查卡住时找人帮忙很正常，但“开不起来怎么办”这句话没人能回答。把下面六项一次发出去，对方基本能直接给结论。

文本

1. 现象：启动就退出 / 玩几分钟崩 / 朋友进不来（挑一个，说清时间点）
2. 时间线：昨天正常，今天加了插件 X、把视距改成 8
3. 设备：手机型号、内存大小、Android 版本
4. 服务端：核心与版本、Java 来源与版本、JVM 内存上限
5. 日志：终端最后 50～100 行，或崩溃报告里含 Caused by 的那一段
6. 已试过：改了什么、结果如何（贴上面那张改动记录表）

日志优先用「更多 → 崩溃报告」里的完整日志：那一页可以复制也可以分享，而且不会上传到任何服务器，你自己决定发给谁。发之前记得把公网地址、隧道 ID、令牌打码。

一句话描述现象的技巧

把“开不起来”换成“点启动后 8 秒退回已停止，终端最后一行是 UnsupportedClassVersionError”。后者已经包含了现象、耗时和关键日志，别人不用再问一轮。

上机自查

能说出最后一次正常玩的时间，以及那之后第一件改动。
备忘录里有一份改动记录，至少 2 行“改了什么 → 结果如何”。
已经备份过一次，并且知道备份文件放在哪个目录。
终端里复制到了完整日志，不只是截图。
能明确说出问题卡在七层里的哪一层。

下一步#

还不会读终端输出：小白看日志
已经确定是起不来：启动失败排查
服务端起来了但朋友进不去：客户端报错大全
想先看环境检查结论：运行诊断