メインコンテンツまでスキップ

プロキシネットワーク（BungeeCord／Waterfall／Velocity）

ResourcePackManagerはプロキシネットワークで動作します。jarは1つだけ（ResourcePackManager.jar）で、すべてのバックエンドとプロキシに同じjarをインストールします。バックエンド上ではバックエンドの役割（マージ、ホスト、プッシュ、変換）で動作し、VelocityまたはBungeeCord／Waterfallプロキシ上では同じjarがプラットフォームローダーを自動検出してプロキシの役割（ネットワーク側のBedrock配信）で動作します。両者の役割は自動的にリンクします：プロキシがネットワークキーを保有し、プレイヤーが初めてそのバックエンドに接続したときにキーをプッシュします — プラットフォーム別のプロキシ用jarも、貼り付けるキーもありません。

このページ全体で「プロキシプラグイン」とは、プロキシの役割で動作しているその同じ ResourcePackManager.jar を指す略語です。

プロキシプラグインの役割​

プロキシプラグインの仕事は、Bedrockパックのマージと配信です。複数のバックエンドがあるネットワークでは、各バックエンドが独自のBedrockパック（マージされたJavaパックの変換版）を生成します。プロキシプラグインは：

  1. 各バックエンドの小さなHTTPサーバーから /bedrock.zip と /mappings.json を5秒ごとにポーリングします。強いETagと If-None-Match を優先しつつ、古いバックエンドとの互換性のために If-Modified-Since も維持します。変更のないファイルは 304 を返すため、帯域コストはほぼゼロです。各バックエンドは実際にバインドした正確なHTTPポートを通知するため、プロキシは通常そのポートに自動的にヒットします（バックエンドのHTTPポート解決を参照）。
  2. インボックスの状態が安定するのを待ちます — 連続する2回のポーリングが同じファイルハッシュの集合を観測した時点でマージします。
  3. すべてのバックエンドのBedrockパックを1つのネットワーク全体パックにマージします。
  4. アイテムマッピングが存在する場合、マージされたGeyserカスタムマッピングファイルをプロキシの plugins/Geyser-*/custom_mappings/ にコピーします。
  5. 接続時にGeyserの SessionLoadResourcePacksEvent を通じてマージされたパックをBedrockクライアントに配信します。

プロキシプラグインはBedrockプレイヤーにのみ有用です。 ネットワーク上のJavaパック配信は、依然として通常の setResourcePack ／ addResourcePack API を通じてバックエンドごとに行われます — Javaクライアントには、接続中のバックエンドが送ることを選んだパックが表示されます。ネットワークがJava専用なら、プロキシプラグインは不要です。

セットアップ — 1ステップ（Bedrockが必要ならFloodgateも）​

Floodgate​

FloodgateはBedrockプレイヤーがプロキシで認証するために必要です。RSPMがプロキシとバックエンドをリンクするためには不要です — Java専用のネットワークなら、Floodgateがまったくなくてもプロキシプラグインを動かせます。

RSPMがプロキシで初めて起動した時点でFloodgateがプロキシにインストールされていた場合、RSPMは plugins/floodgate/key.pem から一度だけネットワークキーをシードします。そのため、既に動作していた既存のネットワークはアップグレードをまたいで同じアイデンティティを保ちます。その初回起動の後、キーはRSPM自身の network-key ファイルに置かれ、key.pem が再び読まれることはありません。

ResourcePackManager.jar をプロキシにコピーする​

jarは1つだけです。Bukkit／Paperバックエンドにインストールするのと同じ ResourcePackManager.jar が、そのままプロキシプラグインでもあります — VelocityとBungeeCord／Waterfallの実装が1つのシェードされたjarにまとめられており、実行中のプラットフォームを自動検出します。展開すべきプラットフォーム別のプロキシ用jarはありません。

