Satisfactory サーバーの立て方｜初心者でも失敗しない手順と注意点

2026年2月14日

「Satisfactoryをマルチで遊びたいけど、ホストが落ちるとワールドも止まる…」
そんな悩みを解決するのが、Dedicated Server（専用サーバー）です。サーバーを立てておけば、ホストが不在でもワールドは稼働し続け、友だちが好きな時間に参加できます。

とはいえ、検索してみると不安の声も多いはずです。

「結局、レンタル・VPS・自宅PCのどれが正解なの？」
「ポート開放って何を開ければいい？ 7777だけ？ 8888も？」
「Server Managerの“証明書の警告”って承認して大丈夫？」
「追加できない、タイムアウトする…どこを見れば原因が分かる？」
「ホスト型マルチのセーブを、専用サーバーへ安全に移行できる？」
「更新でワールドが壊れたり、巻き戻ったりしない？」
「重い・ラグいのはサーバーが弱いせい？工場の作り方のせい？」

こうした疑問が残ったまま見よう見まねで設定すると、
「立てたのに入れない」「友だちだけ接続できない」「セーブが読み込めない」
といった“ありがちな詰まり”にハマりやすいのが現実です。

そこでこの記事では、初心者でも迷わないように、次の順番で“失敗しない型”にまとめます。

まず最初に、専用サーバーが必要かを判断（ホスト型との違い）
方式選び（レンタル／VPS／自宅PC／Docker）で後悔しない基準
Dedicated Serverの導入〜起動〜Server Manager初期設定の流れ
接続で詰まりやすいポート・FW・ルータ設定の要点（古い情報の見分け方も）
セーブ移行、更新、バックアップ、監視まで含めた安定運用

公式情報や運用実例で確認できる範囲の内容を優先しつつ、実際に詰まりやすいポイントは「どう切り分けるか」まで踏み込んで解説します。この記事を読み終える頃には、建てて・入って・続けられる状態まで持っていけるはずです。

あわせて読みたい

Satisfactoryに強いレンタルサーバー完全攻略｜初心者向けおすすめ比較と選び方 Satisfactoryをマルチで遊び始めると、だいたい次の壁にぶつかります。「楽しい」からこそ、工場が大きくなって、人数も増えて、ホスト運用が限界になってくるんですよ…

記事でできること（結論：建てて・入って・続けられる状態まで）

このページは、初心者でも迷いにくいように、専用サーバーの流れを 「選ぶ → 立てる → 接続する → 運用する」 の順でまとめます。

最短：パネル付きレンタルで、サーバー作成〜接続まで一気に完了
自由度：VPS/クラウドで自前構築して、更新や再起動を自動化
つまずき回避：ポート・FW・Server Manager（ゲーム内管理）まで一緒に整理

前提：Satisfactoryの専用サーバー（Dedicated Server）は、Steamの「Satisfactory Dedicated Server（ツール）」として配布されており、Windows/Linuxで動かせます。
※プレイ用PCに同居させることも可能ですが、安定性を求めるなら別マシン／VPSが安心です。

最短ルート：パネル付きレンタルでサクッと常時ワールド

「難しい設定は苦手」「とにかく24時間ワールドを動かしたい」なら、レンタルが最短です。多くの場合、サーバー作成・再起動・バックアップ・セーブのアップ/ダウンロード まで管理画面で完結します。

レンタル選びのコツ（失敗しにくいチェック項目）

Satisfactory対応が明記されている（“Satisfactory Dedicated Server”として提供）
拠点（リージョン）に東京など近い場所がある（Pingが下がりやすい）
バックアップ機能（自動/手動、世代管理）がある
セーブの入れ替えが簡単（ファイルマネージャやワンクリック復元）
ポート設定が自動（ここが地味に大きい…！）

だいたいの料金イメージ（例）
※価格は変動するので、最終的には各社の最新表示を優先してください。

例：10スロット/30日で $16前後 のプランがあるホストもあります
例：10スロット/30日で £11台 の表示があるホストもあります
例：4人・6GB/12人・8GBなど、人数とメモリで段階化しているホストもあります
（※後述のとおり、工場が育つほどメモリが増えがちなので、余裕を見て選ぶのが安全です）

手順（レンタルの基本はどこもほぼ同じ）

プランを選ぶ
- 目安：少人数でも、長期運用なら メモリは余裕を（工場の規模で重くなります）
サーバーを作成して起動（リージョンは近い場所を選択）
管理画面で 接続情報（IP/ポート） を確認
ゲーム内の Server Manager からサーバーを追加して接続
初回ログイン時に 管理者パスワード（Admin） と 参加用パスワード（任意） を設定
Auto Pause（無人時停止） のON/OFFを決める
- 工場を常時動かしたいならOFFが便利
- 省リソース重視ならONが安全
バックアップ設定（最低限これだけはやる ✅）
- 「更新前に手動バックアップ」「毎日自動」「世代を残す」など

レンタルでよくあるつまずき（先に潰す）

友だちが入れない → ポート開放が必要な方式（自宅設置）ではないか／表示されているポート番号が違う
無限ロード → 後述の “追加で必要になったポート” が絡むことがあります（とくに最近の更新で報告あり）

あわせて読みたい

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

自由度重視：VPS/クラウドで自前構築して運用を自動化

VPSは「最初だけ少し手間、あとは楽」が作れます。サーバーの更新・再起動・バックアップを 仕組み化 しやすいのが強みです。

まず押さえる“現実的な必要スペック”

目安として、専用サーバーは メモリ12GB以上 が案内されることが多く、
工場が大きい／4人超／長期ワールドなら 16GB以上 を見込むと安定しやすいです。
CPUは「コア数」より 1コア性能が効きやすい とされます。
ストレージは、サーバーファイル＋セーブで増えるので 余裕を確保（SSD推奨）

自前構築の全体像（これだけ覚えれば迷いにくい）

SteamCMDで専用サーバー（AppID: 1690800）を入れる
サーバー起動 → ログを確認
必要ポートを開ける（FW/セキュリティグループ/ルータ）
systemd等で常駐化（再起動しても自動で立ち上がる）
バックアップを自動化（更新前スナップショットが最強）

SteamCMDのイメージ（Linux例）
（コマンドは環境で変わるので、雰囲気として見てください）

steamcmd
login anonymous
force_install_dir /opt/satisfactory
app_update 1690800 validate
quit

運用をラクにするポイント（ここが“VPSの勝ち筋”）

常駐化：落ちても自動復帰（systemdのRestart設定など）
更新の作法：
- ① サーバー停止 → ② バックアップ → ③ 更新 → ④ 起動 → ⑤ 接続テスト
バックアップ方針：
- “毎日自動”＋“更新前は手動で別枠保存” が安心 😊
複数サーバー運用：ポートをずらして併設（デフォルト衝突を回避）

あわせて読みたい

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

つまずき防止：接続（ポート/FW）と初期設定（Server Manager）を一緒に解決

ここが一番詰まりやすいので、「最低限ここだけは覚える」をまとめます。

1) まず結論：開けるべきポートは“バージョン差”がある

最近の更新で、従来と違うポート要件が出てきた報告があります。迷ったらこの方針が安全です。

基本：ゲーム用ポート（例：7777） を開ける
追加：最近の更新で TCP 8888（Reliable Messaging） を要求するケースが報告されています
- 開いていないと 無限ロード や 接続不良 の話が出ています

最初にやるべきチェック（30秒）

サーバーが動いているマシンで
- Windows：ファイアウォールの受信許可
- VPS：セキュリティグループ（受信ルール）
- 自宅：ルータのポート転送
  が設定できているか確認

“自宅設置”で特に多い落とし穴

CGNAT（そもそも外部公開できない回線）
→ その場合、がんばっても友だちは入れません。レンタル or VPSが確実です。
友だちが入力しているのが LANのIP になっている
→ 外部からは グローバルIP（またはドメイン）を使います。

2) Server Manager（ゲーム内）での初期設定：ここまでやれば完成

ゲーム内で完結するのがSatisfactoryの良いところです。基本の流れはこれだけです。

ゲームを起動 → Server Manager を開く
Add Server（追加）
- IP（またはドメイン）＋ポートを入力
サーバーを選択して接続
初回は Adminパスワード を設定（管理用）
必要なら Playerパスワード を設定（参加制限）
Auto Pause をON/OFF
- ON：誰もいない時は止まる（省リソース）
- OFF：工場を回し続けたい時に便利
バックアップ（手動でもOK）を一度取っておく

3) 症状別のクイック対処（初心者がハマる順）

タイムアウトする／友だちだけ入れない
- ポート転送がルータ側でできているか（自宅）
- VPSの受信ルールでTCP/UDPが閉じていないか
- 入力しているIPがグローバルIPか
無限ロードになる
- 最近の更新で話題の TCP 8888 が閉じていないか確認
- 併設している別サーバーとポートが衝突していないか
ラグい／カクつく
- メモリ不足の兆候がないか（大規模セーブほど増えます）
- リージョンが遠すぎないか（東京など近い拠点へ）

最後に：5分でできる完成チェック ✅

[ ] サーバーが起動している（ログが流れている）
[ ] 友だちが 外部IPで接続 できる
[ ] Adminパスワードを設定した
[ ] Auto Pauseの方針を決めた
[ ] バックアップを取れる状態にした（更新前に必ず！）

最初に判断：専用サーバーが必要か（ホスト型マルチとの違い）

Satisfactoryのマルチは、大きく 2つのやり方 があります。

ホスト型（ゲーム内で自分がホスト）：誰か1人が自分のPCでセーブを開き、そこに他の人が参加する方式
専用サーバー（Dedicated Server）：ゲームとは別にサーバーを立て、そこへ全員が接続する方式（レンタル/VPS/自宅PCなど）

初心者が迷いにくいよう、まずは違いをざっくり表にします。

スクロールできます

比較ポイント	ホスト型（ゲーム内）	専用サーバー
24時間稼働	✕（ホストが落ちると止まる）	○（常時稼働に向く）
参加の自由度	△（ホストがいないと遊べない）	○（好きな時間に参加しやすい）
負荷のかかり方	ホストPCが重くなりやすい	負荷をサーバー側へ分けられる
導入の手軽さ	◎（すぐ遊べる）	△（構築・運用が必要）
コスト	基本0円	0円〜（レンタル/VPSは月額）

30秒セルフ診断（結論だけ先に）✅
次のうち 1つでも当てはまる なら、専用サーバーを検討する価値があります。

みんなのログイン時間がバラバラ（「ホスト待ち」が発生している）
工場が育ってきて、ホストPCの負荷やラグが気になる
ワールドを長期で育てたい（数週間〜、継続前提）
参加人数が増えそう／出入りが多い

専用サーバーのメリット（ホスト落ち回避／24時間稼働／負荷分散）

専用サーバーの価値は、ひと言でいうと 「ワールドの拠点を“みんなの共有インフラ”にできる」 ことです。

メリット

ホスト落ち問題が消える
ホストが寝落ち・回線落ち・PC再起動しても、サーバーが生きていればワールドは残ります。
24時間稼働に向く（参加が自由）
仕事や学校の都合で時間が合わなくても、各自が空いたときに入りやすくなります。
プレイ用PCの負荷を軽くできる
工場が巨大になるほど処理が重くなりがちですが、サーバーへ処理を寄せることで、参加者側は比較的ラクになります（※ネットワーク環境による差はあります）。
管理がしやすい（運用を仕組み化できる）
例：定期再起動、更新手順、バックアップの世代管理などを「ルール化」しやすいです。

注意点（ここだけは知っておく）⚠️

専用サーバーは “立てたら終わり”ではなく運用が必要（更新・再起動・バックアップなど）
自宅運用だと ポート設定や回線事情（CGNATなど） で詰まることがある
→ 迷うならレンタル/VPSが安定です

