7 Days to Die サーバーの立て方｜迷わない選び方と最短で成功する手順まとめ

2026年2月14日

「7 Days to Dieで友達と遊びたい。でもサーバーって、結局どれが正解…？」
そう感じて検索している人はかなり多いはずです。

「ホストでいいの？それとも専用サーバー？」
「24時間稼働させたいけど、レンタルって何を選べばいい？」
「Dedicatedって難しそう。ポート開放とか、失敗しそうで不安…」
「IP:Portってどこを見ればいいの？フレンドが入れない原因が分からない」
「MOD入れたいけど、入れた途端に入室できなくなるのが怖い」
「回線がDS-Liteっぽい…外部公開できないって本当？」
「設定が反映されない、急に重い、ワールドが壊れた…って聞くとビビる」

サーバー構築は、専門用語が多くて“最初の一歩”でつまずきがちです。
でも実際は、最初に「方式選び」と「失敗しない準備」を押さえれば、手順はシンプルです。

このページでは、初心者でも迷わないように、

ホスト／レンタル／自宅PC・VPSのDedicated を「難易度・費用・安定性」で比較
それぞれの 最短手順（テンプレ） を用意
つまずきやすい ポート・ファイアウォール・設定反映・MOD を原因別に整理
さらに、長期運用に必須の バックアップ・定期再起動・復旧の考え方 までまとめます

「今夜だけ友達と遊ぶ」から「24時間の共有ワールドを安定運用する」まで、この記事1本で道筋が見える構成です。
読み終わるころには、あなたの状況に合ったやり方が決まり、最短で“成功する手順”がそのまま実行できる状態になります。

あわせて読みたい

7 Days to Die レンタルサーバーおすすめ比較｜初心者が失敗しない選び方「7 Days to Dieをマルチで遊びたい。でもサーバーって、正直よく分からない……」そんな状態から調べ始める人がほとんどです。「レンタルサーバーって、結局どれを選べ…

まず確認：このページで解決できること（立て方の種類／必要なもの／つまずき回避）

「サーバーを立てる」とは何をすること？（ホスト／Dedicated／常時稼働の違い）

「7 Days to Dieでサーバーを立てる」とは、ざっくり言うと “みんなが同じワールドに入るための入口（接続先）を用意する” ことです。
ただし、その入口の作り方がいくつかあります。

ホスト（いわゆる「ホストして遊ぶ」）
1人のゲームが“親機”になって、ほかの人が参加します。
✅ すぐ始められる反面、ホストが落ちる／抜けると世界も止まる、ホスト側の負荷が重い…などの特徴があります。
Dedicated（専用サーバー）
ゲームとは別に、サーバー用のプログラムを動かしてワールドを管理します。
✅ 安定しやすく、設定の自由度も高め。
⚠️ ただし、設置（レンタル or 自前）やネットワーク設定が絡むことがあります。
※同じPCで「自分が遊ぶ（クライアント）」＋「専用サーバー」を同時に動かす場合、メモリが厳しくなりやすい点は要注意です（公式ストアの注記あり）。
常時稼働（24時間動かす運用）
Dedicatedを 落とさず回し続ける という運用スタイルです。
✅ みんなが好きな時間に入れる、ワールドが育つ
⚠️ バックアップ・再起動・セキュリティ（公開範囲）など“運用”の視点が必要になります

このページでは、初心者が迷いやすいポイント（方式選び・必要なもの・詰まりやすい原因）を先に整理して、後の手順パートでスムーズに進められる状態を作ります。✅

読者のゴール別：あなたはどの方式が正解？

まずは 「何を優先するか」 を決めるのが最短です。
下の表から、近いものを選んでください。

スクロールできます

ゴール	まずおすすめ	つまずきやすい点
とにかく今すぐ遊びたい	ホスト	ホスト負荷・回線・参加できない（NAT等）
いつでも入れる世界にしたい	レンタル（ゲームサーバー/VPS）	プラン選び・設定反映（再起動）
安く＆自由にカスタムしたい	自前Dedicated（自宅PC/VPS）	ポート/Firewall・アップデート管理

迷ったら、次の“3秒診断”でOKです。

PCを24時間つけっぱなしにできる？
- できない → レンタル寄り
ポート開放やFirewall設定に抵抗ある？
- ある → レンタル or ホスト
MODや細かい設定をガッツリ触りたい？
- 触りたい → Dedicated（レンタルでも可／自前ならさらに自由）

今すぐ友達と遊びたい（準備ゼロ優先）

結論：ホスト（ゲーム内でワールドを立てる） が最短です。🚀

✅ 今日このあと遊べる
✅ 追加料金なし（基本は手元の環境で完結）
⚠️ ホストPCに負荷が集中（カクつき・落ちやすさにつながる）
⚠️ ホストが抜けると止まる（“みんなの世界”には育ちにくい）

向いているケース：

2〜4人程度で、短時間のセッション中心
“まず雰囲気を掴む”のが目的

24時間動かしたい（安定・手間少なめ）

結論：レンタル（ゲームサーバー / VPS） がいちばん現実的です。🧩

✅ 回線と稼働が安定しやすい（ホストのPC状況に左右されない）
✅ 管理画面で設定できることが多い（初心者でも触りやすい）
✅ バックアップ機能が用意されているサービスもある
⚠️ 月額コストはかかる（ただし“時間”を買える）

向いているケース：

友達が好きな時間に入れる「共有ワールド」を作りたい
自宅回線の公開（ポート開放など）を避けたい
なるべく手間なく安定させたい

※クロスプレイ（PC/PS5/Xbox等）を前提にする場合、専用サーバー側に“対応条件”があることがあります（後半で触れます）。✅

あわせて読みたい

ゲーム用レンタルサーバー徹底解説｜おすすめ比較・失敗しない選び方「友だちとマイクラやARKをマルチプレイしたいけど、どのレンタルサーバーを選べばいいのかわからない……」「VPSとか専用サーバーって聞くけど、結局どれがゲーム向きな…

あわせて読みたい

VPS 徹底比較｜初心者が最短で選ぶための目的別おすすめ厳選ガイド「VPSって結局、どれを選べばいいの？」レンタルサーバーより自由そうだけど、専門用語が多くて一気に難しく感じますよね。「月額500円台の格安VPSって、遅くない？す…

費用を抑えたい／自由に改造したい（自前運用）

結論：自前Dedicated（自宅PC or VPS） が自由度MAXです。🛠️

✅ 自分の好きなように構成できる（設定・運用・拡張）
✅ VPSを工夫すれば、コスト最適化もしやすい
✅ MODや外部ツール、ログ管理など“やりたいこと”を実現しやすい
⚠️ ネットワーク（ポート/Firewall）と保守（更新/バックアップ）が必須
⚠️ トラブル時に自力で切り分けが必要

向いているケース：

サーバー運用を学びたい／慣れている
MODや調整を積極的に入れて遊びたい
長期運用を自分の管理下に置きたい

この記事の前提（対応プラットフォーム・バージョン差が出やすいポイント）

最後に、最初からズレを防ぐための前提を共有します。ここが揃うと、後半の手順が一気にラクになります。✅

