【2026年10月1日 追記】この記事のあと、サーバーとマイクラ本体の両方が新しい版（サーバー 1.26.52.3）に上がった状態で transport=raknet を試し直したところ、家のSwitchからも、出先のSwitch 2からも入れるようになりました。下に書いた「raknetは拒否された」「出先のSwitchはあきらめた」は、9月時点の結果です。出先から入る方法はplayitを使った新しい記事にまとめました。

自宅のNASでマイクラ（Bedrock版）のサーバーをDockerで動かして、息子とふたりで遊んでいます。24時間動いている機械があるので、パソコンを立ち上げなくてもいつでも入れる。これが便利で、半年近く使ってきました。

それが、ある晩とつぜん入れなくなりました。しかもいつもの「アップデート直後だから、しばらく待てば直る」やつではありませんでした。

原因をたどっていくと、サーバー側の通信方式が RakNet から NetherNet という新しい方式に変わったことに行き当たりました。ただ、最初に書いておきます。「26.50以降は全部NetherNetになったので、Switchからは繋がらない」という単純な話ではありません。サーバーのビルドやクライアントの更新状況によって挙動が違います。実際、私も途中まで見当違いの方向に走りました。

なので、この記事は「これをやれば直る」ではなく、私が何を試して、何が起きて、どこで直ったかを順番に書きます。読んだ人が、自分の環境を一つずつ確認していけるように、最後に確認の順番もまとめました。ネットワークの専門家ではないので、理屈より「やったらどうなったか」が中心です。

目次
  1. ある晩とつぜん、息子がサーバーに入れなくなった
  2. サーバーのログを見たら、勝手に新しくなっていた
  3. NetherNetは何が違うのか
  4. 効かなかった対処を3つ
  5. 原因はSwitchのDNS設定だった
  6. 入口は「サーバー」タブではなく「フレンド」タブだった
  7. Dockerで動かしているなら、ここも疑う（network_mode: host）
  8. 出先からSwitchで入る道は、ほぼ塞がった
  9. 確認する順番（自分用のメモ）
  10. 断定できないこと
  11. まとめ

ある晩とつぜん、息子がサーバーに入れなくなった

症状はこうです。

Switchのマイクラを開いて、いつもどおり「サーバー」タブから自宅のサーバーに入ろうとすると、この画面が出ます。

マルチプレイ接続失敗

クライアントがマルチプレイサービスへの接続を確立できません。インターネット接続を確認し、クライアントを再起動してもう一度お試しください。

詳細については、help.Minecraft.net で「NetherNet」を検索してください。

「サーバーに接続できません」ではなく「マルチプレイサービスへの接続を確立できません」。あとから振り返ると、この一行が答えそのものだったのですが、このときは読み飛ばしていました。

うちの構成を先に書いておきます。

  • サーバー … 24時間動いているNAS上のLinuxで、Dockerのコンテナとして常時稼働
  • Switch … 同じ家のWi-Fi。「サーバー」タブから、DNSを書き換える方法で入っていた（後述）
  • PC … 同じ家のLANから、アドレスを指定して接続

この時点でおかしいと思うべきだったのは、PCからは入れていたことです。サーバーが落ちているわけではない。Switchだけが入れない。それなのに私は、しばらくサーバー側ばかり見ていました。

実は、マイクラがアップデートされるとSwitchから入れなくなる、というのは前からときどき起きていました。そのたびに私は待っていました。数日すると、いつのまにか入れるようになる。無料で配られているサーバーを勝手に動かしているだけなので、そんなものだろうと思っていたからです。

一度だけ、スマホのアプリを経由して繋ぐ方法も試したことがあります。繋がることは繋がったのですが、遊ぶたびにスマホを操作するのが面倒で、やめました。

今回も最初は待つつもりでいました。ただ今回は、待っても直らないやつでした。

サーバーのログを見たら、勝手に新しくなっていた

Dockerで動かしているので、こう打つとログが出ます。

docker logs mc-server

出てきたのがこれです。

================ TRANSPORT TYPE ERROR  ===================
Your current connection type is not set to NetherNet.
In this release, NetherNet is the only supported transport type.
Players will not be able to connect to your game without NetherNet.

To switch, set 'transport=nethernet' in server.properties.
=======================================================