ホスト型で十分なケース（少人数・短時間・外部公開しない）

ホスト型は「いちばん簡単」で、実は多くの人はまずこれで困りません。

ホスト型が向くケース

2〜3人程度で、遊ぶ時間がだいたい揃っている
まずはお試しで、短期間（数回のプレイ） だけやりたい
外部公開はせず、身内だけで遊ぶ
サーバー管理（設定・運用）に時間を使いたくない

ホスト型のよくある限界

ホストがログアウトすると 全員強制終了 になりやすい
工場が巨大化すると ホストだけ重い／参加者にもラグが出やすい
「今日はホストがいないから遊べない」が積み重なり、ワールドが止まりがち

この “限界” を感じたタイミングが、専用サーバー移行のベストタイミングです。

専用サーバーが向くケース（友だちが好きな時間に参加／大規模工場）

次のような状況なら、専用サーバーにすると体験が一気に良くなることが多いです。

専用サーバー推奨の典型例

生活リズムが違うメンバーがいる（夜型・休日だけ・海外など）
出入りが多く、「いつでも入れる場所」 が欲しい
工場が育ってきて、ラグ・カクつき・処理落ち が気になってきた
ワールドを長期で育てたいので、バックアップや更新をきちんと回したい
“管理者” を決めて、パスワード管理や運用ルール を作りたい

迷ったときのおすすめ結論

まずはホスト型で開始
「ホスト待ち」や「重さ」が出たら、専用サーバーへ移行
（この流れが一番失敗しにくいです 😊）

準備チェック：必要スペック・回線・対応環境

サーバー構築に入る前に、ここだけ確認しておくと失敗が激減します。
特に 「メモリ」「上り回線」「ポート設定できる環境か」 の3点が重要です。

人数と工場規模で変わる目安（CPU/RAM/SSD/上り帯域）

専用サーバーは、見た目以上に CPUの“強い1コア”とメモリ が効きます。
また、Satisfactoryはプレイが進むほどセーブが育ち、必要リソースが増えやすいです。

CPU（重要度：高）

目安は Intel i5-3570 / Ryzen 5 3600 クラス以上
多コアよりも 単コア性能が高いCPU のほうが安定しやすい傾向があります

RAM（重要度：最重要）

最低ライン：12GB
安心ライン：16GB（とくに4人超・大規模セーブ）

「今は軽いけど、後で重くなる」のが多いので、迷ったら 最初から16GB寄り にするのが無難です。

スクロールできます

だいたいの状況	目安RAM	コメント
1〜4人・序〜中盤・工場小さめ	12GB（最低）	まず動かす最低ライン
4人超 / 長期運用 / 工場が巨大化しそう	16GB以上（推奨）	後からの増設が面倒なら最初から

ストレージ（SSD推奨）

サーバー本体だけでも容量がそこそこ必要です
実際のサーバーファイルは十数GB規模ですが、更新・ログ・セーブ で増えるため、運用では余裕が大事です

おすすめ：空き 25GB 以上（できればもっと）

「インストールできた」だけで安心せず、空き容量に余白 を残しておくのがポイントです

回線（上り帯域・安定性）

回線は “速さ” より 安定性（途切れない・上りが落ちない） が体感に直結します。

自宅運用なら 上り10Mbps以上を目安 にしつつ、まずは「安定して出るか」を確認
月間通信量が増えることもあるため、データ上限（容量制限） がある回線は注意

チェックリスト（自宅運用の人向け）✅

ルータ設定で ポート開放（ポート転送） ができる
回線が CGNAT 等で“そもそも外部公開できない”タイプではない
上りが 夜だけ極端に落ちる などのクセがない

対応OSと注意点（Windows/Linux、VPSの選び方）

対応OS（結論：Windows / Linux の64bit）

専用サーバーは Windows / Linux で提供されています
64bit（x86_64/amd64）前提。ARM（例：Raspberry Pi）などは基本的に対象外です

Windowsでやるときの注意

セキュリティソフトやWindowsファイアウォールで 通信がブロック されがち
「起動はできるのに外から入れない」場合、原因はOS側の許可設定が多いです

Linuxでやるときの注意

VPSでの定番はLinux（Ubuntu/Debian系など）
サーバーを安定稼働させるには、起動方法を 常駐化（自動復帰） するのがほぼ必須です（systemd等）

VPSを選ぶコツ（初心者向け）

迷ったら、以下を満たすものを選ぶと失敗しにくいです。

リージョンが近い（日本から遊ぶなら日本/近隣の拠点が有利）
メモリ16GBクラス を選びやすいプランがある
NVMe/SSD（HDDは避ける）
固定IPが付く（VPSは基本付くことが多い）
ファイアウォール（受信ルール）を 自分で編集できる

事前に揃えるもの（Steam/Epic、固定IPの考え方、管理用端末）

ここを先に用意すると、構築手順がスムーズになります。

1) 導入に必要なもの

サーバー本体の入手手段
- 代表例：Steam（ツール）/ SteamCMD
クライアント（遊ぶ側）
- Steam版でもEpic版でも、専用サーバーへ接続できます（混在OK）

2) 管理用端末（地味に重要）

初回設定はゲーム内の Server Manager で行うことが多いので、管理者は
- サーバーに接続して設定できるPC
- リモート操作（VPSならSSH、WindowsならRDP等）
  を用意しておくと安心です

3) 固定IPの考え方（初心者が混乱しやすいポイント）

VPS/レンタル：基本 グローバルIP固定 なのでラク
自宅運用：
- グローバルIPは変わることがある（プロバイダ仕様）
- 家の中のサーバーPCには 固定のローカルIP（DHCP予約） を割り当てるのが定石
- 必要なら DDNS（ドメインで繋ぐ仕組み）も検討

4) “運用のための準備”（最初に決めると事故が減る）

管理者パスワード と 参加用パスワード（必要なら）を強めにする
バックアップ方針を決める
- 例：更新前は手動バックアップ ＋ 毎日自動バックアップ
更新タイミングのルール
- 「誰も遊んでいない時間に更新」「更新後は接続テスト」など

方式を選ぶ：レンタル／VPS／自宅PC（失敗しない選定）

Satisfactoryの専用サーバーは、同じ「立て方」でも 選ぶ方式で難易度と安定性が大きく変わります。
初心者が失敗しやすいのは、月額だけ見て選んでしまい、あとから 「接続できない」「運用が回らない」 で詰まるパターンです。

ここでは、判断が早くなるように「3つのコスト」で整理します。

お金のコスト：月額・電気代・機材代
時間のコスト：構築・更新・トラブル対応
事故のコスト：セーブ消失・不正アクセス・突然落ちる

この3つのどれを減らしたいかで、最適解が変わります。

早さ優先：パネル操作で完結する「ゲーム用サーバー」

結論：最短で“遊べる状態”にしたい人向け。初心者はまずここが無難です。

向いている人

とにかく早く、今日から24時間ワールドにしたい
サーバーの仕組み（Linux/コマンド/ポート）に時間を使いたくない
もし詰まっても、サポートや管理画面で解決したい

良いところ

管理画面でだいたい完結（起動・再起動・バックアップ・セーブ管理など）
料金が分かりやすい（人数＝スロットで選べることが多い）
友だちに共有する情報がシンプル（IP/ポート、パスワード）

気をつけるところ

“スロット課金”でも、工場が巨大化すると メモリ不足 が起きることがある
→ 「人数は少ないけど工場は大きい」なら、RAMを選べる/増やせる 会社が安心
複数サーバーを同時運用したい場合、プランや制限を確認

料金イメージ（例）

例：GPORTALは「10 Slots / 30 Days」の表示があり、ロケーションに東京も選べます（表示価格は時期で変動）
例：Nitradoは「10 Slots / 30 days」の表示があり、東京ロケーションの選択肢があります
例：Shockbyteは「プレイヤー数＋RAM目安」でプランが分かれている表示があります

👉 つまりレンタルは、「価格の見通し」と「手軽さ」を買う方式です。

初心者のおすすめ運用

まずはレンタルで開始
工場が重くなってきたら、上位プラン（RAM増）へ
それでも足りなければVPSへ移行（“育った後に引っ越し”でもOK）

あわせて読みたい

自由度優先：VPSで構築（自動更新・監視・柔軟なバックアップ）

結論：安定稼働を仕組みで作りたい人向け。慣れると運用が一番ラクになります。

向いている人

「更新前バックアップ→更新→起動確認」を自動化したい
複数サーバー（本番/検証など）を同じ環境で回したい
サーバーの設定や運用を学びながら最適化したい

良いところ

スペックで選べる（人数ではなくCPU/RAM/SSDで最適化できる）
自動化しやすい
- 自動起動（落ちたら復帰）
- 定期バックアップ
- 更新手順のスクリプト化
使い方次第でコスパが良い（同じVPSで別用途も動かせる）

気をつけるところ（初心者が詰まりやすい）

“動いた”と“外から入れる”は別問題
→ FW（ファイアウォール）とポート設定が必要
障害時に自分で切り分ける必要がある
→ ログ確認、再起動、バックアップ復元など

初心者でも失敗しにくいVPS選びの基準

OSはまず Linux（Ubuntu系） が無難（情報が多い）
RAMは 余裕重視（長期ワールドほど増えやすい）
ストレージは SSD/NVMe、空き容量を残す
リージョンはできるだけ近く（Pingが体感に効く）

VPSで“後悔しない”一言

「月額を下げる」より、“運用で事故らない設計” を優先
→ バックアップと自動復帰の仕組みがあるだけで、体験が別物になります。

あわせて読みたい

コスト優先：自宅PC運用（電気代・セキュリティ・再起動対策が要）

結論：月額を抑えたい人向けですが、初心者は「詰まりやすさ」も理解して選ぶのが大切です。

向いている人

使っていないPCがある（常時稼働しても問題ない）
家の回線やルータ設定に抵抗がない
セキュリティやバックアップを自分で管理できる

良いところ

サーバー代が実質ゼロ（ただし電気代はかかる）
自由度は最強（制限が少ない）
大規模工場になっても、必要なら自分でマシン強化できる

注意点（ここが“落とし穴”）

外部公開には、回線仕様によって そもそも無理 な場合がある（例：CGNAT）
ポート開放はミスりやすい（ルータ／二重ルータ／FW）
セキュリティ責任が自分に来る
- 弱いパスワード
- 不要な公開範囲
- リモート管理の穴
  などは本当に危険です ⚠️
停電・Windows Update・ルータ再起動で落ちる
→ 自動起動・定期再起動・バックアップ が必須になります

自宅運用で最低限やること

サーバーPCのローカルIPを固定（DHCP予約）
ルータのポート転送と、OS側FWの受信許可
管理者パスワードを強くする（推測されにくい長さ）
バックアップを“別媒体”にも残す（PC故障対策）

選定チェックリスト（24時間稼働／バックアップ／DDoS対策／サポート）

最後に、これだけで選べるチェックリストです。
YESが多い方式が、あなたに向いています。

24時間稼働

「ホストがいなくても進めたい」→ レンタル / VPS
「特定の時間だけでOK」→ 自宅でも可（ただし安定性は工夫が要）

バックアップ

「セーブ消失が怖い・更新で壊したくない」→ レンタル（自動） or VPS（自動化）
「手動でもちゃんとやれる」→ 自宅でも可（ただし“別媒体”推奨）

DDoS対策

「公開範囲が広い／不特定の人が入る可能性がある」→ レンタルが無難（対策有無を要確認）
「身内だけ・非公開運用」→ どれでも可（ただしパスワードは強く）

サポート

「自分で切り分ける自信がない」→ レンタル一択に近い
「ログ見て直せる／学びたい」→ VPSが伸びしろ大