前提1：最重要は「バージョン一致」
マルチで一番多い原因は、設定ミスより “ゲーム/サーバーのバージョン違い” です。
- 「安定版（stable）」と「実験版（experimental）」が混ざる
- サーバーは更新したのに、参加者側が未更新
  こうなると「見つかるのに入れない」などが起きやすいです。
前提2：Dedicatedは“別アプリ”として動く（＝負荷の考え方が変わる）
公式ストアには、Dedicatedとクライアントを同一PCで動かすと必要メモリが実質倍になる 旨の注記があります。
そのため初心者は、
- 「自分も同じPCで遊ぶ」→ 余裕あるメモリを想定
- 「サーバー専用機にする」→ 比較的安定しやすい
  という理解で進めるのが安全です。
前提3：PC/コンソールの混在（クロスプレイ）は“条件付き”で考える
現在はクロスプレイが提供されていますが、専用サーバー側の設定条件が絡む場合があります。
この記事では、まずPC中心の基本を押さえつつ、必要な人だけ“クロスプレイ条件”に進める構成にします。
前提4：古い手順のまま進めない（画面や項目名が変わりやすい）
7 Days to DieはアップデートでUIや設定項目の名称が変わることがあります。
この記事では、「項目の意味」「判断基準」「詰まった時の考え方」 をセットで説明し、表記が少し変わっても迷いにくいようにします。
前提5：公開するなら最低限の安全策は必須
不特定多数に公開しなくても、基本は次を押さえましょう。
- パスワード設定（身内用でも推奨）
- 必要なら 参加者制限（ホワイトリスト等）
- ワールドの 定期バックアップ（最優先）
  これだけで“取り返しがつかない事故”をかなり減らせます。🔒

結論：3つの建て方を「難易度・費用・安定性」で比較

方式① ゲーム内ホスト（最短・ただしホスト依存）

いちばん早いのはこれです。ワールドを作って、そのまま友達を呼べます。
ただし、サーバー役＝ホストのPCと回線に負荷が集中します。

向いている人

とにかく今日すぐ遊びたい
2〜4人くらいで、短時間のセッション中心
設定や運用に時間をかけたくない

注意点（ここが“ホスト依存”）

ホストが抜けると世界が止まる（24時間運用は難しい）
ホストPCが重いと、全員がラグを感じやすい
回線品質が低いと「入れない」「タイムアウト」が起きやすい

失敗しないコツ

まずは 少人数＆軽め設定で始める（視界・敵数などを欲張らない）
うまく遊べたら、次の段階としてレンタル/Dedicatedへ移行するとスムーズです ✅

方式② レンタルゲームサーバー/VPS（安定・初心者向け）

「共有ワールドをちゃんと育てたい」なら、最初からここが一番ラクになりがちです。
自宅の回線公開（ポート開放など）を避けられるのが大きいです。

向いている人

みんなが好きな時間に入れる 24時間ワールドがほしい
トラブル時に“原因切り分け”で消耗したくない
管理画面で設定して、迷わず進めたい

レンタルの強み

稼働が安定しやすい（ホストのPC状況に左右されない）
多くのサービスは 設定変更→再起動が簡単
バックアップ機能や復元が用意されている場合もある

注意点

月額費用がかかる（＝“時間と安定”を買うイメージ）
プラン選びを間違えると、人数が増えた時に重くなりやすい

選び方の目安（初心者向け）

迷ったら、まずは “少し余裕あるメモリ” を選ぶ
（7 Days to Dieは設定・人数・ワールド規模でメモリ使用が伸びやすいです）
MODを入れたいなら、ファイル編集やアップロードがしやすい管理方法か確認すると安心です 🧩

あわせて読みたい

あわせて読みたい

方式③ 自宅PC/VPSでDedicated（自由度MAX・設定多め）

最終的に自由なのはこれです。
ただし、「立てて終わり」ではなく、運用（更新・バックアップ・公開設定）が必須になります。

向いている人

MODや細かい設定をガッツリ触りたい
サーバー運用も楽しめる（学びたい）
コストを自分で最適化したい（VPS選定など）

メリット

設定の自由度が最大
監視・自動再起動・バックアップ設計など、やりたいことを実現しやすい
VPSなら自宅より回線面で安定させやすい

デメリット（初心者が詰まりやすい）

ポート/Firewallなどネットワーク周りの理解が必要
アップデートで参加者とバージョンがズレると入れなくなる
何か起きた時、ログを見て自分で切り分ける場面がある

大事な前提（超重要）

Dedicatedと自分のゲーム（クライアント）を同じPCで同時に動かすと、必要メモリが実質増えます。
「遊ぶPC＝サーバー」運用は、余裕を持った構成が安全です ⚠️

プレイ人数別の目安（軽くする設定の考え方も含む）

人数が増えるほど効いてくるのは、ざっくり CPU（特に単体性能）とメモリ、そして “同時に起きるイベント量” です。
目安として、まずは下の考え方でOKです（細かい数値より、判断軸を持つのが大事です）。

スクロールできます

人数の目安	まずおすすめ	つまずきポイント	先にやる対策
1〜4人	ホストでも可	ホスト負荷・回線	設定を軽めにして様子見
5〜8人	レンタル / Dedicated推奨	血の月などで一気に重くなる	敵数や視界など“イベント量”を調整
9〜16人	Dedicated（余裕ある環境）	メモリ不足・処理落ち	スペック増強 or 設定最適化
17人以上	強めのDedicated前提	運用・監視が必要	自動再起動/バックアップ設計

重くなる「原因」を先に押さえる（初心者でも効く順）

体感で効きやすいのは、だいたい次の順です。

血の月（襲撃）の負荷
- 同時に湧く敵が多いほど重くなります
- 人数が増えるほど、同時処理が増えて負荷が跳ねやすいです
視界・描画・ワールド規模
- 視界距離（遠くまで計算/描画）
- ワールドサイズ（生成や保存データが増える）
- “欲張り設定”が積み重なると、ジワジワ重くなります
MOD・追加要素
- 便利な反面、サーバー負荷・競合・更新ズレが起きやすい
- まずバニラで安定→必要なものだけ入れるのが安全です

まず触ると効果が出やすい設定の考え方

「この数値にしよう」よりも、“下げる方向性”を覚えるのがコツです。

血の月の同時出現（敵数）を欲張らない
→ まずは初期値付近で運用し、重ければ段階的に下げる
視界距離を下げる（サーバー側/クライアント側の両面で効く）
ワールド規模を必要以上に大きくしない
1回に変える項目は1〜2個に絞る
→ 何が効いたのか分からなくなるのを防げます ✅

「どれを選べばいいか」迷った時の最短結論

今夜だけ遊ぶ → 方式①ホスト
共有ワールドを安定させたい → 方式②レンタル（初心者の正解になりやすい）
自由度を取り切りたい／学びたい → 方式③Dedicated（ただし運用込み）

共通の事前準備チェック（ここを押さえると失敗が激減）

最初に、ここだけ先に決めると後工程が一気にラクになります。

どの方式で建てる？（ホスト／レンタル／Dedicated）
何人で遊ぶ？（最大同時接続の見込み）
公開範囲は？（身内限定／不特定多数）
ワールドは？（Navezgane／ランダム生成／配布マップ）
バックアップは？（頻度と保存先）

必要スペックの考え方（ホスト兼用は負荷が跳ねる）

結論から言うと、スペックは「固定の正解」がありません。理由は、7 Days to Dieは

