朋友半夜发来一句“进不去”，你打开PCL2看着自己那份一百多个MOD的整合包，脑子里第一反应往往是“是不是网络问题”。十有八九不是。整合包联机这件事，难的地方从来不在“点哪个按钮”，而在于把PCL2的版本管理、整合包的MOD一致性、局域网联机的端口机制、以及异地联机时的内网穿透这四件事串成一条能跑通的链路。这条链路里任何一环错位，表现都是同一句话：连接超时。

我这些年帮人远程看过太多类似的场面：有人把整合包直接拖进.minecraft覆盖，结果两边的Forge版本差了一个小版本号；有人在游戏里点了“对局域网开放”，却没记下那串随机端口；还有人兴冲冲配好了穿透隧道，最后发现防火墙把Java进程挡在外面。下面这份内容，就是把这些环节按我实际操作的顺序摊开讲，从同一屋檐下的局域网，一直讲到隔着几百公里的异地联机，尽量让每一步都能照着做、出了问题知道往哪查。

1. 先搞清楚整合包联机到底卡在哪一层

1.1 三个环节，错一个就白忙

我把整合包联机拆成三层来看，这个分层方式帮我省了很多排查时间。

第一层是客户端一致性。整合包不是一个文件夹那么简单，它是“游戏版本 + 模组加载器版本 + 模组列表 + 配置文件 + 资源包”的组合体。两个人联机，这五样东西必须对得上，尤其是模组加载器（Forge、NeoForge、Fabric、Quilt）的版本号，差一位数都可能让某一方的客户端在握手阶段直接被踢。我见过最典型的例子是：A同学的整合包是从某处下载的完整包，B同学是自己在PCL2里手动装Forge再一个个拖MOD进去，模组名字看着一样，实际配置文件里config目录的内容完全不同，进游戏后一方能开箱子另一方直接崩。

第二层是启动参数与内存。整合包对内存的要求比原版高得多，一百多个模组的包给2G内存，进游戏能进，但走两步就开始卡顿，联机时表现为“对方看到你在原地瞬移”。PCL2的版本设置里可以单独给每个版本分配内存，这一点后面会细讲。

第三层才是网络连通性。这一层又分两种情况：同一个路由器下面，走局域网广播就行；不在一起，就得解决“你家路由器没有公网入口”这个问题，也就是内网穿透要干的活。

三层的顺序不能颠倒。我见过太多人跳过前两层直接折腾网络，配了两小时隧道，最后发现是MOD版本不一致。

1.2 PCL2在整条链路里负责什么，不负责什么

PCL2（Plain Craft Launcher 2）的定位很清晰：它是一个版本与整合包的管理器，外加一个相当好用的下载与修复工具。它帮你做的是：把每个游戏版本装进独立的versions子目录实现版本隔离、自动补全Forge/Fabric的安装、导入.zip或.mrpack格式的整合包、管理Java运行时、生成正确的启动命令。

它不做的事也很明确：它不替你解决网络层的连通问题。你把整合包管得再好，隔着一堵墙的两台电脑之间该不通还是不通。所以别指望在启动器里找到一个“一键联机”按钮就把异地朋友拉进来，网络这一层要单独处理。

版本隔离这个功能值得单独说一句。开启后，每个版本拥有自己的mods、config、saves目录，互不干扰。这对同时玩多个整合包的人是刚需，但联机场景下它会带来一个隐形陷阱：你以为两个人装的是同一个整合包，实际上一个装在隔离目录里、一个装在全局.minecraft根目录下，游戏读的模组根本不是同一批。判断方法很简单，进游戏后看模组列表（Mods按钮）里的数量，两边对一下数字，对不上就是环境不同。

提示：整合包导入完成后，先让双方各自单机进一次游戏，确认能正常进入主世界。单机都进不去，联机一定失败，先把这个变量排除掉。

2. 局域网联机的完整链路：从开房间到对方连上

2.1 同一网段下的最短路径验证

同一个路由器下的联机是最省事的场景，也是验证整合包本身能不能联机的最佳试验场。我建议所有异地联机前的准备工作，都先在这条最短路径上跑通一遍。

操作顺序是这样：房主打开PCL2，选中整合包对应的版本，正常启动进入单人世界。进游戏后按ESC，点“对局域网开放”，这时候会弹出两个选项——游戏模式和是否允许作弊。点确认后，聊天栏会冒出一行绿字，类似“本地游戏已在端口 54321 上开放”。

这行绿字里的端口号必须记下来，它是随机分配的，每次开都不一样。很多人第一次联机失败就是因为默认以为端口永远是25565。

然后房主查自己的局域网IP。Windows下按Win+R输入cmd，敲ipconfig，找“无线局域网适配器”或“以太网适配器”下面的IPv4地址，一般是192.168.x.x这种格式。把这个IP和刚才的端口拼起来，形如192.168.1.7:54321，发给对方。

对方在PCL2里启动完全相同的整合包版本，进主菜单点“多人游戏”，选“直接连接”，把上面那串地址粘进去，回车。顺利的话几秒内就能进。

这里有几个细节值得说透。为什么用“直接连接”而不是等自动扫描？因为Minecraft的局域网广播用的是多播，很多路由器、尤其是开了AP隔离的公共网络，会直接吞掉多播包，导致对方在多人游戏列表里根本看不到你的房间。直接连接绕过了广播，只依赖单播TCP，成功率高得多。

至于端口为什么会变，是因为游戏内开放局域网用的是系统随机分配的临时端口。想固定端口，就得走专用服务端那条路，后面会讲。

2.2 防火墙、Java进程与那个最容易被忽略的弹窗

局域网联机失败的原因里，防火墙占的比例高得离谱。

Windows Defender防火墙在Java进程第一次尝试监听端口时会弹一个对话框，问“是否允许此应用通过防火墙”。这个弹窗经常在游戏启动的一瞬间弹出来，而玩家正盯着加载界面，顺手就点了“取消”，或者干脆没注意到。结果就是：本机自己能进，别人死活连不上。

排查方法很直接：打开“Windows Defender 防火墙”→“允许应用通过防火墙”，在列表里找到Java(TM) Platform SE binary或者javaw.exe，确认“专用”和“公用”两列都打了勾。如果列表里没有，点“更改设置”→“允许其他应用”，手动把PCL2使用的那个Java可执行文件加进去。

这里有个坑：整合包常用的Java版本可能不止一个。你的电脑上可能同时装着Java 8、Java 17、Java 21，PCL2给不同版本的游戏调用的Java不一样。你放行了Java 17的javaw.exe，结果这个整合包用的是Java 21，等于白放行。稳妥的做法是把java安装目录下所有版本的javaw.exe都加一遍，或者干脆在测试阶段临时关闭防火墙验证一下——验证完记得开回来。

还有一个隐蔽问题：某些安全软件会拦截“未知程序监听端口”的行为，表现不是报错，而是静默丢包。如果你确认防火墙已经放行、IP和端口都没错，对方还是超时，可以试着临时退出这类软件再测一次。

2.3 把异地朋友拉进同一个“虚拟家庭网络”

不在一起玩的时候，最接近局域网体验的方案是虚拟局域网组网。原理不复杂：参与方都装同一个组网客户端，登录后加入同一个虚拟网络，客户端会给每台机器分配一个虚拟网段的IP（常见的是10.x.x.x或172.x.x.x开头）。之后你们之间的通信就像是坐在同一个路由器下面，只不过数据走的是组网服务商的中转或者点对点直连。

配置思路（各家工具字段名不同，语义是一致的）：

1. 房主在组网工具里创建一个网络，设置一个网络名和密码，记下分配给自己机器的虚拟IP。
2. 其他人在客户端里“加入网络”，输入同样的网络名和密码。
3. 所有人都能在成员列表里互相看到，并且能ping通对方的虚拟IP。
4. 房主按前面的方式开局域网，把虚拟IP + 端口发给对方。
5. 对方用“直接连接”填入这串地址。

这套方案的好处是不需要你有公网IP，也不需要动路由器，配置成本基本集中在“让所有人都装上客户端并加入同一个网络”这一步。缺点是所有人必须保持客户端在线，而且组网工具本身的质量直接影响延迟——免费线路走中转的时候，跨运营商延迟可能会到一百多毫秒，玩红石机械或者PVP会明显感觉到延迟。

几个实操经验：

• 组网工具默认可能关闭局域网广播转发。有些客户端有“允许局域网”或“允许广播”之类的开关，如果对方在多人游戏列表里看不到房间，去设置里把这个开关打开。
• 虚拟IP是可能变化的。重新登录、切换网络环境后，分配到的虚拟IP有可能变。每次开黑前让房主确认一下当前IP，别拿着上周的地址硬连。
• 确认能ping通再开游戏。这一步能省掉大量扯皮。对方连ping都不通，说明组网这一层就没成，别浪费时间在游戏里试。

3. 内网穿透方案：判断需求、填对参数、接受它的边界

3.1 先确认你缺的到底是公网IP还是端口权限

内网穿透这个词听着唬人，本质就是一句话：你家里的电脑没有可以从外面直接访问的入口，所以要借一台有公网地址的机器做中转，把外面的请求转发进来。

在动手之前，先花两分钟判断你的网络环境，因为这决定了你该选哪种方案。

打开浏览器搜“IP”，看看显示的地址。如果这个地址是10.、172.16.到172.31.、192.168.开头，说明你在运营商的大内网里，基本没有公网IPv4。如果是100.64.到100.127.开头，那是运营商级NAT，同样没有可用的公网入口。这种情况下，路由器上做端口映射是没用的，因为请求根本到不了你的路由器。

即便你拿到了公网IP，还有一道坎：运营商是否封了入站端口。家庭宽带普遍封锁80、443，部分区域对高位端口也有限制。测试方法是用手机流量（不是同一个WiFi）去访问你家IP的某个端口，通不通一目了然。

判断结果对应的方案：

表格里第二行的情况现在越来越少见，绝大多数家庭宽带都属于第三行。

3.2 隧道参数怎么填：四个字段的对应关系

不同穿透工具的界面长得不一样，但核心参数永远是这四个：本地地址、本地端口、隧道协议、远程端口（或由服务端分配）。理解它们的对应关系，换任何工具都能上手。

本地地址：填127.0.0.1最稳妥，前提是穿透客户端和游戏跑在同一台机器上。如果游戏跑在另一台内网机器上，就填那台机器的局域网IP（比如192.168.1.20）。

本地端口：这是最容易填错的一项。它必须和游戏实际监听的端口完全一致。如果你是在游戏里点“对局域网开放”，那就是聊天栏绿字里那个五位数的随机端口；如果你跑的是专用服务端，就是server.properties里server-port的值，默认25565。

隧道协议：Minecraft的Java版联机走的是TCP，选TCP就对了。有些工具会让你选UDP或者“TCP+UDP”，对于纯Java版联机，单TCP足够。基岩版才需要UDP。

远程端口：有的服务由系统随机分配，有的允许你指定。分配到的结果会拼成一个访问地址，形如节点域名:远程端口。这个地址就是你要发给朋友的“服务器地址”。

一个具体的配置示例，用字段名表示（各工具命名不同，含义对应即可）：

隧道名称: mc-integrated-pack 协议类型: TCP 本地地址: 127.0.0.1 本地端口: 54321 远程端口: 25651 # 由服务端分配或自行指定 访问地址: node-xx.example.net:25651

朋友那边在PCL2里“直接连接”，填node-xx.example.net:25651就能进。

这里必须强调一个顺序问题：穿透客户端要在游戏开放局域网之后再启动隧道，或者至少要保证隧道启动时本地端口已经在监听。反过来的顺序会出现“隧道显示在线但连接被拒绝”的假象，因为隧道找不到本地服务，转发过去的连接直接被重置。