プロキシにRSPMを入れないままバックエンドを起動してしまった場合でも、ダウンロードを探しに行く必要はありません。キーを持たないプロキシ配下の各バックエンドは、自身のjarのバイト単位で同一なコピーを plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar に用意し、そのパスをコンソールに出力します。そのファイルをコピーすれば、プロキシとバックエンドのバージョンが食い違うことは決してありません。

同じ ResourcePackManager.jar をプロキシの plugins/ フォルダーにコピーしてください：

プロキシソフトウェア使用するjar
VelocityResourcePackManager.jar
BungeeCordResourcePackManager.jar
Waterfall（Bungeeフォーク）ResourcePackManager.jar

これはいつでもバックエンドから /rspm status を実行して確認できます。Proxy deployment セクションに Network proxy jar: ResourcePackManager.jar と Use the same jar on Bukkit/Paper, Velocity, and BungeeCord/Waterfall. が表示されます。

プロキシを再起動します。これだけです。

編集が必須の設定もなく、貼り付けるべきキーもありません。プロキシは起動時に自らネットワークキーを確立し、各バックエンドに自動的にそれを配布します — 下記のプロキシとバックエンドがリンクする仕組みを参照してください。生成されるプロキシの config.yml に含まれるのは、後述する2つの任意設定だけです。

プロキシの最初のポーリングは起動の約2秒後に発火し、その後は5秒ごとです。単一サイクルの安定性ゲートと組み合わせると、最初のマージは、プロキシが既にコンテンツを生成している少なくとも1つのバックエンドを見ることができるようになってから約7秒後に公開されます。

プロキシとバックエンドがリンクする仕組み​

以下のすべては設定なしで行われます。ここに記載しているのは、ネットワークがリンクしないときに、この手順を知っていること自体が診断のすべてになるからです。

1. プロキシがキーを確立する。 起動時に、次の順序でちょうど1つの値を解決します：

  1. プロキシプラグイン自身のデータフォルダーにある、保存済みの network-key ファイル — 初回以降のすべての起動における定常状態；
  2. プロキシ上に plugins/floodgate/key.pem が存在する場合、そこから導出される一度限りのシード；
  3. 新たに生成されたランダムなキー。

どの分岐が走っても、結果は network-key に書き込まれ、以後は永続的に再利用されます。どれが起きたかはプロキシコンソールに表示されます（Network key loaded ✓、adopted from Floodgate key.pem、または New network key generated）。ファイルを書き込めなかった場合、プロキシは [ERROR] レベルでエラーをログ出力します — その状態は今回の起動においては致命的ではありませんが、次回の再起動で別のキーが生成され、すべてのバックエンドが黙ってリンク解除されるため、フォルダーの権限を修正してください。

2. プロキシが各バックエンドにキーをプッシュする。 プレイヤーがバックエンドに接続するとすぐ、プロキシは rspm:network プラグインチャンネル経由でそのバックエンドにキーを送ります。この向きは意図的なものです：プレイヤー自身のクライアントが登録していないチャンネルではプロキシがプラグインメッセージを転送しないため、バックエンドから要求することは物理的に不可能なのです。

3. バックエンドが受け取って永続化する。 バックエンドはキーを data.yml に保存し、Network key received from the proxy; this backend is now linked. と報告します。付与が受け入れられるのは、バックエンドがまだキーを持っていない間だけです — 既に確立済みのバックエンドは警告をログ出力して現在のキーを保持し、メッセージによって別のネットワークへ向け直されることを拒みます。

モダン転送を使うVelocityでは、付与はプロキシの forwarding.secret に対するHMACで署名され、モダン転送用に構成されたバックエンドはその署名を必須とします。BungeeCord、Waterfall、およびレガシー転送では署名に使う共有シークレットがないため、付与は署名なしで送られ、そのまま受け入れられます。

ステップ2には到達するがステップ3に到達しないバックエンドは、キーのソースが not set のままになります。これがまさに、proxy-extension/ のステージングとBedrock固有の警告バナーを引き起こす状態です。