人数
ワールド設定（視界・湧き・血の月など）
MODの有無
ホスト兼用か、サーバー専用か

で負荷がガラッと変わるからです。

まずは“公式の基準”を起点にする

Steamのシステム要件（最低・推奨）は、最低ラインの目安として使えます。
さらに重要なのが、公式の注意書きとして

Dedicated Serverとクライアント（プレイ）を同じPCで動かすと、RAM要件が倍になる

という点です。
つまり、ホスト兼用（サーバーも自分のプレイも同居）は、想像以上に重くなりやすいです。

初心者が迷いにくい“選び方”

「数字の断定」よりも、次の判断ルールが強いです。

ホスト兼用で遊ぶ
→ まずは「推奨より余裕」を確保（RAMがボトルネックになりやすい）
→ 重いと感じたら、設定を軽くするかレンタルへ移行
Dedicatedを別PC／VPSで動かす（サーバー専用）
→ プレイの快適さが安定しやすい
→ サーバー側はCPU・メモリ・SSDのバランスが大事（特にSSD）
レンタルを使う
→ プラン仕様（推奨人数やメモリ条件）をそのまま採用するのが最短
→ 迷ったら「一段上」を選ぶ（後で増強しにくいサービスもあるため）

ストレージは“容量”より“速度”を優先

ゲーム本体だけでなく、ワールドデータ（セーブ）が増えます。
体感差が出やすいので、可能なら SSD（できれば空き容量も余裕） を前提にしましょう。

最低限の空き容量：公式要件の数値＋セーブ増加分
運用が長いほど、バックアップも増える（＝保存先が必要）

回線と公開範囲（身内限定にする設定・パスワードの重要性）

初心者が詰まりやすいのがここです。ポイントは 「どこまで公開するか」 を先に決めること。

公開範囲のおすすめはこの順

いきなり全世界公開は事故が増えるので、まずは段階的に。

身内限定（パスワード必須）
必要なら 参加者制限（ホワイトリスト／管理者のみ設定権限）
それでも公開したい場合は、あとから サーバー公開へ

身内用でも、最低限これだけは強く推奨です👇

サーバーパスワードを設定（誰でも入れる状態を避ける）
管理用パスワード（Telnet/RCON等）は別に強いものにする
公開するなら、ログイン情報はSNSに貼らない（荒らしの入口になります）

「外から入れない」原因トップ3

「サーバーは動いてるのに友達が入れない」あるあるは、ほぼここに集約されます。

(1) ポートが開いていない／転送できていない
(2) ルーター側の制限（NAT／IPv4がグローバルじゃない等）
(3) PCのファイアウォール（FW）で落ちている

特に(2)は見落としがちです。
DS-Lite / CGNAT などで「そもそも自宅にグローバルIPv4が割り当てられていない」場合、正しく設定しても外部から到達できないことがあります。
この場合は、無理に粘るより

レンタル（ゲームサーバー/VPS）にする
VPNで身内だけ繋ぐ
回線契約やオプションを見直す

のほうが早いです。

まず開ける（転送する）可能性が高いポート

Dedicated（自前/レンタル問わず）で「外から接続」させるなら、一般的に次を確認します。

スクロールできます

用途	目安のポート	優先度
ゲーム接続（基本）	26900付近（設定で変更可）	高
追加の通信（検出/補助）	26901〜26903付近	高
管理用（Telnet/管理パネル等）	8080〜8082付近（使う時だけ）	低（基本閉じる）

※ポイント：設定ファイル側（ServerPort等）で変えているなら、その値に合わせる必要があります。
※管理用ポートは、開けるなら「特定IPだけ許可」など制限をかけたほうが安全です。

ワールドの種類と運用方針（継続／リセット／バックアップ）

ワールド選びは「好み」だけでなく、運用のしやすさに直結します。

ワールドの選択肢（初心者が迷わない整理）

Navezgane（固定マップ）
迷子になりにくく、検証情報も見つけやすい
→ 初心者グループ向き
ランダム生成（RWG）
毎回違う地形で遊べる一方、生成・更新・マップ配布で手間が出ることも
→ “ワールド作り込み”が好きな人向き
配布マップ／プリセット系
すぐ始められるが、導入方法や互換性確認が必要
→ 手順に慣れてからが安全

継続か、定期リセットか

先に決めておくと、揉めにくいです。

継続運用が向く：少人数でまったり、建築を育てたい
定期リセットが向く：参加者が多い、イン率がバラバラ、マンネリ回避したい

おすすめの決め方はシンプルでOKです。

まずは 2〜4週間だけ継続してみる
不満が出たら「次は月1リセット」などへ調整

バックアップは「ルール化」すると強い

初心者ほど、バックアップを“気分”でやると忘れます。
なので、最初からルールを決めるのがおすすめです。

毎日1回（深夜など）＋ 更新・MOD導入前に必ず1回
保存対象は最低限これ
- セーブ（ワールドデータ）
- 設定ファイル（serverconfig.xml等）
- 可能なら 管理者設定・許可リスト など周辺ファイルも
世代管理：最新＋1つ前＋2つ前のように最低3世代残す

これで「壊れた／荒らされた／更新でおかしくなった」時に復帰しやすくなります。✅

用語ミニ辞典（ポート／NAT／FW／RCON・Telnetなど）

最後に、ここだけ押さえるとトラブル対応が急にラクになります。

ネットワーク系

ポート（Port）
通信の“入口番号”。同じIPでも、ポートが違うと別サービス扱い。
TCP / UDP
通信の種類。ゲームはUDP主体になりやすい（設定や実装で両方使う場合も）。
NAT
家のルーターが、家の中の端末をまとめてインターネットへ出す仕組み。
NATがあると、外から家の中に入るには「通り道（ポート転送）」が必要になりやすい。
ポート開放（ポート転送）
ルーターで「外から来た通信を、家の中のサーバーPCへ渡す」設定。
FW（Firewall）
PC側の門番。ルーターで転送しても、PCのFWが閉じていると通れないことがある。

管理・運用系

RCON / Telnet
サーバーを遠隔操作するための“管理用入口”。
便利ですが、公開すると危険なので、基本は
- 使う時だけ有効
- 強いパスワード
- 接続元を制限（特定IP/VPN/SSH経由）
  のどれかは必ずやりましょう。
ホワイトリスト（Whitelist）
“入っていい人だけ”を登録して、他は拒否する仕組み。身内鯖で特に有効。
EAC（Easy Anti-Cheat）
チート対策。導入すると安心な一方、MOD運用と相性が出ることがあります。
→ まずバニラで運用するならON、MOD中心なら方針を決める、という考え方が安全です。

方式①：ゲーム内ホストでマルチを始める（最短ルート）

この方式が向く人／向かない人

向く人

今日このあと、すぐにフレンドと遊びたい（準備ゼロ優先）
まずは少人数で、試しにマルチを体験したい
サーバー運用（設定ファイル編集・バックアップ・常時稼働）はまだ不安

向かない人

みんなが好きな時間に入れる「24時間ワールド」を作りたい
→ ホストが落ちると世界も止まります
参加人数が多い（目安：常時8人以上を狙う、頻繁に出入りがある）
MODをたくさん入れて安定運用したい
→ Dedicated（レンタル/自前）のほうが管理しやすいです