迷ったらこの結論

初心者で最短なら レンタル
“仕組み化して安定運用したい”なら VPS
“安く済ませたい＋ネットワークに強い”なら 自宅PC

全方式共通の流れ（ここを押さえると迷わない）

「レンタル」「VPS」「自宅PC」どれを選んでも、結局やることは同じです。
①入手 → ②初回起動で生成 → ③ゲーム内で登録 → ④外部接続の設定 → ⑤運用設計 の順に進めると迷いにくくなります。

① Dedicated Serverを用意する（Steam/Epic/SteamCMD）

まずは「専用サーバー本体」を用意します。ポイントは “どこで入手しても、Steam版/Epic版のクライアントが接続できる” ことです。

入手方法は主に3つ

レンタル：すでにインストール済み（あなたがやるのは設定と接続だけ）
Steamクライアント（簡単）：ライブラリの「ツール」からDedicated Serverを入れる
SteamCMD（確実）：VPS/Linuxや「ツールが見えない」環境でも導入しやすい

覚えておくと便利な情報

Dedicated Serverは Steam上では“ツール”扱いで、AppIDが決まっています。
SteamCMDなら、基本的に 匿名ログイン → AppIDで取得 → validate の流れです。

SteamCMDの例（雰囲気がわかればOK）

# 例：Linux
steamcmd
login anonymous
force_install_dir /opt/satisfactory
app_update 1690800 validate
quit

💡 初心者向けのコツ

「Steamツールで入れた」or「SteamCMDで入れた」どちらでもOK。
大事なのは “クライアントとサーバーのバージョンを揃える” ことです。
プレイ側がExperimental（実験版）を使っているなら、サーバー側も同系統に合わせないと バージョン不一致 になりやすいです。

② サーバーを起動して初回生成（設定ファイル・保存領域）

サーバーを入れたら、次は 一度起動して「必要なフォルダと設定」を自動生成させます。ここが終わると、セーブ移行やバックアップがやりやすくなります。

起動の考え方（共通）

Windows：インストール先にある FactoryServer.exe を実行
Linux：インストール先にある FactoryServer.sh を実行
（どちらも、起動するとログ（黒い画面）が流れます）

初回起動で起きること

サーバーが 設定ファイルや保存領域（Savedフォルダ） を作る
初回は数分かかることがあります（焦らずログを待つ）

保存場所のイメージ（バックアップの“本丸”）

Windows（代表例）：AppData\Local\FactoryGame\Saved\...
Linux（代表例）：~/.config/Epic/FactoryGame/Saved\...

✅ ここだけ注意

セーブや設定ファイルを触るときは、基本 サーバー停止中 に。
動作中にファイルを入れ替えると、破損や巻き戻りの原因になります。

③ ゲーム内で登録→管理者設定→ワールド作成/移行

Satisfactoryは「ゲーム内のServer Manager」で、初期設定の大部分が完結します。
ここまで来たら、ゴールは近いです。

手順（最短ルート）

ゲーム起動 → メインメニューで Server Manager を開く
Add Server（追加）
- IP（またはドメイン）とポートを入れる
サーバー名を付けて、管理者パスワード（Admin） を設定
- これが「サーバーを“自分の管理下に置く（claim）”」作業です
ワールドを新規作成（まずはここまででOK）
必要なら追加設定
- 参加用パスワード（Client/Player）：身内サーバーなら付けると安心
- Auto Pause：無人時に止めるか（省リソース）/回し続けるか（常時稼働）

既存ワールドを移行したい場合（よくあるニーズ）

やることはシンプルで、イメージは 「.savをサーバー側のSaveGamesに入れる」 です。
ただし安全のために、基本はこの順番がおすすめ👇

移行の安全手順

① サーバー停止
② 既存セーブをバックアップ（念のため別フォルダへ退避）
③ .sav を所定の保存場所へコピー
④ サーバー起動 → Server Manager側で対象セーブを選ぶ（または読み込ませる）

🔐 パスワード運用の小ワザ

Adminは「運営用」、参加用は「入場券」と考えると分かりやすいです。
Adminは共有しない、参加用だけ共有するのが安全です。

④ 外部接続のためのネットワーク設定（FW/ポート転送）

「起動はしてるのに友だちが入れない」の9割はここです。
結論から言うと、最低限 “必要ポートを開ける” のが必須です。

初心者の基本セット（まずはこれ）

ゲーム用ポート：7777（TCP/UDP）
Reliable Messaging用：8888（TCP）
※最近のバージョンでは、このTCP 8888が重要になるケースが増えています。

自宅PCで建てる場合に必要な作業

ルータで ポート転送（Port Forwarding）
- 7777（TCP/UDP）→ サーバーPCのローカルIPへ
- 8888（TCP）→ サーバーPCのローカルIPへ
OS側のファイアウォールでも 受信許可 を入れる

VPSで建てる場合に必要な作業

クラウド側の セキュリティグループ/ファイアウォール で受信許可
OS側（UFWなど）でもブロックしていないか確認

⚠️ よくある落とし穴

8888が別アプリで使用中 → サーバーが別のポートに逃げる場合があります
その場合、外部からは「逃げた先ポート」も通さないと接続できません。
なので初心者は、まず 8888を空けて使う のが安全です。
CGNAT回線（外部公開できない）だと、ルータ設定を頑張っても友だちは入れません。
その場合は レンタル/VPS が現実的です。

切り分けの最短手順（30秒）

① まずは同じ家/同じLANから入れるか（ローカルIPでテスト）
② 次に外部（友だち）から入れるか（グローバルIP/ドメインでテスト）
→ ①OKで②NGなら、だいたい「ルータ転送 or 回線」の問題です。

⑤ 運用設計（更新・バックアップ・自動起動）

最後は「続けられる状態」を作ります。
サーバーは立てて終わりではなく、更新・バックアップ・自動復帰があると一気に安定します。

まず決めるべき“運用の型”

更新の型：止める → バックアップ → 更新 → 起動 → 接続テスト
バックアップの型：毎日自動＋更新前は手動で“別枠保存”
復帰の型：落ちたら自動起動（サービス化/タスク化）

おすすめの運用メニュー（初心者向け）

スクロールできます

目的	やること	目安
バージョン不一致を防ぐ	定期的にサーバー更新	週1〜/大型更新後
セーブ事故を防ぐ	バックアップ世代を残す	7〜14世代
突然死を減らす	自動起動＋自動再起動	毎週/負荷次第
問題の早期発見	ログ確認の習慣	週1でOK

更新の手順（SteamCMD例）

# 停止 → バックアップ（推奨）→ 更新
steamcmd +login anonymous +force_install_dir /opt/satisfactory +app_update 1690800 validate +quit

自動起動の例（考え方）

Windows：タスクスケジューラで「起動時にFactoryServer.exe」
Linux：systemdで「常駐＋クラッシュ時に再起動」

🔒 最低限のセキュリティ

Adminパスワードは強め（長く、推測されにくく）
参加用パスワードを使う（身内でも“念のため”が効きます）
リモート管理（RDP/SSH）は公開範囲を絞る（可能なら特定IPのみ）

最短：レンタル（管理画面つき）で立てる手順

レンタル（ゲームサーバーホスティング）は、「買う → 起動 → ゲーム内で登録」 までが早く、初心者が最も失敗しにくい方法です。
ここでは、サービス名に依存しない形で“どこでも通用する手順”にまとめます。

プラン選びの目安（人数×工場規模×メモリ）

レンタルは「人数（スロット）」で選ぶタイプと、「人数＋RAM目安」で選ぶタイプがあります。どちらでも、考え方は同じです。

まず結論：人数より“工場規模（＝負荷）”を重視します。
Satisfactoryは進行とともに設備が増え、後半ほどサーバー負荷が上がりやすいゲームです。

目安の選び方（迷ったらこの順）

① リージョン：日本で遊ぶなら、可能なら東京など近い場所（Pingが体感に効きます）
② メモリ余裕：工場が大きくなる前提なら、最初から余裕を（後からの引っ越しが面倒）
③ バックアップ：自動バックアップの有無と、世代（履歴）を残せるか
④ セーブ移行のしやすさ：管理画面でアップロードできる／ファイルマネージャやFTPがあるか

よくあるプランの読み替え（初心者向け）

「10 slots」＝最大同時参加の人数枠（性能を保証する数字ではない）
「4 players / 6GB RAM」など＝人数とRAMの目安がセット（初心者は分かりやすい）

失敗しにくい“ざっくり目安”

スクロールできます

状況	選び方のコツ
まず遊び始めたい（序盤〜中盤想定）	小さめプランでOK。バックアップだけは確実に
4人以上／長期で育てる／工場が巨大化しそう	1段上のプランへ。RAMに余裕があるほうが安心
途中で人が増える可能性がある	最初から“上位へ変更できる”サービスを選ぶ

小ワザ：月額だけで選ばず、「バックアップ復元が簡単か」を重視すると、事故ったときのダメージが激減します。

サーバー作成→IP/接続情報の確認→起動状態チェック

購入後にやることは、どのサービスでもほぼ同じです。

手順

管理画面でサーバーを作成
- ロケーション（できれば近い地域）
- 期間・スロット（またはRAMプラン）
サーバーを起動（Start）
管理画面で 接続情報 を控える
- IP（またはドメイン）
- ポート（表示されている場合）
起動状態をチェック
- ステータスが「Running」になるまで待つ
- ログ表示がある場合は、エラーが出ていないか軽く確認

初心者が安心できる確認ポイント

起動直後は数分かかることがあります（初回生成のため）
もし「起動→すぐ落ちる」を繰り返すなら、まずは管理画面のログに目を通します
- ポート競合や設定ファイルの不整合が原因のことが多いです

ゲーム側で登録（証明書の警告／所有権の確立）

ここが“レンタルでも必ず通る”重要ポイントです。
初回接続では、ゲーム内で Server Manager を使うのが基本です。

手順（初回登録）

Satisfactoryを起動 → メニューで Server Manager を開く
Add Server（追加） を押す
管理画面で控えた IP（またはドメイン）＋ポート を入力 → Confirm
証明書の警告（Server Certificate Warning） が出たら内容を確認して進む
- これは多くの場合、サーバーが自分で作った証明書（自己署名）を使うために出ます
そのまま進むと、サーバー名の設定や管理者設定に移ります

ここでやる“所有権の確立（claim）”とは？

最初に接続した人が、管理者パスワードを設定して“このサーバーを管理する人”になる作業です
これをやっておくと、以後の管理（セーブ切替・設定変更など）がスムーズになります

管理者パスワード・参加用パスワード・公開範囲の設定

パスワード設計は、初心者ほど“最初に決めておく”のが正解です。
あとから雑になると、トラブル時に困ります。

おすすめの考え方（2種類に分ける）

管理者パスワード（Admin）：運営用。共有しない（管理役だけ持つ）
参加用パスワード（Join/Player）：入場用。必要なら共有する

設定のコツ

Adminは 長め・推測されにくいものに（英数＋記号が使えるなら混ぜる）
参加用は、身内サーバーでも付けておくと安心（“招待制”になる）
公開範囲を設定できるサービスなら、まずは 非公開〜限定公開 が無難

よくあるミス

Adminを全員に配ってしまう → 設定が変わる／事故時の原因が追いにくい
パスワードを短くする → 推測されやすく、不要なリスクが増えます

ワールド新規作成／既存セーブのアップロード

ここまでできたら、あとは「新規で始める」か「引っ越す」かです。

新規作成（いちばん簡単）

Server Managerから接続 → 画面の案内に従ってワールドを作成
最初は新規で動作確認してから、必要ならセーブ移行すると失敗が減ります

既存セーブのアップロード（安全ルート）

サーバーを停止（重要：動いている状態でファイルを触らない）
管理画面で バックアップを1つ作る（保険）
セーブをアップロード
- サービスによって方法が違います
- 例：ゲーム内の“Manage Saves”からアップロードできるタイプ
- 例：管理画面のファイルマネージャ／FTPで所定フォルダへ入れるタイプ
サーバー起動 → Server Managerでセーブを選んで開始

アップロード時の注意（事故防止）

まず“元セーブのコピー”を手元に残しておく（戻れる状態を作る）
うまく読み込まれないときは、ファイル名や保存先フォルダ違いが多い
分からない場合は、ホスティング側の「セーブ移行ガイド」に合わせるのが最短です

運用をラクにする（自動バックアップ／自動更新／定期再起動）

レンタルの強みは、運用を「機能で片付けられる」ことです。最初に型を作ってしまいましょう。

最低限これだけ（初心者の鉄板セット）✅

自動バックアップ：ON（可能なら毎日、世代は7〜14程度）
更新前バックアップ：手動で1回（大型アプデ時は必須）
定期再起動：週1（重くなってきたら回数を増やす）

あると便利

ログ閲覧（不具合時の切り分けが早い）
ワンクリック復元（セーブ事故の復旧が速い）
スケジュール起動／停止（遊ぶ時間帯だけ動かす運用も可能）

覚えておくと安心なルール

「更新する前にバックアップ」だけ守れば、だいたい取り返せます。
逆に、これをやらないと“取り返せない事故”になりやすいです。

自宅PC（Windows）で立てる手順

インストール方法の選び方（Steamツール／Epic／SteamCMD）

Windowsで自宅サーバーを立てるときは、まず「サーバー本体をどう入れるか」を決めます。結論はこの3択です。

おすすめ順（迷ったら上から）

Steamの「ツール」から入れる（いちばん簡単）
SteamCMDで入れる（VPS流用・自動更新もやりやすい）
Epic単体で完結はしない（サーバー配布は実質Steam側）

ポイントは、ゲームがEpic版でも、Dedicated ServerはSteam側（Steamツール／SteamCMD）で入手して問題ないことです。

方式別の特徴

スクロールできます

方式	向いている人	つまずきポイント
Steamツール	早く確実に動かしたい	「ツール」表示が見つけにくい
SteamCMD	更新・自動化をしたい／ツールが使えない	インストール先指定を忘れて別フォルダに入る
Epicだけ	基本おすすめしない	Dedicated Serverの入手が別経路になる

SteamCMDでの導入（Windows例）
※コピペしても動くように“最低限”に絞っています。

:: 例：C:\steamcmd に steamcmd.exe を置いた想定
steamcmd.exe

login anonymous
force_install_dir C:\SatisfactoryDS
app_update 1690800 validate
quit

うまく更新されない／場所がバラバラになるときは、force_install_dir を必ず入れてください（「入れたつもり」が一番多い落とし穴です）。

初回起動でやること（生成待ち・必要ランタイム・ログ確認）

インストールできたら、次は「初回起動で生成を完了させる」段階です。ここを丁寧にやると、後がラクになります。

1) 起動用ファイルを用意（おすすめ）

Dedicated Serverのフォルダで、起動用の server-start.bat を作ります（任意ですが便利）
中身は例としてこんな感じにしておくと、ログが見やすいです。

@echo off
cd /d C:\SatisfactoryDS\steamapps\common\SatisfactoryDedicatedServer
FactoryServer.exe -log -unattended

2) 初回起動で出やすい確認ダイアログ

初回起動時に、Visual C++ Runtime のインストールを求められることがあります
→ 「はい」で進めてOK（Dedicated Server実行に必要になる場合があります）
Windowsの「ネットワークアクセスを許可しますか？」も出ることがあります
→ プライベートネットワーク側は許可しておくとスムーズです

3) 生成待ち（ここで焦らない）

初回は設定や保存領域を作るため、少し時間がかかることがあります
画面（ログ）にエラーが連続しないかだけチェックしましょう

4) 設定ファイルの場所を把握（後で必ず使う）

例：...\SatisfactoryDedicatedServer\FactoryGame\Saved\Config\WindowsServer\ServerSettings.ini
ここにサーバー名やパスワード等の設定が入ります（ただし多くはゲーム内のServer Managerでも設定できます）

5) 先に“バックアップの型”を決める（事故防止）

セーブや設定を触るときは基本「サーバー停止中」
まずはフォルダ丸ごとコピーできるよう、保存場所を把握しておくのが安全です

Windowsのファイアウォール許可（受信規則の考え方）

「サーバーは起動しているのに友だちが入れない」の原因は、Windows側のブロックがかなり多いです。
考え方はシンプルで、“プログラム”か“ポート”のどちらか（できれば両方）を許可します。

最低限の方針（初心者向け）

FactoryServer.exe を受信許可（プログラム規則）
さらに確実にするなら、次のポートも許可（ポート規則）
- 7777：TCP/UDP
- 8888：TCP（1.1以降の接続で重要になりやすい）

おすすめの作り方（迷わないセット）

スクロールできます

規則タイプ	許可対象	メモ
プログラム	FactoryServer.exe	迷ったらこれを作る
ポート	7777（TCP/UDP）	ゲームの基本ポート
ポート	8888（TCP）	Reliable Messaging用（単一サーバーなら特に重要）

GUIでの手順（ざっくり）

Windows セキュリティ →「ファイアウォールとネットワーク保護」
「詳細設定」→「受信の規則」→「新しい規則」
まずは プログラム を選び、FactoryServer.exe を許可
追加で ポート を選び、上の表のポートを許可

注意（“ファイアウォール”だけでは足りないことがある）

これはWindows内の話です。自宅回線で外部公開するなら、別途 ルータのポート転送 も必要です。
また、複数サーバーを同じPCで動かす場合、8888が使えず別ポートへ逃げることがあります。その場合は逃げた先のポートも外部へ通す必要があります。

自動起動（タスクスケジューラ／サービス化）

自宅サーバーは、PC再起動やWindows Updateで止まりがちです。自動起動を入れておくと「気づいたら落ちてた」を防げます。

方法A：タスクスケジューラ（初心者におすすめ）

良い点：追加ソフト不要、設定が比較的簡単
設定のコツ：
- 「ユーザーがログオンしているかどうかにかかわらず実行」
- 「最上位の特権で実行」
- 「起動時」＋「開始を1分遅らせる」（起動直後の負荷回避）
- 「失敗したら再起動（再試行）」を入れる

方法B：サービス化（安定優先）

良い点：裏で安定して動かしやすい、ログオン不要
現実的には、Windowsでサービス化するには補助ツールを使うことが多いです
→ “まずはタスクスケジューラで十分” と考えてOKです

運用のミニルール（これだけで安定度が上がる）

週1回の定期再起動（深夜など）を入れる
更新前にバックアップ → 更新 → 起動確認の型を固定する

同一PCでプレイする場合の注意（負荷・アカウント・セッション）

「サーバーも遊ぶのも同じPC」でやるのは可能ですが、初心者ほどハマりやすい点があります。

1) 負荷（カクつきやすい）

サーバー＋クライアントで CPU/RAMを食い合うため、工場が育つと一気に重くなりがちです
目安として、同居運用なら メモリは余裕（例：16GB以上） を見込むのが安全です

2) 接続先の使い分け

自分は 127.0.0.1（同PC）やLAN内IPで入れても、友だちはそれでは入れません
→ 友だちは グローバルIP（またはDDNS） で接続します

3) セッション周りの体感差

「自分は入れるのに友だちが入れない」は、だいたい ルータ転送／ポート／回線仕様（CGNAT等） の問題です
先に スマホのテザリング等で“外部から入れるか”をテストすると切り分けが早いです

結論（おすすめ）

最初は同居でもOK
4人以上・長期運用・大規模工場になったら、別PC／VPS／レンタルへ移すほうが結果的にラクです

VPS/クラウド（Linux）で立てる手順

OS初期設定（ユーザー作成・更新・必須パッケージ）

ここでは、初心者がつまずきにくい Debian/Ubuntu系（例：Ubuntu 22.04/24.04） を前提にします。
最初に「安全に運用できる土台」を作るのがポイントです。

1) 専用ユーザーを作る（root直運用は避ける）

サーバー用ユーザー（例：steam）を作成し、そのユーザーでゲームを動かします。
SSHは可能なら 鍵認証 にして、rootログインは無効化できると安心です。

2) OS更新（最初にやると事故が減る）

sudo apt update
sudo apt -y upgrade
sudo reboot

3) 必須パッケージ（SteamCMD＋32bit依存対策）
Satisfactoryの専用サーバーは、環境によっては 32bitライブラリ が必要になります。まずは定番セットから入れるのが安全です。

# まず i386 を有効化（必要になる環境が多い）
sudo dpkg --add-architecture i386
sudo apt update

# SteamCMD + よく使う依存（Debian/Ubuntuの例）
sudo apt install -y steamcmd lib32gcc-s1 lib32stdc++6 libsdl2-2.0-0

4) ファイアウォール（最低限の開放だけ）

SSH（例：22）は自分の接続元だけに絞れるなら絞る
ゲーム用ポートは後述のとおり開放

例（UFWを使う場合）：

sudo ufw allow 22/tcp
sudo ufw allow 7777/tcp
sudo ufw allow 7777/udp
sudo ufw allow 8888/tcp
sudo ufw enable
sudo ufw status

VPS事業者側に「セキュリティグループ（外側のFW）」がある場合、OS側だけでなく外側も同じポートを許可してください。

SteamCMD導入→Dedicated Serverを取得（AppID指定）

ここからが本番です。流れは インストール先を固定 → 匿名ログイン → AppIDで取得 です。

1) インストール先（専用ディレクトリ）を決める

sudo mkdir -p /opt/satisfactory
sudo chown -R $USER:$USER /opt/satisfactory

2) SteamCMDでダウンロード（AppID指定）

steamcmd
login anonymous
force_install_dir /opt/satisfactory
app_update 1690800 validate
quit

更新でハマりやすいポイント

「更新したはずなのに古いまま」問題は、だいたい 違う場所に入っている のが原因です。
→ force_install_dir を毎回指定すると安定します。

Experimentalに合わせたい場合（必要な人だけ）

友だちがExperimentalで遊んでいるなら、サーバーも同系統に合わせないと バージョン不一致 になりやすいです。
ベータ指定の方法は時期で変わることがあるので、ホスティング事業者や運用ガイドの「ベータ指定例」を確認しつつ設定してください。

起動スクリプト作成（ログ出力・無人起動・ポート指定）

サーバーは「起動コマンドが長くなりがち」なので、スクリプト化すると運用がラクです。

1) 起動スクリプト（例：/opt/satisfactory/start.sh）

sudo nano /opt/satisfactory/start.sh

中身（まずは最小構成でOK）：

#!/usr/bin/env bash
set -e

cd /opt/satisfactory
chmod +x FactoryServer.sh

# -log：ログ出力　-unattended：無人起動向け
./FactoryServer.sh -log -unattended

sudo chmod +x /opt/satisfactory/start.sh

2) ポート指定について（結論：最初はデフォルトでOK）

まずはデフォルト（よくある例：ゲーム 7777 / メッセージング 8888）で動かすのが安全です。
複数サーバーを同一VPSで動かすなど、どうしても変更が必要な場合は、起動ログに出る “Listening” や “Port” 表示を見て、実際に使われているポートに合わせて外部開放します。

Docker運用では “ゲームポート” と “メッセージングポート” を分けて指定できる形で公開されており、概念としては同じです（後述のログ確認で追えるようにしておくと迷いません）。

systemdで常駐化（自動起動・クラッシュ時の自動復帰）

「落ちたら自動で戻る」を作ると、専用サーバーが一気に“インフラ化”します。

1) サービスファイル作成

