マイクラ「ネットワークプロトコルのエラー」の対処法|Network Protocol Error・Index 21の確認

マイクラで「ネットワークプロトコルのエラーが発生しました」「Network Protocol Error」と表示されたら、最初にゲームの版・バージョン、エラーが起きるタイミング、クライアントとサーバーのログを確認します。エラー名だけで回線、ポート、Modのどれが原因かは特定できません。参加者が確認できることと、サーバー管理者の作業を分けて進めましょう。

同じNetwork Protocol Errorでも、接続前の失敗と特定の操作後の切断では確認する場所が変わります。

目次

最初に確認する5項目

  • Java EditionかBedrock Editionか。PCだからJava版とは限りません。
  • 自分のゲームの完全なバージョン番号と、接続先が対応するバージョン。
  • 参加直後、特定のワールド・場所へ移動後、アイテム使用後など、切断するタイミング。
  • 自分だけか、他のプレイヤーも同じか。別の接続先では再現するか。
  • 画面のエラー全文、発生時刻、切断レポートやログがあるか。
比較した結果次に確認する場所
自分だけで起き、他の人は同じサーバーへ入れるクライアント版、必要なMod・設定、個別プレイヤーで起きる条件
同じサーバーで複数人に起きる管理者がサーバーログと直近の更新・プラグイン・プロキシ構成を確認
接続はできるが、特定の操作や場所で切断する直前の処理、例外、データやパケットに関係する拡張機能
接続前にタイムアウト・接続拒否になる接続先の稼働、アドレス・ポート、接続経路。プロトコル処理の例外と区別
Bedrock版・コンソールで起きるその版の更新・アカウント・権限・接続条件。Java用のJVMやmodsフォルダーの手順を使わない

参加者:ゲームの版と接続先の対応バージョンを合わせる

Minecraftの マルチプレイの公式条件 は、JavaとBedrockの対応する接続先、更新、安定した接続、アカウントや権限等を説明しています。通常のJavaサーバーにはJava版、Bedrockの世界にはBedrock版を使います。管理者が他の接続方式を案内している場合は、その対応条件を確認してください。

一般の友人とのプレイでは双方のゲームを更新して確認します。一方、指定バージョンのJavaサーバーやModパックでは、管理者が案内する対応版と導入手順を確認します。自分のゲームだけを最新版へ変えたり、サーバーのワールドを古い版へ戻したりして解決しようとしないでください。Snapshot/Previewと通常のリリースの違いも確認します。

サーバー用プラグインすべてをクライアントにも入れる必要はありません。クライアント専用Mod、サーバー専用Mod、双方で必要なModでは条件が異なります。利用するModパックのMinecraft版、ローダー、Mod・依存関係を配布元の案内と照合してください。

切断レポートとログを保存する

Java版の切断画面に「Open Disconnection Report Directory」等のボタンが表示される場合は、そこからレポートを保存します。Java Edition 1.21の公式変更点 では、一部の切断で詳しい情報を保存し、そのボタンを表示する機能が説明されています。すべての切断で同じボタンやレポートが出るわけではありません。

ボタンがない場合や、より詳しい確認が必要な場合は、ゲームのログを確認します。Fabricの ログの場所と共有方法 では、実際のゲームディレクトリの logs/latest.log が最新のログと説明されています。Windowsの標準ディレクトリなら次の場所ですが、Launcherで別のディレクトリを指定している場合はその場所を使います。

%appdata%\.minecraft\logs\latest.log

ゲームを何度も起動し直す前に、問題が出た回のログをコピーして保存してください。クラッシュした場合は crash-reports も確認します。Fabricの クラッシュレポートの読み方 にあるように、レポートには例外、スタックトレース、JavaやModの構成等が含まれます。切断しただけならクラッシュレポートが生成されない場合もあります。

「Index 21 out of bounds for length 21」の意味

ArrayIndexOutOfBoundsException と一緒に表示された場合は、長さ21の配列で範囲外のインデックス21を参照したことを示します。有効な範囲は0〜20です。Oracleの ArrayIndexOutOfBoundsException仕様 は、負の値または配列の長さ以上のインデックスを参照した場合の例外と説明しています。文言だけでなく例外クラスも確認してください。

長さ21の配列:有効なインデックスは 0 ~ 20
インデックス21:範囲外