「この版ではNetherNetしかサポートしていない。NetherNetにしないとプレイヤーは接続できません」。Switchの画面に出ていた「NetherNetで検索してください」と同じ言葉です。

少し上に遡ると、原因がはっきりしました。

Version: 1.26.51.1
Branch: r/26_u5

サーバーのバージョンが上がっていました。その前のログは 1.26.34.3 です。なぜ勝手に上がったのか。自分の設定でした。

environment:
  VERSION: "LATEST"

「常に最新版を使う」という指定です。サーバーを立てたときにそう書いて、そのまま忘れていました。この指定があると、コンテナが再起動するたびに最新のサーバーを取りに行きます。その日たまたま再起動がかかって、新しい方式が必須の版に入れ替わっていた、というわけです。

ここで、長いあいだ勘違いしていたことに気づきました。「マイクラがアップデートされるとSwitchから入れなくなる」と思っていたのですが、実際に更新されていたのはサーバーのほうでした。

NetherNetは何が違うのか

うちのサーバーには bedrock_server_how_to.html という説明書が同梱されています。マイクラを作っている会社が配っているものなので、ネット上の解説記事よりこちらが確実です。バージョンごとに中身が変わるので、自分のサーバーに入っているものを読むのが一番早いです。

そこにはこう書かれていました（1.26.51.1 に同梱されていたもの）。

transport … raknet, nethernet（既定値: nethernet）

nethernet（既定）— WebRTCベースの転送。サーバーは server-port 上のデュアルスタックTCPソケットで、HTTPベースのシグナリングのやりとりを待ち受け、そのうえでクライアントごとにUDP接続を交渉して、ゲーム本体の通信を運ぶ。

raknet — 従来のBedrockのUDP転送。サーバーは server-port と server-portv6 で直接待ち受け、クライアントはそのアドレスとポートに接続する。NetherNetが既定になる前のリリースで使われていたモード。

要するにこういう違いです。

  • RakNet … クライアントがサーバーのUDPポートへ直接つなぐ。「UDPの19132番を開ければ終わり」だったのはこれ
  • NetherNet … まずTCPで「どうやって繋ぐか」の打ち合わせをして、そのあとUDPで本番の通信をする。テレビ会議アプリに近い作り

同じ19132番でも、TCPとUDPの両方が関係します。インターネット側に公開している人は、ここで設定が増えます。説明書には、NetherNetのときだけ意味を持つ項目として、こう書かれていました。

  • server-ip … 待ち受けるアドレス。空なら全部のネットワークで待つ
  • server-udp-ports … ゲーム通信に使うUDPポートの範囲を固定したり、外から見えるポートと内側のポートの対応（NATの変換）をクライアントに伝えたりする設定。これを書かないと、サーバーは自分の家の中でしか通じないアドレスを相手に教えてしまう

さらに、インターネットに公開するならシグナリング側（TCP）の手前にリバースプロキシを置いて、リクエスト数を制限することも勧められていました。外に出すハードルは、以前より上がっています。

効かなかった対処を3つ

ここから、思いついた順に試しては外していきました。結果的に全部ハズレでしたが、同じ道をたどる人がいるはずなので、効かなかったことも書いておきます。

説明書どおり transport=raknet に戻す → うちでは拒否された

説明書に「raknetも選べる」と書いてあるので、設定ファイルに一行足しました。

transport=raknet

サーバーを完全に停止してから起動し直します（server.properties は編集しただけでは反映されません）。そしてログを見ると、まったく同じエラーが出ていました。

Your current connection type is not set to NetherNet.
In this release, NetherNet is the only supported transport type.

説明書には選べると書いてあるのに、本体は受け付けない。ドキュメントと実装が食い違っています。

ただし、これは私の環境で、1.26.51.1（Branch: r/26_u5）で起きたことです。古いビルドでは transport の既定値がRakNetのままだったという情報もありますし、そもそも transport という項目自体が無い版もあります。試す価値はあるので、自分のサーバーで設定して、起動ログでどうなるかを確認してください。設定ファイルの見た目だけでは分かりません。

待ち受けの状態は、OS側からも確認できます。

ss -lntu | grep 19132

RakNetならUDPで、NetherNetならTCPで待っているはずです。うちの場合、NetherNetで動いているときは tcp LISTEN ... *:19132 と出ました。