sudo nano /etc/systemd/system/satisfactory.service

例（初心者でも扱いやすい形）：

[Unit]
Description=Satisfactory Dedicated Server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=steam
Group=steam
WorkingDirectory=/opt/satisfactory
ExecStart=/opt/satisfactory/start.sh
Restart=always
RestartSec=5
LimitNOFILE=100000
TimeoutStartSec=300

[Install]
WantedBy=multi-user.target

2) 反映して起動

sudo systemctl daemon-reload
sudo systemctl enable satisfactory
sudo systemctl start satisfactory
sudo systemctl status satisfactory --no-pager

運用でよく使うコマンド

# 停止
sudo systemctl stop satisfactory

# 再起動
sudo systemctl restart satisfactory

# 自動起動の確認
systemctl is-enabled satisfactory

ログ/クラッシュの確認と保管（原因切り分けの入口）

トラブル対応で一番大事なのは、「どこを見るか」を決めておくことです。

1) まず見る場所（systemd運用ならここでほぼ足りる）

# 直近ログを見る
sudo journalctl -u satisfactory --no-pager -n 200

# リアルタイム監視
sudo journalctl -u satisfactory -f

2) サーバーが“動いている”かの判断基準

起動直後は初期生成で時間がかかることがある（数分待つ）
その後、ログが継続して流れ、エラーで落ち続けていなければ概ねOK

3) 典型トラブルと最短の当たり方

バージョン不一致：サーバー側を app_update 1690800 validate で更新（force_install_dir を忘れない）
外部から入れない：
- VPS事業者側のFW（セキュリティグループ）
- OS側FW（UFW等）
- 開放ポート（7777/8888 など）
  の3点を順に確認
無限ロード/接続が不安定：メッセージング側ポート（例：8888/TCP）が閉じていないかを優先チェック

4) ログの“保管”を簡単にするコツ

journalctl は既に履歴が残るので、初心者はまずこれで十分です。
さらにきっちりやるなら、ログをファイルへ出す（＋logrotate）を検討すると、原因追跡が楽になります。

IPv4/IPv6・マルチホーム（環境で詰まりやすいポイント）

VPSはネットワーク構成が多様なので、ここだけ押さえると詰まりにくいです。

1) IPv4がない（IPv6のみ）VPSは注意

参加者側の回線・環境によっては、IPv6接続が不安定／不可のことがあります。
→ 初心者は IPv4付き のVPSを選ぶほうが安全です。

2) “どのIPで待ち受けるか”問題（マルチホーム）

VPSに複数IP（IPv4/IPv6、複数NIC）がある場合、サーバーが 意図しないインターフェースで待ち受けることがあります。
そのときに使う考え方が マルチホーム（待ち受けIPの固定） です。

目印：

ログに「localhost（127.0.0.1）っぽい挙動」や「想定外のIPでListen」が出る
自分（同一マシン）からは入れるのに外部から入れない

対策（必要なときだけ）：

起動オプションや設定で 待ち受けインターフェースを指定する
（Docker運用では MULTIHOME という形で “待ち受けインターフェース” を指定でき、通常は不要とされています）

3) ポートが2系統ある前提で考える

ゲーム本体の通信（例：7777）
メッセージング（例：8888）
どちらも外部から到達できないと、接続が不安定になったり、特定状況で失敗することがあります。

Dockerで立てる（再現性・移転性を優先したい人向け）

Docker運用の強みは、サーバー環境を 「設定＋データ（ボリューム）」として丸ごと持ち運べる ことです。
OSの再インストールや引っ越しがあっても、基本は 同じ compose を立ち上げ直すだけで復旧できます。

ここでは、初心者が事故りやすいポイント（ポート・保存領域・更新/バックアップ）を“型”としてまとめます。

構成設計（ポート公開／ボリューム／再起動ポリシー）

DockerでDedicated Serverを動かす場合、最初に決めるべきは次の3つです。

ポート公開：外部から接続できるようにする
ボリューム：セーブや設定をコンテナ外に永続化する
再起動ポリシー：落ちても自動復帰させる

最小構成の考え方（初心者の安全ルート）

ポートは最低2つを意識
- ゲーム通信（例：7777）
- メッセージング（例：8888）
データは必ずホストに永続化（コンテナを消しても残るようにする）
restart: unless-stopped で「勝手に落ちた」を減らす

まず動かすための docker-compose.yml 例

これは“ひな形”です。まずはこの形で起動→接続確認→必要に応じて調整、の順が失敗しにくいです。

services:
  satisfactory:
    image: wolveix/satisfactory-server:latest
    container_name: satisfactory-server
    hostname: satisfactory-server
    restart: unless-stopped

    ports:
      - "7777:7777/tcp"
      - "7777:7777/udp"
      - "8888:8888/tcp"

    volumes:
      - "./satisfactory-server:/config"

    environment:
      - MAXPLAYERS=4
      - PUID=1000
      - PGID=1000
      - STEAMBETA=false
      # 必要なら後で：
      # - SERVERGAMEPORT=7777
      # - SERVERMESSAGINGPORT=8888

    # メモリは「最低限の下限」と「上限」を意識すると安定しやすい
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G

起動コマンド：

docker compose up -d
docker compose logs -f

ボリューム（/config）に何が入るのか

永続化の要は ./satisfactory-server:/config です。
多くのイメージでは /config 配下に、ざっくり次が置かれます。

セーブ・設定（ここが最重要）
バックアップ
ログ
ゲームファイル（ダウンロード済み本体）

つまり、引っ越しのときは このフォルダを丸ごと退避しておけば復旧が簡単です。

PUID/PGID は“権限事故”を防ぐ保険

「permission denied」で詰まりやすいので、ホスト側のユーザーIDに合わせるのが安全です。

id
# uid=1000(...) gid=1000(...) なら、PUID=1000 / PGID=1000 でOK

再起動ポリシーは必須に近い

restart: unless-stopped
→ VPS再起動や一時的な落ちに強くなります
さらに安定を上げたいなら、ホスト側で
- 定期再起動（週1など）
- 監視（落ちたら通知）
  を追加すると「気づいたら止まってた」が減ります。

更新とバックアップを「手順化」して事故を防ぐ

Docker運用で一番大事なのは、更新時に セーブを守る手順を固定することです。
慣れるまで“手順を短く・毎回同じに”しておくと失敗しません。

更新の基本ルール

ゲーム本体の更新は「コンテナ起動/再起動時に自動で走る」タイプが多い
ただし、イメージ（コンテナ側）の更新は pull が必要

事故らない更新手順（テンプレ）

サーバー停止（安全第一）

docker compose down

バックアップ（ここが命綱）
- いちばん簡単：./satisfactory-server を丸ごとコピー
- もう少しスマート：saved（セーブ/設定）を世代管理で退避

例：

mkdir -p ./backup_snapshots
tar -czf ./backup_snapshots/satisfactory_$(date +%F_%H%M).tar.gz ./satisfactory-server

イメージ更新 → 起動

docker compose pull
docker compose up -d
docker compose logs -f

接続テスト（管理者だけでOK）
- Server Managerで入れるか
- ワールドが正しく読み込めるか

自動バックアップを活かすコツ

多くの構成では、起動時にバックアップを作ってくれる仕組みがあります。
ただし、更新でトラブルが起きると「起動時バックアップ＝壊れた状態」になることもあるので、

更新前に手動バックアップ（別フォルダ/別媒体）
そのうえで 自動バックアップは日次運用に回す

この二段構えが一番安全です ✅

できれば避けたい運用（初心者がやりがち）

いきなり up -d して、更新が走ってから「やばい」と気づく
セーブをホストに出していない（コンテナ消したら終わり）
“どのフォルダが正”か分からないままファイルを触る

複数インスタンス運用時のポート設計

複数ワールド（例：本番／検証、友だちグループ別）を同一ホストで回したい場合は、次の3点をセットで変えます。

ホスト側の公開ポート（ポート被り回避）
コンテナ内部の使用ポート（サーバーが実際に待ち受けるポート）
データ用ボリューム（/config）（セーブ混線防止）

特に重要なのは、「外側だけ変えてもダメなケースがある」ことです。
Satisfactory系は、サーバー内部で使うポート情報が絡むため、内部ポートも合わせて変えるのが安全です。

例：2台目を 7778/8889 で動かす

services:
  satisfactory2:
    image: wolveix/satisfactory-server:latest
    container_name: satisfactory-server-2
    hostname: satisfactory-server-2
    restart: unless-stopped

    ports:
      - "7778:7778/tcp"
      - "7778:7778/udp"
      - "8889:8889/tcp"

    volumes:
      - "./satisfactory-server-2:/config"

    environment:
      - MAXPLAYERS=4
      - PUID=1000
      - PGID=1000
      - SERVERGAMEPORT=7778
      - SERVERMESSAGINGPORT=8889

このとき、ホスト側のFW（VPSのセキュリティグループ含む）も

7778（TCP/UDP）
8889（TCP）

を忘れずに開けます。

複数運用のチェックリスト

[ ] /config が別ディレクトリになっている（セーブ混線防止）
[ ] ホスト側ポートが被っていない
[ ] コンテナ内ポートも一致している（環境変数で指定）
[ ] FW/セキュリティグループも新ポートを許可
[ ] Server Managerで「別サーバー」として登録している

接続で詰まらない：ポート・FW・ルータ設定の要点

専用サーバーの接続トラブルは、原因の大半が 「必要ポートの前提違い」 と 「FW／ルータでの通し方ミス」 です。
ここでは、初心者が迷わないように「いま何を開けるべきか」と「どこをどう確認するか」を“型”でまとめます。

最重要：必要ポートは「ゲーム/サーバーのバージョン」で前提が変わる

まず最初に押さえるべきは、Satisfactoryはアップデートで“必要ポートの考え方”が変わってきた点です。
古い解説と新しい解説が混ざると、設定が正しそうに見えても繋がりません。

判断のコツ

「最近アップデートした」「1.1系の話を見た」→ 7777に加えて8888も疑う
「古い記事にある“UDPだけ”で設定した」→ 7777をTCP/UDPで開け直すを疑う

現行の基本：既定ポート（例：7777）をTCP/UDPで開放する

現行の基本は、接続先として指定する“標準ポート（例：7777）”をTCP/UDPで通すことです。
ここを「UDPだけ」で開けていると、バージョンによっては接続が不安定になったり、入れなくなるケースがあります。

まずやるべき最小セット（迷ったらこれ）

7777：TCP + UDP
8888：TCP（1.1系で特に重要になりやすい）

ポイント：ポート番号は例です。もしサーバー側でポートを変更しているなら、その変更後の番号に合わせます。

旧情報でよく見る例：UDP 7777/15000/15777 を案内するケース

検索上位や古めのガイドでは、いまだに次の案内を見かけます。

7777（UDP）
15000（UDP）
15777（UDP）

これは「過去の標準」ベースの説明として残っていることが多く、現行の“TCP/UDP 7777”や“8888/TCP”と混ぜると混乱しがちです。

ここでの実務的な結論

“いま必要なポート”だけに絞る（余計な開放は混乱のもと）
特に自宅運用は、ルータ設定で「どれをどこに転送しているか」が見えにくくなるので、不要ポートを残さない方が切り分けが速いです

サーバー側FW（Windows/UFW等）の方針

FW（ファイアウォール）は「サーバーPC（またはVPS）の入口」です。
ここで止められていると、ルータ設定が完璧でも繋がりません。

方針は2つ（初心者は両方やると強い）

ポートを開ける（番号で許可）
プログラムを許可する（実行ファイルで許可） ※Windowsで有効

Windows（自宅PC／Windows Server）

