我的世界服务器怎么搭2个bc，核心答案是同时运行两个互相独立的BungeeCord代理实例，各自监听不同端口，分别接入不同子服，软件本身免费，不需要额外买任何付费插件。这个方案适合玩家数量较大的服务器，用来分流、分区或者做负载均衡，下面我会从原理、配置、子服接入、常见问题四个层面拆开讲，每一步都有实际操作命令和路径。
我的世界服务器怎么搭2个bc？先理解两个BC的分工
BungeeCord本质是一个反向代理,玩家先进BC，再由BC把连接转发给后端的生存服、空岛服、小游戏服，搭两个BC，不等于让两个BC去抢同一个子服，而是给它们分配不同的子服组，或者让它们分别负责不同玩家群的连接入口。
多数情况下,双BC是这样用的：
- 一个BC负责主城、生存等常驻玩法，使用默认的25565端口，玩家进服首选这个地址。
- 另一个BC负责活动服、小游戏服，监听另一个端口比如25566，通过新手指引或者分流插件把玩家带过去。
- 两个BC之间不互通数据,但共用同一个玩家数据库，比如MySQL，这样玩家在两边看到的数据是一致的。
如果你只是希望“两个BC互备”，也就是一个挂了另一个还能进，那么可以做成相同子服列表的两个BC实例，玩家通过不同域名或不同IP访问，这种方式在配置上是一样的，区别在于两个BC的config.yml里监听端口不同，后端子服地址相同。
搭建两个BC的关键操作：环境、下载、端口配置
我的世界开服配置bc端口需要什么环境
行业共识认为,BungeeCord对服务器配置要求远低于子服，但它需要独立的内存和Java环境，双BC建议至少给每个实例分配512MB内存，具体看你服务器总内存，如果只在本地用来测试，一台电脑开两个BC和若干子服也是可行的。
准备清单：
- 安装Java 8或更高版本，推荐Java 11，兼容大多数BungeeCord构建。
- 从SpigotMC官网下载BungeeCord.jar，不建议用来源不明的魔改版本。
- 准备好两个文件夹,例如bc1和bc2，分别存放两个BC的文件。
- 如果你的服务器在云端,注意安全组或防火墙要放行对应端口。
国内服务器搭建bc要花钱吗
软件层面完全免费,BungeeCord遵循开源协议，官方构建不需要购买，国内服务器搭bc要花钱的部分只有云主机、带宽、域名备案等基础设施，一台2核4G的内存服务器，用国内厂商活动价买，通常足够支撑BC加几个轻量子服，如果你已有子服，只是加两个代理实例，纯硬件开销几乎可以忽略。
手把手配置两个BC的config.yml
第一步：复制并修改监听端口
进入bc1文件夹,运行一次BungeeCord.jar生成默认配置，然后编辑config.yml，找到listen节点，默认是0.0.0.0:25565，保留即可，bc2的config.yml中改成：
listen: 0.0.0.0:25566这样两个BC就有了各自的入口端口,注意，如果子服端口刚好也在25565，会冲突，确保端口全局唯一。
第二步：添加子服到server列表
在config.yml的servers段下面，按以下格式添加你的后端子服，使用的是子服实际监听端口：
servers:
lobby:
address: 127.0.0.1:25570
restricted: false
survival:
address: 127.0.0.1:25571
restricted: falsebc1用来带主城和生存,bc2用来带活动服和小游戏服，两个BC完全可以配置不同的server列表，也可以配置相同的，看你的分流策略。
第三步：开启ip_forward和online_mode
为了让子服能看到玩家真实IP,并避免UUID问题，两个BC的config.yml里都要设置：
ip_forward: true子服端的spigot.yml或者paper-global.yml里也要同步开启bungeecord模式，把online-mode设为false，子服不直接暴露公网，只允许BC转发来的连接。
第四步：分别启动两个BC
在bc1目录下执行：
java -Xms512M -Xmx1024M -jar BungeeCord.jarbc2目录下同样执行,只是启动命令里的-Xmx可以根据需要调整，两个BC会同时运行，控制台日志里分别输出Listening on /0.0.0.0:25565和Listening on /0.0.0.0:25566。
如果你用的是面板,比如宝塔或翼龙面板，直接在面板里创建两个Java实例，启动命令写入上述JAR路径即可，面板方式更适合国内服务器搭bc，因为端口管理和进程守护更省心。
双BC模式下后端子服的具体接入流程
子服与BC的对应关系怎么规划
把子服归类到两个BC下,最清晰的方案是给每个BC分配独立的一组子服，比如bc1管辖子服列表为lobby、survival、skyblock，bc2管辖列表为event、bedwars、practice，玩家进入不同端口后，只能看到对应BC管辖范围内的子服。
具体在config.yml里修改方式：
- bc1的servers节点写上自己那组子服的地址。
- bc2的servers节点写上自己那组子服的地址。
- 如果想让玩家通过bc1跳到bc2的子服,需要把目标子服同时加入两个BC的列表，但这样会造成同一个子服被两个代理监听，容易产生重复连接。
为了避免混乱,建议只在双BC共用一个中转子服时使用重复配置，其余子服严格分开，这样一个BC重启或故障时，影响范围被限制在该BC管辖的子服群内，不会拖垮全部玩家生态。
子服安装与核心设置
后端子服需要先安装Paper或Spigot,然后在服务端配置文件里启用BC支持，Paper核心中要编辑paper-global.yml，找到bungeecord相关选项并打开，位置通常在：
settings:
bungee:
online-mode: false
server: 根据你的实际设置Spigot的话,在spigot.yml中设置bungeecord: true，这个过程需要同步修改所有子服，漏掉一个就会导致玩家进子服时被踢回BC，提示“Can’t connect to server”。
双BC的玩家数据统一
两个BC各自运行,但玩家注册数据、背包数据、经济数据都要共用同一套文件，推荐把这些数据全部放到外部MySQL数据库，然后子服和BC插件都读取同一个库，以LuckPerms权限插件为例，在plugin.conf里设置同一个数据库连接地址和库名，双BC环境下权限就自然同步了。
如果用本地文件型数据,两个BC之间会出现控方双雄问题，比如玩家在bc1生存服里抢到下界，在bc2活动服里却看到旧数据，严重破坏游戏体验。
两个BC独立运行后的性能观察与对比
多bc与单bc哪个更稳定，哪个划算
单BC的好处是玩家之间可以在同一个网络上互相串联,数据流都在一根管道里，不需要额外管理，但单BC同时在线超过一定人数后，主线程的队列处理会变慢，玩家会感受到卡顿和连接超时。
多BC把玩家拆散到不同代理上,每个BC只处理一部分连接，稳定性更好，代价是需要多占一块内存，以及处理玩家跨BC时的数据同步，比如玩家在bc1的主城，想传送到bc2的活动服，直接runcmd是跨不过去的，得写专门的插件或通过后端子服间通讯。
划算角度：双BC并不会增加额外授权费，但你需要内存预算，如果你的总在线人数在100人以下，一个BC足够；如果常驻在线能有200人以上，或者同一时间有大量玩家频繁跳服，双BC的稳定性优势就体现出来了，简单判断标准是BC控制台频繁刷Connection info日志，同时子服TPS正常的情况下玩家仍觉得延迟高，就说明BC本身该分流了。
观察BC状态与调整内存
两个BC实例同时运行,建议在启动命令中固定最小堆和最大堆，避免JVM动态申请内存时出现抖动，比如bc1和bc2都使用：
java -Xms512M -Xmx768M -jar BungeeCord.jar这样每个BC最多占用768MB,双BC合计约1.5GB，如果子服也在同一台云主机，要注意总内存不能超限，可以定期在控制台执行gstats，查看当前内存和线程状况。
如果你觉得BC响应慢,但子服TIPS正常，优先检查是不是BC的堆内存太小，频繁触发Full GC，调整时逐步增加Xmx值，每增加256MB观察半天，不要一次性翻倍，避免影响同机其他进程。
双BC搭建常见问题与优化
端口冲突和防火墙导致连不上
两个BC发现其中一个启动报错Address already in use，说明端口被占用，用命令查看占用关系：
netstat -anp | grep 25566找到占用进程后,要么改BC的listen端口，要么杀掉占用进程，如果是云服务器，还要检查安全组的入站规则是否放行了25566端口，很多情况下BC本身没配置错，就是防火墙挡住了。
BC延迟高，子服却正常
BC转发依赖子服的连接池和压缩设置,在config.yml里检查connection_throttle，默认4000，单位是毫秒，意思是新连接4秒内重复连接会被拒绝，如果你的服务器有玩家频繁掉线重连，把这个值调小到1000，或者设置connection_throttle_limit为3。
子服和BC运行在同一台机器时,建议都使用127.0.0.1作为内部地址，这样走的是本机回环，速度最快，如果跨机房，内网IP延迟会明显影响BC和子服之间的通信。
两个BC如何共用MOTD和玩家列表
双BC公开展示时会同时展示两个不同的MOTD,如果你不希望玩家迷糊，可以在BC配置中修改motd和online_mode设置，玩家列表的合并需要用到RedisBungee这类插件，它能把多个BC节点的在线玩家聚合到一个虚拟列表中，国内服务器搭bc时很多团队也选择这种方式，一次配置后双BC就像一个大代理，玩家完全没有感知。
Q&A：我的世界服务器怎么搭2个bc时容易踩的坑
两个BC能不能共用同一个数据库
可以,两个BC的玩家数据共同读写同一个MySQL或Redis，注意表前缀要统一，否则可能导致数据覆盖，玩家在线状态建议用Redis做缓存，BC本身不含同步逻辑，用外部存储解决双BC下的玩家数据一致性问题。
双BC环境下玩家跨服怎么操作
常规的跨服是同一个BC下面的子服通过config.yml中的servers地址跳转，使用/custom命令，如果玩家需要从bc1的子服跳到bc2的子服，BC之间没有直接互传接口，解决办法是让两个BC都连接一个公共“中转子服”，把中转服同时配置在两个BC的server列表中，玩家通过进入中转服后在两个BC间移动。
一个BC崩了，另一个能接管所有玩家吗
不能自动接管,BC之间没有故障转移机制，如果bc1崩溃，原先连接bc1的玩家会全部断开，要实现接管，需要依靠域名层面的健康检查，把玩家流量指向仍在工作的bc2，同时bc2的server列表里得包含bc1负责的全部子服，这个操作属于高可用架构，普通中小型服务器不需要做到这一步。
归根结底,我的世界服务器怎么搭2个bc并没有想象中复杂，关键是把两个BC当成两个独立进程分开管理，端口不冲突，子服不重复接错，数据存储统一外部化，剩下的性能问题靠观察日志逐步调整。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771807.html