この方式の本質（初心者が知っておくと失敗が減る）

ホストは「自分のPCでゲームを動かしながら、同時に“サーバー役”も担う」状態です
つまり、ホストのPC性能・回線・裏で走っているアプリが、そのまま全員の快適さに直結します

ホスト側の設定（公開範囲・人数・パスワード・難易度）

ここは「細かく最適化」より、事故を防ぐ初期設定が大事です。
とくに 公開範囲とパスワードは、最初に固めるのが正解です。

まず触る設定（迷ったらこの順）

サーバー可視性（見え方）
- 迷ったら 「友達のみ」 がいちばん安全です
- 「公開」にすると、検索から誰でも入ってくる可能性が上がります
- 「リストに載せない」を選ぶと、見つけづらくなるため、招待や直接接続が前提になります
ゲームパスワード（参加用パス）
- 身内サーバーでも 必ず設定を推奨（公開範囲ミスの保険になります）
- パスは「短すぎない」「推測されにくい」ものに（誕生日・単語1つは避ける）
最大プレイヤー数
- 最初は「実際に来る人数＋少し」くらいでOK
- 選択肢は環境により 2/4/8/16 などがあります
- 多くしすぎても快適になるわけではないので、まずは控えめで始めましょう
地域（Region）
- ホストが日本なら基本は Asia
- 参加者が海外に散らばるほど、誰かが重くなりやすいです（後述の対策へ）
難易度（Difficulty）
- 難易度はゲーム体験の好みですが、初心者の混成パーティなら「中間寄り」からがおすすめ
- まずは「みんながストレスなく戦えるか」を優先し、慣れたら上げるのが安全です

初心者向け：おすすめ初期セット（そのまま使える）

サーバー可視性：友達のみ
パスワード：設定する
最大プレイヤー数：実参加人数＋1〜2
地域：Asia（日本ホストの場合）
難易度：中間（慣れたら調整）
（クロスプレイを使う場合）クロスプレイ有効：ON
※クロスプレイをONにすると最大プレイヤー枠が8になる仕様が案内されています

フレンドの参加手順（招待／検索／合流のコツ）

合流方法は複数ありますが、初心者は「失敗しにくい順」で進めるのがコツです。

合流前に全員で確認するチェック（1分でOK）

同じバージョン（安定版/実験版が混ざっていない）
MODの有無が一致（誰かだけ入っている、が一番詰まる）
EAC（チート対策）のON/OFFが一致（片方だけ違うと入れないことがあります）
ホストがワールドを起動し、ゲーム内で動ける状態になっている

方法A：招待で合流（いちばん迷いにくい）

ホストがワールドを開始（ゲーム内で動ける状態まで）
Steamのフレンド機能（またはオーバーレイ）から 「ゲームに招待」
参加側は招待通知から参加

コツ

「サーバーが一覧に出ない」系のトラブルを回避しやすい
まずは招待で成功させて、安定したら検索合流へ広げるのがラクです

方法B：サーバーブラウザで検索して合流

参加側が「マルチ」→「サーバーブラウザ」を開く
フィルタを確認
- フレンドのみ表示、パスあり、Ping上限、満員除外…などで 見えなくなることがあります
ホストのゲーム名で検索 or フレンド欄から選択して参加
パスワードを入力して合流

コツ

見つからない時は、いったん フィルタを全解除→再検索 が最短
一覧更新が遅いことがあるので、ホスト側・参加側ともに一度ロビーに戻って入り直すと直ることがあります

方法C：見えないときの“最後の合流手段”

サーバー可視性を「リストに載せない」にしている場合などは、直接接続（IP/アドレス指定）が必要になることがあります
ただし、ここは回線・ルーター条件の影響が出やすく、初心者は沼りやすいので、まずは招待方式で成功体験を作るのがおすすめです

よくある不具合と回避策（同期ズレ・落ちる・ロードが長い）

ここでは、初心者が遭遇しやすい症状を「原因 → すぐ効く対策」でまとめます。

症状1：サーバーが見つからない／表示されない

よくある原因

サーバー可視性が「リストに載せない」になっている
参加側のフィルタで弾かれている
起動直後で一覧に反映されていない

すぐ効く対策

まずは 招待で参加（検索を捨てるのが最短）
サーバーブラウザのフィルタを全解除 → 再検索
ホスト・参加側ともに 一度ロビーに戻る／ゲーム再起動

症状2：入ろうとすると失敗する／タイムアウトする

よくある原因

バージョン不一致（安定版/実験版、更新差）
EACのON/OFF不一致
回線の相性（NATやFWなど）が悪い

すぐ効く対策

全員いったん MODなしに揃える（検証をシンプルに）
EAC設定を揃える（ONなら全員ONで起動）
「招待参加」で成功するか試す
それでもダメなら、ホスト側の回線条件（ルーター/FW/グローバルIP）問題の可能性が上がります
※実際に「ポート転送・FW・Public IP」などが原因になりうる、という報告が多数あります

症状3：1人だけ入れない（他の人は入れる）

よくある原因

参加者側の環境（キャッシュ/セキュリティソフト/一時ファイル等）
参加者側だけバージョンや起動オプションがズレている
ごく稀にパスワード入力周りの挙動

すぐ効く対策（順番が大事）

参加者に ゲームファイル整合性チェック
参加者のPCを再起動（ついでに常駐ソフトを減らす）
参加者はサーバーブラウザから接続を試す（招待だけでなく経路を変える）
パスワードが絡む挙動が怪しい場合：
「わざと間違ったパス→再入力で通る」ケースが報告されています（応急処置として）

症状4：同期ズレ／ラグがひどい／カクつく

よくある原因

ホストPCが限界（CPU/RAM/ディスク）
ホスト回線が不安定（Wi-Fi・同時ダウンロード）
設定が重い（視界、湧き、イベント負荷）

すぐ効く対策（効果が出やすい順）

ホストは可能なら 有線LAN、大容量ダウンロードは止める
参加人数が多いなら、一度 人数を絞って再現するか確認
設定を“軽くする方向”へ
- 視界距離を控えめに
- 大量に湧く場面（イベント）を欲張らない
それでも厳しいなら、レンタル/Dedicatedへ移行したほうが総コスト（時間）が下がります

症状5：ロードが長い／入るまでに時間がかかる

よくある原因

初回参加でワールドデータの受け渡しが大きい
ホスト側のディスクが遅い／空き容量が少ない
ランダム生成の大規模ワールドで負荷が高い

すぐ効く対策

ホスト側は SSD推奨、空き容量を確保
初回参加は時間がかかる前提で、全員が余裕のあるタイミングで合流
「毎回長い」なら、ワールド規模や設定を見直す（欲張りすぎない）

方式②：レンタルサーバーで建てる（24時間稼働・初心者向け）

あわせて読みたい

レンタルのメリット/デメリット（手軽さ vs 自由度）

レンタル（ゲームサーバー/ゲーム向けVPS）は、「24時間動かしたい」「友達がいつ入っても遊べるようにしたい」人の定番です。

メリット

常時稼働：ホスト役が落ちても世界が残る
回線が安定しやすい：自宅回線よりラグ/切断が減りやすい
作業が少ない：テンプレート（7DTD用の雛形）で最短起動できる
管理が楽：再起動・バックアップ・更新が“画面操作”で済むサービスもある