受信規則で次を許可するのが基本
- 7777：TCP / UDP
- 8888：TCP
さらに確実にするなら、Dedicated Serverの実行ファイル（例：FactoryServer.exe）を 受信許可（プログラム規則）

よくある落とし穴

“送信規則”を触ってしまう（基本は受信）
プライベートだけ許可して、パブリックがブロックになっている
セキュリティソフト側に別のFWがあり、Windowsの設定が効いていない

Linux（UFW/iptables、VPSで多い）

UFWなら、最小セットはこれです。

7777/tcp
7777/udp
8888/tcp

例（UFW）

sudo ufw allow 7777/tcp
sudo ufw allow 7777/udp
sudo ufw allow 8888/tcp
sudo ufw status

VPSは“二段階FW”を忘れずに

OS側（UFW等）だけでなく、VPS事業者の セキュリティグループ／外部FW でも同じポートを許可する必要があります。

自宅設置のルータ設定（ポート転送・二重ルータ・CGNAT）

自宅運用で詰まる原因は、ほぼここです。
やることは「外（WAN）から来た通信を、サーバーPCへ渡す」＝ポート転送です。

最短の設定手順（自宅ルータ）

サーバーPCのローカルIPを固定する
- 例：DHCP予約で 192.168.1.50 のように固定
ルータのポート転送を設定
- 7777（TCP/UDP）→ 192.168.1.50
- 8888（TCP）→ 192.168.1.50
サーバーPC側FWも同じポートを許可
外部からテスト（ここ重要）

外部テストが重要な理由

ルータによっては「同じ家のWi-FiからグローバルIPで繋ぐ」テスト（NATループバック）が失敗します
→ スマホの4G/5G（Wi-Fiオフ） など、“LAN外”から試すのが確実です。

二重ルータ（ダブルNAT）に注意

次の構成だと、転送しても届かないことがあります。

回線終端装置（ルータ機能あり）＋自分のルータ
ホームゲートウェイ（ONU一体）＋ Wi-Fiルータ

対策の基本

上流機器をブリッジ（ルータ機能オフ）にする
もしくは
上流 → 下流 → サーバーPC の順に 二段でポート転送（やや難しい）

CGNAT（そもそも外部公開できない）を疑う

ルータで頑張っても繋がらない場合、回線がCGNATの可能性があります。
見分ける簡単な目安はこれです。

ルータの「WAN側IP」と、外部サイトで見える「グローバルIP」が一致しない
WAN側IPが 100.64.0.0/10 など、CGNATっぽい帯域になっている

この場合は、自宅公開が難しいので VPS／レンタルに切り替えるのが最短解です。

ありがちな失敗（転送番号の不一致／ポート競合／LANとWANの切り分け）

接続トラブルで“刺さる”失敗例をまとめます。チェックは上から順でOKです。

1) 転送番号の不一致（ポート変換してしまう）

外側7777 → 内側7778 のように “番号を変えて転送” する設定は、ゲームによってはうまく動きません。
外側と内側は同じ番号で揃えるのが安全です（7777→7777、8888→8888）。

2) ポート競合（すでに他のアプリが使っている）

8888や7777が別サービスで使用中だと、Dedicated Serverが別ポートへ逃げたり、起動自体が不安定になることがあります。
対策：
- 使用中ポートを確認（Windowsなら netstat -ano、Linuxなら ss -lntup）
- どうしても複数台／複数インスタンスを動かすなら、サーバー側でポートを明示的に分けて、その番号をFWと転送に反映する

3) LAN内はOK、外からNG（切り分けが大事）

LAN内IP（例：192.168.x.x）で入れる：サーバー自体とPC側FWはだいたいOK
外から入れない：ルータ転送・二重ルータ・CGNAT・VPS外部FW のどれか

4) “開けたつもり”で、プロトコルが違う

7777をUDPだけ許可している（TCPが閉じている）
8888をTCPで許可していない（1.1系で詰まりやすい）

ゲーム内「Server Manager」での初期設定（実質ここが本番）

サーバー追加→状態確認→初回セットアップの流れ

Dedicated Server を立てたら、最後に「ゲーム側」でサーバーを登録して、ワールド（セーブ）を作る必要があります。ここが終われば、友だちがいつでも入れる“常時ワールド”になります。

最初にやること（流れだけ先に）

メインメニューから Server Manager を開く
Add Server で「IP:ポート」を登録
初回は 証明書の警告 が出ることがある（内容を理解して承認）
まだ誰も入っていないサーバーなら Claim（所有権の確立） が出る
サーバー名 と 管理者パスワード を設定
Create Game で「開始地点」と「セッション名」を決めてワールド生成
準備完了後、Join Game で入る（次回からはここが最短）

ここでの重要ポイント

IPを他人に渡す前に、必ず自分が先に接続してClaimする
最初に接続した人が初期セットアップ（＝管理者設定）を行える仕様のため、うっかり先に入られると面倒が増えます。
証明書の警告は「あなたが登録したサーバー」だと確信できる場合のみ承認
不明な相手のサーバーに対して承認すると、意図しない接続リスクが上がります。

管理者パスワードと権限（バックアップ/キック/設定変更）

Server Manager には「入れるだけの人」と「管理できる人」がいます。管理できる人になる鍵が 管理者パスワード です。

よく混同しがちな“2種類のパスワード”

スクロールできます

種類	目的	誰に渡す？
管理者パスワード	サーバー設定変更・セーブ管理など“運営権限”	原則、運営メンバーのみ
参加用パスワード（ある場合）	参加者の入室制限（野良対策）	参加者に共有

管理者になれないと起きること

Server Manager のタブ（設定・セーブ管理など）に入ろうとすると
「未認証」扱いになり、Authenticate（認証） が必要になります。

安全運用のコツ

管理者パスワードは 参加者全員に配らない（荒らし・誤操作の事故が増えます）
共同管理するなら、運営メンバー間で
- 役割（設定担当・バックアップ担当）
- 変更ルール（変更したら共有、スクショを残す）
  を決めておくと揉めません。

ワールド作成（開始地点・セッション名）と自動参加の挙動

Claim が終わったら、次はワールドを生成します。ここで決めるのが 開始地点 と セッション名 です。

開始地点（Starting Area）の考え方（迷ったらこれ）

初心者・少人数：移動や導線がシンプルな場所を選ぶ
大規模工場を見据える：拡張しやすい地形を意識（あとで引っ越すのもアリ）

セッション名（Session Name）は“セーブの身分証”

セッション名は「サーバーの表示名」と別物です
あとでセーブ移行や読み込みをするときに重要になります
「ファイル名を変えてもセッション名は別」というケースがあるので、適当に付けないのがコツ

自動参加（Join）の挙動

ワールド生成が終わるまでは参加できません
生成完了後、Server Manager の Join Game から入れます
作成時に「作ったらそのまま参加」系のチェックがある場合は、オンにすると迷いません（環境により表示は違います）

便利設定（Auto Pause・最大プレイヤー・公開/非公開）

ここからは「運用が楽になる」「事故が減る」設定です。初日で全部完璧にしなくてOKですが、最低限だけ押さえると失敗しにくいです。

Auto Pause（無人時停止）

有効：誰もいない間は工場が止まる（軽い・安全）
無効：誰もいなくても工場が動く（“常時ワールド”感が出る）

✅ 迷ったら

燃料発電中心で枯渇が怖い → Auto Pause 有効
24時間生産したい／資源を回し続けたい → Auto Pause 無効
（ただし燃料切れ・詰まり・ラグ増に注意）

最大プレイヤー（Max Players）

“公式に安定動作を想定している人数”は控えめですが、厳密な上限が固定されているわけではないと言われています
増やすほど CPU/RAM/回線 が効いてきて、同期ズレやラグが出やすくなります

✅ 実務の目安

まずは少なめで運用開始 → 重くなったら上げない（これが一番事故が少ない）

公開/非公開（参加制御）

最低限やるなら 参加用パスワード を設定（野良流入対策）
さらに厳密にしたいなら
- 参加者を固定
- パスワードを定期変更
- 管理者権限を限定
  といった「運用ルール」で固めるのが現実的です

セーブ移行（ホスト型マルチ→専用サーバーへ引っ越す）

「いまの工場、消したくない」場合は移行できます。やり方は大きく2つです。

方法A：ゲーム内の Manage Saves からアップロード（いちばん簡単）

Server Manager を開く（管理者であることが前提）
Manage Saves（または類似のセーブ管理タブ） へ
Upload Save でローカルのセーブを選ぶ
アップロード後、Load Save で読み込む
（読み込み時にサーバーが再起動する挙動があるため、参加者がいるときは避ける）

方法B：ファイルで移す（環境自由度が高い）

サーバー側のセーブ格納場所に .sav を置いて読み込む方式
このとき重要なのが セッション名
「ファイル名」と「セッション名」が一致していないと、読み込みで迷子になりがちです

✅ 事故を防ぐチェックリスト

移行前に ローカルにバックアップを複製（念のため2世代）
移行直後は一度入って
- 拠点が正しく出るか
- 建築物の挙動が破綻していないか
- 権限（管理者）が生きているか
  を軽く確認してから、参加者を呼ぶ

安定運用の基本：更新・バックアップ・監視

専用サーバーは「立てた瞬間がピーク」になりがちです。長期運用で効いてくるのは、結局この3点だけです。

更新：事故を起こさず“揃える”
バックアップ：壊れても“戻せる”
監視：重くなる前に“気づける”

以下では、レンタル／VPS／自宅／Dockerどれでも通用する“運用の型”に落とし込みます。

更新運用（手動/自動、更新後にやるべきこと）

更新の基本ルール（まずこれだけ）

クライアント（遊ぶ側）とサーバーのバージョンを揃える
更新は「いつ」「誰が」「どうやって」を決めておく（事故の9割は曖昧運用）
更新前に バックアップを取ってから（後述）

方式別の更新の考え方

レンタル：管理画面で自動更新が多い
→ 可能なら「更新タイミング（深夜など）」を固定し、更新直後は管理者が一度ログインして確認
VPS/自宅（SteamCMD）：手動でも自動でもOK
→ “更新コマンド”を固定し、validate込みでズレを減らす
Docker：
- ゲーム本体更新＝起動/再起動時に自動で走る構成が多い
- イメージ更新＝pullが必要
  → どちらが更新されるのかを自分の構成で一度だけ把握しておく

更新の最小手順（テンプレ）

参加者へ告知（今入っている人がいるとセーブ事故が増えます）
サーバー停止
バックアップ取得（必須）
更新（SteamCMD / 管理画面 / Docker pull 等）
起動
更新後チェック（ここが重要）

更新後チェック（30秒で終わる項目）✅

Server Managerで 接続できる（管理者がまず入る）
ワールドが 正しくロードされる
参加者も入れる（“管理者だけ入れる”はネットワーク問題の切り分けに不向き）
ログに エラー連発がない
ポート周り（特に 7777 / 8888 を使う構成）は 閉じていない
- ありがちな症状：無限ロード／タイムアウト／誰かだけ入れない

コツ：更新直後は「自分だけOK」で安心しないで、外部の参加者が入れるかまで確認するとトラブルが激減します。

バックアップ戦略（世代管理・復元手順・保管先）

結論：3つのバックアップを持つと強い

直近（すぐ戻す用）：数時間〜1日分
世代（やり直し用）：7〜14世代（最低でも7）
オフホスト（最悪でも守る用）：別マシン/別ストレージへ

バックアップは「作る」よりも「戻せる」が大事なので、復元手順までセットで作ります。

世代管理のおすすめ（初心者でも回る）

スクロールできます

目的	世代数の目安	例
うっかりミスを戻す	3〜5	直近の数回分
更新事故・データ破損に備える	7〜14	1〜2週間分
本当に詰んだ時に守る	1〜3	週1で別媒体へ

保存先（どこに置くべき？）

