【2026年1月最新】BungeeCordネットワーク完全構築ガイド – config.yml設定からサーバー接続数制限まで

はじめに

こんにちは！マイクラサーバー運営の経験を踏まえつつ、複数のマイクラサーバーを効率的に管理できる「BungeeCord（プロキシ）」について、初心者の方にも分かりやすく解説します。

海外の大型サーバーのように、複数のワールド／ゲームモードを行き来できる仕組みは「プロキシネットワーク」で実現できます。本記事では、config.yml設定、接続数制限（上限・スロット・スロットリング）、Waterfallとの比較（開発終了）、IPフォワード（プレイヤー情報転送）まで、画像付きでまとめます。

※本記事は2026年1月時点の情報に基づいて更新しています。料金・仕様・配布形態は変更される場合があるため、必ず公式情報も併せてご確認ください。

この記事で学べること

• BungeeCordネットワークの基本概念と仕組み
• config.ymlの主要設定と編集ポイント
• サーバー接続数制限（上限・スロットリング）の考え方
• WaterfallとBungeeCordの違い（WaterfallはEOL）
• IPフォワード（プレイヤー情報転送）の重要性と設定
• おすすめVPS比較（宣伝・アフィリンクは維持）

BungeeCordとは？基本概念を理解しよう

BungeeCordの基本概念

BungeeCordは、複数のマインクラフトサーバーをつなげて1つのネットワークとして見せるプロキシサーバーです。プレイヤーは1つのアドレスで接続し、ゲーム内でサーバー間（ロビー→サバイバル→ミニゲーム等）を移動できます。

BungeeCordの特徴

• プロキシ機能：プレイヤー接続を中継し、複数サーバーへルーティング
• 統一アクセス：ユーザーは基本的に「入口（プロキシ）」だけを覚えればOK
• 負荷分散：役割ごとにサーバーを分割し、運用を安定化しやすい
• 実サーバーのIP/ポートを隠しやすい：バックエンドを外部非公開にして防御を固められる
• プラグイン：BungeeCord向けのプラグインでネットワーク運用を拡張可能

BungeeCordネットワークの仕組み

BungeeCordネットワークは主に次の要素で構成されます。

要素	役割	必要性
BungeeCord（プロキシ）	入口・中継役（ユーザーが接続する先）	必須
ロビー（Hub）	初回接続・待機・サーバー選択の拠点	推奨
ゲームサーバー群	サバイバル／建築／ミニゲーム等の実プレイ	必須（1台以上）

注意：ネットワークとして動かすだけなら、最低でもプロキシ1台＋バックエンド1台（合計2系統）で成立します。一般的な「ネットワークらしい運用（ロビー＋複数ゲーム）」では、プロキシ＋ロビー＋ゲームのように3系統以上に分ける構成が多いです。

BungeeCordネットワークの構築手順

構築の準備

BungeeCordネットワークを構築する前に、次を準備してください。

• Java実行環境：BungeeCord（プロキシ）とバックエンド（Paper/Spigot等）で必要
• サーバー環境：VPS/専用サーバー（複数台でも、1台で複数ポート運用でも可）
• バックエンド（Paper/Spigot等）：先に単体で起動確認しておく

なお、Minecraft Java版のサーバー運用では、バージョンによって必要なJavaが変わります。例として、Minecraft Java版 1.18以降はJava 17が必要になります（バックエンド側）。運用するMinecraftのバージョンに合わせてJavaを選んでください。

BungeeCordのダウンロード

最新版のBungeeCordは、Jenkins（CI）で配布されています。

BungeeCord公式ダウンロードページ（Jenkins）

起動スクリプトの作成

BungeeCord（例：BungeeCord.jar）を配置し、起動用スクリプトを作成します。

Windows用（start.bat）

@echo off
java -Xms512M -Xmx1G -jar BungeeCord.jar nogui
pause

Linux用（start.sh）

#!/bin/bash
java -Xms512M -Xmx1G -jar BungeeCord.jar nogui