デメリット

月額費用がかかる
自由度はサービス次第：
- “ゲーム専用の管理画面型”は簡単だけど、できる改造に制限があることも
- “VPS型”は自由度が高い代わりに、設定・保守が増える
設定ミス＝復旧に時間：バックアップ運用をしないと事故る（後述）

【最短】申し込み〜起動までの共通手順（テンプレ型）

サービスが違っても、流れはほぼ同じです。迷ったらこの順で進めると失敗が激減します。

ゲームを選ぶ（7 Days to Die）
プランを選ぶ（人数・ワールド規模に合わせる）
初期設定（サーバー名/パスワード/公開範囲/ワールド）
作成・起動（初回はワールド生成で少し待つ）
接続情報を確認（IP・ポート・JOIN用パスワード）
ゲームから参加（IP:Portで接続 → パス入力）

ここで詰まりやすいのは「プラン選び」と「接続情報の打ち間違い」です。次の見出しで潰します。

プラン選び（人数・メモリ・CPUの考え方）

まず見るべきは メモリ、次に CPU。
7DTDは「ワールド生成」「ゾンビ大量湧き（ブラッドムーン）」「拠点が巨大化」あたりで負荷が跳ねます。

ざっくり目安（迷ったら一段上を選ぶ）

スクロールできます

同時プレイ人数	目安メモリ	こんな遊び方だと上げる
2〜4人	4〜8GB	RWGの大きいワールド / 建築多め
5〜8人	8〜16GB	ブラッドムーン重め / MOD導入
9人以上	16GB以上	大規模拠点・高設定・イベント運用

“公式側で示されている目安”も必ず確認
例として、テンプレート提供元によっては「メモリ○GB以上必須/推奨」が明記されていることがあります。
→ その数値がある場合は、まずそこを下回らないのが鉄則です。

初期設定（サーバー名／パスワード／公開範囲／ワールド）

初期設定は「後から変えられるもの」と「変えると事故りやすいもの」が混ざっています。最初は下のテンプレでOKです。

初期設定テンプレ（身内サーバー向け）

サーバー名：誰のサーバーか分かる名前（例：〇〇グループ）
パスワード：必ず設定（短すぎない）
公開範囲：友達のみ または 非公開＋招待
最大人数：実際の人数＋1（運用枠）くらい
ワールド：
- 迷ったら 固定マップ（安定）
- 慣れたら RWG（ランダム生成）
生成サイズ：大きいほど重い（最初は控えめが安全）

公開設定や管理用パスワードを甘くすると、荒らし対策が一気に面倒になります。身内でも“鍵”は必須です。

IP・ポートの確認と接続

接続は「正しい情報を、正しい形式で入れる」だけで9割解決します。

チェックポイント

IPアドレス：管理画面に表示されたものをそのまま
ポート：サービスが指定している番号（変更していないならデフォルト）
入力形式：多くは IP:Port（例：123.45.67.89:26900 のように）

参加手順のコツ

ゲーム内の「IP接続」系の導線を使う
パスワードはコピペ推奨（打ち間違いが多い）
反映直後（作成直後/再起動直後）は、数分待ってから再接続すると通ることがある

設定変更の基本（管理画面でできること／できないこと）

レンタルは大きく2タイプです。ここを誤解すると「できない…」で沼ります。

A. 管理画面が強い“ゲーム専用”タイプ

できる：起動/停止、再起動、パス変更、ワールドリセット、（サービスによって）設定画面での項目変更、簡易バックアップ
苦手：OSレベルの細かい改造、特殊構成、自由な常駐ツール

B. 自由度の高い“VPS”タイプ

できる：ほぼ何でも（SSHで編集/導入/自動化）
苦手：全部自己責任（更新・FW・バックアップを自分で回す）

初心者はまずAでOK。MODを本格導入したり、細かい自動化をしたくなったらBへ、がスムーズです。

再起動・停止・バックアップ（運用の最重要ポイント）

レンタル運用は、バックアップがあるかどうかで安心感が別物です。

最低限のルール

設定ファイルを触る前に：バックアップ
変更を反映させるとき：再起動（またはstop→start）
大きな作業（MOD導入/アップデート/ワールド変更）の前：世代バックアップ＋復元手順の確認

“自動バックアップがあるサービス”でも油断しない

いつ作られるか（アップデート時/ワールドリセット時など）
何世代残るか
どこに保存されるか
どう戻すか（コマンド/画面）

この4点だけは最初に押さえると、事故っても復旧できます。

ログの場所と見方（原因切り分けの第一歩）

ログは「原因当てゲーム」を終わらせる最短ルートです。

見る順番（初心者向け）

管理画面にログ表示がある → まずそこ
SSHで入れる → サーバーの実行ログ/コンソール出力を見る
接続できない系 → “ポート”と“パス”を再確認してからログへ

症状→当たりを付ける早見

入れない：ポート未開放 / IP・ポート違い / パス間違い / サーバー起動中ではない
すぐ落ちる：メモリ不足 / 設定ファイルの書式ミス / MOD不整合
重い：ゾンビ数・視界・ワールドサイズ・同時接続が過多

serverconfig.xml を編集して“自分好み”にする

管理画面だけでは足りない調整（難易度、昼夜、ゾンビ上限など）は、設定ファイル編集が近道です。
ただし、編集＝事故の入口でもあるので、手順を固定化しましょう。

編集方法（SSH／ファイルマネージャ）

おすすめ手順（安全運用テンプレ）

バックアップ（最低でも設定ファイルのコピー）
サーバー停止（稼働中にいじらない）
serverconfig.xml を編集
保存
サーバー起動
接続して反映確認（NGなら即ロールバック）

サービスによっては、

SSHで vi 等で直接編集
ブラウザのファイル管理機能で編集
SFTPでDL→編集→UP
のいずれか（または複数）が選べます。

まず触るべき設定トップ10（例：人数・パス・ポート・難易度・昼夜など）

「変えて嬉しい」「事故りにくい」「効果が大きい」を優先して10個に絞ると、次が扱いやすいです。

サーバー名（一覧で見分ける）
サーバーパスワード（身内鍵）
公開範囲（非公開/友達/公開）
最大人数（実人数に合わせる）
ワールド種別（固定 / RWG）
シード（RWGで同じ世界を再現）
ワールドサイズ（大きいほど生成・運用が重くなる）
難易度（遊び心地の要）
昼夜の長さ（テンポ調整）
パフォーマンス系（例：同時湧き上限など）
　→ 重いときは、ここを下げるだけで体感が大きく変わります。

ポートや管理系（Telnet/RCON/Web管理）を触る場合は、セキュリティ前提で。パス未設定は危険です。

反映されない時に見るチェック（再起動／権限／保存場所）

反映されない原因は、だいたいこのどれかです。

サーバーを再起動していない（stop/startが必要なタイプも）
編集したファイルが違う（同名が複数ある）
保存できていない（権限/改行コード/アップロード失敗）
サービス側の管理画面設定が優先されている（画面側が上書きするタイプ）
ワールド/セーブデータ側の制約（設定変更が“新規ワールドから”反映の項目もある）

MOD導入の考え方（サーバー側・参加者側・相性問題）