同じディスクだけ：故障で同時に消えるので弱い
別ディスク/別フォルダ：最低ライン
別マシン/クラウド：理想（オフホスト）

Dockerの場合は特に、/config（または永続化ディレクトリ）丸ごとを固めて退避できる形が強いです。

復元手順（テンプレ：これをメモしておく）

サーバー停止（ここが最重要）
現在のデータを「退避」（上書き前に逃がす）
バックアップを所定の保存場所へ戻す
起動
管理者がログインして確認
- ワールドが想定どおりか
- 進行が巻き戻りすぎていないか
- 権限（管理者）が維持されているか

復元後にやりがちな事故

“今の壊れた状態”を上書きしてしまい、戻る場所が消える
→ だから 復元前に退避が必要です。

最低限のセキュリティ（強いパス／管理画面の公開範囲／SSH保護）

「身内サーバーだから大丈夫」と思いがちですが、外部公開＝入口を作ることなので、最低限だけは固めておくのが安全です。

強いパスワード運用（Admin/参加用の分離）

管理者パスワード：運営のみ（共有しない）
参加用パスワード：参加者に共有（必要なら定期変更）

強いパスの目安

可能なら 12〜16文字以上
辞書語だけ／短い数字だけは避ける
“運営が覚えられる強さ”でOK（完璧より継続）

公開範囲（できれば“最小公開”）

開放ポートは 必要なものだけ
参加者が固定なら、可能な範囲で アクセス元を絞る（VPSのセキュリティグループ等）

補足として、Dedicated Serverはバージョンによって 追加の通信（例：8888/TCP） が重要になります。
このポートは近年「埋め込みHTTP API」用途も絡むため、不用意に広く晒さず、必要最低限で運用するのが無難です。

SSH保護（VPS/クラウド運用の最低ライン）

鍵認証にする（パスワードSSHを避ける）
rootログインを避け、一般ユーザー＋sudoにする
FWで SSHは自分の接続元だけ許可できるなら許可
余裕があれば fail2ban 等で総当たり対策

トラブル時の確認ポイント（ログ・クラッシュ・設定ファイル）

トラブル対応は、「切り分け順」 がすべてです。次の順に見ると、最短で原因に当たりやすいです。

1) 症状で当たりをつける（最短チャート）

自分は入れる／他人が入れない
→ まずネットワーク（ポート・FW・ルータ・VPS外部FW）
誰も入れない／サーバーが落ち続ける
→ ログ、依存不足、設定ファイル破損、メモリ不足
入れるが重い／カクつく／同期が遅い
→ CPU/RAM不足、セーブ肥大、常時稼働設定、回線上り

2) ログの確認（“まずここ”）

Linux（systemd運用）
- 直近ログ：journalctl -u satisfactory --no-pager -n 200
- 追跡：journalctl -u satisfactory -f
Docker
- docker compose logs -f
Windows
- サーバー起動コンソール（黒画面）
- 可能ならログ出力オプションでファイル化（運用が楽になります）

ログで見るポイントはこの3つだけでOKです。

起動直後に 同じエラーが連発していないか
ポート周りで Bindできない（使用中） になっていないか
バージョン不一致っぽいエラーが出ていないか

3) クラッシュ・フリーズの“ありがち原因”

メモリ不足：大規模工場ほど起きやすい
更新直後の不整合：validate込み更新＋再起動で改善することがある
セーブ周り：移行直後や復元直後に起きたら、別世代へ戻して切り分ける

4) 設定ファイル（最後に触る）

初心者は、まず Server Manager側で設定できるものはゲーム内で済ませるのが安全です。
ファイルを直接触るのは、次のときだけが無難です。

管理画面/Server Managerから変更できない項目を調整したい
変更内容を“手順化”して再現したい
トラブル復旧で既知の設定に戻したい

その場合でも、編集前にConfig一式をバックアップしてから触るのが鉄則です。

重い・ラグいを減らす：原因別の改善

ラグの正体はだいたい次のどれかです。

サーバーの計算が追いつかない（CPU）
セーブや同時接続でメモリが足りない（RAM）
遅延やパケットロスで同期が崩れる（回線）

まずは“体感”で当たりをつけると、改善が早いです。

スクロールできます

症状	まず疑う原因	最短で試すこと
ゴムバンド、位置ズレ、操作が反映されない	CPUが詰まり気味	車両・経路計算を減らす／建築を小分け
数分ごとに一瞬止まる	オートセーブ負荷	オートセーブ間隔を長めに／保存先をSSDへ
特定の人だけ入れない・遅い	回線・地域・上り	サーバー地域を近く／上りを確保／Wi-Fi回避

CPUが苦しい（車両・経路計算・大量設備の最適化発想）

Dedicated Server は「コア数を増やせば必ず速い」タイプではなく、単発の計算が重いと一気に詰まりやすいです。
そのため、CPU対策は “重い処理を減らす”＋“重い瞬間を散らす” の2軸で効きます。

1) 車両・経路計算を“減らす/単純化する”

車両（トラック系）は、運用が増えるほど「ルート管理」「衝突」「再計算」などが重なりやすいです。

車両の台数を増やすより、路線を統合する（本数を減らす）
交差点だらけの複雑ルートより、単純な往復に寄せる
どうしても詰まる場所は、別輸送（ベルト/列車など）に置き換えも検討

体感で効く目安：車両が増えるほど「人が増えたわけじゃないのにラグい」が起きやすいです。

2) “大量に一気に変更”を避ける（建築のコツ）

大規模な建築・撤去・配線は、サーバーがまとめて処理して一瞬止まりがちです。

コンストラクターを10台置く → さらに10台…のように分割して作業
物流の流れを一気に切り替えない（切替は区画ごと）
重い時間帯（オートセーブ直前/直後）に大工事をしない

3) サーバー側の“余計な同居”を減らす

自宅PCで「同一PCでプレイ＋サーバー」だと、CPUを奪い合ってラグが出やすいです。

可能なら サーバーとプレイを分ける（別PC / VPS / レンタル）
VPSなら「vCPUたくさん」より、高クロック・高単コア性能を優先してプラン選び

4) CPUが苦しいサイン（見逃さない）

参加者が増えたわけでもないのに、突然ゴムバンドが増える
作業（建築/配線）に対して反映が遅れる時間が増える
サーバー側で特定コアが張り付く（監視で気づける）

この場合は「工場を縮める」より先に、車両と大工事のやり方を変えるのが効きやすいです。

メモリが苦しい（巨大セーブ・同時接続・バックアップの設計）

RAM不足は「突然落ちる」だけでなく、ジワジワ重くなる／オートセーブで止まるの形でも出ます。
まずは “足りてるか” を見える化しましょう。

1) RAMの目安は「人数」より「セーブの育ち具合」

序盤は軽くても、工場が巨大化するとサーバーは重くなります。

小規模：最低ラインでも動くことはある
中〜大規模：余裕RAMがあるほど安定（後半ほど効く）

※Dedicated Serverのメモリ目安として「12GB最小、より大きいセーブや4人超なら16GB推奨」という情報が整理されています（後述の出典参照）。

2) オートセーブ由来の“カクッ”は調整できる

数分ごとに一瞬止まるなら、オートセーブ負荷が当たりのことが多いです。

オートセーブ間隔を少し長めにする（例：5分→10分など）
ただし長くしすぎると、事故時の巻き戻りが増える
→「安定＞保険」か「保険＞快適」か、サーバー方針で決める

さらに効くのが保存先です。

セーブ・バックアップは SSD/NVMe に置く
HDDや空き容量が少ない環境は、保存時に詰まりやすい

3) バックアップは“世代数”が多すぎても重くなる

バックアップを残しすぎると、ディスクも管理も膨らみます。

おすすめはこのイメージです。

直近：3〜5世代（即戻し用）
日次：7〜14世代（更新事故・破損対策）
週次：別媒体へ1〜3本（最終防衛）

Dockerなら特に、永続化ディレクトリ（/config 等）を丸ごと固めて退避できる形にしておくと復旧が速いです。

4) メモリ不足のサイン（早めに手を打つ）

起動はするが、時間が経つほど操作反映が遅くなる
参加者が増えると急に不安定
OSがスワップを使い始める（Linuxなら free -h、Windowsならタスクマネージャ）

この状態で無理に続けるより、RAM増強（上位プラン）か、定期再起動＋バックアップ強化のほうが結果的に安定します。

回線が苦しい（地域選び・Ping・上り帯域の見積もり）

回線問題は「CPU/RAMが余っているのにラグい」で気づきます。
対策は “距離”と“上り”と“安定性（ロス/ジッター）” の3点です。

1) 地域選び：まず距離（Ping）を縮める

参加者が日本中心なら、日本に近いリージョンが有利
海外混在なら、全員の中間に寄せる（妥協点を作る）

Pingが下がるだけで「同期が気持ち悪い」が改善することは珍しくありません。

2) 上り帯域：自宅回線は“アップロード”がボトルネックになりやすい

ダウンロードが速くても、上りが細いと多人数で崩れやすい
家族の動画配信・クラウド同期・大容量アップロードがあると一気に悪化

できる対策：

サーバーPCは 有線LAN（Wi-Fiは不安定要因になりやすい）
ルータで QoS を有効化（上りの詰まりを抑える）
自宅で限界なら、VPS/レンタルへ移すのが最短

3) ロス/ジッター：速度より“揺れ”が敵

Pingが低くても、揺れるとラグに見えます
特定の人だけ不安定なら、その人の回線や経路が原因のことも多いです

切り分けのコツ：

参加者の中で「誰でも重い」→ サーバー側（地域/上り/負荷）
「特定の人だけ」→ その人の回線、IPv6/IPv4経路、Wi-Fi環境

工場を止めない運用（Auto Pauseの扱い方）

Auto Pause は「誰もいない時にシミュレーションを止める」設定で、軽く・安全に運用したい人ほど向きます。

Auto Pause を有効
- 無人時に負荷が落ちる
- 燃料枯渇や想定外の詰まりが起きにくい
- 省リソースで安定しやすい
Auto Pause を 無効（工場を回し続ける）
- 24時間生産できる
- ただし、サーバー負荷が増えやすく、低スペックだとラグ要因になる

「止めない」運用にするなら、先にこの2点を整えると事故が減ります。

電力が絶対に止まらない設計（燃料補給の詰まり対策）
定期バックアップ＋定期再起動（重くなる前提で回す）

よくある質問（検索されがちな詰まりどころ）

追加できない／タイムアウトする／外部から入れない

「Server Managerに追加できない」「追加はできるけど入れない」「外部の友だちだけ入れない」は、原因がだいたいパターン化しています。まずは “どこまで届いているか” を切り分けるのが近道です。

最短チェック（上から順に）

サーバーが本当に起動しているか
- レンタル：管理画面が「Running」か
- VPS/Linux：サービスが生きているか（systemd / Docker logs）
- Windows：Dedicated Serverのコンソールが落ちていないか
同じネットワーク内（LAN）から入れるか
- 自宅運用なら、まずは LAN内IP（192.168.x.x など） で試す
- これで入れるなら、サーバー自体は動いていて 外部公開（ルータ/回線）の問題 に寄ります
外部（スマホ回線など）から入れるか
- 家のWi-Fiを切って 4G/5Gから試す（NATループバック問題を避ける）

タイムアウトの典型原因と対処

ポート不足（特に1.1以降）
- まずは 7777をTCP/UDP、加えて 8888をTCP まで通す（サーバー側FW＋外部FW＋ルータ転送の全部）
IPの指定ミス
- 自宅：友だちに渡すのは グローバルIP（またはDDNS）
- VPS：基本は VPSのIPv4（IPv6のみ環境は詰まりやすい）
ルータの二重化（ダブルNAT）
- 上流機器にもルータ機能があると、転送しても届きません
- 解決策：上流をブリッジ化 or 上流→下流→サーバーへ二段転送
CGNAT（そもそも外部公開できない回線）
- ルータのWAN側IPと、外部で見えるIPが一致しないなら疑う
- 対策：VPS/レンタルへ移すのが最短