動作確認​

プロキシコンソール​

再起動から ~10 秒以内（バックエンドが起動中であると仮定）に、次のような出力が見えるはずです：

[ResourcePackManager] Network key loaded ✓
[ResourcePackManager] Network key provisioning ready on rspm:network; backends are keyed as players connect.
[ResourcePackManager] NetworkSync starting (poll interval 5000 ms, network-http-offset 1 - endpoint announcements preferred, fallback HTTP port = mcPort + offset)
[ResourcePackManager] NetworkSync: inbox stabilized — merging 2 Bedrock zip(s) and 2 mappings file(s) across 2 backend(s).
[ResourcePackManager] Merged Bedrock pack published at .../merged/Bedrock.zip (sha1=...).
[ResourcePackManager] ✔ Network resource pack is now ready (... KB, sha1 ABCD1234)

プロキシでの /rspm status​

スナップショットを表示します：ネットワークキーのフィンガープリント、バックエンド一覧、/bedrock.zip・/mappings.json・/rspm-update.jar に対するバックエンドごと／パスごとの取得結果（200／304／404／CONNECT_FAILED）、受信したエンドポイント通知、参照できるリレーエントリ、連続空ポーリングカウンター、マージ済みBedrockパックとマージ済みマッピングがディスク上にあるかどうか（およびそのサイズ）と現在のマージ済みパックのSHA-1プレフィックス、network-http-offsetフォールバック、検出されたGeyserプラグインフォルダーとデプロイされたマッピングファイル、そしてプロキシでのFloodgate／Geyserの有無。Velocityは resourcepackmanager.command.status または resourcepackmanager.* を受け付けます。BungeeCordは resourcepackmanager.command.status ノードを正確に登録し、権限プラグインによってはワイルドカード展開でこれを満たせます。コンソールから実行できます。出力に秘密情報は現れない（ネットワークキーは短い一方向ハッシュのフィンガープリントとしてのみ表示され、認証トークンも出力されません）ため、寛容に付与しても安全です。

バックエンドでの /rspm status​

Deploy mode 行が network-backend になっているはずです。Network key fingerprint には短いハッシュが表示されます — これはプロキシが出力するフィンガープリントと一致していなければなりません。Network key source は、このバックエンドがどのようにキーを得たかを示します：

ソース行意味
provided by the proxy通常のリンク済み状態。プレイヤーの接続時にプロキシがキーを付与しました。
saved on this server以前の起動で既にキーを持っていた（またはスタンドアロンのサーバーが自分で生成した）状態です。
adopted from Floodgate's keyこのバックエンドのローカルの plugins/floodgate/key.pem から一度だけシードされました。
not set — the proxy sends one when a player next connects here未リンク。 プロキシ起動後にまだ誰も接続していないか、プロキシにRSPMが入っていない／サポート対象外のプロキシです。

Bedrockクライアント​

Bedrockで接続します。ワールドに到達する前にリソースパックのダウンロードプロンプトが表示されるはずです。カスタムアイテムは、ただのアーマースタンドではなく意図したモデルで描画されます。

設定リファレンス​

バックエンド plugins/ResourcePackManager/config.yml​

ネットワークモードは自動検出されます — networkMode: true のようなフラグを設定する必要はありません。検出シグナル（いずれか1つで十分）：

  1. Floodgateが存在し、Geyser-Spigotが存在しない — Bedrock-via-proxyケースの最強シグナルです。
  2. spigot.yml: settings.bungeecord: true — 旧来のBungeeCord／Waterfall IP転送スイッチです。
  3. paper-global.yml: proxies.velocity.enabled: true — モダンなVelocity転送です。

