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

ResourcePackManagerはプロキシネットワークで動作します。同じ ResourcePackManager.jar をプロキシと、リソースパックを提供する各バックエンドにインストールしてください。それ以外の登録済みサーバーにはRSPMを入れなくても構いません。バックエンドではパックのマージ、ホスト、配信、変換を行います。VelocityまたはBungeeCordでは、jarがプロキシのプラットフォームを検出し、ネットワークのBedrock配信を処理します。プロキシはネットワークキーを保有し、プレイヤーが各バックエンドへ初めて接続したときにキーを送信します。

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

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

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

1. 登録済みバックエンドのうちRSPMを実行しているものを検出し、その参加バックエンドから /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クライアントに配信します。

ネットワーク上のJavaパックは、通常の setResourcePack ／ addResourcePack APIで各バックエンドから配信されます。プロキシの役割には、Bedrockパックのマージに加え、ネットワークキーの配布と認証付きRSPM更新の伝播があります。Java専用ネットワークのJavaパック配信には不要です。

セットアップ

Floodgate

Floodgateを使うと、Bedrockプレイヤーは有料のJava Editionアカウントなしで認証できます。GeyserはJavaアカウントによるオンライン認証にも対応しています。使用する認証方式についてはGeyserのセットアップガイドに従ってください。RSPMのプロキシとバックエンドはFloodgateなしでもリンクできます。

プロキシでRSPMを初めて起動した時点でFloodgateがあれば、RSPMは plugins/floodgate/key.pem からネットワークキーを導出し、既存ネットワークの識別情報を維持します。その後は、有効なキーが保存されている限り、RSPMの network-key ファイルを使います。保存済みキーがないか無効な場合は、ランダムなキーを生成する前にFloodgateからの導出を再試行します。

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

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

プロキシにRSPMを入れずにバックエンドを起動した場合でも、改めてダウンロードを探す必要はありません。キーを持たないプロキシ配下の各バックエンドは、自身のjarとバイト単位で同一のコピーを plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar に用意し、その正確なパスをコンソールに表示します。このファイルをコピーすると、そのバックエンドで現在動いているバージョンがインストールされます。ネットワークのバージョンをそろえるため、他のバックエンドも更新してください。

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

プロキシソフトウェア	使用するjar
Velocity	ResourcePackManager.jar
BungeeCord	ResourcePackManager.jar

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

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

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

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

バックエンドの検出

プロキシは登録済みサーバーでRSPMの有無を調べます。RSPMを実行していないサーバーのためにパック同期を待たせることはありません。エンドポイント通知や検証済みのキャッシュ内容から、参加バックエンドをすぐに確認できる場合があります。それ以外は解決済みHTTPエンドポイントをバックグラウンドで確認し、同時実行は最大2件、タイムアウトは5秒です。未確認サーバーは約1分後に再確認されます。

/rspm status は確認済み参加数と残りの各サーバーの検出状態を表示します。RSPM not confirmed は検出処理がRSPMの存在を確認できていないという意味で、不在の証明ではありません。参加するはずのサーバーなら、バックエンドのアドレス、HTTPポート、到達性を確認してください。別のバックエンドにRSPMをインストールすると、自動的に検出されます。

確認済みバックエンドの接続に失敗すると、その参加バックエンドの更新失敗として報告されます。利用可能なコミット済みコンテンツは保持され、直接取得とリレーの結果は引き続き /rspm status で確認できます。空ポーリング回数がゼロなのはコンテンツが利用できるという意味で、すべての接続が正常だという意味ではありません。

検出によって更新権限が与えられることはありません。プラグインの自動更新には、引き続きネットワークキー認証とjar検証が適用されます。

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

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

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）。不正な形式の network-key ファイルは置き換えられます。RSPMが新しいキーを保存できない場合や、既存の network-key ファイルを読み取れない場合、次回の再起動で変わる可能性のあるキーで動作するのではなく、プロキシの役割は Could not establish persistent RSPM network identity または Cannot read established RSPM network identity で起動を中止します。フォルダーの権限を修正してからプロキシを再起動してください。

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

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

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

ステップ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 IP転送スイッチです。
3. paper-global.yml: proxies.velocity.enabled: true — モダンなVelocity転送です。

ネットワークモードの代替ポート設定は networkHttpOffset-v2 です。バックエンドが実際のバインドポートを通知する前に、プロキシが推測してポーリングするHTTPポートを制御します。既定値は 1 です。そのポートはプロキシとバックエンド間で到達可能であるか、リレー経路が利用できる必要があります。詳細はセルフホストを参照してください。

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

プロキシ config.yml

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