MODは満足度が上がる一方で、不具合原因の8割にもなりがちです。入れるならルール化が正解。

導入前チェック（バージョン一致／バックアップ必須）

ゲーム本体のバージョン（安定版/Experimental）を揃える
MODが対応しているバージョンか確認
サーバーと参加者で必要なMOD範囲を整理（サーバーのみ/全員必須）
導入前にバックアップ（ワールド＋設定）
追加は“1つずつ”（まとめて入れると原因特定が地獄）

導入手順（アップロード→再起動→参加者へ周知）

サーバー停止
MODファイルを所定フォルダへ配置（サービスの案内に従う）
サーバー起動
参加者へ共有
- 必要MOD一覧
- バージョン
- 導入手順（参加者側が必要な場合）
入室テスト（主催者が先に入って確認）

レンタルで詰まりやすいポイント集

入れない（IP:Portが違う／パスワード／公開設定）

まずこれを上から順に確認してください。

サーバーは「起動中」になっているか
IPとポートは合っているか（IP:Port の形式）
JOINパスワードは合っているか（見た目が●でもOK）
公開範囲が“非公開”になっていないか
ポート開放が必要なタイプなら、開放できているか（TCP/UDPの指定も含む）

重い（視界・敵数・ワールド設定・同時接続）

重さ対策は「スペック増強」より先に“設定の引き算”が効きます。

ワールドサイズを上げすぎない（生成も運用も重くなる）
同時湧き（ゾンビ上限）を下げる
ブラッドムーンの強度設定を控えめにする
不要なMODを外す（まずはバニラで安定させる）
参加者の回線/PC負荷も疑う（全員が重いのか、一部だけか）

設定が戻る／初期化っぽい（復旧の考え方）

“初期化された”ように見えるのは、実際には次のケースが多いです。

編集したのが別ファイルだった（反映先ではない）
アップデートで設定が上書きされた
ワールドリセットを実行してしまった
セーブデータの場所（フォルダ）を間違えて触った

復旧の最短ルート

まずバックアップの有無を確認
“戻し方”が提供されているなら、その手順に沿って復元
ダメなら、現状を退避してから復元を試す（上書き事故を防ぐ）

方式③：自宅PC/VPSでDedicated Serverを立てる（Windows/Linux）

全体の流れ（インストール→設定→起動→公開→接続）

Dedicated Server運用は、ざっくりこの順で進めると迷いません。

サーバーファイルを用意（SteamCMDで取得・更新できる形にする）
serverconfig.xml を編集（公開方法・ワールド・ゲーム設定を決める）
サーバー起動（ヘッドレス運用の形にする）
外部公開（ファイアウォール＋ルーターのポート転送）
接続テスト（LAN内→外部→フレンドの順で確認）
安定運用（自動起動・定期再起動・バックアップ）

Step1：サーバーファイルを用意（SteamCMD中心）

Dedicated Serverは、SteamCMD（コマンド版Steam）で インストール／更新 できるのが強みです。
「自宅PC」でも「VPS（Ubuntuなど）」でも同じ発想で運用できます。

インストール先の設計（データと実行ファイルを分ける）

最初にフォルダ設計を決めると、事故が減ります。

おすすめ構成（例）

サーバー本体（実行ファイル）: C:\7dtd\server\ / /opt/7dtd/server/
バックアップ置き場: C:\7dtd\backup\ / /opt/7dtd/backup/
（可能なら）ログ置き場: C:\7dtd\logs\ / /var/log/7dtd/

ポイントは、サーバー本体とセーブ/バックアップを分離すること。
アップデートで上書きされても、セーブが巻き込まれにくくなります。

SteamCMDで取得（例：Windows / Linux共通の考え方）

# SteamCMDの中で実行（対話モード）
force_install_dir /opt/7dtd/server
login anonymous
app_update 294420 validate
quit

よくある落とし穴

force_install_dir を先に指定しないと、意図しない場所に入ることがある
初回はサイズが大きく、validate も含めると時間がかかる

更新・検証（アップデート時に壊れた時の戻し方）

運用で一番怖いのは「更新で世界が壊れた／MODが噛み合わない」なので、手順を固定化します。

更新の安全手順（テンプレ）

プレイヤー退出（可能ならサーバー内アナウンス）
セーブ/設定をバックアップ
SteamCMDで更新（app_update ... validate）
起動 → 入室テスト（管理者だけ）
問題なければ通常運用へ

壊れた時の戻し方（現実的な最短）

「サーバー本体」ではなく、まず セーブをバックアップから戻す
MOD絡みなら、いったん MODを外して素の状態で起動確認
バージョン固定が必要なら、Steam側の「ベータ」指定（ブランチ名）は時期で変わるので、Steamクライアントのツールのプロパティで確認してから固定する

Step2：serverconfig.xml の基本設定

serverconfig.xml は「接続まわり」と「ゲーム体験」をまとめて決める中心ファイルです。
基本は valueだけ変更し、項目名（name）は触らないのが鉄則です。

最低限の設定（名前・説明・パス・最大人数・公開範囲）

最低限ここだけ押さえると、身内サーバーは成立します。

サーバー名（一覧で探すため）
説明文（身内用メモでもOK）
パスワード（公開するなら必須）
最大人数（実人数＋少し）
公開設定（身内限定／非公開など）
ベースとなるポート（後でFW/ルーターと一致させる）

身内向けの考え方

「公開しない（一覧に出さない）」＋「パスワード」＋「ホワイトリスト」
→ これが一番安全で、荒らし対策も軽いです。

ゲーム体験に効く設定（難易度・昼夜・ゾンビ関連・ルート）

ここは「重さ」「雰囲気」「テンポ」に直結します。
最初は欲張らず、プレイしながら調整が失敗しにくいです。

難易度（戦闘の辛さ）
昼夜の長さ（建築・探索のテンポ）
ブラッドムーンの頻度/規模（人数が増えるほど負荷が出やすい）
ルート量・復活（進行速度が変わる）
ワールド生成（固定マップ or RWG、サイズ、シード）

RWG（ランダム生成）注意

初回生成が長いことがあります。起動直後に「落ちた？」と判断せず、ログを見て待つのが安全です。

設定が飛んだ時の復元と権限（“保存したのに反映されない”対策）

「反映されない」の原因は、だいたい次のどれかです。

サーバー再起動が必要（Stop/Startが必要なタイプもある）
編集したファイルが違う（同名が複数ある）
権限/保存ミス（Linuxでroot権限が必要、改行コードが変になった等）
管理画面型の仕組みが上書きしている（VPSテンプレ等）

対策の型

変更前にバックアップ（serverconfig.xml をコピー）
変更は少しずつ（1回に10項目触らない）
反映確認は「管理者だけ」で先に入ってチェック

Step3：サーバーを起動（ヘッドレス運用）

Windows：バッチ起動／管理者で起動すべきケース

Windowsは、基本的に 同梱の起動用bat をベースにするのが安全です。
自作する場合は「サーバーフォルダをカレントにして起動」が鉄則。

管理者で起動した方がいい例

FWルールやログ出力先をシステム側に置いている
権限まわりでエラーが出る（保存できない等）

Linux：常駐運用（systemd化の考え方）

Linuxは、落ちても復帰できるように systemdでサービス化しておくと安定します。

考え方（ざっくり）