ネットワークモード固有で重要な唯一のつまみは networkHttpOffset-v2 で、プロキシが各バックエンドでポーリングするフォールバックHTTPポート（バックエンドが実際にバインドしたポートを通知する前にプロキシが推測するポート）を制御します。既定 1 は事実上すべてのホスティングで動作します。完全なポート解決の話はセルフホストを参照してください。

通常の運用では、各バックエンドが自身の本物のHTTPポートをプロキシに自動通知する（magmaguy.com のエンドポイントレジストリ経由）ため、オフセットは起動時／失敗時のフォールバックとしてのみ参照されます。下記のバックエンドのHTTPポート解決を参照してください。

プロキシ config.yml​

プロキシプラグインは初回起動時に最小限の既定設定を書き出します。各プロキシが自身のプラグイン識別子からフォルダーを導出するため、パスはプラットフォームによって異なります：

プロキシソフトウェア設定ファイルのパス
Velocityplugins/resourcepackmanager/config.yml
BungeeCord／Waterfallplugins/ResourcePackManager/config.yml

含まれる設定はちょうど2つで、どちらも任意です：

# FALLBACK offset added to each backend's Minecraft port to derive the HTTP
# port this proxy will hit for /bedrock.zip and /mappings.json BEFORE that
# backend has announced its real ResourcePackManager HTTP port. Default 1.
# In normal operation the backend announces the exact port it bound, so this
# value is only used at startup or if announcement fails — but if it IS used,
# it should match each backend's networkHttpOffset-v2.
network-http-offset-v2: 1

# Installs and updates this universal ResourcePackManager.jar in the proxy's
# Geyser extensions folder, which is what makes custom Bedrock ENTITIES render.
# Default true. Setting it to false stops future installation and update
# staging; it does not delete an extension jar that is already installed —
# remove that by hand while Geyser is stopped.
geyser-extension-auto-install: true

バックエンド側の対応する設定は、バックエンドの config.yml にある networkHttpOffset-v2 と geyserExtensionAutoInstall です。両者は別々の設定です — プロキシで拡張のインストールをオフにしても、バックエンド側がオフになることはなく、その逆もありません。

プロキシプラグインは config.yml と並んで、同じフォルダーに network-key ファイルも書き出します。これは設定ではなく生成された状態です：編集しないでください。また、異なるネットワーク間でコピーしないでください。削除すると、プロキシは次回起動時にまったく新しいキーを生成し、既に配布済みだったすべてのバックエンドがリンク解除されます（各バックエンドは古いキーを保持し、置き換えを受け入れません）。コピーが正しいのは1つのケースだけです：同じバックエンド群の前段に2つのプロキシがあり、両者が1つのキーを共有しなければならない場合です。

プロキシ側に force-resource-pack の設定はありません。パック受け入れの強制はバックエンド側の判断です（バックエンドの config.yml の forceResourcePack）。プロキシプラグインはBedrockパックの配信しか扱わず、Javaパックを送信することは一切ないためです。古いプロキシの config.yml にまだ force-resource-pack の行が残っている場合、それは単に無視されるので削除して構いません。

network-key の設定エントリは意図的にありません — 貼り付け式のキーは、タイポによってプロキシ↔バックエンドのリンクがどこにもエラーを出さずに壊れてしまうため、プレリリース段階で廃止されました。キーはプロキシとバックエンドがリンクする仕組みで説明したとおり、プロキシが確立してバックエンドに自動配布します。

バックエンドのHTTPポート解決​