メモリ割り当ての目安（プロキシ）

• 小規模：512MB〜1GB
• 中規模：1GB〜2GB
• 大規模：2GB〜（同時接続数・プラグイン次第）

config.yml詳細設定ガイド

config.ymlの基本構造

BungeeCordの設定は、初回起動後に生成されるconfig.ymlを編集して行います。

主要設定項目の解説

設定項目	説明	推奨
listeners（配下のhost等）	待受IP/ポート、MOTD、接続挙動などをまとめて管理	運用に合わせて調整
ip_forward	プレイヤーのIP/UUID等をバックエンドへ転送する（後述）	true（一般的なネットワーク運用では必須）
online_mode	プロキシ側でMojang認証を行うか	true（通常運用）
player_limit	プロキシ経由の最大接続数（全体上限）	サーバー性能と設計に応じて
connection_throttle / connection_throttle_limit	接続スロットリング（短時間の連続接続を抑制）	後述の目安を参照

サーバー設定（serversセクション）の例

serversセクションでは、ネットワークに参加するバックエンドサーバーを定義します。

servers:
  lobby:
    motd: '&6ようこそロビーサーバーへ！'
    address: 127.0.0.1:25566
    restricted: false
  survival:
    motd: '&aサバイバルサーバー'
    address: 127.0.0.1:25567
    restricted: false
  creative:
    motd: '&bクリエイティブサーバー'
    address: 127.0.0.1:25568
    restricted: false
  pvp:
    motd: '&cPvPサーバー'
    address: 127.0.0.1:25569
    restricted: true

パラメータ	説明	例
motd	サーバー説明文（色コード使用可）	&6ようこそロビーサーバーへ！
address	バックエンドの接続先（IP:ポート）	127.0.0.1:25566
restricted	権限のないユーザーの接続を制限する	true / false

接続順序（priorities）の設定

prioritiesセクションで、初回接続時やキック時などの接続先優先順位を設定できます。

priorities:
- lobby
- survival
- creative

設定のベストプラクティス

• ロビー（hub）を最優先に設定
• 特殊サーバー（PvP等）はrestrictedをtrueにして、権限で制御
• サーバー名は英数字・短め推奨（運用で混乱しない）
• バックエンドは外部から直接接続できないように設計（後述のセキュリティ）

サーバー接続数制限の設定方法

接続数制限の基本設定

BungeeCordでは、ネットワーク全体の上限としてplayer_limitを設定できます（プロキシ経由の最大接続数）。

# BungeeCord config.yml（例）
player_limit: 100

一方で、バックエンド側（各サーバー）には、サーバーごとのスロット（最大人数）としてserver.properties の max-playersで制御するのが基本です。サーバーごとに人数を分けたい場合は、バックエンド側のmax-playersを用途別に調整してください。

# 各バックエンド server.properties（例）
max-players=40

同一IPからの接続制限（スロットリング）

短時間に同一IPから接続が連打されると、負荷や不正接続（ボット等）の原因になります。BungeeCordには接続スロットリングとして、connection_throttleやconnection_throttle_limitが用意されています。

# BungeeCord config.yml（例）
connection_throttle: 4000          # ミリ秒
connection_throttle_limit: 3       # 同一IPからの接続試行上限（短時間）

設定項目	説明	目安
connection_throttle	接続試行の最小間隔（ミリ秒）	4000〜10000
connection_throttle_limit	同一IPからの短時間接続の上限	3〜5

プラグインによる高度な制限

より柔軟に制限したい場合、BungeeCord向けプラグインを併用します（例：同一IP同時接続の上限、特定ユーザーの除外、メッセージ変更など）。

プラグイン名	機能	用途
AddressLimit	同一IPからの接続人数を制限	多重ログイン・ボット対策
IPLimiter	同一IPの同時接続数を制限（除外設定等）	負荷対策・乱用抑止
BungeeTabListPlus	タブリストをネットワーク全体で管理	サーバー別表示・スタッフ枠表示など
OnlyProxyJoin	指定の入口以外からの参加を抑止（構成次第）	直叩き対策の補助