サーバーを前のバージョンに戻す → 今度はSwitchが拒否した

新方式が嫌なら、新方式になる前のサーバーを使えばいい。単純な発想です。

VERSION: "1.26.34.3"

心配だったのはワールドです。一度新しいサーバーで開いたワールドを古いサーバーに戻すと、壊れたり開けなかったりすることがあります。これは杞憂で済みました。

Opening level 'worlds/Bedrock_level/db'
Server started.

ワールドは普通に開きました。ついでに言うと、うちは毎日午前3時にワールドを自動バックアップしていて30世代残しているので、最悪でも前日に戻せる状態でした。こういう作業は、バックアップがあるかないかで手の出し方がまるで変わります。

しかし、Switchから入ろうとすると今度はこう出ました。

「古いバージョンのマイクラです」

当たり前でした。Switch側のマイクラはもう新しい版に更新されていて、こちらから古いバージョンに戻すことはできません。サーバーを新しくすると新方式で入れない、古くするとバージョン違いで入れない。完全に挟まれました。

別のサーバーソフトに載せ替える → RakNetは話せたが、それでも入れなかった

公式のサーバーが新方式しか受け付けないなら、両方に対応している別のサーバーを使えばいいのでは、と考えました。マイクラのサーバーには、有志が作っている互換ソフトがいくつかあります。その一つの PowerNukkitX が、ちょうど前日に新バージョンへ対応していました。

いまのサーバーは触らずに、別のポート（19134）で検証用に立てました。遊んでいるワールドを壊すわけにはいかないので、まっさらな新規ワールドです。起動ログにはこう出ました。

RakNet listening on udp/19134

外から問い合わせると、ちゃんと返事が返ってきます。

MCPE;Yuru Test Server;2193;1.26.50;0;20;...;Survival;1;19134;19134

従来方式で待ち受けている状態です。これならSwitchから届くはず——と思って試してもらったら、またさっきの「マルチプレイ接続失敗」でした。

ここでようやく、最初のエラー文をちゃんと読み直しました。「サーバーに接続できません」ではなく「クライアントがマルチプレイサービスへの接続を確立できません」。サーバーの手前で止まっている、という意味だったわけです。

犯人は、Switch側の設定でした。

原因はSwitchのDNS設定だった

Switchのマイクラには、サーバーのアドレスを自分で入力する画面がありません。PC版やスマホ版にある「サーバーを追加」が、コンソール機には無いのです。自宅に立てたサーバーで遊ぶには、どうにかして「ここに繋げ」と伝える必要があります。

そこで昔から使われているのが、DNSを書き換える方法です。Switchのネットワーク設定でDNSを手動にして、専用のアドレスを入れておく。すると「サーバー」タブに並んでいる公式サーバーを選んだときに、本物ではなくアドレスを入力できる画面が出てきます。そこで自宅サーバーのIPを打ち込む。うちもこれで遊んでいました。

この設定が、悪さをしていました。

新しい通信方式では、サーバーに繋ぐ前にMicrosoft側のサービスと話をする必要があります。DNSを書き換えていると、その通信まで巻き添えで壊れてしまう——というのが私の理解です。「クライアントがマルチプレイサービスへの接続を確立できません」は、そのままの意味だったわけです。

確かめ方は簡単でした。DNSを元に戻して、公式サーバーに入れるかどうか見ればいい。

1. 設定 → インターネット → インターネット設定 → 接続中のネットワークを選ぶ → 設定の変更 → DNS設定 を 「自動」 にする
2. マイクラを完全に終了して起動し直す（ホーム画面に戻るだけでは足りません。ソフトを閉じます）
3. 「サーバー」タブの、もともと並んでいる公式サーバーのどれかに入ってみる

入れました。つまりDNSの書き換えが原因、で確定です。

なお、DNSを書き換える方法そのものは、公式に用意された仕組みではありません。新しい通信方式に対応しているという公式の情報は見つけられませんでした。うまく動いていたのはたまたまで、いつ使えなくなってもおかしくない類のものだった、ということだと思います。

入口は「サーバー」タブではなく「フレンド」タブだった

ただ、DNSを自動に戻すと、今度は自宅サーバーを指定する画面が出せません。八方塞がりに見えました。

