友達のためにパルワールド専用サーバーを立てる

友達がパルワールド(Palworld)の 1.0 を見て、一緒にやろうと誘ってきた。彼らは二年前に一度クリア済みで、この大型アップデートを機にもう一周したいらしい。私もちょうどその時期は暇だった。

正直、このゲームへの第一印象はよくなかった。当時の「ポケモンのパクリ」騒動があったからだ。でも後にその訴訟に勝ち、1.0 の更新幅も本当に大きいので、思ったほどひどくないのかもと、私も手を出した。

友達は最初、Radmin VPN でみんなを繋いでいた。この方法は駄目とは言わないが、私にはいつも資安面のもやもやが残る。Radmin のような仮想 LAN は P2P で動く。両端が直接繋げるなら直接繋ぎ、相手の NAT やファイアウォールを抜けられないと、サービス提供元自身の中継サーバーに退避する。友達の家のネットワークを考えると、どの組も全部抜けられるとは思えず、大半は中継に落ちるだろう。中継の代償は二段階ある。一つは遅い(パケットが遠回りする)、もう一つはゲームのトラフィックが無料・クローズドソースのサービスのサーバーを通ること。確かに全体は暗号化されている。だが接続を第三者に一周させるかどうかは、私にとっては不要なリスクだ。そして私にはちょうど 24/7 で動いている家用マシンがあったので、彼らの進行がまだ浅いうちに割り込んだ。専用サーバーを立てよう、みんな私の家に直接繋げばいい。

というわけでこの記事だ。Docker でパルワールド専用サーバーを立てるのは難しくない。docker compose up で数分で動きだす。難しいのは次の一歩:立ったのに、友達が入ってこられない。 ここで詰まる人は、「どう立てるか」で詰まる人よりずっと多い。この記事は全行程を一通り歩く。リソース見積もり、docker-compose、最も詰まりやすい UDP 接続、そして「友達がバージョン不一致で入れないと言う」の直し方まで。すべてのコマンドはそのまま実行でき、パスワードと IP はプレースホルダなので、自分のものに置き換えてほしい。

まず、どの image を使うか、そしてメモリは実際どれだけ食うか#

先に一言:多くの人が自ホストで使うのは公式の専用サーバーツール(SteamCMD で直接 PalServer を引く)で、必ずしも Docker ではない。 私が Docker を選ぶのは、単に使い慣れていて、マシン上の他サービスと一貫して管理しやすいからだ。あなたも常時起動のサーバーがあって docker が手に馴染むなら、この道は快適だ。使っている image はコミュニティ管理の thijsvanloef/palworld-server-docker で、SteamCMD のダウンロード、設定ファイル生成、バックアップ、RCON を全部包んでいる。

メモリはまず一つ迷信を崩したい。ホスティング業者のスペックページを見ると、判で押したように「16GB から、32GB でより安定」と書いてある。あの数字は保守的だ(彼らは RAM も売っている)。実際には小規模なら日常はとても軽い。私のこの Linux docker で 3~5 人を回して、実測はだいたい 1.2GB あたりだった(長時間監視ではなく、ふと見た値)。

ではなぜまだメモリを気にするのか。パルワールドにはメモリリークという持病があるからだ。プロセス自体が時間とともに少しずつ肥大していく。ゲーム内で何を建てたかとは無関係に。コミュニティの実測では、4 人サーバーを再起動なしで回し続けると、一週間で 5G から 8~12G まで登ることがある。だから正しい手は 32G を用意することではなく、mem_limit で上限を抑え、毎日の定時再起動(メモリを解放する。誰かオンラインなら延期)を組み合わせ、リークを妥当な範囲に押さえること。そうすればいくら長く回しても、同じマシンの他サービスを巻き込まない。

最小限で動く docker-compose#

コアの設定はそう多くない。枝葉を落として、本当に押さえるべき数行だけ残したものがこれ:

services:
  palworld:
    image: thijsvanloef/palworld-server-docker:latest
    restart: unless-stopped
    container_name: palworld
    stop_grace_period: 30s          # 停止シグナル後、保存に 30 秒残す
    ports:
      - "8211:8211/udp"             # ゲーム接続、UDP(重要、下で詳述)
      - "27015:27015/udp"           # Steam query、UDP
      - "127.0.0.1:25575:25575"     # RCON、ローカルのみ、外からは触れない
    environment:
      PLAYERS: "16"
      SERVER_NAME: "My Palworld"
      SERVER_PASSWORD: "<あなたのサーバーパスワード>"
      ADMIN_PASSWORD: "<あなたの管理パスワード>"
      UPDATE_ON_BOOT: "true"        # コンテナ起動時にゲーム更新を確認
      RCON_ENABLED: "true"          # 自動バックアップ/再起動が優雅な終了に使う
      BACKUP_ENABLED: "true"
      AUTO_REBOOT_ENABLED: "true"   # 毎日再起動、肥大したメモリを解放
    mem_limit: 16g
    volumes:
      - ./data:/palworld            # ゲーム本体 + セーブがここ

