1. 为什么偏偏是 Mac Mini 来跑 MC 服务器1.1 从一台闲置小主机说起手里这台 Mac Mini 是去年换下来的M 系列芯片16GB 统一内存512GB 固态。平时放在桌角吃灰偶尔拿来当个下载机。直到某天晚上几个老伙计在群里嚷嚷着要重开一个 Minecraft 服务器我才突然意识到——这玩意儿不就是现成的服务器吗低功耗、静音、体积小、性能够用这几个标签贴在 Mac Mini 身上简直完美。你可能会问为什么不用云服务器我算过一笔账一台能稳定跑 10 人左右模组生存的云主机月付少说也要大几十到上百块一年下来够买半台二手 Mac Mini 了。而且云服务器的 CPU 单核性能往往很拉胯MC 这游戏偏偏又极度吃单核性能主频上不去TPS 就稳不住人一多就卡成幻灯片。Mac Mini 的 M 系列芯片单核性能在消费级里属于第一梯队功耗却只有十几瓦到几十瓦。7×24 小时开着一个月电费也就几块钱。再加上 macOS 本身是 Unix 内核跑 Java 版服务端天然友好命令行工具齐全拿来当 MC 服务器再合适不过。1.2 这套方案到底能解决什么问题说白了这个项目的核心目标就三个稳定、低延迟、低成本。稳定指的是服务器能长时间不崩、不卡顿、不丢档。低延迟指的是同城或同省的朋友连进来延迟能压在 20ms 以内打怪挖矿没有明显的操作滞后感。低成本则是指硬件一次性投入之后后续几乎没有额外开销电费忽略不计。适合谁来参考如果你手里正好有一台闲置的 Mac Mini或者正打算收一台二手的来当家庭服务器又或者你是个小团体的服主厌倦了云服务器的高昂月费和性能瓶颈那这套方案就是为你准备的。哪怕你之前没怎么碰过命令行跟着走也能搭起来。1.3 先泼一盆冷水Mac Mini 跑 MC 的先天短板在开始之前我得先把丑话说在前头。Mac Mini 跑 MC 服务器并不是没有坑。第一个坑是内存。M 系列芯片用的是统一内存CPU 和 GPU 共享。如果你买的是 8GB 版本那基本只能跑原版或者轻量插件服模组服想都别想。16GB 是起步24GB 或 32GB 才能比较从容地跑中型模组包。这个在选购二手机的时候一定要看清楚别贪便宜买 8GB 的到时候哭都来不及。第二个坑是散热。Mac Mini 的散热设计偏向静音长时间满载运行机身会温热但一般不会降频降得太厉害。不过如果你把它塞在密闭的柜子里那就不行了。我实测下来放在通风的桌面上连续跑一周CPU 温度稳定在 70 度上下完全可以接受。第三个坑是系统生态。有些 MC 服务端的插件或者工具是专门为 Linux 写的在 macOS 上跑需要额外折腾。比如某些基于 glibc 的二进制工具在 macOS 上就得找替代方案或者用容器跑。这个后面会详细讲。2. 开服前的硬件与系统准备2.1 机型选择与内存容量的硬性门槛先说说机型。目前市面上能买到的 Mac Mini从 M1 到 M4 都有M4 之后的型号性能更强但价格也更高。如果你只是跑原版或者轻量插件服M1 的 16GB 版本就绰绰有余了。我实测过M1 跑 Paper 服务端10 个玩家在线视距开到 10TPS 稳定在 20内存占用大概 4 到 6GB。如果你要跑模组服比如那种包含几百个模组的大型整合包那建议至少 M2 Pro 或者 M4 的 24GB 版本。模组服的内存占用是插件服的好几倍而且模组加载本身就很吃 CPU 单核性能。我试过用 M1 16GB 跑一个 200 模组的整合包启动就花了将近 5 分钟进游戏后 TPS 经常掉到 15 以下体验很差。换成 M4 24GB 之后启动时间缩短到 2 分钟以内TPS 基本能稳住 19 到 20。这里给一个简单的内存对照表方便你判断自己的需求服务端类型最低内存推荐内存适用机型原版生存4GB8GBM1 8GB 及以上轻量插件服6GB12GBM1 16GB 及以上中型模组服12GB20GBM2 Pro 16GB 及以上大型模组整合包20GB32GBM4 Pro 24GB 及以上注意这里说的内存是分配给 Java 虚拟机的堆内存不是整机内存。整机内存还要留出几个 GB 给系统和其他后台进程。所以 16GB 的机器最多分配给 MC 服务端 10 到 12GB再多就会开始用交换分区性能反而下降。2.2 系统版本与 Java 运行时的匹配macOS 的版本建议保持在较新的稳定版比如 macOS 14 或者 15。太老的系统可能缺少一些新的命令行工具或者对 Java 的支持不够好。Java 运行时的选择是个关键点。MC 服务端从 1.17 开始官方推荐使用 Java 17。1.20.5 之后推荐 Java 21。如果你跑的是模组服那还要看模组加载器 Forge 或者 NeoForge 的要求。一般来说Java 21 是目前最稳妥的选择兼容性最好。在 macOS 上安装 Java我推荐用 Homebrew省心省力。打开终端先装 Homebrew然后一行命令搞定brew install openjdk21装完之后还需要把 Java 加到环境变量里。macOS 上 Homebrew 装的 OpenJDK 默认不会自动链接到系统路径需要手动处理一下sudo ln -sfn /opt/homebrew/opt/openjdk21/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-21.jdk然后验证一下java -version如果输出显示 21 版本那就没问题了。这里有个小坑如果你之前装过其他版本的 Java可能会冲突。用which java看看当前用的是哪个如果不是你刚装的就调整一下 PATH 的顺序。2.3 网络环境与端口的基础配置Mac Mini 一般放在家里走的是家庭宽带。这里有几个事情要确认。首先是公网 IP。如果你想让外面的朋友连进来那你的宽带需要有公网 IP。现在很多运营商默认给的是内网 IP需要打电话申请。这个各地政策不一样有的免费给有的要加钱。如果没有公网 IP那就只能走内网穿透或者组网方案这个后面会提。其次是端口映射。MC 服务端默认监听 25565 端口。你需要在路由器的管理后台把这个端口映射到 Mac Mini 的内网 IP 上。内网 IP 建议在路由器里给 Mac Mini 绑定一个固定的 DHCP 地址免得重启之后 IP 变了映射失效。最后是防火墙。macOS 自带的防火墙可能会拦截入站连接。你需要在系统设置里把 Java 进程加入允许列表或者干脆在测试阶段临时关闭防火墙。不过我不建议长期关闭还是加白名单比较稳妥。提示如果你的宽带没有公网 IP可以考虑用 Tailscale 或者 ZeroTier 这类组网工具把几个朋友拉进同一个虚拟局域网然后直接用内网 IP 连接。这种方式延迟略高一点但胜在简单不需要折腾路由器。3. 服务端选型与核心配置调优3.1 Paper、Fabric、Forge 到底选哪个服务端的选择直接决定了你后续的玩法方向和折腾难度。Paper是目前最流行的插件服务端基于 Spigot 优化而来性能好插件生态丰富。如果你只是想和朋友玩原版生存加点小游戏、经济系统、领地保护之类的插件那 Paper 是首选。它的配置文件清晰社区支持也好遇到问题基本都能搜到答案。Fabric是轻量级的模组加载器启动快对原版改动小。适合想加一些辅助模组比如小地图、性能优化、背包整理但又不想大改游戏内容的玩家。Fabric 的服务端配置相对简单模组兼容性也不错。Forge是老牌的模组加载器大型整合包基本都用它。缺点是启动慢内存占用高而且不同模组之间的冲突比较常见。如果你要跑那种几百个模组的整合包那基本没得选只能上 Forge 或者它的衍生版 NeoForge。我个人的建议是先从 Paper 入手把服务器跑起来熟悉一下基本的运维操作。等有经验了再根据需求切换到模组服务端。不要一上来就搞大型整合包那样很容易被各种报错劝退。3.2 启动参数的计算与 JVM 调优启动参数是很多新手容易忽略的地方但它对性能的影响非常大。默认的启动脚本往往只设置了内存上限没有做垃圾回收的优化跑久了就容易卡顿。先看内存参数。-Xms和-Xmx分别是最小和最大堆内存。建议把这两个值设成一样避免 JVM 在运行过程中动态调整堆大小带来的性能波动。比如你想分配 8GB就写-Xms8G -Xmx8G然后是垃圾回收器。Java 21 默认用的是 G1 GC对 MC 服务端来说已经够用了。但如果你追求更低的停顿时间可以试试 ZGC 或者 Shenandoah。不过这两个在 macOS 上的表现我实测下来和 G1 差别不大除非你的内存特别大否则没必要折腾。一个比较通用的启动参数模板是这样的java -Xms8G -Xmx8G \ -XX:UseG1GC \ -XX:ParallelRefProcEnabled \ -XX:MaxGCPauseMillis200 \ -XX:UnlockExperimentalVMOptions \ -XX:DisableExplicitGC \ -XX:AlwaysPreTouch \ -XX:G1NewSizePercent30 \ -XX:G1MaxNewSizePercent40 \ -XX:G1HeapRegionSize8M \ -XX:G1ReservePercent20 \ -XX:G1HeapWastePercent5 \ -XX:G1MixedGCCountTarget4 \ -XX:InitiatingHeapOccupancyPercent15 \ -XX:G1MixedGCLiveThresholdPercent90 \ -XX:G1RSetUpdatingPauseTimePercent5 \ -XX:SurvivorRatio32 \ -XX:PerfDisableSharedMem \ -XX:MaxTenuringThreshold1 \ -jar server.jar nogui这一长串参数看着吓人其实核心就几个用 G1 GC控制停顿时间在 200ms 以内调整新生代的比例让垃圾回收更平滑。AlwaysPreTouch这个参数会让 JVM 在启动时就把内存全部占住虽然启动慢一点但运行起来更稳定不会因为内存分配而卡顿。3.3 服务端配置文件的逐项拆解服务端的server.properties文件里有几个参数直接影响性能和体验值得单独拿出来说。view-distance是视距默认是 10。这个值越大玩家能看到的范围越广但服务端的负载也越高。对于 Mac Mini 来说建议设在 6 到 8 之间。我实测过视距从 10 降到 6TPS 能从 18 提升到 20效果很明显。玩家那边可能会觉得视野稍微近了一点但流畅度提升是值得的。simulation-distance是模拟距离控制怪物、作物、红石等游戏逻辑的活跃范围。这个值默认和视距一样但可以单独调低。比如视距设 8模拟距离设 6这样玩家能看到较远的风景但只有近处的实体在活动能省不少 CPU。max-players是最大玩家数。这个要根据你的硬件和玩法来定。原版生存 10 个人左右Paper 插件服 15 到 20 个人模组服可能只能撑 5 到 8 个人。不要设得太高否则人一多就卡。network-compression-threshold是网络压缩阈值默认是 256。这个值决定了多大的数据包会被压缩。对于家庭宽带来说上传带宽通常比较有限开启压缩能省不少流量。但如果你的 CPU 比较弱压缩本身也会消耗性能。Mac Mini 的 CPU 足够强保持默认或者调到 512 都可以。sync-chunk-writes这个参数控制区块写入是否同步。默认是 true改成 false 能提升性能但万一服务器崩溃可能会丢一点最近的区块数据。如果你有定期备份的习惯可以改成 false。4. 从零到一的完整开服实操4.1 目录规划与文件下载先在 Mac Mini 上建一个专门的目录把所有服务器相关的文件都放在里面。我习惯放在用户目录下的mc-server文件夹mkdir -p ~/mc-server cd ~/mc-server然后下载服务端核心。以 Paper 为例去官网找到对应版本的下载链接用curl直接下载curl -o server.jar https://api.papermc.io/v2/projects/paper/versions/1.21.1/builds/xxx/downloads/paper-1.21.1-xxx.jar注意把 URL 里的版本号和构建号换成你实际需要的。下载完之后先跑一次让它生成配置文件java -Xms4G -Xmx4G -jar server.jar nogui第一次运行会报错退出这是正常的因为它需要你同意 EULA。打开生成的eula.txt把eulafalse改成eulatrue然后再跑一次。4.2 首次启动与 EULA 同意第二次启动服务端会开始生成世界。这个过程可能需要几分钟取决于你的 CPU 性能和世界大小。你会看到控制台刷出一堆日志最后出现Done字样就说明启动成功了。这时候你可以用localhost:25565在游戏里连一下确认能进去。如果能进说明服务端本身没问题。接下来就是配置外网访问和插件了。注意首次启动时不要急着把内存设得太大。先用一个较小的值跑起来确认没问题之后再调整。因为如果参数有问题大内存启动失败会更浪费时间。4.3 插件安装与权限组配置Paper 的插件安装很简单把下载好的.jar文件丢进plugins文件夹然后重启服务器就行。常用的插件有 EssentialsX基础指令、LuckPerms权限管理、WorldGuard领地保护、CoreProtect方块记录等。这里重点说一下 LuckPerms 的配置因为权限系统是很多新手容易搞混的地方。LuckPerms 的核心概念是“组”和“权限节点”。你可以创建一个默认组给普通玩家一些基础权限比如/spawn、/home、/tpa。然后创建一个管理员组继承默认组的所有权限再加上 ban、kick、op 等管理权限。配置的方式有两种一种是在游戏里用指令另一种是直接编辑配置文件。我推荐用指令因为不容易出错。比如创建一个组/lp creategroup default /lp creategroup admin然后给组分配权限/lp group default permission set essentials.spawn true /lp group default permission set essentials.home true /lp group admin parent add default /lp group admin permission set essentials.ban true最后把玩家加到对应的组里/lp user Steve parent set default /lp user Alex parent set admin这套流程走下来权限系统就基本成型了。后续再根据实际需求微调就行。4.4 内网穿透与远程访问的替代方案如果你没有公网 IP或者不想折腾路由器那可以用组网工具来实现远程访问。Tailscale 是我用得比较顺手的一个安装简单配置也直观。在 Mac Mini 上安装 Tailscalebrew install tailscale然后启动并登录sudo tailscaled install-system-daemon tailscale up它会给你一个链接在浏览器里打开登录账号这台机器就加入你的虚拟网络了。然后让你的朋友也安装 Tailscale加入同一个网络。之后他们就可以用 Mac Mini 的 Tailscale IP 来连接服务器了。这种方式的延迟会比直连公网 IP 高一点但胜在稳定不需要公网 IP也不受运营商限制。对于小团体来说完全够用。5. 性能压测与常见故障排查5.1 用 Spark 定位卡顿根源服务器跑起来之后最怕的就是莫名其妙卡顿。这时候就需要一个性能分析工具Spark 是目前最好用的一个。它是一个插件装上去之后可以用指令生成性能报告。比如你想看看最近几分钟的 TPS 波动可以用/spark tps它会显示最近 1 分钟、5 分钟、15 分钟的平均 TPS。如果 TPS 低于 20那就说明有性能问题。接着可以用/spark profiler start让它跑个几十秒然后/spark profiler stop它会生成一个链接在浏览器里打开就能看到详细的火焰图。哪个方法占用的 CPU 时间最多一目了然。我遇到过好几次卡顿都是因为某个插件在疯狂遍历实体用 Spark 一查就找到了。5.2 内存泄漏与 GC 频繁的典型症状内存泄漏是模组服常见的问题。症状是服务器运行一段时间后内存占用越来越高GC 越来越频繁最后要么卡死要么直接崩溃。判断是不是内存泄漏可以看 GC 日志。在启动参数里加上-Xlog:gc*:filegc.log:time,uptime:filecount5,filesize10M这样 GC 日志会写到gc.log文件里。如果看到 Full GC 越来越频繁而且每次回收之后内存下降得越来越少那基本就是泄漏了。解决的办法通常是逐个排查模组或者插件。先把所有非核心的模组禁用跑一段时间看是否还有泄漏。如果没有再逐个加回来直到找到罪魁祸首。这个过程比较耗时但没办法模组冲突就是这样。5.3 玩家进不来先查这五个地方玩家连不上服务器是最常见的问题。我整理了一个排查顺序按这个来基本能解决九成以上的连接问题。排查项检查方法常见问题服务端是否运行看控制台有没有 Done启动失败端口被占用端口是否监听lsof -i :25565服务端没绑定到正确端口防火墙是否放行系统设置里的防火墙规则Java 进程被拦截路由器映射是否正确路由器后台的端口转发规则内网 IP 变了映射失效公网 IP 是否有效在外部网络 ping 一下运营商给了内网 IP如果这五项都没问题那可能是服务端的server.properties里server-ip绑定了错误的地址。默认是留空表示监听所有网卡。如果你之前改过记得改回来。5.4 存档备份与回档的保命操作最后说一个最重要的事情备份。MC 服务器最怕的就是存档损坏一旦坏了几百个小时的心血就没了。我用的方案是定时任务加脚本。写一个简单的备份脚本#!/bin/bash DATE$(date %Y%m%d_%H%M%S) tar -czf ~/mc-backups/world_$DATE.tar.gz ~/mc-server/world find ~/mc-backups -name world_*.tar.gz -mtime 7 -delete然后用crontab设置每天凌晨 4 点执行一次0 4 * * * /bin/bash ~/backup.sh这样每天都会自动备份而且只保留最近 7 天的不会把硬盘塞满。如果哪天存档出了问题解压最近的备份覆盖回去就行。提示备份的时候最好先让服务器保存并关闭或者在备份前执行save-all指令确保数据都写入了磁盘。直接备份正在运行的世界文件夹可能会得到不一致的数据。6. 长期运行的维护心得6.1 定时重启到底有没有必要关于定时重启社区里一直有争议。有人觉得没必要有人觉得能预防内存泄漏。我的看法是如果你的服务器跑的是原版或者轻量插件服那没必要定时重启跑几周不重启也没问题。但如果是模组服尤其是那种大型整合包那建议每天或者每两天重启一次。原因很简单模组服的代码质量参差不齐内存泄漏几乎是必然的。定时重启能强制释放内存让服务器保持在一个相对干净的状态。我一般设置在凌晨 5 点这时候基本没人玩重启的影响最小。重启的方式也有讲究。不要直接 kill 进程那样可能会丢数据。正确的做法是先执行stop指令等服务器完全关闭之后再重新启动。可以写一个脚本来自动化这个过程#!/bin/bash screen -S mc -X stuff stop\n sleep 30 cd ~/mc-server screen -dmS mc java -Xms8G -Xmx8G -jar server.jar nogui这个脚本用screen来管理服务端进程先发送 stop 指令等 30 秒再重新启动。配合 crontab就能实现无人值守的定时重启。6.2 模组更新与版本升级的稳妥节奏模组更新是个让人又爱又恨的事情。新版本可能修复了 bug也可能引入了新的 bug。我的策略是不追新只求稳。具体来说服务端核心和模组的版本不要一出来就更新。等个一两周看看社区反馈确认没有大面积的问题再动。更新之前一定要备份存档和配置文件。更新之后先自己进去跑一圈确认没问题再通知其他人。如果是大版本升级比如从 1.20 升到 1.21那更要谨慎。很多模组可能还没适配新版本强行升级会导致服务器起不来。正确的做法是先在一个单独的测试环境里跑一遍确认所有模组都能正常工作再迁移正式服。6.3 功耗、噪音与散热的长测记录最后分享一下我这台 Mac Mini 长期运行的实测数据。功耗方面待机大概 5 到 8 瓦满载跑 MC 服务器大概 25 到 35 瓦。按 30 瓦算一天 0.72 度电一个月大概 22 度。按居民电价算一个月电费也就十块钱出头。相比云服务器这个成本几乎可以忽略不计。噪音方面Mac Mini 的风扇在低负载下基本不转满载时会有轻微的风声但放在桌面上几乎听不到。我把它放在书桌角落距离人大概一米晚上安静的时候才能隐约听到一点风扇声。散热方面连续跑了一周之后机身顶部摸起来温温的大概四十度左右。用软件看 CPU 温度稳定在 65 到 75 度之间。这个温度对于长时间运行来说是完全正常的不用担心。唯一需要注意的是灰尘。Mac Mini 的进风口在底部时间长了容易积灰。建议每隔几个月用压缩空气吹一下底部保持通风顺畅。这套方案我跑了大半年除了偶尔因为模组冲突重启一下整体非常稳定。几个朋友玩得也挺开心延迟低不卡顿体验比之前用的云服务器好太多了。如果你手里正好有闲置的 Mac Mini不妨试试说不定能给你带来意想不到的惊喜。