サーバーを分ける構成

対象は Java 版のサーバーです。設定の名前は、2026 年 10 月時点の PaperMC と Velocity のドキュメントによります。

プロキシで 1 つの接続先にまとめる

参加する方は、1 つのアドレスに接続するだけで、複数のサーバーの間を移動できます。間に入るのがプロキシの Velocity です。Velocity は PaperMC が開発しているプロキシで、以前の BungeeCord や Waterfall に代わって使われています。

Velocity の README は、1 つのプロキシで数千人を扱うことを目標に掲げています。バックエンドサーバー (プロキシの先で、ワールドを動かすサーバー) は、それぞれが 1 つのスレッドでワールドを計算するため、サーバーを分けるほど、全体で使えるコアが増えます。

プレイヤーの情報を渡す設定

Velocity は、参加する方の情報 (UUID、IP アドレス、スキン) を、バックエンドサーバーに渡します。渡し方は、安全な「modern」を使います。Velocity が作る forwarding.secret の値を、バックエンドサーバーと一致させます。

# velocity.toml
player-info-forwarding-mode = "modern"

# バックエンドサーバー(Paper)の server.properties
online-mode=false

# バックエンドサーバー(Paper)の spigot.yml
settings:
  bungeecord: false

# バックエンドサーバー(Paper)の config/paper-global.yml
proxies:
  velocity:
    enabled: true
    online-mode: true          # velocity.toml の online-mode と合わせる
    secret: "forwarding.secret の値"

バックエンドサーバーは online-mode を切るため、プロキシを通さずに直接接続できる状態にしてはいけません。直接接続できると、ほかの人になりすまして参加できてしまいます。バックエンドサーバーは、プロキシからの接続だけを受け付けるよう、ファイアウォールやネットワークで分けます。

分け方

役割で分ける

ロビー、ミニゲーム、イベントの会場など、役割ごとにサーバーを分ける方法です。もっとも確実で、大規模なサーバーの多くがこの形です。1 つのワールドに入れる人数の上限は、そのサーバー 1 台の性能で決まります。

同じワールドを複数用意する

同じ内容のワールドを複数のサーバーに用意し、人数で振り分ける方法です。MMORPG のサーバー Wynncraft は、1 つのワールドを 50 人までとして、多くのワールドに分けています (大規模な運営の例)。

ディメンションごとに分ける

オーバーワールド、ネザー、ジ・エンドを、それぞれ別のサーバーで動かす方法です。1 台のサーバーでは 3 つのディメンションを同じスレッドで順番に計算するため、分けると、それぞれのディメンションが 1 つのスレッドを使えます。

構築のときは、次の点に対応します。

• ディメンションを無効にする: オーバーワールドのサーバーでは、ゲームルールの allow_entering_nether_using_portals を false にし (1.21.8 までは server.properties の allow-nether=false)、Paper の bukkit.yml の allow-end: false でジ・エンドを読み込まないようにする
• ポータルでの移動: ポータルに入ったことをプラグインで検知し、プロキシを通して別のサーバーへ送る。戻るときの出現の位置も決めておく
• プレイヤーの状態の同期: インベントリ、体力、経験値、エフェクトを、サーバーの間で引き継ぐ。HuskSync のような同期のプラグインは、MySQL などのデータベースと Redis を使う (MySQL との連動)
• ゲームの仕組みの違い: ネザーとオーバーワールドの座標の対応 (1 対 8) によるポータルのつながり、エンダードラゴンの討伐の状態、エンダーパールなどのサーバーをまたぐ動きは、そのままでは引き継がれない。企画に必要な範囲を決めて対応する

Java 版 1.20.5 からは、サーバーがプレイヤーを別のサーバーに移す仕組み (/transfer コマンドと転送のパケット) も、ゲームに組み込まれています。移動先のサーバーでは、server.properties の accepts-transfers を true にします (既定は false)。プロキシを使わない構成の選択肢になりますが、移動先のサーバーへの接続をやり直すため、プロキシでの移動に比べて切り替えに時間がかかります。

1 つのワールドを分けて計算する

全員が同じワールドに集まる企画で、ワールドそのものを分けて計算する方法です。

チャンクごとに別のサーバーで計算する方法は、1 台の限界を超えられる一方で、サーバーの間の同期の遅れや、境目をまたぐモブとレッドストーン回路の扱いなど、難しさも増えます。同じ考え方の WorldQL Mammoth は、負荷の試験で 600 を超える接続で停止し、現在は開発を終えています。本番の企画では、事前に同じ規模で試してから使います。多くの場合は、役割やディメンションで分ける構成と、設定の調整を組み合わせるほうが確実です。

複数のサーバーにする難しさ

• データの共有: 権限、インベントリ、ランキングなど、サーバーをまたいで使うデータは、データベースにまとめ、どのサーバーからも同じ値を読めるようにする
• サーバーの間の移動: 移るときにプレイヤーの状態を引き継ぎ、移動中の失敗や、アイテムが増える・消えるといった不整合が起きないようにする
• プラグインの対応: プロキシとバックエンドサーバーの両方に入れるプラグインがある。バックエンドサーバーのバージョンもそろえる
• 運用の手間: 更新、監視、バックアップの作業が、サーバーの数だけ増える。立ち上げと更新を自動化しないと、運用が追いつかない
• プロキシを複数にする場合: プロキシの間でプレイヤーの情報を共有する仕組みが必要になる。LuckPerms のドキュメントは、プロキシが複数のときは Redis での連絡を勧めている

統合版の参加

スマートフォンや家庭用のゲーム機の統合版 (Bedrock) から参加できるようにするには、Geyser を使います。Velocity を使う構成では、Geyser は Velocity にだけ入れます。Floodgate を使うと、Java 版のアカウントがない統合版の方も参加できます。

Geyser は、既定では UDP の 19132 番 (RakNet) で統合版の接続を受けます。Java 版は TCP の 25565 番です。統合版の通信の方式は NetherNet への移行の途中のため、導入の前に、最新の公式の情報を確認します (ポートと通信)。Cloudflare Spectrum は統合版に対応していないため、統合版の接続の保護は別に考える必要があります (Cloudflare Spectrum での保護)。Geyser が対応する Minecraft のバージョンは限られるため、Java 版のサーバーのバージョンを上げる前に確認します。

参考にした資料

• Velocity (GitHub)
• Player information forwarding (Velocity)
• Commands/transfer (Minecraft Wiki)
• Server.properties (Minecraft Wiki)
• Bukkit configuration (PaperMC)
• Folia (GitHub)
• MultiPaper (GitHub)
• ShreddedPaper (GitHub)
• WorldQL Mammoth (GitHub)
• HuskSync (GitHub)
• Network Installation (LuckPerms)
• Setup (GeyserMC)

• 記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
• 記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
• 記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
• 技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。