1. 先想清楚：异地联机到底难在哪
我的世界联机这件事，说简单也简单，说折腾也折腾。几个朋友不在同一个屋檐下，想进同一个存档一起挖矿、盖房子，最先撞上的问题不是游戏版本对不对，而是网络根本找不到对方。很多人第一次尝试时会以为“输入IP就能连”，结果要么连接超时，要么显示无法连接至服务器，折腾一下午连主界面都没进去过。这类教程常被归到“内网穿透”这个大类里，但真要把事情做明白，得先把它拆成三个更朴素的问题：你的电脑有没有公网地址、端口有没有对外开放、数据包该从哪条路绕过去。把这三件事理顺，联机就不再是靠运气。
这篇内容面向的是有一定电脑基础、愿意自己动手的玩家：你有一台能开游戏的电脑，可能还有一台便宜的云主机，想让最多五六个人在同一个世界里玩。下面会从方案选型讲到具体配置，再到踩坑排查，尽量把“为什么这么做”讲透。需要先说明一点：所有操作只建议用于自己或熟人小圈子的游戏联机，不要拿来做任何超出授权范围的网络访问，这是底线。
1.1 三个现实约束：公网地址、端口、中转
家用宽带大多数情况下拿到的是运营商内网地址，路由器WAN口上那个IP并不是真正的公网IP。这意味着外部朋友直接填你家IP，数据包到了运营商那一层就被丢了，根本进不了你家路由器。即便运气好有公网IP，光猫和路由器两层NAT也会让端口映射变得麻烦。所以第一个约束是地址可见性：要么想办法拿到公网地址，要么找一个有公网地址的中间人帮你转发。
第二个约束是端口。游戏服务端启动后会监听一个端口，Java版默认是25565，基岩版默认是19132。端口没开，或者开了但防火墙没放行，外面的人照样连不进来。很多人只改了服务端配置，忘了云主机的安全组，结果本地测试一切正常，朋友一连接就超时，问题就出在这。
第三个约束是中转。当双方都不具备直接互访条件时，就需要一台双方都能访问的机器做“二传手”。这台机器可以是云主机，也可以是具备公网地址的服务器。它的作用不是替你玩游戏，而是把朋友的连接接住，再转给你的电脑。理解了这个模型，后面所有配置都是在回答“中转机怎么搭、端口怎么开、流量怎么走”。
1.2 方案选型对比：官方联机、虚拟局域网、自建中转
常见做法大致三类，各有各的适用场景。官方提供的联机服务省心，不用自己维护服务器，但通常按人数或时长计费，而且对模组、插件、存档迁移有一定限制，适合“就想快速开一局”的人。虚拟局域网类工具的思路是把几台电脑拉进同一个虚拟网络，游戏里直接填对方虚拟地址，配置门槛低，但依赖第三方客户端，长期使用要看服务条款，延迟也受中转节点影响。
自建中转的优势是可控：机器是你的，端口是你的，配置和日志都能看到，出了问题能定位。缺点是前期要花一两个小时搭环境，后续还要做备份和更新。我的建议是，如果你只是偶尔玩一两次，用官方联机最省事；如果你想长期开一个固定存档，或者要装模组、加插件，自建中转更划算。下面这套流程就是围绕自建中转展开的，使用一台低配云主机作为入口，把游戏流量转到你自己的电脑或另一台服务器上。
需要补充的是，选择方案时别只看“能不能连上”，还要看延迟和带宽。中转节点离你和朋友越近，延迟越低；上行带宽越足，能容纳的人越多。这两个指标后面会具体算。
2. 自建中转的核心原理与参数计算
2.1 数据是怎么从朋友电脑走到你的存档的
假设朋友A在上海，你的游戏服务端跑在成都家里的电脑上，中转机租在离两边都不远的一个机房。朋友A启动游戏，客户端向中转机的公网地址发起连接；中转机上的转发程序收到连接后，根据事先配置好的规则，把这条连接转给你的电脑；你的服务端处理完游戏逻辑，数据再沿原路返回。整个过程中，朋友A只知道中转机的地址，你的家庭地址始终没有暴露，这也是自建中转的一个附带好处。
这里的关键是“规则”怎么写。转发程序通常需要知道三件事：监听哪个端口、把流量转给哪个内网地址和端口、用什么协议。监听端口就是朋友填的那个端口，转发目标就是你电脑的局域网IP加游戏端口。协议方面，Java版主要走TCP，基岩版走UDP，两者不能混。很多人配置完发现Java版能进、基岩版进不去，八成是协议只写了TCP。
还有一点容易被忽略：你家电脑的局域网IP最好是固定的。路由器重启后DHCP重新分配，IP从192.168.1.100变成192.168.1.101，中转规则就失效了。在路由器里给游戏电脑做一条静态地址绑定，或者在系统里手动设固定IP，能省掉后面很多莫名其妙的“昨天还能连今天不行”。
2.2 带宽、延迟、并发人数怎么估算
我的世界对带宽的要求没有想象中高，但也不能忽略。Java版一个玩家正常游走、挖矿，上行大概占用几十到一百多KB/s；如果有人在跑图、加载新区块，瞬时能冲到几百KB/s；开红石机器或者大量掉落物时还会更高。按经验值粗算，五个人同时在线，给服务端预留2Mbps到4Mbps的上行比较稳妥，十个人建议6Mbps以上。注意这里说的是上行，家用宽带的下行通常很大，上行往往只有二三十Mbps，甚至更低，这是很多人忽略的瓶颈。
中转机的带宽也要看。中转机承接的是所有玩家的流量总和，如果五个人每人平均100KB/s，中转机至少要有4Mbps左右的转发能力，再加上协议开销，留一倍余量更保险。云主机通常按带宽计费，买之前先确认峰值带宽和流量包，别玩到一半被限速。
延迟方面，中转机的地理位置决定了基础延迟。朋友和中转机之间的延迟、中转机和你之间的延迟会叠加。如果朋友在南方、你在北方，中转机选在中间区域通常比选在一边更均衡。实际测试方法很简单：在中转机上对两边分别做网络质量测试，看平均延迟和丢包，别只看最低值。
2.3 端口与协议：TCP和UDP都要考虑
Java版服务端默认监听25565/TCP，基岩版默认监听19132/UDP。如果你只开Java版，配TCP就够了；如果两个版本都想支持，或者朋友里有手机、主机玩家，UDP也要放行。端口不是非得用默认值，改成高位端口能减少被扫描的概率，但改完要同步改转发规则、安全组和客户端连接地址，三处缺一不可。
这里有个实操细节：云主机的安全组和系统防火墙是两层。安全组在云平台控制台配置，系统防火墙在机器内部配置，两层都放行才算真正打开。我见过不少人只在系统里关了防火墙，忘了安全组，或者反过来，折腾半天以为是转发程序的问题。排查时先用本机命令测端口是否监听，再从外部测是否可达，一层一层往下剥。
3. 云主机中继环境搭建实操
3.1 选机器与系统：别一上来就买高配
中转机不需要显卡，也不需要大内存，它只负责转发流量。一个人数不多的小服，1核1G或者1核2G的入门配置就够用，系统选常见的Linux发行版即可，装个轻量级环境，别选带图形界面的镜像，白白占资源。地域选择上，优先选离你和朋友网络路径都比较顺的节点，买之前可以先看看各地区的测试地址，简单测一下延迟。
系统装好后第一件事是更新软件源并装好常用工具，比如文本编辑器、网络诊断工具、进程管理工具。命令不复杂，但建议养成先更新再装东西的习惯，避免版本太旧导致后面编译或运行报错。第二件事是创建一个普通用户来跑转发程序，不要一直用管理员账号，权限收窄一点，出了意外影响也小。
注意：云主机的登录凭证要保管好，建议使用密钥登录并关闭密码登录。中转机暴露在公网，弱口令是最常见的风险来源。
3.2 安全组与系统防火墙开端口
假设我们规划三个端口：一个给Java版联机用，比如30000/TCP；一个给基岩版用，比如30001/UDP；再留一个管理端口，只允许你自己的地址访问。在云平台控制台的安全组里，入方向分别添加规则，来源可以先填具体地址段，确认能通之后再考虑是否放宽。出方向一般默认放行，不用特别处理。
系统层面的防火墙也要对应放行。以常见的firewalld为例，添加端口的命令是firewall-cmd --add-port=30000/tcp --permanent，UDP同理，改完记得reload。如果用ufw，则是ufw allow 30000/tcp。命令本身不难，难的是别忘了执行重载，否则规则写了不生效。
配置完之后做一次自检：在机器上用ss -lntup看端口有没有被程序监听；从另一台机器用nc -vz 中转机地址 30000测连通性。两步都通过，才说明网络层没问题。如果第一步通过、第二步不通，多半是安全组或防火墙；如果第一步就不通，说明程序没起来或者端口写错了。
3.3 部署开源中转工具（配置示例）
转发程序的选择上，建议用成熟的开源方案，社区文档多，出问题好查。不同工具配置字段不一样，但核心逻辑一致：一端跑在公网机器上负责接客，一端跑在内网机器上负责把流量送到游戏服务端。下面给一份通用配置思路，字段名用占位符表示，实际使用时对照所选工具的文档替换。
# 中转机侧配置示例 server_addr = 0.0.0.0 server_port = 30000 protocol = tcp auth_token = 换成你自己的长随机字符串 # 内网侧配置示例 remote_addr = 中转机的公网地址 remote_port = 30000 local_addr = 127.0.0.1 local_port = 25565 protocol = tcp auth_token = 与中转机保持一致几个关键点。第一，认证令牌一定要改，别用示例值，长度建议二十位以上，混合大小写和数字。第二，local_addr如果游戏服务端和转发客户端在同一台电脑上，填127.0.0.1即可；如果不在同一台，填服务端的局域网IP。第三，协议要和游戏版本对应，Java版用TCP，基岩版用UDP，两者分开配置，不要图省事写成一个。
配置写好后先在前台运行，观察日志有没有报错，确认显示“连接成功”“监听中”之类的信息，再用游戏客户端测试。前台跑通之后再改成后台服务，避免一上来就配开机自启，出了问题连日志都找不到。
3.4 开机自启与日志查看
中转机重启后程序如果没起来，朋友就会突然连不上，所以开机自启要配好。常见做法是写一个systemd服务单元，把启动命令、工作目录、运行用户写进去，然后systemctl enable加systemctl start。写单元文件时注意Restart=on-failure，程序异常退出能自动拉起，省得半夜掉线没人管。
日志方面，建议把标准输出重定向到固定文件，并用日志轮转控制大小，别让一个日志文件涨到几个G把磁盘撑满。查看日志时重点看三类信息：启动时有没有绑定端口失败、运行中有没有大量连接超时、退出前有没有内存或权限相关报错。这三类基本覆盖了八成问题。
内网侧的那台电脑同样要配自启，尤其是家里电脑偶尔重启的情况。可以把转发客户端做成计划任务或服务，开机自动连上中转机。家里路由器最好也给游戏电脑保留固定地址，减少变量。
4. 游戏服务端配置与联机验证
4.1 Java版服务端最小配置
Java版服务端启动后会生成server.properties，里面有几项和联机直接相关。server-port是监听端口，默认25565，如果你打算让转发程序转到本机，保持默认也行，改的话记得同步改转发配置。online-mode控制正版验证，公开服建议保持开启，熟人小圈子如果都是正版玩家也建议开启，减少冒名顶替的风险。white-list建议设为true，配合白名单文件只放行熟人。max-players按实际人数设置，别开太大。view-distance和simulation-distance直接影响性能，人少可以适当调高，机器弱就调低，别盲目拉满。
启动命令里要分配足够内存，比如-Xms2G -Xmx2G，具体看机器内存和玩家人数。内存太小会频繁卡顿甚至崩溃，太大又浪费。第一次启动建议看日志确认“Done”出现，表示服务端加载完成。如果卡在生成世界或者报端口占用，先解决再继续。
4.2 白名单、正版验证与权限
白名单的用法是先在控制台执行whitelist on，再用whitelist add 玩家ID逐个添加。注意玩家ID区分大小写，填错了对方就进不来。正版验证开启时，玩家必须使用正版账号登录，这对小圈子来说更省心，不用额外装验证插件。如果确实有朋友使用离线账号，需要关闭正版验证，但一定要配合白名单和访问控制，别把端口公开给所有人。
权限方面，普通玩家不需要给OP。需要建筑或者调试时临时给，用完就撤。OP权限过大，误操作能直接把存档搞坏。建议至少保留一份自动备份，后面会讲。
4.3 基岩版与Java版的差异处理
基岩版走UDP，端口默认19132，服务端程序也和Java版不同。如果你要同时支持两个版本，最省事的做法是分别开两个服务端，分别配转发规则，而不是指望一个端口通吃。手机上玩的朋发连接时填中转机地址加端口，注意基岩版客户端对地址格式比较敏感，别多打空格或者漏掉端口。
还有一种情况是跨版本互通，需要额外的互通层，配置更复杂，延迟也会增加。小圈子建议统一版本，少折腾。
4.4 让朋友连进来的三种方式
第一种是直接填中转机公网地址加端口，比如中转机IP:30000，这是最直接的方式。第二种是用域名，把域名解析到中转机，朋友填域名加端口，好处是换机器时不用通知所有人改地址。第三种是通过游戏内的“添加服务器”保存书签，把地址存下来，下次直接点。无论哪种，第一次连接前先让朋友用网络测试工具确认能通到中转机端口，能省掉大量“我这边连不上”的扯皮。
验证顺序建议是：本机先连127.0.0.1确认服务端正常；再用中转机本地地址连一次确认转发程序正常；最后让朋友从外部连。逐层验证，出了问题能立刻定位是哪一段。
5. 常见问题排查实录
5.1 连接超时与握手失败
连接超时通常出在网络层：安全组没开、防火墙没放行、端口写错、中转程序没监听。排查时先在服务器上用ss -lntup确认端口处于LISTEN状态，再从外部用nc或在线端口检测工具测。如果外部不通而本机通，重点查安全组和防火墙。握手失败则多半是协议不匹配，比如客户端走TCP、转发配了UDP，或者游戏版本和服务端版本差太多。看日志里有没有“protocol error”“unexpected packet”之类的关键词，能快速缩小范围。
还有一种隐蔽情况：中转机和内网侧都正常，但家里电脑的局域网IP变了，转发目标指向了一个不存在的地址。表现就是中转机日志显示连接建立后立刻断开。解决办法是给游戏电脑固定IP，或者用主机名代替IP，减少变动。
5.2 进去了但卡顿、方块回弹
能进游戏但体验差，先分清是延迟问题还是带宽问题。按F3看延迟数值，如果延迟持续偏高，说明路径绕远或者中转节点不合适，考虑换节点。如果延迟不高但频繁回弹、方块挖了又出现，多半是上行带宽被占满或者服务端性能不足。检查家里宽带上行是否被其他程序占用，比如网盘同步、视频上传；检查服务端日志有没有“Can't keep up”提示，有的话降低视距、减少实体、增加内存。
中转机带宽被打满也会造成类似现象。云主机控制台一般能看到带宽监控，对照游戏时段看曲线，如果持续贴着上限，就该升级带宽或者限制人数。
5.3 掉线、内存溢出与服务端崩溃
偶发掉线先看中转机日志和游戏服务端日志的时间点是否对得上。如果中转机先报连接重置，问题在网络；如果服务端先报异常，问题在游戏侧。内存溢出常见于模组较多或者区块加载量大的存档，表现是运行一段时间后突然卡死然后退出。解决方向是加内存、减模组、限制视距，以及设置定时重启。
崩溃后别急着重开，先保留日志。日志里搜索“Exception”“Error”“OutOfMemory”能快速定位。养成崩溃前自动备份的习惯，比事后补救有用得多。
5.4 排查速查表
| 现象 | 优先检查 | 常见原因 | 处理方向 |
|---|---|---|---|
| 连接超时 | 安全组、防火墙、端口监听 | 端口未放行或程序未启动 | 逐层测试连通性 |
| 握手失败 | 协议类型、版本号 | TCP/UDP配错、版本不匹配 | 对照日志改配置 |
| 能进但卡顿 | 上行带宽、延迟、服务端负载 | 带宽占满、视距过高 | 降视距、升带宽、限人数 |
| 频繁掉线 | 中转日志、服务端日志 | 网络抖动、内存不足 | 查时间点、加内存 |
| 昨天能连今天不能 | 局域网IP、端口占用 | DHCP重新分配、程序未自启 | 固定IP、配自启 |
6. 安全运维与长期使用心得
6.1 最小权限与访问控制
中转机暴露在公网，最基本的几条要守住：管理端口不对外网开放，只允许自己的地址访问；认证令牌定期更换；转发程序用普通用户运行；系统补丁及时更新。游戏侧开启白名单，别为了方便把online-mode关了又不设限制。端口可以选高位随机值，减少被自动扫描命中的概率，但这只是降低噪音，不能替代访问控制。
如果发现日志里有大量陌生地址尝试连接，说明端口被扫到了。处理方法很简单：换端口、更新令牌、检查白名单，必要时在安全组里限制来源地址段。别慌，也别去研究对方是谁，把入口收紧就行。
6.2 备份与更新节奏
存档是这类项目里最值钱的东西。建议至少每天自动备份一次，保留最近七到十四天的版本，备份文件放到另一块磁盘或者另一台机器上。手动备份也很重要，在装新模组、改配置、给OP权限之前先备一份，出问题能回滚。
更新方面，游戏服务端、转发程序、系统组件都不要追最新。先在测试环境跑一遍，确认存档能加载、朋友能连上，再切到正式环境。更新前看一遍变更说明，重点看有没有配置格式变化，很多“更新完连不上”都是字段改名导致的。
6.3 成本控制与替代方案
一台低配云主机按月计费，成本通常不高，但如果只是周末玩几个小时，可以考虑按量计费或者用更轻量的方案。替代思路包括：用官方联机服务按需开房间；用虚拟局域网工具临时组网；或者把服务端放在一台常开的低功耗设备上，只在需要时开启中转。选择哪种，取决于你玩的频率和对存档控制权的要求。
我自己折腾下来，最深的体会是别把联机当成一次性任务。网络环境会变，IP会变，程序会更新，朋友的时间也对不上。把配置写成文档、把备份做成自动、把排查步骤记下来，下次出问题能少花一半时间。还有一个小技巧：给中转机和游戏服务端各建一个简单的状态检查脚本，定时看端口和进程，异常时给自己发个提醒，比等朋友来问“怎么又连不上”要主动得多。