ところが、DNSを戻した状態でマイクラの「フレンド」タブを開いたら、そこに自宅のワールドが出ていました。「LANワールド」として。選んだら、いつものワールドにそのまま入れました。息子と作った建物もそのままです。

これが今の正解でした。

  • 入口は「サーバー」タブではなく「フレンド」タブ
  • 同じLAN（同じ家のWi-Fi）にいる機器には、サーバーが自分から「ここにいますよ」と知らせている
  • DNSは書き換えない。自動のまま

サーバー側では、この設定が関係します。

enable-lan-visibility=true

LAN上での検出に応答するかどうかの設定です。説明書によると、RakNetで動いている場合、この設定を有効にすると、server-port を別の番号に変えていても既定の19132番・19133番にも追加でバインドします。同じ機械で複数のサーバーを動かしている人は、ここがポート衝突の原因になります。「ポート番号を分けたのに起動しない」ときは疑ってみてください。

ずっと遠回りをしていたことになります。アドレスを入力する画面を出すことばかり考えていましたが、そもそも入力しなくても見える道が用意されていた。ただし、それが見えるようになるにはサーバー側にもう一つ条件がありました。

Dockerで動かしているなら、ここも疑う（network_mode: host）

実は、DNSを戻す前の段階で、サーバー側の設定をもう一つ変えていました。結果から言うと、これが無ければ「フレンド」タブにも出てきませんでした。

Dockerでサーバーを動かすとき、既定ではコンテナは仮想的な別のネットワークの中にいます。外から使えるように、必要なポートだけを通してやる形です。うちの設定もそうなっていました。

ports:
  - "19132:19132/udp"

これで、外からポート19132に来た通信はコンテナに届きます。PCから「このIPのこのポート」と指定して繋ぐぶんには、これで足ります。実際、PCからはずっと入れていました。

ただ、「フレンド」タブに出てくる仕組みは、これでは足りません。あれはサーバーが家のネットワーク全体に向かって「ここにいますよ」と呼びかけているもので、宛先を指定しない通信です。この呼びかけが、Dockerの仮想ネットワークの外に出ていかない。だからSwitchからは、家の中にいるのに見えなかったわけです。

しかも、この呼びかけに使われているのは19132番ではありませんでした。うちのサーバーが動いている機械で、どのプログラムがどの口を開けているのか見てみると、こうなっていました。

$ sudo ss -lnup | grep 7551
UNCONN 0  0  *:7551  *:*  users:(("bedrock_server-",pid=22344,fd=21))

UDP 7551番を、マイクラのサーバー本体が開けています。ゲーム本体の通信とはまったく別の口です。ちなみに19132番のほうは、NetherNetで動いているいまはTCPでしか待っていません。

$ ss -lnt | grep 19132
LISTEN 0  5  *:19132  *:*

つまり「19132番さえ通してあれば大丈夫」と思って ports に19132番だけ書いていると、LAN検出の呼びかけは通り道が無いままになります。私がまさにこれでした。ポートを一つずつ開けていくより、network_mode: host にしてしまうほうが確実です。

切り分けのために、ホストのネットワークを直接使う形に変えました。

# 変更前
ports:
  - "19132:19132/udp"

# 変更後
network_mode: host

network_mode: host は、「コンテナを仮想ネットワークに入れず、家のネットワークに直接いることにする」という指定です。こうすると ports の指定は不要になります（書いてもエラーになります）。Dockerのポート転送を経由しなくなるので、Docker側が原因かどうかを切り分けるのにも使えます。

注意点があります。

  • サーバーが使うポートは機械本体のポートをそのまま占有します。同じポートを使う別のソフトがあると衝突します
  • これは「Switchから繋ぐための公式な作法」ではありません。うちの環境ではこれで見えるようになった、という話です
  • hostにしただけで、ルーターのポート開放やファイアウォールの設定が正しくなるわけではありません

待ち受けの状態は、さきほどのコマンドで確認できます。

ss -lntu | grep 19132

最終的な設定ファイルは、こうなりました。

services:
  mc-server:
    image: itzg/minecraft-bedrock-server
    container_name: mc-server
    restart: always
    stop_grace_period: 60s
    environment:
      EULA: "TRUE"
      VERSION: "LATEST"
      SERVER_PORT: "19132"
      ALLOW_LIST: "true"
    network_mode: host
    volumes:
      - /home/ユーザー名/minecraft/data:/data