今は目立たないが後で踏むポイントがいくつか:

• 8211 と 27015 の後ろの /udp を落とさないこと。パルワールドは UDP で動く。うっかり TCP と書くと、サーバーは起動し、自分のローカルからも繋げるが、外の人は一人も入れない。
• RCON を 127.0.0.1 に固定:自動バックアップ/再起動が先に警告をブロードキャストして優雅に終了するための管理チャネルで、ローカル専用、外に出してはいけない。
• mem_limit と AUTO_REBOOT_ENABLED は一組で、上のメモリ肥大に真正面から対処するもの。

本当に詰まるのはネットワーク:UDP 接続の三つの関門#

docker compose up -d のあと、サーバーは 8211 で動き、同じネットワークから LANのIP:8211 に繋ぐのは大抵問題ない。そして友達が繋ぐと、入ってこられない。

パケットがインターネットからあなたの家のあのコンテナまで届くには、途中に三つの関門があり、一つでも欠けると通れないからだ:

sudo ufw allow 8211/udp comment 'Palworld game'
sudo ufw allow 27015/udp comment 'Palworld query'

二つのよくある誤解を、時間を無駄にする前にはっきりさせておく:

では 27015 は開ける必要があるのか。これは Steam の query ポート(A2S プロトコル)で、「あなたのサーバーの状態が Steam のサーバーブラウザに表示されるかどうか」だけに関わる。最小限にしたいなら まず 8211 だけ開ける。友達は あなたのアドレス:8211 に直接繋いで遊べる。誰かが本当に Steam のお気に入りからオンライン状態を見たがったら、あとで 27015 を足せばいい。

ワールド設定の落とし穴:ini を直接いじると上書きされる#

サーバーが繋がったら、経験値倍率などを調整したくなるはずだ。ここに必ず踏む落とし穴がある:この image は起動のたびに環境変数から PalWorldSettings.ini を再生成する。 その ini ファイルを手で書き換えても、次のコンテナ再起動で上書きされ、直したのに直っていない状態になる。

正しいやり方は、設定を docker-compose.yml の environment ブロックに書き、生成時にあなたの値を持たせること。よく使うもの:

友達が「バージョン不一致」で入れない:サーバーが遅れている#

数日遊んで、ある友達が「入れない、バージョン不一致と出る」と報告してきた。ほぼ必ず同じ原因だ:彼の client はすでに新版に自動更新され、あなたの server は旧版に止まっている。

どう確認する?buildid を比べる:ローカル server の buildid を Steam 最新の buildid と突き合わせ、違えば遅れている。

ここに厄介な錯覚を暴いておく:コンテナのログに container is up to date と出ていて、もう最新だと思い込むこと。あの一行は Docker image が最新という意味で、ゲームファイルが最新という意味ではない。 ゲーム更新は UPDATE_ON_BOOT がコンテナ起動時に SteamCMD を一度走らせて引くもので、コンテナが数日再起動なしで回り続けていたら、この数日の新版を掴む機会がなかったわけだ。

直し方はコンテナを再起動して、SteamCMD 更新を一度トリガーすること:

docker compose up -d --force-recreate

だが再起動はオンラインの人を蹴り出す。直接やってはいけない。優雅なやり方は、まず RCON でブロードキャストして保存し、それから再起動すること:

毎回手動で見張りたくなければ、AUTO_UPDATE_ENABLED をオンにする。server が定時に自分で更新を確認し(誰かオンラインなら先にブロードキャストしてから更新するよう設定もできる)、ゲームに新版が出ても友達が入れなくなることは二度と起きない。

18GB のゲーム本体を毎日バックアップディスクに入れない#

最後に見落としやすい運用の罠。私のように、サーバーのディレクトリ全体を毎日 rsync でバックアップする仕組みがあるなら、パルワールドを足したあとは要注意だ:あの data/ フォルダはゲーム本体まるごと、18GB 近くを抱えていて、放っておくと毎日バックアップディスクに詰め込まれる。

本当にバックアップが要るのはセーブだけで、あの 18GB のゲームファイルではない(ゲームファイルはいつでも再ダウンロードできる)。だから:

• メインの rsync から palworld/data(ゲーム本体)を除外する
• セーブディレクトリ(Pal/Saved)を単独でバックアップする。消えたら痛いのはそこだ
• パルワールドのセーブも既存の古いバックアップ整理ループに入れる(例:7 日だけ残す)

.gitignore の方も data/ が除外されているかついでに確認し、18GB のゲームファイルがバージョン管理に紛れ込まないようにする。

一ページのチェックリスト#

全行程を、そのまま写せる順番に凝縮: