iceFetchツール解説記事プライバシー規約English

Debian/UbuntuでNetherNet対応のMinecraft Bedrockサーバーを構築する（nginxによるHTTPS付き）

2026-09-23

近年のMinecraft Bedrock Dedicated Server (BDS) のビルドは、従来のRakNet UDPプロトコルを置き換えるWebRTCベースのトランスポートであるNetherNetに対応しています。本ガイドではDebian 12 / Ubuntu 22.04+向けに、BDSのインストール、NetherNetの有効化、適切なポートの開放、systemd のサービスとしての実行、必要に応じてnginxでシグナリングの前段にHTTPSを配置する方法、そして最後にiceFetchツールを使ってサーバーが到達可能かを確認するまでを、コピー＆ペースト可能なコマンドで示します。

NetherNetは接続を2つのチャネルに分けます。TCP上で行われる小さなHTTPシグナリングのやり取りと、UDP上で行われる実際のゲームプレイ（暗号化されたWebRTCデータチャネル）です。両方のポートを開放する必要があります。

前提条件

sudo apt update
sudo apt install -y unzip curl

パブリックIPを持つ64ビットのDebian/Ubuntuホスト（またはポートフォワードできるルーター）が必要です。HTTPSのセクションでは、そのホストを指すドメイン名も必要になります。

1. BDSをダウンロードして展開する

公式のBedrockサーバーダウンロードページを開き、利用規約に同意して、Linux向けのダウンロードリンクをコピーします（バージョン番号が付いています。例: bedrock-server-1.26.x.zip）。その後:

# ダウンロードページからコピーしたURLを貼り付けてください
cd /tmp
curl -L -A "Mozilla/5.0" -o bedrock-server.zip "PASTE_THE_LINUX_ZIP_URL_HERE"

sudo mkdir -p /opt/bedrock
sudo unzip -o /tmp/bedrock-server.zip -d /opt/bedrock

# 専用の非特権ユーザーで実行します
sudo useradd -r -m -d /opt/bedrock -s /usr/sbin/nologin bedrock 2>/dev/null || true
sudo chown -R bedrock:bedrock /opt/bedrock

2. server.propertiesでNetherNetを有効化する

/opt/bedrock/server.propertiesを編集し（例: sudo -u bedrock nano /opt/bedrock/server.properties）、次のように設定します:

transport=nethernet
server-port=19132
# server-portv6 は nethernet では無視されます — server-port 上でデュアルスタックのソケットが開かれます。

# ゲームプレイのメディア用のUDPクライアントトランスポートポートです。
# 形式: [ip:]external[-external]:internal[-internal]
# 外部から到達可能なマッピングを公開します（あなたのパブリックIPに置き換えてください）:
server-udp-ports=203.0.113.10:19132-19151:19132-19151

online-mode=true
allow-list=true
enable-lan-visibility=false

3. サーバーアイデンティティキーを保存する（そして複数サーバー間で共有する）

各サーバーは長期間有効なアイデンティティキーを持っています。クライアントが信頼するのはその公開鍵です — 信頼はその鍵に紐づくのであって、ホスト名、IP、network idには紐づきません。プレーンなHTTPシグナリングでは、クライアントは初回接続時にその鍵をピン留めします（trust-on-first-use）。そのため、最初の接続では一度だけ信頼確認のステップが表示されます。

この鍵は手動で保存します。初回起動時に、サーバーコンソールで次のコマンドを実行してください:

serveridentity save

これにより、現在の鍵がkeys/server_identity_key.pemに書き出されます（serveridentity statusで確認でき、serveridentity deleteで削除できます）。現在の鍵は次回起動まで変わらない点に注意してください — 保存した後はサーバーを再起動し、永続化された鍵を読み込ませてください。

複数のサーバーを運用していますか？ このファイルを、同じアイデンティティを共有させたいすべてのサーバーにコピーして、それらを再起動してください。すると各サーバーは同じアイデンティティキーを提示するため、クライアントはグループ全体を1つのアイデンティティとして扱います。初回（HTTPのみ）の信頼確認ステップは、サーバーごとではなくグループ全体で一度だけ発生します。このファイルは非公開にしてください — 入手した者は誰でもあなたのサーバーグループになりすませます。

このtrust-on-first-useのステップは、プレーンなHTTPシグナリングに適用されます。シグナリングの前段にHTTPSを配置する場合（後述）は、代わりにTLS証明書が信頼を提供します。

4. ファイアウォールを開放する（ufw）

2つの異なるものが到達可能でなければなりません — TCPのシグナリングポートと、UDPメディアの範囲です:

sudo apt install -y ufw
sudo ufw allow 19132/tcp
sudo ufw allow 19132:19151/udp
sudo ufw enable

ホストがNATの背後にある場合は、ルーターで同じTCPポートとUDP範囲をそのホストに転送してください。単純なポートフォワードで十分です — クライアントはサーバーがアドバタイズするcandidateにUDPで直接接続し、別途relayは介在しません。

5. systemd のサービスとして実行する

/etc/systemd/system/bedrock.serviceを作成します:

sudo tee /etc/systemd/system/bedrock.service >/dev/null <<'UNIT'
[Unit]
Description=Minecraft Bedrock Dedicated Server
After=network-online.target
Wants=network-online.target

