最新の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のセクションでは, そのホストを指すドメイン名もいります。
NATの背後にいる場合は, NetherNetのトラブルシューティングのポート開放セクションを参考にマッピングを行ってください。
公式の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/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=falsetransport=nethernet**を設定すると, BDSはUDPメディアソケットに加えて, server-port上でTCPのHTTP シグナリングサーバーを開きます。server-udp-ports**はUDPメディアポートを制御します。ip:プレフィックスを付けると, 外部から到達可能なマッピングを広告します。コロンの両側の範囲は同じ長さでなければなりません。同時接続プレイヤー1人につき, 少なくとも1つのUDPポートが必要です。 max-playersと同じかそれ以上の範囲を開放し, さらに余裕を持たせてください。保留中や途中まで開いたセッションも, タイムアウトするまでそれぞれポートを占有するためです。範囲が小さすぎると, いっぱいになった時点で新しい接続を黙って拒否します。上記の例(19132〜19151)では20個のポートを確保しています。各サーバーは長期間有効なアイデンティティキーを持っています。
クライアントが信頼するのはその公開鍵です。信頼はその鍵に紐づくのであって, ホスト名, 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証明書が信頼を提供します。
到達可能にすべきものは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は介在しません。
/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
UNITsudo systemctl daemon-reload
sudo systemctl enable --now bedrock
sudo systemctl status bedrock --no-pager
journalctl -u bedrock -f # ログを監視しますシグナリングエンドポイントは, ステータスリクエストに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で提供したい場合は, 以下を続けてください。
大規模なネットワークでは, シグナリングエンドポイントをHTTPSで提供しています。
同じようにするには, BDSをループバックにバインドし, パブリックポートではnginxにTLSを終端させます。
server.propertiesで, シグナリングソケットをlocalhostに制限し, nginxがパブリックポートを占有できるようにしてから, 再起動します:
server-ip=127.0.0.1
server-port=19132sudo systemctl restart bedrockserver-ipはnethernetでも有効です。
UDPメディアは引き続きserver-udp-portsのパブリックマッピングを使います。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クライアントや診断ツールは, ハンドシェイク中に接続を拒否します。
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-runTLS越しに確認します:
curl https://mc.example.com:19132/v1/join今度はHTTPS越しに, 同じJSONが得られるはずです。
プロキシされるのはシグナリングだけで, UDPメディアは引き続きserver-udp-portsのポートへ直接流れます。
ローカルのcurlは, サーバーが自分自身に応答することを証明するだけです。
パブリックなインターネットから到達可能かを確認するには, このサイトのiceFetchツールが便利です。ローカルテストでは捕捉できないNAT, ファイアウォール, 証明書の問題を見つけられます。
Cloudflareのエッジからあなたのサーバーに疎通確認を行います:
mc.example.com)とPort(19132)を入力します。transportはautoのままにしてください。プレーンなHTTPを使い, サーバーがHTTPS専用の場合はTLSにフォールバックします。server-udp-portsのマッピングは正しいはずです。Server infoが失敗する場合, シグナリングが到達不能です(TCPポート, NATの転送, またはHTTPSの場合は証明書を確認してください)。
infoは動作するのにFetch candidatesが0を返す場合は, UDPプールが一時的に枯渇しているか, メディアポートが到達不能です。server-udp-portsを広げ, UDPのファイアウォールを確認してください。
ポートなどの設定がうまく行っていることを確認してください。また, NetherNetのトラブルシューティングを参考にしてもいいかもしれません。
NetherNetサーバーは, 実際には1つのアドレス上の2つのサービスです。HTTPシグナリングエンドポイント(TCP)と, WebRTCメディア(UDP)です。
両方を到達可能にし, BDSをsystemd のサービスとして実行し, 必要に応じてシグナリングをnginx + TLSで包めば, すっきりしたHTTPSの前段になります。
そして, iceFetchで全体を外部から確認してください。
シグナリングのやり取りが内部で実際にどのようなものかについては, iceFetchの仕組みをご覧ください。
ツール解説記事APIプライバシー規約 · iceFetch は Mojang および Microsoft とは無関係です。