VERSION は LATEST のままにしました。古い版に固定してもSwitchから弾かれるので、もう上げ続けるしか道がないからです。今回のようなことがまた起きる可能性は残りますが、退路がない以上そうするしかありません。

出先からSwitchで入る道は、ほぼ塞がった

正直に書きます。ここは直せていません。

これまでは、外部トンネルのサービスと、さきほどのDNS書き換えを組み合わせて、旅行先や出張先からも息子と一緒に遊べていました。これが今回、まるごと使えなくなりました。

理由は単純で、Switchには接続先を入力する画面が無いからです。回線側をどう工夫しても——トンネルを張っても、VPNを通しても——入力する場所が無ければそこへ行き着けません。唯一の抜け道がDNS書き換えで、それが今回塞がれた、という話です。

いま分かっている範囲を整理すると、こうなります。

  • 家の中のSwitch … ○ 「フレンド」タブのLANワールドから入れる
  • 家の中のPC … ○ アドレスを指定して入れる
  • 出先のPC … ○ VPNで自宅に入ってしまえば、家の中と同じ
  • 出先のSwitch … △ 規約違反のリスクを取る方法しか残っていない（後述）

出先のPCについては、外部トンネルよりVPNのほうが楽だと思っています。うちはすでに自宅にVPN（Tailscale）を入れていて、これは別の記事に書きました。PCなら自宅サーバーのアドレスを指定して繋げるので、VPNで家の中に入ってしまえばそれで済みます。外部トンネルのように、自宅サーバーを世界に向けて開かずに済むのも安心です。

外部トンネルを使い続ける場合は、新方式に合わせて設定が増えます。ここは私はまだ試していませんが、説明書を読む限りこうなるはずです。

  • シグナリング用にTCPのポートを通す
  • ゲーム本体の通信用にUDPのポート範囲を通す
  • server-udp-ports に「外から見えるアドレスとポート → 内側のポート」の対応を書く

ひとつだけ残っている方法（ただし私は使いません）

スマホを中継役にしてSwitchから繋ぐタイプの第三者製アプリがあります。私も以前ひとつ使ってみて、遊ぶたびにスマホを操作するのが面倒でやめました。

このとき私が知らなかったのですが、この手のアプリには「Xbox Live経由で『フレンド』タブに表示させる」という方式のものがあります。こちらは同じWi-Fiにいる必要がありません。仕組みとしては、捨てアカウントでサインインしてサーバーを「そのアカウントが遊んでいるゲーム」として流し、Switch側のフレンド一覧に出す、というものです。つまり出先からでも使える可能性があります。

ただし、この方式を提供している側が、自分でこう警告しています。

Broadcasting to Xbox Live works by emulating a game client. This may break Xbox Live’s terms of service, and the account you sign in with could be banned.

（Xbox Liveへのブロードキャストは、ゲームクライアントを装うことで動いています。Xbox Liveの利用規約に反する可能性があり、サインインに使ったアカウントはBANされることがあります）

条件と注意点は、こうなっています。

  • 捨てアカウント（本アカウントとは別のMicrosoftアカウント）が必須。BANされるのはサインインした側のアカウントです
  • その捨てアカウントを、遊ぶ側のアカウントのフレンドに登録しておく必要がある
  • ベータ扱いの機能で、使えない時間帯がある
  • 新しい通信方式に対応しているかは、提供元のサイトに記載がありません。私も試していないので分かりません

私はこの方法を取らないことにしました。使い勝手の問題もありますが、息子と遊ぶために、アカウントがBANされる可能性を引き受けるのは割に合わないと考えたからです。

なので、うちの結論は「出先での同時プレイはあきらめる」です。ただし「手段がまったく無い」わけではありません。リスクを承知のうえで使う方法なら残っている、というのが正確なところです。

出先のSwitchについては、理屈の上では「持ち運べるルーターを経由して、自宅のネットワークの中にいることにする」という手があります。ただし「ここにいますよ」という呼びかけを通すには、経路だけをつなぐタイプのVPNでは足りません。もっと低い層でつなぐ仕組みが要ります。機材も設定も大がかりで、うまくいく保証もないので、私はここまでやらないことにしました。