[Service]
User=bedrock
WorkingDirectory=/opt/bedrock
Environment=LD_LIBRARY_PATH=.
ExecStart=/opt/bedrock/bedrock_server
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
UNIT
sudo systemctl daemon-reload
sudo systemctl enable --now bedrock
sudo systemctl status bedrock --no-pager
journalctl -u bedrock -f      # ログを監視します

6. ローカルで確認する

シグナリングエンドポイントは、ステータスリクエストにJSONで応答します:

curl http://127.0.0.1:19132/v1/join
# {"name":"Dedicated Server","protocol":2193,"version":"1.26.x",
#  "level":"...","players":0,"maxPlayers":10,"gameType":0}

そのJSONが表示されれば、シグナリングは動作しています。この時点で、プレイヤーはすでにプレーンなHTTPシグナリング経由で接続できます。代わりにシグナリングをHTTPSで提供したい場合は、以下を続けてください。

7. （任意）nginx + Let’s EncryptによるHTTPS

大規模なネットワークでは、シグナリングエンドポイントをHTTPSで提供しています。同じことをするには、BDSをループバックにバインドし、パブリックポートではnginxにTLSを終端させます。

7a. BDSをループバックにバインドする

server.propertiesで、シグナリングソケットをlocalhostに制限し、nginxがパブリックポートを占有できるようにしてから、再起動します:

server-ip=127.0.0.1
server-port=19132
sudo systemctl restart bedrock

（server-ipはnethernetでも有効です。）UDPメディアは引き続きserver-udp-portsのパブリックマッピングを使います — nginxはそれには関与しません。

7b. nginxをインストールして証明書を取得する

sudo apt install -y nginx certbot

# HTTP-01チャ範囲には、発行中にポート80が到達可能である必要があります
sudo ufw allow 80/tcp
sudo certbot certonly --standalone -d mc.example.com
証明書は、プレイヤーが接続するホスト名と一致していなければなりません。 アドレスがmc.example.comであれば、証明書のsubject/SANもmc.example.comでなければなりません。不一致があると、厳格なTLSクライアントや診断ツールは、ハンドシェイク中に接続を拒否します。

7c. nginxのリバースプロキシ

sudo tee /etc/nginx/sites-available/bedrock-signaling >/dev/null <<'CONF'
server {
    listen 19132 ssl;
    listen [::]:19132 ssl;
    server_name mc.example.com;

    ssl_certificate     /etc/letsencrypt/live/mc.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mc.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:19132;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_read_timeout 30s;
    }
}
CONF

sudo ln -sf /etc/nginx/sites-available/bedrock-signaling /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

証明書を最新の状態に保ちましょう — certbotは更新用のタイマーをインストールします。更新時にはnginxをリロードしてください:

sudo certbot renew --deploy-hook "systemctl reload nginx" --dry-run

TLS越しに確認します:

curl https://mc.example.com:19132/v1/join

今度はHTTPS越しに、同じJSONが得られるはずです。プロキシされるのはシグナリングだけで、UDPメディアは引き続きserver-udp-portsのポートへ直接流れます。

8. iceFetchで動作を確認する

ローカルのcurlは、サーバーが自分自身に応答することを証明するだけです。パブリックなインターネットから到達可能であること — ローカルテストでは捕捉できないNAT、ファイアウォール、証明書の問題を見つけること — を確認するには、このサイトのiceFetchツールを使ってください。Cloudflareのエッジからあなたのサーバーに到達します:

  1. iceFetchツールを開きます。
  2. サーバーのHost（例: mc.example.com）とPort（19132）を入力します。transportはautoのままにしておきます — プレーンなHTTPを使い、サーバーがHTTPS専用の場合はTLSにフォールバックします。
  3. Server infoをクリックします — サーバーの名前、バージョン、プレイヤー数が表示されるはずです。これでシグナリングが外部から到達可能であることが確認できます。
  4. Fetch candidatesをクリックします — 1つ以上のICE candidateが得られるはずです。これらはサーバーがゲームプレイ用にアドバタイズするUDPエンドポイントです。正しいパブリックアドレスが列挙されていれば、server-udp-portsのマッピングは正しいということです。
Server infoが失敗する場合、シグナリングが到達不能です（TCPポート、NATの転送、またはHTTPSの場合は証明書を確認してください）。infoは動作するのにFetch candidatesが0を返す場合は、UDPプールが一時的に枯渇しているか、メディアポートが到達不能です。server-udp-portsを広げ、UDPのファイアウォールを確認してください。

まとめ

NetherNetサーバーは、実際には1つのアドレス上の2つのサービスです。HTTPシグナリングエンドポイント（TCP）と、WebRTCメディア（UDP）です。両方を到達可能にし、BDSをsystemd のサービスとして実行し、必要に応じてシグナリングをnginx + TLSで包んで、すっきりしたHTTPSの前段を用意しましょう — そしてiceFetchで全体を外部から確認します。シグナリングのやり取りが内部で実際にどのようなものかについては、iceFetchの仕組みをご覧ください。

ツール解説記事プライバシー規約 · iceFetch は Mojang および Microsoft とは無関係です。