“友だちだけ入れない”のときのコツ

まず管理者が一度サーバーへ入り、起動直後の設定が完了しているか確認（初回生成中だと参加者が失敗しやすい）
友だち側が会社回線・学内回線だと、外向き通信が制限されることがあります（別回線でテスト）

一覧に出ない／証明書の警告が出る

一覧に出ない

Dedicated Serverは「検索して出てくるサーバーブラウザ」型ではなく、基本的に 自分で追加（Add Server）する運用です。

一覧に出ない＝故障ではないことが多いので、次を確認します。

Server Manager で Add Server を使っているか
IP:ポート を正しく入れているか（スペースや全角コロンに注意）
自宅運用で、LAN内から試しているなら LAN内IP を入れているか

証明書の警告が出る

これは多くの場合、サーバーが自前で証明書（自己署名）を生成するために出る“正常系”です。

安全な判断基準

自分が今まさに立てたサーバー（IP/ホストが一致） → 承認してOK
見覚えのないIP、第三者が用意したサーバー → 承認しない方が安全

ただし、警告のあとに接続が失敗する場合

サーバー時刻がズレていると、TLSで「まだ有効になっていない証明書」扱いになることがあります
- VPS/Linux：NTP有効化（時刻同期）
- Windows：時刻同期（タイムゾーン含む）を確認
それでもダメなら、8888/TCP未開放が絡むケースが多いので、ポートを再確認します（次項の切り分けへ）

ポートを開けたのに繋がらない（外部・内部の切り分け）

「開けたはず」のまま沼る原因は、“どこで止まっているか”が曖昧なまま設定を増やしてしまうことです。
ここは 3つの壁 を意識すると整理できます。

壁は3枚

サーバー本体のFW（Windows Defender Firewall / UFW など）
VPS事業者の外部FW（セキュリティグループ等。VPSのみ）
家庭用ルータのポート転送（自宅運用のみ）

まずは“内部→外部”の順で確認する

自宅PCで立てている場合

サーバーPC自身から入れる（localhostやServer Manager）
同じ家の別PCから LAN内IP で入れる
スマホ回線から グローバルIP で入れる

この順で、どこで失敗するかが分かれば原因はほぼ絞れます。

よくある“開けたつもり”の正体

TCP/UDPの片方しか許可していない
- 7777は TCP/UDP の両方を揃える前提で考える
8888/TCPが抜けている（1.1以降で詰まりやすい）
ルータ転送の転送先IPが変わっている
- サーバーPCのIPがDHCPで変わると、転送が別PCに飛びます
- 対策：DHCP予約で固定
外側ポートと内側ポートを変換してしまっている
- 外7777→内7778のような変換は、ゲームによっては失敗しやすい
- 基本は 同じ番号で揃えるのが安全
NATループバック問題
- 家の中から“グローバルIP”で試すと失敗するルータがあります
- 外部テストは必ず スマホ回線で

セーブが読み込めない／巻き戻る／移行に失敗する

セーブ周りは「壊れた」よりも、別のセーブを読んでいるケースが多いです。焦らず、次の順で当たると復旧が早いです。

読み込めない・移行に失敗する時の鉄板チェック

サーバーを停止してから作業しているか
- 動作中にアップロード/上書きすると破損しやすい
アップロード後に“ロード（Load）”までしているか
- Uploadしただけで、サーバーが新規ワールドを起動し続けていることがあります
セッション名の混同がないか
- 「サーバー名」と「ワールド/セッション名」は別
- 似た名前が並ぶと、違うワールドを選びがちです

巻き戻る（進行が戻って見える）ときの典型原因

別ワールドに入っている
- “最近作ったテストワールド”が残っていて、そこに入ってしまう
バックアップ世代を誤ってロードしている
- 自動バックアップが多い環境ほど起きがち
ホスト型マルチのローカルセーブと混ざっている
- 移行後は「専用サーバー側のセーブ」が正
- 手元の古いセーブをうっかり上書きしない

安全な移行手順（最小）

ローカルの対象セーブを コピーで二重保管
サーバー停止
サーバー側もバックアップを1本作る（保険）
Upload（またはファイル配置）
Loadして起動
管理者が入り、拠点や進行を確認してから参加者へ共有

セーブの場所が分からないとき（目安）

Windows（通常起動）：ユーザープロファイル配下の ...FactoryGame\Saved\SaveGames\server が基本
Linux：ユーザーディレクトリ配下の ...FactoryGame/Saved/SaveGames/server が基本
Docker：永続化している /config 側にセーブがまとまる構成が多い

※Windowsで「サービス化」して動かしていると、保存先が“システムユーザー側”に寄って迷子になりやすいです。初心者はまず通常ユーザーでの運用が安全です。

人数を増やしたい／サーバーを引っ越したい

人数を増やしたい

やることは2段階です。

設定上の上限（Max Players）を上げる
耐えられるだけのリソース（CPU/RAM/回線上り）を確保する

失敗しにくい増やし方

いきなり倍にせず、+1〜+2ずつ
増やした直後は
- ラグ（ゴムバンド）
- オートセーブの停止時間
- 接続失敗が増えないか
  を短時間チェック

人数より効くこと（体感改善が大きい）

車両・経路計算が増えすぎていないか
大規模工事を“分割”して行う
1.1以降で 8888/TCP が正しく通っているか（接続の安定性に影響しやすい）

サーバーを引っ越したい（レンタル⇄VPS⇄自宅⇄Docker）

引っ越しは「サーバー本体」よりも セーブと設定を持っていく作業です。

引っ越しの最短手順（事故防止）

旧サーバー停止
旧サーバーでバックアップ作成（世代も残す）
セーブ（必要なら設定も）を新サーバーへ移す
新サーバー起動 → Server ManagerでLoad → 管理者が確認
友だちへ新しい接続先を共有
- IPが変わるので、Server Managerへの再登録が必要
- 証明書も再承認が必要になることがあります

Dockerの引っ越しが強い理由

/config（永続化フォルダ）を丸ごと移せば、復旧が速い
ただし、移転後は ポート公開とFW を新環境でも同様に通す必要があります（忘れやすい）

5分で終わる最終チェックリスト

起動・ポート・FW・Server Manager・バックアップの確認項目

以下を上から順に潰せば、「建てたのに入れない」「友だちだけ入れない」の大半は回避できます。
（✅が全部付けば“いつでも遊べる状態”です）

0:00–1:00　起動している（落ちていない）✅

[ ] サーバーが Running（レンタルは管理画面で確認）
[ ] 直近ログに 同じエラーが連発していない
- Linux(systemd)：journalctl -u satisfactory -n 50 --no-pager
- Docker：docker compose logs -n 80
- Windows：Dedicated Serverのコンソールで落ちていない／エラーがループしていない
[ ] 起動直後の初期生成が終わっている（数分かかることがある）
→ 生成中は「タイムアウトっぽく見える」ことがあります

ここで止まるなら：まずはメモリ不足・更新不整合・依存不足（Windowsのランタイム等）を疑い、再起動→ログ確認でOK。

1:00–2:00　サーバーが“待ち受け”できている（ポート競合なし）✅

[ ] サーバーが必要ポートで待ち受けている
- Linux：ss -lntup | egrep '7777|8888'
- Windows：netstat -ano | findstr 7777 / findstr 8888
[ ] すでに別アプリが同じポートを使用していない（競合すると起動しても不安定）

目安（現行でまず疑う2つ）

7777：TCP/UDP
8888：TCP
（ポートを変更している場合は、その番号に合わせて確認します）

2:00–3:30　FW（OS＋外側）とルータ転送が“同じ番号”で通っている✅

ここが一番多い詰まりポイントです。チェックは3段で行います。

A. OS側FW（サーバー本体）

[ ] Windows：受信規則で 7777(TCP/UDP) と 8888(TCP) を許可
（可能なら実行ファイル許可も追加）
[ ] Linux(UFW等)：同ポートを許可

B. VPSの外側FW（セキュリティグループ等）※VPSのみ

[ ] 7777(TCP/UDP) と 8888(TCP) を許可
※OS側だけ開けても、外側が閉じていると到達しません

C. 自宅ルータのポート転送 ※自宅のみ

[ ] 転送先IP（例：192.168.1.xx）が固定されている（DHCP予約推奨）
[ ] 外側→内側が 同じ番号 で転送されている（例：7777→7777）
※変換転送（外7777→内7778）は、トラブルが増えやすいです
[ ] 二重ルータ（ダブルNAT）になっていない
[ ] CGNATっぽくない（WAN側IPと外部から見えるIPがズレていると要注意）

外部テストの鉄則

[ ] 家のWi-Fiを切ったスマホ（4G/5G）など、LAN外から接続テスト
※自宅内からグローバルIPで試すと失敗する機器があります（NATループバック問題）

3:30–4:30　Server Managerで“初回セットアップ完了”✅

[ ] Server Managerで Add Server（IP:ポート）できる
[ ] 証明書警告は「自分のサーバー」だと確信できる場合のみ承認
[ ] まだ未設定なら Claim（所有権の確立） が完了している
※先に他人がClaimすると面倒が増えます
[ ] 管理者パスワード を設定・保管した（参加者全員に配らない）
[ ] ワールド作成（Create Game）またはセーブロード（Load）ができ、管理者がログインできる

ここで引っかかるときの型

追加はできるがJoinできない → ポート（特に8888/TCP）か外部到達性を再チェック
一覧に出ない → “検索に出るタイプ”ではないので、Add ServerでOK

4:30–5:00　バックアップが“作れて・戻せる”✅

[ ] バックアップ保存先を把握している（Dockerなら永続化ディレクトリ、レンタルならバックアップ機能）
[ ] 手動バックアップを1本作った（更新前の保険として最重要）
[ ] 世代管理の方針を決めた
- 例：直近3〜5 + 日次7〜14 + 週次を別媒体へ
[ ] 復元手順が分かる（最低限これだけ）
- ①サーバー停止 → ②現データ退避 → ③バックアップを戻す → ④起動 → ⑤管理者が確認

まとめ

Satisfactoryの専用サーバーは、やることを整理すれば難しくありません。失敗の多くは、手順そのものよりも「前提の取り違え」と「切り分け不足」から起きます。

この記事の要点を最後にまとめます。

専用サーバーは、ホスト落ち回避・24時間稼働・負荷分散に強い
少人数・短時間ならホスト型でも十分な場合があります。
方式は目的で選ぶのが正解
早さ優先ならレンタル、自由度や自動化ならVPS/Docker、コスト優先なら自宅PC（ただし運用負担あり）。
共通の流れは5ステップ
Dedicated Server入手 → 起動 → Server ManagerでClaim/管理者設定 → ワールド作成/移行 → ネットワーク設定 → 運用設計。
接続トラブルの主因はポート・FW・ルータ
まずは「内部から入れるか／外部から入れるか」で切り分け、必要ポートは“いまの前提”で揃えるのが近道です。
Server Managerは実質ここが本番
サーバー追加→証明書警告の扱い→Claim→管理者権限→ワールド作成/ロードまでを管理者が先に完了させると、参加者が迷いません。
長期運用は「更新・バックアップ・監視」で決まる
更新前バックアップ、世代管理、復元手順の固定、ログ確認ルートの確保で“壊れない運用”になります。
重い・ラグいは原因別に対策できる
CPU（車両・経路計算・大量変更）／メモリ（巨大セーブ・同時接続・保存負荷）／回線（距離・上り・揺れ）で打ち手が変わります。