ExecStart：startserver.sh を -configfile=... 付きで起動
WorkingDirectory：サーバーフォルダ
Restart：on-failure（落ちたら復帰）
ログ：journalctlで追えるようにする（＋必要ならファイルにも）

（※ファイル例をそのままコピペするより、「自分のパスに合わせる」ことを優先してください）

管理者設定（admin・whitelist・ban・権限設計）

管理者やホワイトリストは、serveradmin.xml 側でまとめて管理するのが一般的です。

最初に決めると楽なルール

管理者（admin）にするSteamIDを決める（2人以上いると安心）
身内ならホワイトリスト運用にする（参加者を固定）
公開するなら、ban（荒らし対策）も想定しておく

Step4：外部公開の最重要ポイント（ファイアウォール＋ルーター）

ここが最大のつまずきポイントです。
逆に言うと、外部公開さえ通れば8割勝ちです。

開けるべきポートの考え方（ゲーム用／管理用を分ける）

「ゲーム参加に必要なもの」と「管理用」は分けて考えます。

代表的な例（デフォルト構成の目安）

スクロールできます

用途	プロトコル	ポート例
ゲーム接続（基本）	TCP	26900
ゲーム接続（基本）	UDP	26900〜26903
Telnet管理（使う場合）	TCP	8081
Web管理（使う場合）	TCP	8080

※ここは あなたの serverconfig.xml の設定が正 です。変更しているなら、それに合わせます。

Windows Defender Firewall / Linux（ufw等）での許可

優先順位はこうです

まずローカルPC（LAN内）から接続できるか（FWの問題を切り分け）
次に外部（スマホのテザリング等）で接続できるか（ルーター/NATを切り分け）

Linux（ufwの例）

sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp

管理用ポート（telnet等）は、開けるとしても 特定IPだけ許可が安全です。

ルーターのポート転送（NAT・IPv6・DS-Liteで詰まるケース）

自宅PCで立てるなら、ルーターで ポート転送（ポートフォワード） が必要です。

最低限やること

サーバーPCのLAN内IPを固定（DHCP予約など）
ルーターで「外→内」への転送設定を作る
- 外部ポート26900 → サーバーPC:26900（TCP/UDP）など

DS-Lite/CGNATが絡むと詰まりやすい

ISP側でIPv4が共有される方式（CGNAT）だと、家庭のルーター設定だけでは 外部からの着信が成立しない ことがあります
ルーターに「グローバルIPv4が降ってきていない」場合、ポート転送を頑張っても無理なケースが出ます

グローバルIPが使えない場合の代替（VPN/トンネル等の選択肢）

ポート開放ができない（またはしたくない）場合、現実的な選択肢は次の3つです。

レンタル/VPSに移す（確実。参加者は普通に入れる）
グローバルIPv4が付く回線/オプションへ変更（環境依存）
メッシュVPN（Tailscale/ZeroTier等）で身内限定
- 参加者全員がVPNに参加する必要がある
- “公開サーバー”には向きにくい

Step5：接続手順（IP:Portで入る／見つからない時の探し方）

ゲーム内で直接接続する手順

いちばん確実なのは IP:Portでの直接接続です。

グローバルIP:ポート（例：xxx.xxx.xxx.xxx:26900）
パスワードがあるなら入力
入れたら成功。まずは管理者だけでテストします

サーバーブラウザで検索するコツ（条件・フィルタ）

一覧から探す場合は「見えない原因」を潰していきます。

公開設定が「非公開」だと一覧に出ない
フィルタ（地域、パスワード有無、Ping条件）で弾かれている
サーバー名の表記ゆれ（似た名前が多い）

おすすめの確認順

まず直接接続 → 通ったらOK
一覧に出したいなら、公開設定とフィルタを見直す

運用を安定させる（自動起動・定期再起動・バックアップ）

自動起動（Windowsタスク／Linuxサービス）

Windows：タスクスケジューラで「PC起動時にbat実行」
Linux：systemdでサービス化（落ちたら自動復帰）

「誰もいない時に落ちて、気づかれない」を防げます。

定期再起動とメモリリーク対策の考え方

長時間運用は、環境によって徐々に重くなることがあります。

毎日 or 数日に1回、深夜帯に再起動（身内ならこれで十分）
再起動前に告知（Discord等）して混乱を防ぐ
強制killではなく、可能なら管理コマンドで安全停止

セーブ・ワールドのバックアップ/ロールバック手順

バックアップは「手動でやろう」だと絶対忘れます。

最低限の仕組み

1日1回：セーブフォルダをZIP化して保存
世代管理：最低でも直近3〜7世代
復元テスト：一度は“戻せるか”を試す（これが超重要）

トラブルシューティング大全（症状→原因→対処）

タイムアウト／入れない（ポート・FW・転送・公開設定）

原因の切り分け（最短ルート）

サーバーは起動している？（プロセス/ログ）
LAN内から入れる？（入れるなら「ルーター側」問題）
外部回線（テザリング等）から入れる？（入れないなら「転送/CGNAT」）
serverconfig のポート設定と一致している？
DS-Lite/CGNATで“そもそも外部から来れない”状態ではない？

ワールド破損・リージョン読み込み失敗（復旧の順番）

復旧の優先順位

まずバックアップから復元（最短・確実）
直前に入れたMOD/設定変更を戻す
RWG生成直後なら「待つ」（生成が長い場合がある）
どうしてもダメなら新規ワールド（ただし原因調査は残す）

ラグ・カクつき（設定で軽くする優先順位）

効果が出やすい順に“引き算”します。

ブラッドムーンの規模・ゾンビ同時湧きを下げる
ワールドサイズを欲張らない（大きいほど重い）
同時接続人数に対してCPU/メモリが足りているか確認
MODを外して素の状態で比較（原因切り分け）

バージョン不一致（サーバー更新／参加者側の合わせ方）

サーバー更新後に、参加者側が古いままだと弾かれます
逆に、サーバーを古いバージョンに固定している場合は、参加者も同じ版に合わせる必要があります

運用のコツ

身内サーバーは「更新日」を決めて一斉に合わせる
大型更新の直後は、バックアップを厚めにしてから更新する

上級：Dockerで7 Days to Dieサーバーを建てる（VPS/自宅）

Dockerが向くケース（再現性・移行・アップデートのしやすさ）

Dockerは「最速で立てる」より、運用をラクにするための道具です。次に当てはまるなら相性がいいです。

環境を丸ごと再現したい（同じ構成を別VPS/別PCへコピーしてすぐ再開）
サーバー移行が多い（引っ越し・増強・別プロバイダへ移動）
更新の手順を固定化したい（pull → 再作成で済ませたい）
サーバー本体と設定・セーブをきっちり分離したい（永続化ボリューム）
依存関係（SteamCMDやライブラリ）をホストOSに汚したくない

逆に、次ならDockerは“過剰装備”になりがちです。

友達と今すぐ遊ぶだけ（ゲーム内ホストで十分）
OSの操作に慣れていない／まずは管理画面型レンタルが安心
トラブル時にログやネットワークを追うのが不安（Dockerは切り分け要素が増えます）

最小構成（compose・ポート・永続化ボリューム）

ここでは「コンテナは消しても、ワールドと設定は残る」最小構成にします。
ポイントは次の3つだけです。