復活の目は2つあります。DNS書き換えの仕組みを作っている人たちが新方式に対応するか、マイクラ側がコンソール機でのサーバー追加を解禁するか。どちらも待つしかありません。出先での同時プレイは、当面あきらめています。

確認する順番（自分用のメモ）

同じ症状になったとき、この順番で見ると切り分けやすいと思いました。

1. PCなど他の端末から入れるか確かめる。入れるなら、サーバーではなくクライアント側を疑う
2. サーバーのログを見る（docker logs など）。バージョンが上がっていないか、トランスポート関連のエラーが出ていないか
3. 自分のサーバーに同梱されている説明書（bedrock_server_how_to.html）を開く。ネットの解説記事ではなくこれを見る。transport という項目があるか、既定値は何か
4. transport=raknet を試し、サーバーを完全に停止してから起動し直す。効くかどうかはビルドによる
5. ss -lntu | grep 19132 で実際の待ち受けを見る。RakNetならUDP、NetherNetならTCP
6. enable-lan-visibility による19132・19133への追加バインドを確認する（複数サーバーを動かしているとき）
7. Dockerならbridge構成とhost構成を一つずつ試す
8. SwitchのDNS設定を「自動」に戻し、マイクラを完全に終了してから起動し直す
9. 「フレンド」タブにLANワールドとして出ていないか見る
10. 出先からの接続は、上が全部片付いてから考える

断定できないこと

この記事で確かなのは、うちのサーバー（1.26.51.1 / Branch r/26_u5）とうちのSwitchで起きたことだけです。

通信方式がRakNetからNetherNetへ切り替わっていること、NetherNetがTCPのシグナリングとUDPのゲーム通信を組み合わせる方式であることは、サーバー同梱の説明書で確認しました。一方で、次のことは断定できません。

  • すべてのバージョンで transport=raknet が拒否されるのか。うちでは拒否されましたが、ビルドによって既定値も対応状況も違うようです
  • 入れなくなった原因が、本当に通信方式の変更「だけ」なのか。ルーターのNAT、ファイアウォール、Dockerのポート転送、LAN検出の設定が同時に絡んでいる可能性はあります
  • DNS書き換えが壊れた理由は、私の推測です。公式の説明を見つけたわけではありません
  • UDP 7551番がLAN検出に使われていることは、自分の機械で bedrock_server が開けているのを確認しました。ただしどのバージョンでもこの番号なのかは確認していません
  • 出先向けの中継アプリが、いまの通信方式で動くのかどうか。使っていないので分かりません

なので、ここに書いた手順をそのまま信じるのではなく、自分の環境で一つずつ確認してもらうのが確実です。特に「自分のサーバーに入っている説明書を読む」は、遠回りに見えて一番早い道でした。

まとめ

  • Switchから急に入れなくなったら、まずPCから入れるか試す。入れるならサーバーは生きている
  • 次にサーバーのログ。マイクラ本体ではなく、サーバーが勝手に新しくなっていることがある
  • Your current connection type is not set to NetherNet が出ていたら、通信方式の切り替わりに巻き込まれている
  • 説明書にある transport=raknet は、うちでは拒否された。効くかはビルド次第なので、ログで確認する
  • 古いバージョンへの固定は退路にならない。Switch側はもう新しくなっていて、下げられない
  • SwitchのDNSは「自動」に戻す。DNS書き換えで自宅サーバーに入る方法は、繋がらない原因そのものになっていた
  • 入口は「サーバー」タブではなく「フレンド」タブのLANワールド
  • Dockerなら network_mode: host も試す。仮想ネットワークの中にいると、LANへの呼びかけが外に出ない。呼びかけに使われるのは19132番ではなくUDP 7551番だった
  • 出先のSwitchは、規約違反とBANのリスクを取る方法しか残っていない。うちはあきらめました

作業に入る前に、ワールドのバックアップだけは取ってください。私は毎日自動で取っていたので、バージョンを上げ下げする作業も気楽にできました。戻せる状態を作ってから触る、これに尽きます。

うちは結局、その晩のうちに息子とまた同じワールドに入れました。遠回りはしましたが、家の中で遊ぶぶんには元通りです。サーバーを置いているNAS本体の話はこちらの記事に書いています。