プロキシは、各バックエンドで /bedrock.zip と /mappings.json をポーリングするためにどのHTTPポートを使えばよいかを知る必要があります。プロキシはそのポートを次の順序で解決します：

  1. バックエンドが通知したエンドポイント（優先）。 各バックエンドは、実際にバインドした正確なHTTPポートを、ネットワークキーをキーとして magmaguy.com のエンドポイントレジストリにアップロードします。ポーリングのたびに、プロキシはこのリストを更新し、バックエンドが通知したポートを、Minecraftポート（および利用可能な場合はホスト）でサーバーリストのエントリと突き合わせます。これは、バックエンドに明示的な selfHostPort を設定した管理者も、バックエンドが自動的に mcPort + 1 に着地する場合も、同一に扱われることを意味します — プロキシはバックエンドが実際にバインドしたものをそのまま使います。
  2. mcPort + network-http-offset-v2（フォールバック）。 一致する通知が利用できない場合（例：どのバックエンドもまだ通知していない最初のポーリング、またはエンドポイントレジストリが一時的に到達不能）にのみ使われます。これが、フォールバックに依存する場合に2つのオフセットを一致させておくべき理由です。

プロキシは意図的にバックエンドをポートスキャンしません — それはホストにとって不正な振る舞いに見えるためです。直接取得がまったく機能しない場合、リレー経路（下記）が決定的な答えになります。

プロキシでの /rspm status は、バックエンドごとに、どのポートが選ばれたか、そしてそれが通知由来かオフセットフォールバック由来かを表示します。

安定性とマージのケイデンス​

プロキシはマージ前に、インボックスの状態が安定するのを待ちます：最初のポーリングがファイルハッシュ集合のベースラインを設定し、同じ集合を観測する次のポーリングがマージをトリガーします（1サイクルの安定性ゲート）。約2秒の初期遅延と5秒のポーリング間隔により、最初のマージはプロキシが少なくとも1つのバックエンドがコンテンツを生成しているのを見ることができるようになってから約7秒後になります。それ以降のマージは、インボックスファイルのSHA-1集合が変わったときだけ再ZIP化されるので、長い静寂期間のコストはほぼゼロです。

バックエンドは bedrock.zip を一時ファイルに書き込んでからアトミックにリネームするため、/bedrock.zip ルートは常に完全なzipを提供します — プロキシは書き込み途中の読み取りを防御する必要がなく、これがゲートが2サイクルではなく1サイクルである理由です。

直接取得 vs リレーフォールバック​

既定の経路は直接取得です：プロキシは各バックエンドに対して http://<backend-host>:<mcPort + offset><path> にHTTP GETを行います。

プロキシがバックエンドのHTTPポートに直接到達できない場合（共有／マネージドのMinecraftホスティングでMCポートは公開されているが隣接ポートはファイアウォール越し、というケースが典型）、バックエンドは自分の bedrock.zip と mappings.json を、ネットワークのネームスペース下（ネットワークキーから導出される）にある magmaguy.com のリレーエンドポイントにプッシュします。直接取得がハード失敗したとき、プロキシはリレーを一覧してダウンロードします。

両方の経路が同じマージステップにフィードされるため、オペレーターが選ぶ必要はありません — 直接取得が優先（magmaguy.com への帯域コストゼロ）で、必要なときにリレーが透過的に動作します。

リレーのサーバー側TTLは30分です。バックエンドはエントリを生かしておくため25分ごとにプッシュします。クリーンシャットダウンではTTLを待たずに即座にエントリを落とします。

よくある問題のトラブルシューティング​

バックエンドがネットワークキーをまったく受け取らない​

症状：バックエンドでの /rspm status が Network key source: not set — the proxy sends one when a player next connects here を示し、バックエンドのコンソールが次を繰り返します：

[ResourcePackManager] This backend is behind a proxy but has no network key yet, so it is not linked to the proxy.
[ResourcePackManager] The proxy sends one automatically the first time a player connects to this server.