ポート公開：ゲーム用のTCP/UDPをホストへ転送
永続化：設定・セーブ（＋可能ならサーバーファイル）をボリュームへ
再起動方針：落ちても勝手に起きる（unless-stopped）

docker-compose.yml（最小テンプレ）

services:
  7dtd:
    image: didstopia/7dtd-server
    container_name: 7dtd
    environment:
      SEVEN_DAYS_TO_DIE_UPDATE_CHECKING: "1"
    ports:
      - "26900:26900/tcp"
      - "26900:26900/udp"
      - "26901:26901/udp"
      - "26902:26902/udp"
    volumes:
      - ./7dtd_data:/app/.local/share/7DaysToDie
      - ./7dtd_steamcmd:/steamcmd/7dtd
    restart: unless-stopped

この構成で何が起きる？

./7dtd_data に serverconfig.xml とセーブ（ワールド）が残ります
./7dtd_steamcmd に サーバー本体ファイル（SteamCMDで取得する領域）が残ります
コンテナを作り直しても、ボリュームが残っていれば世界は消えません ✅

最初の起動でやること（手順の型）

docker compose up -d で起動
一度起動すると、永続化先に デフォルトの serverconfig.xml が生成される
コンテナを止める → serverconfig.xml を編集 → 再起動
IP:Port で入室テスト（まず管理者だけ）

つまずきやすいポイント

自宅運用は「Dockerのポート公開」だけでなく、ホストOSのFW許可＋ルーターのポート転送も必要です（VPSはFWだけで済むことが多い）
Linuxで bind mount したフォルダの権限が合わないと、設定が保存できない／ログが出ないことがあります
→ 迷うなら、まずは named volume を使う（権限問題が減ります）

環境変数で設定を管理する（パスワード等）

結論：Dockerは「環境変数に全部入れる」より、秘密情報だけ環境変数にして、ゲーム設定は serverconfig.xml に寄せるのが安全です。

まずは .env で“秘密”を分離する（おすすめ）

docker-compose.yml と同じ場所に .env を作って、パスワードなどを置きます。

SERVER_PASSWORD=your_strong_password
TELNET_PASSWORD=another_strong_password

compose側はこうします（例：起動引数に参加パスを入れる場合）。

environment:
  SEVEN_DAYS_TO_DIE_SERVER_STARTUP_ARGUMENTS: "-logfile /dev/stdout -quit -batchmode -nographics -dedicated -serverpassword=${SERVER_PASSWORD}"
  SEVEN_DAYS_TO_DIE_TELNET_PASSWORD: "${TELNET_PASSWORD}"

コツ

.env はGit管理しない（うっかり公開事故を防ぐ）
参加用パスと管理用パス（Telnet等）は必ず分ける
参加用パスは serverconfig.xml 側に書いてもOK（どちらかに統一すると混乱しにくい）

「環境変数でできること／できないこと」を先に割り切る

この系統のDockerイメージは、だいたい次のパターンです。

起動方法・ログ出力先・ブランチ（安定/実験）・更新チェックなどは環境変数で制御しやすい
ゲーム体験の細かい調整（難易度、昼夜、湧き等）は serverconfig.xml を編集するほうが管理しやすい

「パスワードだけ環境変数」「ゲーム設定はXML」という役割分担にすると、運用が崩れにくいです。

アップデート手順と注意点（ワールド保護・互換性）

Docker運用の強みは、更新手順をほぼ固定化できることです。
ただし、7DTDは更新で挙動が変わることがあるので、ワールド保護（バックアップ）が最優先になります。

安全なアップデート手順（テンプレ）

サーバー停止（プレイヤー退出）
バックアップ（7dtd_data を丸ごとコピー or zip化）
イメージ更新 → 再作成
- docker compose pull
- docker compose up -d
管理者だけで入室して動作確認
問題なければ通常運用へ

注意点（ここだけ押さえると事故が減る）

大きな更新の直後は、互換性問題が出やすい
→ いきなり本番ワールドを更新せず、バックアップから複製してテストすると安全
自動更新（更新検知で再起動）を使う場合でも、
「更新前バックアップ」だけは自動化できる仕組みにしておくと安心
「設定が反映されない」ときは、まずここを確認
- 編集している serverconfig.xml が 永続化先のものか
- 保存後にコンテナ（サーバー）を再起動したか
- 権限で書き込めているか（Linuxのbind mountあるある）

よくある質問（FAQ）

何人まで快適？（人数別のボトルネック）

「快適な人数」は、方式（ホスト／レンタル／Dedicated）と設定（特にブラッドムーン）で大きく変わります。なので、人数そのものより どこが詰まりやすいかを先に押さえるのがコツです。

スクロールできます

同時人数の目安	快適にしやすい方式	詰まりやすい部分（ボトルネック）	先に効く対策
1〜4	ホストでもOK	ホストPCのCPU/RAM、上り回線	まずは軽め設定で開始、ホストは有線＋常駐アプリ停止
5〜8	レンタル / Dedicated推奨	ブラッドムーン時のCPU、RAM不足、ディスクI/O	敵数・同時湧きを抑える、SSD化、メモリ余裕のあるプラン
9〜16	Dedicated（余裕ある環境）	“イベント集中”で処理落ち、拠点巨大化で負荷増	設定最適化＋スペック増強、定期再起動、バックアップ運用
17+	強めDedicated＋運用前提	管理・監視・トラブル対応の負担	自動化（再起動/バックアップ）と権限設計、ログ監視

人数が増えるほど効く要素（優先順）

CPU（特に一時的に負荷が跳ねる場面）：ブラッドムーン、同時湧きが多い設定
メモリ（じわじわ効く）：長期運用、拠点やデータ増、MOD
ディスク（体感に直結）：セーブ/読み込み、RWG生成 → SSD推奨
回線（上り）：自宅ホスト・自宅Dedicatedほど影響大

「何人まで行けそう？」の見積もりの考え方

人数を増やす前に、ブラッドムーンを1回テストして「重さのピーク」を見る
重いなら、まずは “同時に起きる処理量”を減らす（敵数・湧き・視界）のが最短です 💡

サーバーの引っ越しはできる？（レンタル↔VPS↔自宅）

できます。ポイントは「サーバー本体」より ワールド（セーブ）と設定を正しく移すことです。

移行で持っていくもの（基本セット）

Saves（ワールド/セーブ）
GeneratedWorlds（RWGを使っている場合）
serverconfig.xml（設定）
serveradmin.xml（admin/whitelist/ban/権限）
Mods（使っている場合）

移行の安全手順（テンプレ）

旧サーバー停止（参加者を退出させる）
セーブ一式をバックアップ（ZIP化推奨）
新サーバー側に同じ構成で配置
同じゲームバージョンで起動テスト（いきなり最新版に上げない）
管理者だけ入室 → 問題なければ参加者へ共有

よくある移行トラブル

新旧で バージョンがズレて入れない
→ まずはバージョンを合わせて起動し、安定してから更新
RWGなのに GeneratedWorlds を移しておらず地形が噛み合わない
→ RWG運用は「Saves＋GeneratedWorlds」をセットで扱う
レンタル→自宅で ポート開放が必要になって詰まる
→ “外部公開できない回線”なら、VPS/レンタル継続かVPN方式を検討

補足：セーブ場所を変えたい