3.3 免费线路的真实体验与几个绕不开的限制

我用免费穿透线路跑过一段时间的整合包联机，说几句实话，省得你对它抱有不切实际的期待。

带宽是硬约束。免费线路通常给1到5 Mbps的带宽，这个数字看着不小，但Minecraft联机时服务端要持续同步实体位置、区块数据、物品栏变化，一个一百多个模组的整合包，加载新区块时的瞬时流量相当可观。带宽不够的表现是：能进游戏，但走几步就被拉回原地，或者开箱子要等两三秒才显示内容。

延迟取决于节点位置。中转节点在同城或者相邻城市，延迟可能只有二三十毫秒，体验接近局域网；节点跨了大半个国家，一百多毫秒起步，这时候红石时序、战斗判定都会出问题。选节点的时候优先看地理位置，别只看“线路等级”这类宣传词。

免费隧道通常不保证地址长期不变。断线重连后远程端口可能变，域名也可能变。这意味着每次重开都要重新把地址发给朋友。如果你打算长期开一个固定服务器，得考虑付费的固定端口方案，或者换回虚拟局域网组网。

部分工具对长连接有心跳限制。Minecraft的TCP连接一旦长时间没有数据往来（比如两个人都站在一个地方不动），可能被中途设备判定为空闲连接而掐断。表现是“玩着玩着突然掉线”。这种情况可以在服务端的server.properties里调一下network-compression-threshold，或者干脆让玩家动一动。不是什么优雅的方案，但确实有效。

4. 连不上时的排查链路：按层级倒推，别瞎试

4.1 五层排查顺序

我把排查分成五层，从下往上查，每层都有明确的验证动作。这套顺序的价值在于每次验证都能排除掉一整类可能性，而不是在游戏里反复点击“连接”碰运气。

第一层：游戏本身能不能跑。双方各自单机进一次游戏，能进主世界、能正常打开背包。这一层不过，后面全是空谈。

第二层：登录方式是否一致。这一点很多人忽略。PCL2支持正版登录和离线登录两种方式，联机双方的登录方式必须匹配。一方正版一方离线，握手阶段就会被拒绝。统一一下，全部用同一种方式再试。

第三层：整合包是否真的同一个。对比三样东西：游戏版本号（主菜单左下角或者PCL2的版本列表）、模组加载器版本、模组数量。三项全对得上才算同一个环境。有个偷懒但有效的办法：让双方把mods文件夹的文件名列表导出来对比，数量一样、名字一样，基本就没问题。

第四层：网络通不通。按前面的方案不同，验证动作也不同：

• 局域网：对方ping 房主IP能不能通。
• 虚拟组网：对方ping 虚拟IP能不能通。
• 穿透隧道：在朋友机器上telnet 节点域名 远程端口，看是连接成功还是被拒绝/超时。

telnet在Windows上默认没启用，可以在“启用或关闭Windows功能”里勾上“Telnet客户端”，或者用PowerShell的Test-NetConnection -ComputerName 节点域名 -Port 远程端口代替，输出里的TcpTestSucceeded是True就说明端口通了。

第五层：服务端日志说什么。跑专用服务端的话，控制台会打印每一条连接尝试。看到lost connection、mismatched mod channel list这类字样，基本能直接定位到是模组不匹配还是网络中断。

4.2 症状对照表

这张表我建议存下来。实际排查时先对症状，再按五层顺序验证，比漫无目的地改配置高效得多。

5. 长期开服才需要操心的几件事

5.1 内存分配不是越大越好

整合包玩家有个普遍误区：内存给得越多越流畅。实际情况不是这样。

Minecraft的Java进程有一个垃圾回收机制，堆内存给得越大，单次回收的停顿时间越长。给一个一百多模组的包分配16G内存，可能出现“平时很顺，每隔十几秒卡一下”的锯齿状表现，体验反而不如8G。

我的经验值是这样：轻度整合包（50个模组以内）给4G，中度（50到150个）给6到8G，重度（150个以上带大量模型和世界生成）给8到10G。超过10G除非你在跑超大视距或者几百个模组，否则收益递减明显。