次の順で確認してください：

  1. プロキシ起動後、そのバックエンドに実際に誰か接続しましたか？ 付与はプレイヤーの接続に乗って届きます。まだ誰も訪れていないロビーがキーを持たないのは正常です。
  2. そもそもプロキシにRSPMが入っていますか？ バックエンドはまさにこのケースのために、自身のjarのコピーを plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar に用意します。それをプロキシの plugins/ フォルダーにコピーし、プロキシを再起動してください。
  3. Velocityのモダン転送：バックエンドの転送シークレットはプロキシのものと一致していますか？ モダン転送用に構成されたバックエンドは、署名なし、または誤って署名された付与を意図的に拒否します — このチェックだけが、権限のないプロキシがあなたのバックエンドにキーを与えるのを防いでいます。バックエンドのログには2つのケースのどちらに当たったかが出ます。両側でシークレットを修正すれば、次のプレイヤー接続で自動的に再試行されます。再武装のためにどちらかを再起動する必要はありません。
  4. プロキシがサポート対象外のプロキシではありませんか？ プロキシの役割を実行できるのはVelocityとBungeeCord／Waterfallだけです。

Floodgateの key.pem はもうこれには関係しないことに注意してください。プロキシに plugins/floodgate/key.pem がない状態は完全にサポートされています — プロキシは代わりに自前のキーを生成します。ただしBedrockプレイヤーがそもそもプロキシに到達するには、依然としてFloodgateが必要です。

2つのプロキシが同じバックエンド群の前段にある​

両方のプロキシが同じネットワークキーを提示しなければなりません。さもなければ各バックエンドは先に到達したほうにリンクし、もう一方を拒否します（A proxy offered a network key that differs from the one this backend already uses をログ出力します）。主プロキシのRSPMデータフォルダーにある network-key ファイルをもう一方のプロキシにコピーし、再起動してください。

~20秒後に「No merged pack content」警告が出る​

連続4回の空ポーリングサイクルの後、プロキシはポーリングしたすべてのバックエンド、試行したURL、結果を列挙する1回限りの複数行警告をログ出力します。警告は最もよくある修正方法を説明します：

  • すべてのバックエンドで CONNECT_FAILED — プロキシがバックエンドのHTTPポートにまったく到達できません。velocity.toml ／ config.yml のアドレスがプロキシから実際に到達可能なもの（プロキシのネットワークから解決できないDockerの内部名ではない）であること、そしてバックエンドのHTTPポートがプロキシとバックエンド間で開いていることを確認してください。警告は、バックエンドごとに試行した正確なHTTPの host:port と、そのポートがバックエンドの通知由来か mcPort + networkHttpOffset-v2 フォールバック由来かを表示します。そのポートを開く手段がない（マネージドホスティング）場合は、上記のリレーフォールバックセクションを参照してください — バックエンドが自動でリレーにアップロードしているはずです。
  • すべてのバックエンドで NOT_FOUND_404 — バックエンドは起動していますが、Bedrockパックを生成していません。各バックエンドで /rspm status を実行してください。Bedrock Packの診断ブロックが理由を教えてくれます（最も多いのは、マージされたパックに変換可能なアイテムマッピングやエンティティバンドルがない、または最初のミックスサイクルがまだ完了していない、です）。

警告は詰まった期間ごとに1回発火します。少なくとも1つのバックエンドがコンテンツを返し始めると NetworkSync: recovered 行がログに出力されます。

初回プロキシ起動時にBedrockプレイヤーにカスタムモデルが見えない​

Geyserはプロキシ起動時にだけカスタムアイテムテーブルを登録します。Bedrockパックを生成したバックエンドより先にプロキシが起動した場合、Geyserは空のマッピングテーブルで動作し、そのセッションの残り時間ずっとそのままになります。

修正：バックエンドが最初の Merged Bedrock pack published 行をログに出した後、プロキシを一度再起動してください。RSPMはプロキシ起動のたびに前回実行時のマッピングを事前デプロイするので、これが噛むのは新規インストール時のみです — 以降の起動では、Geyserがスキャンする前に何かが用意されています。

プロキシ起動時に「Duplicate bedrock_identifier」警告が出る​