プロキシソフトウェア	設定ファイルのパス
Velocity	plugins/resourcepackmanager/config.yml
BungeeCord	plugins/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 を保存します。この生成済みの状態を維持し、異なるネットワーク間ではコピーしないでください。削除すると次回起動時にキーを再決定しますが、Floodgateのファイルがあれば同じキーを再現する場合があります。キーが変わると、配布済みのバックエンドは古いキーを保持し、新しいキーを拒否します。同じバックエンド群を使う2つのプロキシはキーを共有する必要があるため、この場合はプロキシ間でファイルをコピーしてください。

プロキシ側に 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 は、バックエンドごとに、どのポートが選ばれたか、そしてそれが通知由来かオフセットフォールバック由来かを表示します。

安定性とマージ間隔

Javaホスティングの設定はプロキシ配下のバックエンドにも適用されます。Javaのセルフホスト確認が失敗した場合、RSPMはJava配信をリモートホスティングへ切り替えながら、/bedrock.zip と /mappings.json 用にバックエンドのHTTPサーバーを稼働させ続けることができます。

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

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

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

既定の経路は直接取得です：プロキシは各バックエンドに対して 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 がなくても対応しており、プロキシが独自のキーを生成します。Floodgateの認証とRSPMのネットワークリンクは別の機能です。

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

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

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

確認済みRSPM参加バックエンドがある状態で空のポーリングが4回続くと、プロキシはその参加バックエンド、試行したURL、結果を列挙した警告を出します。最初の参加バックエンドをまだ探している新しいプロキシは、関係のない登録済みサーバーをパック取得失敗として数えません。警告にはよくある解決方法が示されます：

• すべてのバックエンドで 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の走査前に保存済みマッピングを読み込めます。後からカスタムアイテムを追加・削除した場合も起動時のマッピングが変わるため、再起動が必要です。新しいカスタムエンティティIDやプロパティ型にも同じ対応が必要です。

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

Bedrock 識別子が異なっても、Java のアイテム・モデル・条件のセレクターが同じ場合があります。解決済みの元モデルの名前を変えるだけでは、それらのアイテムを区別できません。custom-model-data の値を分けるなど、異なるセレクターを割り当ててください。現在のマージ処理は同じセレクターなら legacy より現行の definition を優先し、同じ種類なら後の項目を優先します。重複排除後に残るのは一方だけです。

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

Bedrockセッションが使用可能なRSPMパックなしで読み込まれると、プロキシは resourcepackmanager.* を持つオンラインのスタッフへチャット通知を送ります：

⚠ [RSPM] BedrockプレイヤーAliceがリソースパックの準備前に接続したため、カスタムモデルではなく通常のアーマースタンドが表示されています。切断して再接続するよう伝えてください。次のセッションでパックが読み込まれます。（原因：...）

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: ... がログに出力されます。

実行ファイル更新の認証失敗

/rspm-update.jar でHTTP 401 が返ると、そのバックエンドからのjar自動伝播だけが一時停止します。Bedrockパックとマッピングの直接ポーリングは継続します。更新経路の再試行間隔は1分から始まり、最大15分まで延長されます。両側の /rspm status にあるネットワークキーのフィンガープリントを比較し、報告されたURLが意図したバックエンドに到達することと、バージョンが一致することを確認してください。

フィンガープリントが異なる場合は、プロキシ上の /rspm status が現在の手順を示します。意図したプロキシとバックエンドであることを確認し、影響を受けるバックエンドを停止し、その plugins/ResourcePackManager/data.yml をバックアップしてから networkKey エントリだけを削除します。その後バックエンドを起動し、このプロキシ経由で参加して、再びキーが付与されるようにします。プロキシの network-key とFloodgateのキーはそのまま残してください。プロキシ上の401のコンソール警告は、まだFloodgateの key.pem をコピーするよう案内しますが、この案内は古くなっています。RSPMは独自のネットワークIDを保存するため、key.pem を変更しても既存のRSPMキーは置き換わりません。サポート用に両側の状態出力を保存してください。

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

• プロキシプラグイン経由でのネットワーク上のJavaパック。 Javaクライアントは、通常のAPIを通じて各バックエンドから直接パックを受け取ります。プロキシ側のJavaパックミキサーはありません。
• バックエンドをまたいだJavaパックマージ。 各バックエンドのJavaパックは独立しています。プレイヤーがバックエンドを切り替えると、新しいバックエンドのパックを受け取ります。
• ネットワークキーのライブローテーション。 バックエンドはキーを持たない場合にのみキーを受け入れ、置き換えメッセージを拒否します。すべてのコンポーネントを停止してから、プロキシの network-key と各バックエンドの data.yml 内の networkKey を削除すると、再配布が可能になります。ただし、キーの変更は保証されません。プロキシがFloodgateの key.pem から同じキーを再び導出する場合があります。