この数字は、開くべきポート番号、Modの個数、必要メモリー量ではありません。数値だけで特定のModやMinecraftの不具合を断定せず、実際の例外クラス、Caused by:、直後の at ... にある処理名と発生時刻を確認します。Java版の処理の例外を、Bedrock版にもそのまま適用しないでください。

ログにModやプラグイン名があれば確認対象になりますが、その名前があるだけで作者の不具合と確定するわけではありません。依存関係や他の拡張との互換性も含め、前後のログと再現手順を開発元へ伝えます。実際に取得していない例を「典型的な実ログ」として扱わないことも大切です。

管理者:変更前に停止・バックアップし、検証環境で比べる

参加者は、サーバーの設定やワールドを変更できません。まず発生時刻とレポートを管理者へ伝えます。管理者は PaperMCの基本トラブルシューティング を参考に、サーバーを正常に停止し、ワールド・設定・プラグイン等を含むサーバーフォルダーをバックアップしてから変更します。可能ならコピーを検証環境に使います。

  1. サーバー側の同時刻のログを確認し、例外、処理名、起動時の読み込みエラーを探します。
  2. 直前に変更したサーバー版、プラグイン、Mod、プロキシ、設定を一覧化します。
  3. 検証用の新規ワールドで、対応する最小構成と同じクライアント条件を比較します。本番のModワールドをModなしで上書き保存しないでください。
  4. 改善した場合は、依存関係を守って機能を段階的に戻し、どの変更で再現するか確認します。
  5. 修正を本番へ適用する前にバックアップから戻せることと、通常の遊び方で問題がないことを確認します。

Paperの手順は、プラグインをグループに分けて原因を絞る場合も、依存するライブラリと利用側をまとめて確認するよう説明しています。Fabric等のModサーバーには、そのローダーとModの条件を適用します。「全部外して本番ワールドを開く」「認証を無効にする」を一律の解決策にはしません。

Javaの版は使用するサーバーの要件と照合する

Java版サーバーでは、起動スクリプトが実際に使うJavaのバージョンを確認します。ターミナルの java -version と、スクリプトにフルパスで指定したJavaが違うこともあるため、起動ログも見ます。Bedrock専用サーバーやコンソールへ同じJava設定は適用しません。

Paperを使う場合は PaperMCの要件表 を確認してください。確認時点の表ではPaper 1.20〜1.21.11の推奨がJava 21、26.1以降がJava 25です。別のサーバーやModパックに同じ要件を一律適用せず、対象の配布元で確認します。Javaの版を変えればIndex例外が必ず直るわけではありません。

接続前の失敗なら、接続経路を別に確認する

タイムアウトや接続拒否の場合は、管理者がサーバーの稼働と実際の待受アドレス・ポートを確認します。参加者側が公開サーバーへ接続するだけなら、自宅ルーターへ新しい受信ポート転送を追加することを最初の対処にしません。ゲーム内へ入った後、同じ操作でIndex例外が出る場合は、その処理のログ確認を優先します。

Java系サーバーの設定は、使用ソフトの資料で確認します。PaperMCのserver.properties資料 では、server-port の既定値は25565、server-ip はバインド先で空欄なら全インターフェースと説明されています。これを「自動で正しいIPを検出する機能」と混同せず、ホスティングやプロキシの指定がある場合はその条件に従います。

外部から自宅サーバーへ到達できない場合は、管理者が利用回線・ルーター・ホストのファイアウォールを確認します。LAN内の待受があることだけで、インターネットから到達できるとは証明できません。セキュリティ機能を一括停止したり、online-mode=false で認証を外したりすることを、プロトコルエラーの汎用対処にしないでください。

管理者・開発元へ伝える情報

情報記録する内容
版・構成Java/Bedrock、ゲーム版、サーバーソフトとビルド、ローダー、Modパック、プロキシ
再現条件接続直後・特定操作・場所、全員か一人か、別環境の比較結果
ログ発生時刻、切断レポート、クライアントとサーバーの同時刻のログ、例外全文
変更点直近の更新・追加・設定変更と、元に戻して検証した結果
相談先接続先管理者、ログと構成に合うサーバー/Mod/プラグインの開発元

ログを共有するときは、IPアドレス、ユーザー名、パス、認証情報等の扱いを確認します。問題に関係する例外や構成を削り過ぎず、適切な窓口で共有してください。画面の短い文言に合わせて設定を一度に多数変えるより、同じ条件で一つずつ比較した記録が原因の特定に役立ちます。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次