在PCL2里改内存的位置在“版本设置”→“设置”→“Java与内存”，把“最大内存”调成你要的值。注意这里改的是启动参数，改完要重启游戏才生效。

另外提醒一句：开服的那一方内存要给足。服务端要同时处理世界模拟和多个玩家的数据同步，同样一个整合包，客户端的推荐内存和服务端的需求不是一回事，服务端建议比客户端多给2G。

5.2 用专用服务端替代“游戏内开房间”

玩到一定程度，你会发现“在游戏里点对局域网开放”这种方式有很多限制：端口随机、关掉游戏服务端就没了、某些模组在客户端开房间时不工作、房主退出世界就暂停。

这时候该换成专用服务端。整合包作者通常会在下载包里附带一个server文件夹，里面有一个启动脚本和server.properties。流程是：

1. 把服务端文件夹放到一个路径里全是英文、没有空格的目录下。中文路径在某些Java版本下会导致读取失败，这个坑很常见。
2. 编辑eula.txt，把eula=false改成eula=true。
3. 编辑server.properties，把server-port改成你想要的固定端口（比如25565），online-mode按前面说的登录方式统一设置。
4. 双击启动脚本，等控制台出现Done字样。
5. 把地址发给朋友。

专用服务端的好处是端口固定、房主可以退出、崩溃后能看日志定位。代价是配置门槛高一些，而且服务端和客户端的模组列表必须严格一致——除了少数明确标注“仅客户端”的模组，其余都要在服务端装一份。

注意：server.properties里有一项view-distance，整合包默认值可能给到10以上，服务端压力会很大。网络条件一般的话调到6到8，能明显改善联机流畅度。

5.3 备份、白名单与地址管理

长期开服还有几件小事，都是被坑过之后才重视起来的。

备份。整合包的世界存档动辄几个G，崩一次可能全没了。我的习惯是每次开服前把world文件夹复制一份，命名带上日期。整合包联机时模组之间互相干扰的概率比原版高得多，存档损坏不是小概率事件。

白名单。服务端暴露到公网之后，会有人扫端口进来。在server.properties里把white-list设为true，然后在控制台执行whitelist add 玩家名，只有名单里的人能进。这一步花不了一分钟，能省掉很多麻烦。

地址管理。如果用穿透隧道，把当前的访问地址记在一个双方都能看到的地方（比如群公告），别每次都靠翻聊天记录。地址变了就更新。

6. 我在实际操作中踩出来的几条经验

说几个文档里不会写、但实际会遇到的细节。

整合包导入后先别急着改设置。有些人导入完立刻去调内存、改Java版本、删多余的模组，结果把整合包作者调好的兼容性配置破坏了。先进一次游戏确认能跑，再动别的。

Java版本跟着游戏版本走。1.16及以下用Java 8，1.17到1.20.4用Java 17，1.20.5往上用Java 21。PCL2在安装版本时通常会自动匹配，但手动导入的整合包不一定。版本对不上，表现是启动就崩，日志里会有UnsupportedClassVersionError。

联机前把双方的整合包文件对一下哈希。听起来麻烦，但只要双方用的是同一个下载来源、同一个文件，哈希必然一致。这是排除“我们装的是同一个包”这个变量的最快方式。不一致就重新传一份，别想着靠对比模组列表一个个查，太慢。

穿透隧道不要拿来做长期公网服务。免费隧道适合朋友之间临时开黑，玩完就关。长期挂着既有带宽限制，也有地址变动的问题。真要做长期服务器，考虑正规的云主机托管服务端，把世界数据传上去，成本可控，连接质量也靠谱得多。

最后一条，也是最重要的：联机失败的时候，一次只改一个变量。我见过有人一次同时改端口、换Java、重装整合包、换穿透工具，最后成了也不知道是哪一步起的作用，下次出问题还是不会查。按第五层的顺序，一层一层验证，慢一点但每一步都有确定的结果。