2つのバックエンドが同じベースアイテムに対して同じBedrock識別子を出力しました。後勝ち；そのアイテムを提供するバックエンドが1つだけでよいなら無害です。両方のバックエンドが同じベースアイテムで別々のカスタムアイテムをホストすべきなら、自動生成されるハッシュが異なるように、ソースとなるJavaモデルのいずれかをリネームしてください。

Bedrockプレイヤーが接続したのにパックが見えない​

プロキシは、Bedrockセッションが使用可能なRSPMパックなしでロードされたとき、オンラインのすべてのJavaプレイヤーにチャットバナーを発火します：

⚠ [RSPM] Bedrock player Alice connected before the resource pack was ready — they're seeing plain armor stands instead of custom models. Tell them to disconnect and reconnect; the pack will load on their next session. (Cause: ...)

Bedrockプレイヤー自身もモーダルポップアップを受け取り、プロキシコンソールにもバナーが表示されます。さらに深く調査する必要がある場合は、デバッグストリームを有効にしてください（VelocityとBungeeCordの両方で利用可能）：

/rspm debug bedrock on

これは GeyserBinder からの詳細な [RSPM-BedrockDebug] ログ行をオンにします。問題を再現したら、オフにしてください：

/rspm debug bedrock off

設定はプロキシ再起動でオフにリセットされるため、誤って付けっぱなしになることはありません。

ネットワーク上でのRSPMの更新​

すべてのバックエンドとプロキシで同じjarなので、すべてのコンポーネントを同じバージョンに保ってください。

手動の手順は次のとおりです：バックエンドのjarを更新し、その同じ ResourcePackManager.jar をプロキシの plugins/ フォルダーに再コピーし、プロキシを再起動します。

RSPMはプロキシ側の作業を自分で行うこともできます。各バックエンドは、認証付きの経路（/rspm-update.jar。共有ネットワークキーから導出したトークンで保護されており、キー自体が送信されることはありません）を通じて自身のユニバーサルなプラグインjarをプロキシに提供します。プロキシは、提供されたファイルが完全なユニバーサルRSPM jarであり、プラットフォーム記述子のバージョンが一致し、想定どおりのエントリポイントを持つことを検証し、ダウングレードを拒否し、そして何かを置き換える前にステージングしたバイト列を告知されたサイズとSHA-256と突き合わせて検証します。プロキシプラグイン用に同じjarをステージングし、プロキシでホストされているGeyserが検出された場合はそれにバンドルされたGeyser拡張もステージングします。これらのファイルはプロキシのシャットダウン時に適用され、以前のファイルはロールバック用のコピーとして保持されます。

これは認証されたネットワークの信頼境界であり、Nightbreakに対する独立した出所検証ではありません：共有ネットワークキーを配布済みのバックエンドはすべて、構造的に妥当な同等以上のバージョンのRSPM jarを提供する存在として信頼されます。そのキーを保護し、それを共有するすべてのバックエンドを信頼されたインフラとして扱ってください。

そのため実務上は、バックエンドを更新してからプロキシを再起動するだけで十分なことがほとんどです — プロキシは自分向けに一致するjarを既にステージングしているはずです。アップデートが拒否された場合は、理由とともに Rejected backend-offered ResourcePackManager update: ... がログに出力されます。

まだサポートされていないこと​

  • プロキシプラグイン経由でのネットワーク上のJavaパック。 Javaクライアントは、通常のAPIを通じて各バックエンドから直接パックを受け取ります。プロキシ側のJavaパックミキサーはありません。
  • バックエンドをまたいだJavaパックマージ。 各バックエンドのJavaパックは独立しています。プレイヤーがバックエンドを切り替えると、新しいバックエンドのパックを受け取ります。
  • ネットワークキーのライブローテーション。 バックエンドがキーを受け入れるのは一度だけで、メッセージによる置き換えを受け付けません。ローテーションするには、プロキシの network-key ファイルを削除し、すべてのバックエンドの data.yml から networkKey を消したうえで、すべてを再起動する必要があります。