第四章 服务器崩溃诊断与排查

在进行任何排查前，务必对整个服务器进行完整备份。

服务端运行时的终端（控制台）会输出大量日志信息，学会阅读并利用它们是解决问题的关键。日志根据严重程度分为以下几级： 日志一般可分为以下几种：

• [INFO]：白色字体，表示常规信息。无需担心。
• [WARN]：黄色字体，表示警告，如模组更新提示、非关键性配置异常，可以稍微留意。
• [ERROR]：红色字体，表示错误，可能会导致服务器出现问题或崩溃。 需要关注，尤其是大量频繁出现的时候。
• [FATAL]：红色字体，表示致命错误，几乎必然导致服务器崩溃。 需要立即处理。 通常出现 [FATAL] 报错前的第一个[ERROR] / [WARN] 会是解决问题的关键。

4.1 排查流程

当出现异常日志时，可以按照如下步骤解决：

1. 寻找日志：崩溃信息通常记录在 crash-reports/ 文件夹下按时间命名的文件中。若未生成崩溃报告，则查看logs/latest.log 中崩溃时间点附近的记录。
2. 初步分析：将文件丢给AI分析，并告诉AI”这是一个Minecraft服务器崩溃报告，请分析原因并提供解决方案”，这样能解决大多数问题。 下文将帮助你熟悉常见错误类型和解决流程。
3. 寻求帮助：若仍无法解决，例如XDUCraft技术组。 提问时附上复现步骤、 游戏版本、 模组版本、 Java版本、相关错误日志等可以大大提高问题解决的概率。

不要把大段的日志文件直接发送到社交平台，这会造成严重的刷屏。 可以将你的日志上传到mclo.gs上，然后将分享链接发给他人以便分析。

4.2 常见的崩溃类型

• 同一模组重复添加。
• 模组缺失前置/前置版本错误。
• 模组对应的加载器/版本错误：如将 Fabric 模组加入了 Forge 服务端等。
• 将仅客户端模组加入了服务端：如将CustomSkinLoader等模组加入了服务端。
• 内存不足。
• 端口已被占用：这通常是因为你开启了多个服务器并使用了同一个端口（如默认的25565），请关闭其中一个服务器，或在server.properties将其中一个服务器的端口更改为其他值。 如果你使用了SakuraFrp，请在控制台上同样进行端口更改。 这类崩溃问题应当是AI能够判断出来，且比较容易解决的，相信借助AI读者可以自行解决。 如果服务器崩溃的原因与上述问题无关，那么可以采取下文的方式。

4.3 常见的解决方式

一般地，解决服务器崩溃有这样几种方法：

• 已知由哪一个（或多个）模组引发错误时：
  1. 在官网上检查模组/整合包是否存在更新，测试更新后有无异常。 （不建议单独更新整合包中的某个模组，而应当直接更新整个整合包）
  2. 在MCMOD/CurseForge/Modrinth上找到对应的模组条目，查看正文和评论中是否有人提到了相关错误及解决方法。
  3. 只添加这几个模组（及必要的前置），查看问题是否仍然存在。（必要时可将模组适当降低版本）
  4. 如果确认问题仍然存在，请看4.4内容。
• 未知哪个模组引发错误，通常使用二分法进行排查。
  1. 将文件夹中的模组移出一半，检查问题是否消失。
  2. 不断缩小排查范围，直至定位到问题模组。 （希望群U能早点找到错误，二分法太耗时了(；へ： ) ）

4.4 仍然无法解决现有错误？

• 若已确认错误由哪些模组导致，你可以采用以下方式：
  • 向作者提出 Issue ：找到模组对应的 GitHub 仓库，在 Issues 栏目提出你的问题。
    1. 搜索 Issues 中是否已经有人提出相同问题。
    2. 使用英文提交 Issue （除非明知对方使用中文）。建议使用AI进行辅助。
    3. 清晰描述问题，提供复现步骤、 游戏版本、 模组版本、 Java版本、相关错误日志或崩溃报告链接。
    4. 保持友好和耐心的态度。
  • 尝试寻找是否有非官方版解决了该问题。例如，对于 1.7.10 版本， GTNH 团队维护了很多早已停更的模组，并发布了非官方版解决各种BUG。建议在可信平台（如 GitHub ）上寻找该类文件。
• 若出现疑难杂症，可以采用如下方式：
  • 求助他人，如XDUCraft技术组，或其他相关的MC交流平台。同样需要注意提供日志和测试环境。
  • 成为一条咸鱼。