補足：セキュリティ面では、バックエンドをファイアウォールでプロキシからの接続だけ許可するのが王道です。加えて、構成によってはBungeeGuard等の対策も検討すると安全性が上がります（後述）。

Waterfall vs BungeeCord 徹底比較

重要：WaterfallはPaperMCによりEOL（End of Life：サポート終了）が告知されています。新規構築では、基本的にVelocityまたはBungeeCordを前提に設計するのが現実的です。

基本的な違い

WaterfallはBungeeCordの派生として使われてきましたが、現在はEOLです。ここでは運用目線で比較します。

項目	BungeeCord	Waterfall
開発状況	SpigotMCにより継続	EOL（サポート終了）
互換性	Bungee向けプラグインが中心	（EOLのため将来的な追従は期待しにくい）
推奨	安定性重視の選択肢	新規は非推奨

BungeeCordの利点

• 長年の運用実績と安定性
• 豊富なプラグイン資産
• 導入事例が多く、情報を探しやすい

BungeeCordの欠点

• 設計が古く、最新のセキュリティ機構（VelocityのModern Forwarding等）と比べると工夫が必要
• ネットワーク規模が大きいほど、権限・転送・監視など運用設計が複雑になりがち

2026年の推奨選択

• 1位：Velocity（モダン設計・プレイヤー情報転送が強固。新規ネットワークで採用例が多い）
• 2位：BungeeCord（安定性・既存プラグイン資産重視）
• 3位：Waterfall（EOLのため新規は非推奨）

IPフォワード設定の重要性

IPフォワーディングとは

IPフォワーディング（プレイヤー情報転送）は、プロキシが受け取ったプレイヤーのIPアドレスやUUID等を、バックエンドサーバーへ正しく渡す仕組みです。これが正しくないと、ログ・BAN・権限などが意図通りに動かない原因になります。

BungeeCord側の設定

BungeeCordのconfig.ymlで、IPフォワードを有効にします。

# BungeeCord config.yml（例）
ip_forward: true
online_mode: true

バックエンドサーバー側の設定（Paper/Spigot）

バックエンド側は、プロキシ前提の設定に切り替える必要があります（「入口はプロキシのみ」という設計とセットで考えます）。

server.properties

# すべてのバックエンドサーバーで設定（例）
online-mode=false

spigot.yml（Spigot/Paper系）

settings:
  bungeecord: true

Paper 1.19+（config/paper-global.yml の例）

Paperでは、グローバル設定としてプロキシ関連をpaper-global.ymlのproxies配下で管理します。BungeeCord配下のonline-modeは、プロキシ側のonline_modeと一致させてください。

proxies:
  bungee-cord:
    online-mode: true

Velocityを採用する場合：Paper側はVelocityのModern Forwardingを使う設定（secret等）が別途必要になります。BungeeCord前提の設定（settings.bungeecord）と干渉するため、Velocity運用時はPaperMC Docsの手順に従って調整してください。

セキュリティ注意点

バックエンドをonline-mode=falseにする以上、バックエンドへ外部から直接入られるとリスクになります。次を必ず実施してください。

• ファイアウォールでバックエンドのポートを閉じ、プロキシからの接続だけ許可する
• 必要に応じてBungeeGuard等の追加防御（トークン等）も検討する

設定確認方法

確認方法	期待される結果
権限・BANの挙動	ネットワーク全体で想定通りに動作する
ログ（接続IP等）	プロキシIPではなく、プレイヤー情報が適切に扱われる
エラーメッセージ	「IP forwardingを有効にせよ」等が出ない

おすすめVPS比較【2026年1月最新】

BungeeCord（またはVelocity）ネットワークに適したVPSサービスを紹介します。複数サーバーを安定運用するため、メモリ・CPU・回線品質・バックアップ等の観点で選びましょう。

※料金は2026年1月時点の公式表示を参考に記載しています。キャンペーンや契約期間で変動する場合があります。