Satisfactory×XServer入門｜GAMEs・VPS for Game・VPSの違いと選び方

2026年2月14日

Satisfactoryのマルチを本気で楽しみ始めると、だいたい一度はこう思います。

「ホストのPCを落とすと全員落ちるのがつらい…」
「24時間動かしたいけど、自分のPCをつけっぱなしは無理」
「専用サーバーって難しそう。結局どこで建てるのが正解？」

そこで候補に上がりやすいのが XServer ですが、いざ調べると別の悩みが出てきます。

「XServer GAMEs・VPS for Game・VPS、名前が似すぎて違いが分からない」
「初心者はテンプレでいい？それとも最初からVPS？」
「人数が増えたらどのタイミングで増強すればいい？」
「必要ポートって何を開けるの？ “繋がらない”が怖い」
「短期で試したい。ムダな料金は払いたくない」
「ワールドが消えたら泣く。バックアップや移行ってどうするの？」

このページでは、Satisfactoryの専用サーバー運用でつまずきやすいポイントを先回りしつつ、XServerの3サービスを 「できること／できないこと」「向いている人」「最短で始める手順」「安定運用のコツ」 の順に整理します。

筆者目線ではなく、公式マニュアルに基づく事実と、初心者がハマりやすい“実務の落とし穴”を分けて説明するので、読み終わるころには次が判断できるようになります。

あなたは GAMEs / VPS for Game / VPS のどれを選ぶべきか
どこまでをテンプレで済ませ、どこから自分で触るべきか
“快適さ”を落とさずに、料金をムダにしない運用の作り方

「まずは今週末に動かしたい」人も、「長期運用で安定させたい」人も、ここで迷いを終わらせましょう。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

最初に結論：あなたはどのXServerを選ぶべきか（1分診断）

「SatisfactoryをXServerで遊びたい」といっても、“どこまで自分で面倒を見るか”で正解が変わります。
まずは次の4つに答えるだけで、だいたいの最適解が決まります。

Q1：とにかく最短で遊びたい？（設定を極力したくない）
Q2：あとから人数や負荷が増えても拡張したい？（32GB以上も視野）
Q3：サーバーの細かい調整・自動化もやりたい？（自由度重視）
Q4：まずは短期で試して、合うなら延長したい？（お試し運用）

💡ざっくり結論（迷ったらこれ）

初心者の最短ルート：XServer GAMEs（Satisfactory対応）
→ “まず動かす”が最優先。短期でも始めやすいのが強み。
長期運用・人数増に強い：XServer VPS for Game
→ ゲーム向けに使いやすく、上位メモリ帯まで伸ばしやすい。
自由度MAX（上級寄り）：XServer VPS
→ できることが広い分、運用の責任も増える（学びながら育てたい人向け）。

優先順位別おすすめ（安さ／手軽さ／自由度／安定性）

「何を優先するか」で、選び方はこう整理できます。
（※金額は公式掲載の代表値をベースにしています。キャンペーン等で変動することがあります）

スクロールできます

優先したいこと	おすすめ	理由（初心者目線で）
手軽さ（最優先）	XServer GAMEs	画面の案内に沿って進めればOK。設定の迷子になりにくい
短期で試す	XServer GAMEs	3日など短めの期間から入りやすい（「合うか確認」向き）
長期で安定運用	XServer VPS for Game	長期契約・上位プランが選びやすく、成長するワールドに合わせやすい
自由度（カスタム・運用自動化）	XServer VPS	“自分のサーバー”として作り込める。用途の幅が広い
コスパ重視（同じメモリ帯で比較）	ケース次第	“管理の手間”もコスト。安くても手間が増えると逆に損しやすい

✅初心者が失敗しやすいポイント
「月額が安い＝簡単」とは限りません。
“運用の手間（更新・再起動・バックアップ）を誰がやるか”まで含めて選ぶと、後悔が減ります。

迷ったらこの構成（Satisfactoryは16GB以上が前提になりやすい理由）

Satisfactoryの専用サーバーは、プレイが進むほど負荷が上がりやすいゲームです。
特に初心者が詰まりやすいのが、最初のスペック選びです。

結論：迷ったら「16GB以上」から。
理由は大きく2つあります。

1）XServerの“ゲーム用イメージ/テンプレ”側で16GB以上が条件になりやすい

Satisfactory用の環境（アプリイメージ）が、8GB以下だと選べない仕様として案内されています。
→ 初心者が「手順通りに進める」なら、自然と16GB以上が前提になります。

2）ゲーム特性として、後半ほどメモリ消費が増えやすい

工場が巨大化（ベルト・装置・輸送が増える）
オートセーブや同期が重くなる
参加人数が増えるほどサーバー側の処理が増える

🧩「16GBで足りる/足りない」の目安（ざっくり）

身内数人で、工場規模も控えめ：まずは16GBでスタートしやすい
人数が増える／工場が巨大化する予定：最初から上位メモリ帯を検討（または後で増強できるサービスを選ぶ）

⚠️見落としがちな落とし穴
XServer GAMEsはプランが分かりやすい一方、上位メモリ帯へ伸ばしたいとなると、最初から「VPS for Game / VPS」を選んだほうがスムーズなケースがあります。
「将来的に大規模化しそうか？」を最初に考えるのがコツです。

このページで解決できること（できないこと）

解決できること ✅

あなたに合うXServerの選び方（GAMEs / VPS for Game / VPS）
迷いやすい「手軽さ vs 自由度」「短期テスト vs 長期運用」の判断
なぜ16GB以上が“無難な出発点”になりやすいか（サービス仕様＋ゲーム特性）

このページだけでは解決しきれないこと ❌

「あなたのワールド規模（工場の密度）」「参加人数」「MOD運用」の細部まで踏まえた最適スペックの断定
→ ただし、次の行動指針は出せます：
“まず16GBで開始 → 重くなったら増強できる選択肢を確保”
具体的な構築手順（ポート設定、接続、バックアップ、移行）
→ ここは別章で、手順を画像・チェックリスト形式で解説するのがベストです。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

Satisfactoryのマルチ方式を整理（“ホスト”と“専用サーバー”の違い）

Satisfactoryのマルチは大きく 2方式 あります。
初心者が迷うのは「友達と遊べればOKだからホストでいい？」と思いつつ、途中から重くなったり、ホスト不在で進められなかったりする点です。

まずは違いを、ざっくり表で押さえてください。

スクロールできます

比較ポイント	ホスト（自分のPCで部屋を立てる）	専用サーバー（XServer等で24時間稼働）
始めやすさ	最短（いまのPCでOK）	初期設定が必要（ただしサービスによって簡単）
稼働時間	ホストが起動している間だけ	24時間稼働しやすい
負荷	ホストPCに集中（ゲーム＋配信＋通話で重い）	負荷を分離（プレイPCは軽くなりやすい）
参加の自由度	ホストがいないと遊べない	ホスト不在でも参加できる
安定性	自宅回線・PC状態に左右されやすい	データセンター回線で安定しやすい
コスト	追加費用なし（電気代は増えがち）	月額などランニングコストが発生

このページの「Satisfactory × XServer」文脈では、専用サーバー＝XServer上に置く“常設ワールド”と考えると分かりやすいです。

専用サーバーにすると何が良くなる？（24時間稼働・負荷分離など）

専用サーバー化のメリットは、ひとことで言うと “マルチの面倒が減る” ことです。
特にSatisfactoryは、進行するほど工場が巨大化して処理が重くなりやすいので、体感差が出やすいです。

1）24時間稼働で「誰かがホストになる問題」が消える

ホストが落ちたら全員終了…が起きにくい
「今日はAが建築、明日はBが増設」みたいに、参加が自由になります

2）負荷が分かれるので、プレイPCが楽になりやすい

ホスト方式だと、ホストのPCは「ゲームを動かす」＋「サーバー処理」も担当しがちです
専用サーバーにすると、プレイ側はクライアントに集中でき、ホストだけ重いが起きにくくなります

3）通信が安定しやすい（全員が“同じ条件”になりやすい）

自宅回線・Wi-Fi状況・ルーター設定に左右されにくい
「ホストだけ快適で、他がラグい」問題が緩和されることがあります

4）運用が“仕組み化”できる（バックアップ・移行がやりやすい）

ワールド（セーブ）を管理しやすい
いざというときの復旧手順を作りやすい（※これは後半の“バックアップ章”で重要になります）

📝初心者向けの現実的な判断基準

「週に何回も遊ぶ」「参加者が増えそう」「工場が大きくなる予定」なら、専用サーバーにする価値が出やすいです。

専用サーバーが向かないケース（少人数・短時間だけ等）

専用サーバーは万能ではありません。次の条件が多いなら、まずホストで十分なこともあります。

1）2〜3人で、短時間だけ遊ぶことが多い

“立ててすぐ遊ぶ”が正義
常設の必要が薄いなら、ホストのほうが手軽です

2）ワールドを頻繁に作り直す（検証・気分転換が多い）

専用サーバーは「継続して育てる」ほどメリットが大きい
逆に、毎回違うワールドで少し遊ぶだけなら恩恵が小さめです

3）コストをかけたくない／管理が不安

月額が発生する
“更新”や“再起動”など、最低限の運用は必要になります（サービスが簡単でもゼロにはならない）

4）トラブル時に自力で切り分けができないと不安

例：つながらない原因が「XServer側」「自宅回線側」「ゲーム側」のどれか
ただし、これは知識というより“手順”の問題なので、チェックリストがあると解決しやすいです

✅おすすめの始め方（失敗しにくい順）

まずホストで遊ぶ → 「常設が欲しい」「重い」が出たら専用サーバーへ
逆に、最初から“常設前提”なら専用サーバーでOK（後戻りもできます）

用語ミニ辞典（IP／ポート／Ping／ワールドデータ）

ここだけ分かれば、XServerでの接続・運用の理解が一気に楽になります。

IP（アイピー）

サーバーの“住所”のようなもの
友達が接続するときに必要になります
似た言葉で「ローカルIP（家の中の住所）」と「グローバルIP（世界に公開された住所）」があります
- 専用サーバー接続では、基本的に グローバルIP を使うイメージでOKです

ポート

同じ住所（IP）の中にある“入口番号”
「ゲーム用の入口」「問い合わせ用の入口」など役割で分かれていることがあります
つながらない原因で多いのが、ここが閉じている（フィルターやFWで遮断）ケースです

Ping（ピング）

通信の往復にかかる時間（低いほど反応が良い）
Pingが高いと、操作の反映が遅れたり、同期がもたついたりします
注意：Pingが低くても、サーバーの処理が重いとカクつくことがあります（別問題です）

ワールドデータ（セーブ／マップデータ）

あなたの工場・建築・進行状況が入ったデータ
“マルチ＝共有ワールド”なので、ワールドデータの扱いが重要になります
専用サーバー運用では特に、次の2つを意識すると安心です
- バックアップを取る（復元できる状態にする）
- 移行手順を決める（ローカル→サーバー／サーバー→別環境）

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

XServerで立てる前のチェックリスト（失敗を減らす前提条件）

「申し込み→起動→接続」までをスムーズにするには、始める前の準備が8割です。
この章は、初心者がつまずきやすいポイントを先回りで潰すためのチェックリストとして使ってください。

必要なもの（Steam/Epic、管理できるメール、クレカ等）

まずは「環境」と「連絡・支払い」と「運用」の3つに分けて揃えると迷いません。

ゲーム側（必須）

✅ Satisfactory（PC版）：Steam版 or Epic版（どちらでもOK）
✅ ゲームを起動できるPC（専用サーバーをXServerに置いても、遊ぶPCは必要）
✅ ボイスチャット手段（Discordなど：必須ではないけど、マルチは体感が激変）

XServer側（必須）

✅ XServerのアカウント登録（メールで本人確認が入ることがあります）
✅ 管理できるメールアドレス（普段使い・受信できるもの）
✅ 支払い手段（クレカ等：選べる方法は申し込み画面で確認）

運用のため（強く推奨）

✅ パスワード管理（使い回しNG。メモ帳よりパスワード管理アプリ推奨）
✅ 「共有する情報」をまとめる場所（例：Discordの固定投稿）
- サーバー名（分かりやすい名前）
- 接続先（IPやアドレス）
- 必要ならポート番号
- プレイヤー用パスワード（身内運用なら設定推奨）
- 管理者用パスワード（絶対に別で強固に）

📌ここで一言
専用サーバーは「立てたら終わり」ではなく、最低限 “パスワード管理”と“バックアップの意識” が必要です。ここを雑にすると、後で高確率で困ります。

目安スペックの考え方（人数・工場規模・放置運用で変わる）

Satisfactoryは、序盤は軽くても、進行とともに重くなりやすいタイプです。
だからこそ、最初から“最適解”を当てにいくより、増強しやすい前提で選ぶのが安全です。

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

まずは 「テンプレが使える・推奨されるライン」 を満たす
次に 「増えたときに伸ばせるか」（プラン変更・上位メモリ帯）を確認
最後に 「重くなる前兆」を見て増強する

💡ポイント：16GB以上が“出発点”になりやすい
XServerのSatisfactory向け環境では、8GB以下だと選べない（16GB以上が必要）と案内されているケースがあります。
そのため、初心者が「手順通り・迷わず」進めるなら、自然と16GB以上が基準になりやすいです。

プレイヤー人数別の目安（少人数／中人数／大人数）

ここは“断定”よりも、失敗しにくい目安として見てください。
工場の規模やオートセーブ頻度でも変わるため、最終的には運用しながら調整するのが前提です。

スクロールできます

人数イメージ	まずの目安	こうなったら増強検討
少人数（2〜4人）	16GBから始めやすい	後半でカクつき増・セーブが重い
中人数（5〜10人）	24〜32GBを視野	同時接続でラグ、サーバー再起動頻度が増える
大人数（10人以上）	32GB以上を想定	工場が巨大化するとさらに上が必要なことも

🧠「増強が必要か」を判断する実務サイン

サーバーのメモリ使用量が常に高止まり（スワップが増える）
オートセーブ時の引っかかりが目立つ
人が増えるほど同期がもたつく
再起動直後だけ軽く、しばらくすると重くなる

※この“見方”を知っておくと、無駄に高スペックへ飛ばずに済みます。

重くなる要因（建築密度・ベルト量・自動化の進行度）

Satisfactoryが重くなる原因は「人数」だけではありません。
むしろ多いのは、工場の作り方（密度・物流・継続稼働）です。

負荷が上がりやすい代表例

✅ 建築密度が高い（同じ範囲に設備を詰め込みすぎ）
✅ ベルト・スプリッター・合流が大量（物流の枝分かれが多い）
✅ 長距離物流が増える（車両・ドローン・列車などの運用が本格化）
✅ 常時稼働のラインが多い（放置運用で処理が積み上がる）
✅ 巨大な拠点が複数（全体管理が重くなりやすい）
✅ オートセーブの負荷（ワールドが大きいほど影響が出やすい）

🎯初心者ができる“重くしにくい作り方”の方向性（概念だけ）

物流を「一本化」して、分岐を減らす
一箇所に詰め込まず、拠点を整理して“見通し”を作る
放置稼働前提なら、後で拡張できる余白を最初から確保する

サーバーを公開する／身内だけにする（公開範囲の決め方）

ここはトラブルの種類が変わるので、最初に方針を決めておくとラクです。

身内だけ（おすすめ）

👍向いている：友達・固定メンバーで遊ぶ、荒らしが不安
進め方の基本：
- サーバー情報は公開しない
- プレイヤー用パスワードを設定（必須レベルで推奨）
- 管理者パスワードは別・強固に（絶対に共有しない）
追加の安全策（できれば）：
- 共有はDiscord等の限定チャンネルに固定
- 参加者が増えるなら、参加ルール（建築/解体/資材持ち出し）も明文化

公開（上級寄り）

👍向いている：募集して遊びたい、コミュニティ運用したい
注意点：
- 予期せぬ参加・荒らし・設定変更リスクが上がる
- ルール整備・監視・復旧（バックアップ）が必須級
公開するなら最低限：
- プレイヤー用パスワードを設定
- 管理者パスワードを強固に
- バックアップ頻度を上げる（万一の復元前提）
- 公開範囲（SNSにIPを晒す等）を慎重に

🔎「公開か身内か」迷ったら

まずは 身内運用 → 安定したら公開を検討
この順番が、最も失敗しにくいです。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

【比較】XServer GAMEs・XServer VPS for Game・XServer VPSの違いを一気に理解

「Satisfactoryの専用サーバーをXServerで立てたい」ときに迷うのは、性能よりも “どこまで自分で管理したいか” です。
結論から言うと、3サービスはこう住み分けできます。

XServer GAMEs：クリック中心で最短スタート。運用の手間を減らしたい人向け
XServer VPS for Game：ゲーム向けに扱いやすいVPS。テンプレ＋必要なら中身も触れる
XServer VPS：最も自由。ゲーム以外も含めて「サーバーそのもの」を作り込みたい人向け

できること／できないこと（自由度・管理画面・テンプレ有無）

まずは「できる／できない」を、初心者が失敗しやすいポイントに絞って整理します。

スクロールできます

項目	XServer GAMEs	XServer VPS for Game	XServer VPS
始めやすさ	とても簡単（ゲーム専用）	簡単（ゲーム用導線がある）	目的次第（自由＝手順が増えやすい）
管理画面	ゲーム向け管理画面（設定変更がしやすい）	ゲームパネル（電源操作・コンソール等）	VPSパネル（サーバー全般の管理）
テンプレ	最初からゲーム用に整備	ゲームテンプレ／OSテンプレの両面がある	OS・アプリイメージ等で自分好みに構築
中身（OS）に触れる自由度	低い（お手軽優先）	中〜高（必要に応じて触れる）	最高（好きに構築）
「Satisfactory以外」も同じサーバーで運用	基本は不可（別ゲームは別枠になりやすい）	やり方次第で可能（切替の発想）	可能（ただし自己管理）
周辺ツール導入（自動バックアップ、監視など）	制限されやすい	ある程度可能	自由に可能

初心者が特に意識すると失敗が減るのはここです。

「テンプレに任せたい」→ GAMEs / VPS for Game
「困ったら自分で直したい（原因調査や改善をしたい）」→ VPS for Game / VPS
「ゲーム以外の用途も同居させたい」→ VPS（もしくはVPS for Gameを工夫）

ポイントとして、VPS for Game は“ゲーム寄りVPS”なので、ゲームを起点に始めつつ、必要ならコンソール・OS側の操作へ踏み込めます。
逆に GAMEs は“運用を簡単にする代わりに自由度を絞る”設計です。

料金の仕組みの違い（短期契約・長期割引・前払いの注意）

料金は数字の大小だけでなく、「どの単位で契約するか」が根本的に違います。
ここを理解すると、ムダな出費が減ります。

XServer GAMEs：短期で始めやすい（期間型）

「○日間でいくら」という 期間型で分かりやすい
Satisfactoryは、短い期間から始められる表記があるので「まず試す」に向く
注意点：短期ほど割高になりやすいので、数週間〜数か月遊ぶなら長めの期間も検討価値あり

XServer VPS for Game：月額（契約期間で月額換算が変わる）

「スペック × 契約期間」で決まる VPS型
1か月から長期まで選べ、長期ほど月額換算が下がる（キャンペーン条件が付くこともある）
注意点：
- 長期契約は“前払い総額”が大きくなりやすい（月額が安く見えても総額で判断）
- キャンペーンは期限・条件がある（終了日・割引率は申込時に要確認）

XServer VPS：最も汎用。料金表と増設・オプションの考え方が重要

いわゆる標準的なVPSで、使い方の自由度が高いぶん、料金も「基本料金＋必要なら追加」という考え方になる
特徴として、プランによっては 無料でメモリ容量を増やせる仕組みが案内されている
注意点：
- ゲーム用途はメモリを食いやすいので、“最初から余裕”か“後で伸ばせる設計”が大事
- Satisfactoryのように、利用できるプラン条件（例：メモリ◯GB以上）が付くケースがあるため、事前確認が必須

【最短ルート】XServer（GAMEs / VPS for Game）で“テンプレ”から建てる手順

テンプレ型の強みは、「専用サーバーのインストール〜起動」までの面倒をサービス側が肩代わりしてくれることです。
その代わり、初心者がつまずくのはほぼ次の3点に集約されます。

申し込み時の選択（プラン・期間・初期設定）
通信設定（パケットフィルター／FW）
「起動しているのに繋がらない」の切り分け

ここでは、“最短でマルチ開始できる順番”に並べて解説します。

手順の全体像（この章でやること一覧）

最短ルートは、次の流れです（GAMEsもVPS for Gameも基本は同じ発想）。

サービスを選ぶ（GAMEs or VPS for Game）
申し込み（プラン・期間・初期設定を確定）
管理画面でサーバーを用意（テンプレ適用／起動）
通信を許可（パケットフィルター／FW）
起動チェック（ステータスとログ）
ゲーム側で初期設定（サーバー名・管理者PW・セッション作成）
フレンドを招待（接続先情報を共有）

補足：テンプレ型でも「ゲーム内の初期設定」は必要です。
専用サーバーは、最初に接続した人が 管理者パスワード設定やワールド開始（セッション作成）を行って、初めて“遊べる状態”になります。

申し込み時に間違えやすいポイント（プラン・期間・初期設定）

初心者が後悔しやすいのは、スペックそのものより 「選び方」です。

プラン（メモリ）
- Satisfactoryは、テンプレ利用の条件として 16GB以上が前提になりやすいです。
- ここを外すと「テンプレが選べない」「手順どおりに進まない」になりがちです。
契約期間（短期か長期か）
- まず試すなら短期、腰を据えるなら長期が有利になりやすい
- ただし長期は“前払い総額”が大きくなるので、最初は無理しないのが安全です。
初期設定（サーバーの置き場所・名称など）
- 後からサーバーが増えると、名前が雑だと確実に迷子になります。
- “誰が見ても分かる名前”にしておくと、運用が一気にラクになります。

サーバー名・管理用パスワードの決め方（後で困らない命名）

サーバー運用で「後から地味に効く」のが、命名とパスワード設計です。

おすすめの命名テンプレ（例）

SAT_グループ名_公開範囲_リージョン_作成日
例：SAT_Friends_Private_Tokyo_2026-02

こうしておくと、あとで複数ワールドを回しても混乱しません。

パスワードは“3種類”を分けて管理

XServerログイン用（管理画面に入るためのPW）
ゲーム内の管理者PW（サーバー管理権限。最重要）
プレイヤー用PW（任意）（身内運用なら設定推奨）

最低限のルールだけ守ると事故が激減します。

管理者PWは 長め＋使い回し禁止
共有するのは プレイヤー用PWだけ
可能ならパスワード管理ツールに保存（メモ帳は避ける）

プラン選定の目安（最小構成／増強の判断ライン）

迷ったら16GB以上をスタート地点にしてください。
理由はシンプルで、テンプレ利用の条件に引っかかりやすいことと、Satisfactoryが後半ほど重くなりやすいからです。

目安（初心者向けの現実ライン）

2〜4人で開始：まず16GBで始めやすい
5〜10人、工場が巨大化しそう：24〜32GBも視野
放置運用（常時稼働）を本気でやる：最初から余裕を持つか、増強できる前提で選ぶ

増強を検討する“分かりやすいサイン”

再起動直後は軽いのに、しばらくすると重くなる
オートセーブの引っかかりが増える
同時接続が増えるほどラグが目立つ

初期設定：通信を通す（パケットフィルター／FW）

テンプレで起動できても、外部から通信できないと参加できません。
XServerでは主に 「パケットフィルター設定」（サービスにより表記差あり）で制御します。

基本の考え方

GAMEs：推奨設定が入っていることが多い（ただし変更したら要再確認）
VPS for Game：ゲームパネルから通信許可を設定できる
さらに OS側FW（Linux/Windowsのファイアウォール）が有効な場合は、そちらも許可が必要

「まずパケットフィルター → 次にOS側FW」を意識すると、迷いにくいです。

必要ポートの整理（ゲーム・クエリ・ビーコン等）

結論として、Satisfactory専用サーバーは 複数のポートを使います。
ただし最重要なのは「あなたが使っているテンプレが、どのポートに割り当てているか」です。

まず確認すべき優先順位

XServerの管理画面に表示される “接続用ポート”
Satisfactory側の既定ポート（一般的な目安）

目安としては、以下がよく使われます（変更可能／環境によりずれることがあります）。

スクロールできます

役割（イメージ）	よく使われる既定値	プロトコルの目安
ゲーム通信の主ポート	7777	UDP中心（状況によりTCPも許可推奨）
問い合わせ（Server Managerで参照される系）	15777	UDP
ビーコン（通信補助）	15000	UDP

ポイント

競合していると 7778 / 15001 のように「次の番号」へずれることがあります。
そのため、“既定値を鵜呑み”にせず、最終的に サーバーログや管理画面の表示で確定させるのが安全です。

また、XServer GAMEsでは、ゲーム内で入力するポートが 7777 と案内されるケースがあります。
この場合は、まず表示どおりに進めてOKです（サービス側が接続しやすい形に合わせている可能性があります）。

“開けたはずなのに繋がらない”ときの確認順

ここは焦りやすいので、順番が命です。
上から順に潰すと、最短で原因にたどり着けます。

サーバーは本当に起動中？
- 管理画面でステータスが稼働になっているか
- ログが止まっていないか（クラッシュしていないか）
接続先は“正しいIP/アドレス”？
- コピペしたIPが最新か（再作成・切替で変わることがあります）
- “ローカルIP”ではなく外部から見える接続先になっているか
ポート番号は合っている？（ここが最多）
- ゲーム内Server Managerで入力しているポート
- 管理画面に表示されているポート
- 変更しているなら、変更後の値になっているか
パケットフィルターで許可できている？
- UDP/TCPの指定を間違えていないか
- ポート範囲がズレていないか（7777だけでなく7778等が必要な場合も）
OS側FWでブロックしていない？（VPS系で起きがち）
- LinuxのFW（ufw等）
- Windowsファイアウォール
バージョン不一致（意外とある）
- クライアントとサーバーの更新タイミングがズレると入れないことがあります
- いったん更新を揃えて再起動が近道です
IPv6/IPv4の噛み合い（最後の砦）
- 環境によってはIPv6既定の影響で接続に癖が出ることがあります
- ここまで来たらログを見て、どのアドレスで待ち受けているかを確認すると早いです

サーバー起動・動作確認（ステータス／ログの見方）

起動できたかどうかは、「管理画面」と「ゲーム側」の両方で確認すると確実です。

管理画面で見るポイント

ステータス：稼働中になっている
リソース：CPU/メモリが極端に張り付いていない
ログ：エラーが連発していない（起動ループになっていない）

ゲーム側で見るポイント

Server Managerで追加したサーバーがオンライン表示になる
初回接続時に、サーバー名・管理者PWの設定へ進める
セッション（ワールド）を作成して、実際にスポーンできる

初回起動で時間がかかるケースと対処

初回は次の処理が走りやすく、すぐに“完成形”の挙動にならないことがあります。

専用サーバー本体の初期展開
設定ファイル・フォルダの生成
初回起動に伴う内部更新

対処はシンプルです。

まず ログが動いているかを見る
途中で止まっていないなら、しばらく待ってから再確認
明らかにエラーで止まっているなら、再起動 → それでもダメならポート/FWを見直す

（“待つべきか直すべきか”は、ログが更新されているかどうかが目安になります）

再起動の影響（ワールド保存との関係）

専用サーバーは、再起動しても基本的にワールドは残ります。
ただし 止め方が雑だと、直前の変更が反映されないことがあり得ます。

安全な運用の考え方

プレイ中に落とす必要があるなら、まずプレイヤーを退避させる
可能なら「保存→停止」の順で行う（急な電源断は避ける）
定期メンテは、人がいない時間に実施する

また、専用サーバーは設定やセーブ関連が「正常終了」で保存される前提になりやすいです。
“なんとなく強制終了”を続けると、後で地味に困るので、ここだけは丁寧にやるのがおすすめです。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

ゲーム側での接続・参加手順（サーバー情報の入力〜合流まで）

接続に必要な情報をまとめる（IP／ポート／パスワード）

専用サーバー参加で必要なのは、基本この3つだけです。先に「共有用メモ」を作っておくと、合流が一気にスムーズになります。

1）接続先（IP またはホスト名）

いわゆる「サーバーの住所」です。
XServerの管理画面に表示される IP/ホスト名 をそのまま使うのが安全です。

2）ポート番号

迷ったら 7777 が基本（専用サーバーの標準ポートとして扱われることが多い）です。
ただし環境によって変わることがあるので、XServer側の表示（またはサーバー側設定）を最優先にしてください。
通信は TCP/UDP 両方が関係する前提で考えると、トラブル時の切り分けがラクになります。⚠️

3）パスワード（ある場合）
パスワードは混同しやすいので、役割で分けて覚えるのがコツです。🔑

プレイヤー用パスワード：参加者が入るための鍵（身内運用なら設定推奨）
管理者パスワード：サーバー設定・管理権限の鍵（絶対に共有しない）

共有テンプレ（そのままコピペでOK）

サーバー名：
接続先（IP/ホスト名）：
ポート：
プレイヤー用パスワード（設定している場合）：
参加ルール（後述の運用ルール）：

✅ ここまで揃っていれば、参加者は「招待」なしで合流できます。

ホスト招待ではなく“専用サーバー参加”で入る手順

ホスト招待（Steam/Epicの招待）ではなく、ゲーム内の“Server Manager（サーバー管理）”から追加して参加する流れです。

手順（初心者向けに最短で）

サーバーが起動していることを確認
- XServer側でステータスが稼働になっているか
- ※止まっていると、いくら入力が正しくても入れません
Satisfactoryを起動 → メインメニューを開く
「サーバー管理（Server Manager）」を開く
- マルチ用のサーバー一覧・設定を扱う画面です
「サーバー追加（Add Server）」を選ぶ
- 接続先（IP/ホスト名）を入力
- ポートは基本 7777 のまま（XServer側に別指定があればそれに合わせる）
追加できたら、一覧から対象サーバーを選び「参加（Join Game）」
初回だけ“設定がまだ”の場合がある
専用サーバーは、立てただけではワールドが始まらないことがあります。
その場合は、管理者が ゲーム内UIからセッション（ワールド）作成/読み込み を行って初めて遊べる状態になります。

つながらないときの“最短チェック”（ここだけ見ればOK）

サーバーが稼働中になっている？
IP/ホスト名を打ち間違えていない？（コピペ推奨）
ポートが合っている？（基本7777／XServer表示を優先）
プレイヤー用パスワードを設定しているのに、未入力ではない？
管理者がセッションを作成していない（まだワールドが始まっていない）可能性は？

管理者設定（パスワード・権限・参加者の運用ルール）

専用サーバーが快適になるかどうかは、最初の管理者設定でほぼ決まります。
初心者でも最低限これだけ押さえればOKです。

管理者が最初にやること（超重要）

サーバー名を設定（誰の何サーバーか分かる名前に）
管理者パスワードを設定（長め・使い回し禁止）
必要なら プレイヤー用パスワードを設定（身内ならおすすめ）
セッション（ワールド）を作成 or 既存セーブを読み込み
- ここが未実施だと、参加者が来ても“遊べる状態”になりにくいです

権限とパスワードの運用ルール（これで事故が減る）

管理者パスワードは 管理者のみ（共有しない）
参加者には プレイヤー用パスワードだけを渡す
参加者が増えるなら、パスワードは定期的に更新（抜けた人がいる場合は特に）

身内サーバーの“揉めない”ミニルール例（必要なものだけ採用でOK）

🧱 建築・解体：他人の設備は勝手に壊さない（変更は相談）
📦 共有箱：共通資材／個人資材を分ける（ラベル運用が楽）
⏰ 放置運用：AFKで放置するなら一言（電力・物流が止まりにくい）
🔧 メンテ：再起動・更新をする時間帯を決める（「深夜に落ちてた」を防ぐ）

覚えておくと上級者っぽくなるポイント

専用サーバーは「最初に接続した人」が設定を進める流れになりやすいので、初回は管理者が入って初期設定を済ませるのがスムーズです。
「誰でも管理できる」状態にすると便利な反面、設定変更やトラブルも増えます。最初は管理者を絞るのが安全です。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

ワールド移行とバックアップ（いちばん事故る所を先回り）

既存ワールドを持っていく手順（ローカル→サーバー）

結論から言うと、やることは 「.sav を正しい場所へ置いて、サーバー側でそのセーブを読み込む」 だけです。
ただし事故りやすいので、最初に“安全な型”を作ってから移行します。🧰

全体の流れ（初心者はこの順で）

ローカルのセーブを確保する（複製して退避）
サーバーを止める（動いたまま上書きしない）
サーバー側のバックアップを1本取る（保険）
サーバーのセーブ保存先を特定する（ここが分かれ道）
.sav をアップロード
サーバーを起動 → ゲーム内で“そのセーブ”をロード
5分だけ動作確認（ログイン・保存・再起動の確認）

移行前にやること（世代管理・命名・復元テスト）

ここを省くと、だいたい後で泣きます。先に“復元できる状態”を作りましょう。🛟

1）セーブの世代管理（最低3世代）
おすすめはこの3本セットです。

現行（最新）：いま遊んでる最新版
安定版（1つ前）：昨日 or 直前の安定してた状態
保険（重要作業前）：大型工場・大型更新・MOD変更の直前

2）命名ルール（見ただけで戻せる）
セーブは後で混ざるので、ファイル名に情報を埋めます。

例：WorldName_2026-02-14_beforeUpdate.sav
例：WorldName_2026-02-14_preMegaFactory.sav

3）復元テスト（1回だけでOK）
「バックアップ取ったつもり」事故を潰します。

ローカル：複製した .sav を別フォルダへ置く
サーバー：“空のワールドを一度作って保存” → どこに .sav が生成されるか確認
これで 正しい保存先フォルダが確定します（環境差を吸収できる最強手順）

ローカル側：セーブ場所の見つけ方（Windowsの基本）

Windowsキー + R → 次を貼り付け → Enter
- %LOCALAPPDATA%\FactoryGame\Saved\SaveGames
Steam/EpicのIDっぽいフォルダの中に .sav が入っています
更新日時が新しいものを選ぶのが基本（不安なら3本まとめて退避）

サーバー側：セーブの保存先を見つけるコツ（ここが最重要）

専用サーバーのセーブは、だいたい次のどちらかにいます。

パターンA：.../.config/Epic/FactoryGame/Saved/SaveGames/server
パターンB：.../FactoryGame/Saved/SaveGames/server

✅ 一番安全な判定方法
1回だけ新規ワールドを作って保存し、増えた .sav がある場所が“正解”です。
（ホスティング方式や起動ユーザーの違いで、保存先がズレる事故を防げます）

アップロード〜読み込み（失敗しない型）

サーバーを停止（可能なら管理パネルから停止）
.sav を SaveGames/server フォルダへアップロード
サーバー起動
ゲーム内の Server Manager（サーバー管理） から
- 対象サーバーに接続 → セッション（ワールド）をロード/選択
最後に、次を確認して終了
- 参加できる
- 手動セーブできる
- 再起動しても同じワールドで入れる

バックアップ設計（頻度／保存先／復元手順）

バックアップは「頑張る」より “仕組み化” が勝ちです。
Satisfactoryはハマるほど工場が肥大化するので、後からの復元が重くなります。🧱

おすすめ設計：二段構え（セーブ＋スナップショット）

スクロールできます

層	何を守る？	方式	目安頻度	向いている復元
軽量バックアップ	ワールド（.sav）	`SaveGames/server` を退避	毎日 or 遊んだ日ごと	ワールド破損・巻き戻し
重量バックアップ	サーバー全体	サービスのイメージ保存/バックアップ機能	週1 + 大きな変更前	設定含めて丸ごと復旧

保存先は“分散”が正義（3-2-1っぽく）

サーバー内（サービスのバックアップ領域）
ローカルPC（外付け/別フォルダ）
できればクラウド（Google Drive等）にも1世代

バックアップ頻度の考え方（これだけでOK）

🗓️ 定期：週1（最低ライン）
🧨 イベント前：アップデート、設定変更、MOD導入、巨大工場の着工前
💤 放置運用する前：長時間稼働に入る前に1本

“壊れた”ときに最短復旧するための型

トラブル時は、慌てて上書きするのが一番危険です。
次の順で“戻れる手段”を残しながら進めます。🚑

最短復旧フロー（上から順に試す）

サーバーを停止（まず事故拡大を止める）
現状のセーブを退避
- broken_YYYYMMDD.sav のように名前を変えて保存（証拠保全）
1つ前のセーブに差し替え（軽量バックアップ）
- SaveGames/server に戻す → 起動 → ロード確認
ダメなら サービスのバックアップ/イメージから復元（重量バックアップ）
- サーバー全体を“正常だった時点”へ戻す
最後の手段：新規サーバーに再構築 → セーブだけ移植
- 工場（.sav）が生きていれば、環境を作り直しても復旧可能

復旧を速くする“管理メモ”テンプレ（コピペ推奨）

最終正常日時：
直前にやった変更（設定/MOD/更新）：
使う復元データ名：
復元方法（セーブ差し替え or イメージ復元）：
復元後チェック（参加/保存/再起動）：

このメモがあるだけで、復旧が“作業”になります（パニックになりにくいです）。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

安定運用のコツ（更新・再起動・監視・スケール）

アップデート対応（クライアントとサーバーの版ズレ防止）

Satisfactoryの専用サーバー運用で一番起きやすいのが「クライアントとサーバーの版ズレ」です。
結論、“更新タイミングを1つにまとめる”のが最強の予防策です。

版ズレが起きる典型パターン

クライアントが先に更新（Steam/Epicが自動更新）→ サーバーが旧版のまま
ブランチ違い（早期アクセス／実験版など、同じタイトルでも配布ラインが違う）
再起動が不完全（サーバー更新が走る前に中断・失敗）

XServer運用での“ズレ防止の型”（初心者向け）

遊ぶ前に、管理者が 「サーバー再起動 → 更新反映 → 接続確認」 をルーチン化する
- XServerのSatisfactoryは、再起動時にアップデート有無を確認して自動更新される方式が案内されています（＝“再起動が更新トリガー”になりやすい）
大型アップデート時は、まず バックアップ（手動セーブ＋ファイル退避） を取ってから更新
参加者には「今日は○時に更新してから集合」と共有して、更新タイミングを一本化

もし版ズレが起きたときの最短手順

参加者側：ゲームを一度終了 → 再起動（Steam/Epic更新が残っていないか確認）
管理者側：サーバーを再起動（更新チェックを走らせる）
それでもダメなら：
- しばらく待つ（サーバー側の更新配布が遅れるケースがある）
- 直前に枝（Experimental等）を切り替えたなら、参加者とブランチを合わせる

トラブル調査のコツ（詰まったらここを見る）

ログを確認すると「何が起きているか」が早いです
- 例：FactoryGame.log（クライアント／サーバーで保存場所が異なる）

定期再起動は必要？（重くなる前に効くメンテ）

結論、“必要になることが多い”です。
Satisfactoryは遊ぶほど工場が肥大化して、長時間稼働で重くなりやすいので、定期再起動＝予防整備として効きます。

定期再起動が効きやすい症状

しばらく稼働すると カクつきが増える
参加・ロードに時間がかかるようになる
何もしてないのに 応答が不安定になる（体感）

おすすめ頻度（迷ったらこの目安）

身内4人前後・中規模：週1〜2回
放置運用が多い／工場が巨大：毎日1回（深夜など無人帯）
まずは軽く始めて、効果があるなら回数を増やすのが安全

再起動で事故らない手順（テンプレ）

事前告知：
- 「○時に再起動します。5分前に一度集合してください」
再起動直前：
- 重要作業を止める（大工事の途中は避ける）
- 可能なら 手動セーブを1本（保険）
再起動後：
- 管理者が先にログインして ワールドが正しくロードできるか確認
- 参加者を招集

知っておくと得する設定の考え方

「無人時に工場を動かしたい」なら、無人時停止（自動ポーズ）系の設定が関わります
「とにかく安定優先」なら、無人時は止めて負荷を下げるのも手です

プラン変更の判断基準（CPU/RAM不足のサイン）

プラン変更は“最後の手段”ではなく、快適さを買う最短ルートになることがあります。
ただし、先に 数字（リソース）→ 症状 の順で判断すると失敗しません。

まず見る場所：リソースグラフ（CPU/メモリ/ディスク/ネットワーク）

XServer VPS（/ for Game）には、CPU使用率やディスクI/O、ネットワーク送受信量などをグラフで確認できる案内があります
ここを見るだけで「体感ラグ」の原因がかなり絞れます

増強を検討する“よくあるサイン”

CPU：
- 高負荷が続く（プレイヤー増・工場拡大時に顕著）
- 体感としては「全員が同時に重い」「操作遅延が一定して出る」
メモリ：
- 長時間稼働で悪化、再起動で一時的に改善しやすい
- 大規模ワールドほどメモリ要求が増える
ディスク：
- オートセーブの瞬間に引っかかりが出る
- ロードが遅い／保存が遅い
ネットワーク：
- サーバー側が問題なくても、上りが細いと全員に影響が出ることがある

プラン変更時の注意（先に知っておくと安心）

申請後、完了までの間に一部機能が使えない・時間がかかる場合がある旨が案内されています
一方で、プラン変更に伴うデータ移動など利用者作業が不要と案内されているケースもあります
→ つまり、“遊ばない時間帯に申請する”のが鉄板です。

ラグ／カクつきの原因切り分け（回線・サーバー・ゲーム設定）

「重い」は原因が1つとは限りません。初心者ほど、次の順で切り分けると早いです。🔍

切り分けの順番（最短ルート）

回線側（参加者1人だけ？全員？）
サーバー資源（CPU/メモリ/ディスク/ネットワーク）
ゲーム内要因（工場密度・ベルト量・オートセーブ・設定）

症状→原因の当たり表（簡易）

スクロールできます

症状	可能性が高い原因	まずやること
1人だけ重い	その人の回線/Wi-Fi/PC	有線化、別回線で試す
全員が同時に重い	サーバーCPU/RAM不足	リソースグラフ確認 → 再起動 → 増強検討
オートセーブでガクッ	ディスクI/O or セーブ肥大	セーブ前後の負荷を見る、バックアップ設計見直し
時間が経つほど悪化	メモリ系・蓄積系	定期再起動を導入
そもそも接続が不安定	FW/ポート/経路	ポート設定・フィルタ設定を再確認

“ログを見る”と一気に早い場面

変な切断・クラッシュ・挙動不審は、FactoryGame.log が手がかりになります
サーバー側のログは「サーバーのインストールディレクトリ配下に保存される」前提で紹介されている情報があり、環境によって置き場が違うこともあるので、まずはログ名で探すのが確実です

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

セキュリティと安全運用（身内サーバーでも最低限）

身内サーバーでも、事故はだいたい「悪意のある第三者」より “うっかり” で起きます。
この章は 「乗っ取り・情報漏れ・荒らし・復旧不能」 をまとめて防ぐための、最低限だけに絞った実務ガイドです。

管理画面・SSH・パスワード運用の基本

最初に守るべき対象は3つです。

スクロールできます

守るもの	具体例	取るべき基本策
アカウント	XServerアカウント、ゲームパネル	二段階認証、強いパスワード、共有しない
サーバー操作権	SSH、root権限、管理画面	鍵認証、ログイン経路を絞る、不要な入口を閉じる
ワールド	セーブ、設定ファイル	バックアップ、復元手順、更新前の退避

まずやるべき最低限（チェックリスト）

1）二段階認証を入れる（最優先）

XServerアカウント側で二段階認証を有効化します。
ゲーム用サービス側でも、二段階認証の設定導線が用意されていることがあります。
これだけで「パスワード流出＝即終了」を避けやすくなります。

2）“共有しないパスワード”を明確に分ける
パスワードが混ざると事故が増えます。最低でも次の3系統を分離してください。

XServerアカウント（最上位）：契約・支払い・全体設定に関わる
（VPS系なら）SSH/OSログイン：サーバー内部を触れる
Satisfactory管理者パスワード：ゲーム内の管理権限

共有する可能性があるのは プレイヤー用パスワードだけにします。

3）VPSを使うなら、SSHは“鍵認証”が基本
XServerのVPSはSSH Key（公開鍵）を登録して鍵認証を行う手順が案内されています。
初心者でも、やることはこの2つに絞ると安全性が上がります。

鍵認証を使う（公開鍵を登録）
（任意だが推奨）パスワード認証を無効化
- 「鍵を持っている人だけ入れる」状態に寄せられます

4）パケットフィルター（通信制限）はONが基本
VPS系では、SSH接続手順の中でも「パケットフィルターをON（推奨）」の流れが出てきます。
考え方はシンプルです。

開けるポートは“必要な分だけ”
使っていないポートは閉じる（後で増やすのは簡単、戻すのは面倒）

やりがちなNG例（これだけ避けるだけでも事故が減る）

参加者に管理者パスワードを渡す
“とりあえず全部開放”のまま放置
パスワードをDiscordの公開チャンネルに貼る（ログが残る）
アカウントを家族・友人と共用する

公開範囲の制御（パスワード／参加フロー／ログの確認）

専用サーバーは、原則として 「接続先を知っている人は入れる」 仕組みになりがちです。
特に重要なのが、Satisfactory側の仕様として プレイヤー用パスワード保護が初期状態で有効ではない点です。
つまり、身内運用でも「設定しない＝実質公開」に近づきます。

最低限の防衛ライン（身内サーバー向け）

1）プレイヤー用パスワードを必ず設定する

参加者の入口を「知っている人だけ」にします
共有する情報が増えるほど漏れやすいので、パスワードで最後に締めるのが安全です

2）参加フローを固定する（漏れにくい運用）
おすすめはこの形です。

共有場所：Discordの限定チャンネル（閲覧権限を絞る）
共有情報：
- 接続先（IP/ホスト名）
- ポート
- プレイヤー用パスワード
管理者パスワードは共有しない（管理者のみ保管）

3）“抜けた人がいる”タイミングで必ず変更する
身内運用で一番多い漏れは悪意より「情報が残る」ことです。

メンバー脱退
スクショ・配信で映った
Discordログが流出（招待リンク、アカウント乗っ取り等）

このタイミングで プレイヤー用パスワードを変更すれば、被害を切り離せます。

ログで確認する（“気づける”状態を作る）

「怪しいかも？」を勘で終わらせないために、最低限ここだけ見られるようにしておくと強いです。

Satisfactory専用サーバーのログ：FactoryGame.log（起動ごとにローテーションされる）
- 想定外の再起動、エラー連発、接続関連のエラーの手がかりになります
XServer側の稼働状況：CPU/メモリが不自然に跳ねていないか
- 荒らしというより「負荷が限界」「設定ミス」の発見に効きます

“荒らし対策”の考え方（事前に決めるルール）

荒らし対策は、強い仕組みを作るより 「被害を小さく・復旧を速く」 が現実的です。
初心者が最短で守りを固めるなら、次の3点セットで十分に強くなります。

1）事前ルール（揉めない・壊れない）

身内でも、ルールがないと “善意の事故” が起きます。最小限だけ決めましょう。

設備の解体・改造：他人の設備は勝手に触らない（変更は一言）
共有資材：共有箱と個人箱を分ける（看板で運用）
大工事：やる前に共有（電力落ち・物流崩壊を防ぐ）
再起動：管理者が行い、事前告知する

2）緊急時の手順（荒らしっぽい時に迷わない）

「起きてから考える」と手遅れになりやすいので、やることを固定します。

① サーバー停止（被害拡大を止める）
② 現状のセーブを退避（証拠・復元用）
③ プレイヤー用パスワードを変更（入口を閉じる）
④ 1つ前のバックアップへ復元（最短復旧）
⑤ 必要なら接続情報を変更（IP/ポートの再共有）

※この流れをDiscordに固定しておくだけで、復旧が作業になります。

3）バックアップが最大の荒らし対策

荒らし対策で最も強いのは「巻き戻せる」ことです。
身内サーバーでも、最低限この運用にしておくと安心です。

遊んだ日ごとにバックアップ1本（手動でもOK）
大きな変更前（アップデート、MOD導入、巨大工場着工前）にもう1本
保存先はサーバー内だけにせず、PCやクラウドにも分散

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

【上級編】XServer VPSで“自前構築”する場合の設計図（テンプレに頼らない）

自前構築は「最短で立てる」よりも、自由度・再現性・運用のしやすさを取りに行くやり方です。
ここでは、XServer VPS（Ubuntu想定）で Satisfactory専用サーバーを“運用前提”で組む設計を、手順の意味がわかる形でまとめます。

どんな人が自前構築向き？（メリットとコスト）

自前構築が向くのは、ざっくり言うと “触れる人” です。テンプレより手間は増えますが、得られるものも大きいです。

自前構築のメリット（テンプレより強い点）

自由度が高い
OS・ミドルウェア・ログ収集・監視・自動更新などを自分の型にできる
トラブル時に原因を追いやすい
どこで何をしたかが把握できる（＝復旧が速い）
他ゲームにも横展開しやすい
SteamCMD＋systemd＋FWの型ができると、別タイトルもほぼ同じ流れでいける

コスト（これを許容できるなら向いている）

初期構築：数時間〜（慣れれば短縮）
運用責任：自分
OS更新、障害対応、セキュリティ、バックアップ設計まで含む
ミスの影響が直撃しやすい
ポート・権限・ディスク枯渇などの “初歩事故” はテンプレより起きやすい

逆に、テンプレの方が向く人

「まず遊びたい」が最優先
SSHやLinux操作に慣れていない
障害対応に時間を割きたくない（トラブル＝即終了になりやすい）

構築の流れ（SteamCMD／サービス自動起動／更新の自動化）

ここからは “あとで困らない順番” に並べます。ポイントは、最初からサービス化と更新導線まで作ってしまうことです。

0）前提を固める（最初にやると後が楽）

OSは Ubuntu 24.04 など、長期運用前提のものに統一（XServerで提供あり）
管理用の一般ユーザーを作って、普段はroot作業を減らす
サーバー用途のディレクトリを決める（例：/opt/satisfactory など）

💡Satisfactory専用サーバーは Steam 上で 専用のアプリ（App ID: 1690800） として配布されています。
「ゲーム本体」とは別枠なので、ダウンロード設計も分けて考えると管理が楽です。

1）SteamCMDを入れる（“更新の仕組み”の土台）

SteamCMDは、サーバー更新を自動化するための核です。
Ubuntu系なら、まず以下が定番です。

multiverse有効化
i386アーキテクチャ追加（SteamCMDが32bit依存の都合で必要になるケースが多い）
steamcmd をインストール

※環境によっては「パッケージが見つからない」等があるので、詰まったら リポジトリ設定（multiverse） を最初に疑うのが近道です。

2）サーバーファイルを配置する（ダウンロード先を固定）

SteamCMDで重要なのは 「インストール先ディレクトリを固定」 することです。
運用で迷子になりやすい典型パターンがこれです。

どこに入ったかわからない
権限がrootと一般ユーザーで混在
更新したのに起動している実体が別ディレクトリ

おすすめは、専用ユーザー（例：steam）を作り、そのユーザーの所有に揃えること。

force_install_dir（インストール先固定）
login anonymous
app_update 1690800 validate

という流れが基本になります。

3）初回起動で“設定ファイルを生成”→以後はサービスで管理

初回起動は、設定・ワールド関連の初期生成が走りやすいので、

最初は手動起動で一度だけ通す
生成物を確認したら systemd（サービス）に移行

が事故りにくいです。

サービス化の狙いはこれです👇

OS再起動後も自動で上がる
落ちたら再起動できる
“起動手順” が1つに固定される（属人化しない）

4）更新の自動化は「2択」で設計すると迷いません

自動更新は、運用方針で正解が変わります。

A：再起動時に毎回アップデート（シンプル、事故りにくい）

systemd の ExecStartPre で SteamCMD 更新 → 起動
ただし、再起動に時間がかかりやすい

B：定時にアップデート → 再起動（運用が安定）

深夜などに cron でサービス再起動
“遊んでる最中に更新が入る” 事故を避けやすい

💡「自動化＝勝手に更新」ではなく、“いつ更新するかを固定する” のが運用品質です。

5）ワールドと設定の“逃げ道”を最初から用意

自前構築で一番の地雷は「更新・設定変更のやり直しが効かない」状態です。

最低限、最初からこの2つを固定します。

ワールドデータの保存場所
バックアップの保存先（別ディスク/別領域が理想）

ログの集約とトラブル調査の型

“自前構築の強み”が一番出るのがここです。
ログと調査は、型を決めるだけで復旧速度が段違いになります。

ログは「2系統」で見る（まず迷わない）

systemd / journal（プロセスとしてのログ）
- 起動できているか
- 落ちた理由は何か
- 再起動ループしていないか
ゲーム側ログ（FactoryGame.log 等）（ゲームとしてのログ）
- 接続・認証・API周りのエラー
- セーブやロードの失敗
- ポートやネットワークの異常

“繋がらない”時の最短チェック順（テンプレ）

上から順に潰すだけでOKです。

① サービスが生きているか（status / 再起動ループ）
② ポートが待ち受けているか（想定のUDP/TCP）
③ FWが塞いでいないか（XServer側＋OS側の二重確認）
④ クライアントとサーバーのバージョンが揃っているか
⑤ ログに “API/port/IPv6” 系のヒントが出ていないか

🧠コツ：原因を「ゲーム」「OS」「ネットワーク」に分けて、どの層の障害か当てにいくと迷子になりません。

ファイアウォール設計（必要な通信だけ通す）

自前構築は自由度が高いぶん、穴も自分で塞ぐ必要があります。
おすすめは “二段構え” です。

外側：XServerのパケットフィルター（入口を絞る）
内側：OSのFW（UFW等で最小許可）

Satisfactoryで基本的に必要になりやすいポート整理

一般に、Satisfactory専用サーバーは 複数のUDPポートを使います。

ゲーム用（例：UDP 7777）
ビーコン用（例：UDP 15000）
クエリ/接続口（例：UDP 15777）（クライアントUIで指定する側）

また、環境によっては 7777/TCP も必要になったという報告があり、詰まった時の追加候補になります（最初から全開放せず、症状が出たら足すのが安全）。

ルール設計の基本形（身内サーバーでもこれで十分）

許可：必要ポートのみ（SatisfactoryのUDP群）
許可：SSH（22/TCP）は“自分のIPだけ”が理想
拒否：それ以外は全部
OS側ではSSHにレート制限（ブルートフォース対策）

複数インスタンスを回すなら「ポートセット」を分ける

同一VPSで複数ワールドやテスト環境を持つ場合は、

インスタンスA：7777 / 15000 / 15777
インスタンスB：7778 / 15001 / 15778

のように 3点セットで番号を揃えて設計すると管理が楽です。
ビーコンポートは、使用中だと自動で次を探す挙動があるため、最初から衝突しない割り当てにしておくのが安定します。

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

トラブルシュート集（症状→原因→解決の早見表）

まずは「何が起きているか」を 3分類 すると、最短で解決に近づきます。

接続できない：通信（IP/ポート/フィルター）か、版ズレか、サーバー未起動
プレイ中に重い：回線か、サーバー資源（CPU/RAM/ディスク）か、工場の肥大化
セーブが怪しい：保存先・上書き・巻き戻り（世代管理不足）が主犯

最初にざっくり当たりを付ける早見表です👇

スクロールできます

症状	ありがちな原因	最初にやること
無限ロード	ポート不一致／サーバー側が落ちている／版ズレ	サーバー稼働確認 → ポート確認 → 再起動
一覧に出ない	Queryポートが閉じてる／違うポートに向けてる	ポート（特にQuery）とフィルター確認
タイムアウト	FW/フィルターで遮断／IP間違い／経路不安定	IPコピペ確認 → フィルター → OS側FW
TPS低下・全員ラグ	サーバーCPU/RAM不足／工場が重い	リソース確認 → 再起動 → 工場軽量化
1人だけラグ	その人の回線/PC側	有線化・再起動・設定軽量化
ロールバック	古いセーブをロード／保存が反映されていない	最新セーブの場所確認 → 世代で戻す
破損疑い	強制終了・上書き事故・セーブ肥大	退避 → 1つ前へ復元 → 検証

接続できない（無限ロード／一覧に出ない／タイムアウト）

接続系は、だいたい 「サーバーが生きていない」か「ポートが噛み合っていない」 のどちらかです。
焦って設定を触る前に、次の順番で“確定”させると最短です。

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

サーバー稼働：XServer側で「稼働中」か（落ちていたら何をしても入れません）
入力ミス：IP/ホスト名をコピペし直す（手打ちはミスります）
ポート一致：ゲーム内のポート欄と、サーバー側の待受ポートが一致しているか
フィルター/FW：XServerのパケットフィルター → OS側FW（VPSなら）も確認
版ズレ：クライアントとサーバーの更新タイミングが揃っているか

ポート／フィルターの確認ポイント

ここがいちばん事故ります。ポイントは 「どのポートが“何の役割”か」 を分けて考えることです。

Satisfactory専用サーバーで出てきやすいポート（代表例）

ゲーム用ポート：UDP 7777（一般的な既定）
Query（一覧・情報取得）：UDP 15777（一般的な既定）
Beacon（補助通信）：UDP 15000（一般的な既定）

ただし注意点があります。

ゲーム内の Server Manager（サーバー管理）で入力する“ポート欄” は、環境によって既定が異なります。
- 一般的には 15777（Query） が既定
- XServerのテンプレ手順では 7777 を入力する案内になっているケースがあります
  👉 まずは XServer側の案内どおりに入力し、うまくいかないときに「サーバー側の設定（Queryポート）がどれか」を見直すのが安全です。

XServerでのフィルター確認（やることはシンプル）

✅ パケットフィルター（ゲームパネル側）で、必要ポートを許可しているか
✅ VPSの場合は OS側FW（ufw/Windows FW） でも同じポートを許可しているか
✅ プロトコルを間違えていないか（UDPが主役。詰まったらTCPも追加検討）

「開けたはずなのにダメ」の典型

ポートは開けたが 別の番号に接続している（7777と15777の混同）
XServer側はOKだが OS側FWが遮断（VPSで多い）
ルールはあるが 範囲指定がズレている（例：7777だけで、7778に逃げていた等）

確認のコツ（再現性が上がる）

“いま接続に使っているポート”を、Discordなどに 固定メモにしてブレを防ぐ
複数インスタンス運用なら、
7777/15000/15777 の3点セットを インスタンスごとに+1して割り当てる（例：Bは 7778/15001/15778）

クライアント・サーバーのバージョン不一致

版ズレは「正しく設定しているのに入れない」系の代表です。💥
特にアップデート直後は起きがちなので、手順を固定すると解決が速くなります。

よくあるパターン

クライアントだけ先に更新（Steam/Epicの自動更新）
サーバーの再起動がされておらず、更新が反映されていない
ブランチが違う（早期アクセスとExperimentalなど）

最短の解決手順（テンプレ）

参加者全員：ゲームを終了 → ランチャー側で更新が終わっているか確認 → 再起動
管理者：サーバーを再起動（XServerでは再起動が更新反映のトリガーになりやすい）
それでもダメ：
- 少し待って再起動（配布のタイミング差が出ることがあります）
- ブランチ（EA/Experimental）を全員で揃える

切り分けの目安

“版が違う”表示が出る → まず版ズレ確定で対処
“タイムアウト”だけ → 版ズレより通信（ポート/FW）優先で確認

プレイ中に重い（TPS低下・ラグ・巻き戻り）

重さの原因は、だいたい 回線・サーバー資源・工場規模 のどれかです。
最短で当てるコツは「誰が重いか」です。

原因の当て方（超重要）

全員が同時に重い → サーバー側（CPU/RAM/ディスク）や工場規模が濃厚
1人だけ重い → その人の回線/PC設定が濃厚
オートセーブの瞬間だけガクッ → ディスクI/O or セーブ肥大が濃厚

まずやること（順番）

サーバーのリソース（CPU/メモリ/ディスク）を確認
一度再起動して改善するか確認（“蓄積系”なら効きます）
改善しないなら、工場側の負荷を落とす（下の手順）

工場規模が原因のときの対処（軽量化の順番）

工場の軽量化は「全部作り直す」ではなく、効くところから順にが正解です。
おすすめの順番はこの通りです。

1）無駄に動いているラインを止める（最短で効く）

使っていない生産ラインを停止（スイッチや入力遮断）
詰まりで回り続けているラインを整理
→ “常時稼働している量” が減ると、体感が改善しやすいです

2）物流の密度を下げる（地味に効く）

ベルトの分岐・合流が多い箇所を整理
同じ場所で何度も折り返すベルトを減らす（配線の見直し）
→ “モノが流れる経路”が複雑なほど重くなりやすい傾向があります

3）超密集拠点を分散（中長期で効く）

1拠点に詰め込みすぎたら、工程ごとに拠点を分ける
巨大工場の中心部だけ整理して、全体を作り直さない
→ いきなり全面改修より、“重い中心”を薄くするほうが失敗が少ないです

4）運用でカバー（再起動・セーブ間隔の調整）

定期再起動を導入（無人時間帯に）
オートセーブ間隔を見直す（短すぎると引っかかりが増える）
※間隔を伸ばす場合は、事故時の巻き戻りが増えるので、バックアップ運用とセットで

セーブが怪しい（ロールバック／破損疑い）

セーブ系の事故は、焦って上書きすると悪化します。
まず 「現状を退避」→「戻す」 の順番を徹底してください。

よくある症状

ロールバック（進捗が戻っている）
ロードで落ちる／入れない
一部だけ変（建築が消える等）※原因は多様なので、まずは世代で切り戻しが安全

最初に確認すること

“どのセーブをロードしているか”が最新か（似た名前のセーブで迷子になりがち）
サーバー停止せずにセーブを触っていないか（上書き事故の元）

復元手順（バックアップから戻す）

ここは「型」があると事故りません。🧰

最短復元テンプレ（安全第一）

サーバー停止（被害拡大を止める）
現状のセーブを退避

例：broken_YYYY-MM-DD.sav のようにリネームして残す（証拠保全）

バックアップから 1つ前の正常セーブ を用意
サーバーの SaveGames/server に配置（置き場所は環境で変わるので、分からなければ“新規ワールド保存で生成される場所”を正解にする）
サーバー起動 → 管理者が先に接続 → ロード確認
保存→再起動→再度入れる まで確認（これで復元成功が確定）

復元が早くなるコツ

バックアップは最低でも 3世代（最新／1つ前／大工事前）を残す
ファイル名に日付とイベント名を入れて、迷子を防ぐ
例：World_2026-02-14_beforeUpdate.sav

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

料金・コスパ最適化（ムダなく続ける）

短期で試す／長期で安くする（契約期間の考え方）

Satisfactoryのサーバー費用は、「どのサービスを使うか」と「どれくらいの期間で払うか」で体感が大きく変わります。まずは “失敗しない順番” で考えるのがコツです。

結論：迷ったらこの流れが堅い

まず 短期で動作確認（想定どおり遊べるか・重さは許容か）
問題なければ 30日→90日 などへ伸ばす
さらに「半年〜年単位で稼働」なら 長期契約があるVPS系 を検討

期間選びの目安（超ざっくり）

週末だけ試す：3日（まず“動くか”を確認）
1〜4週間遊ぶ：30日（途中でやめてもダメージが小さい）
1〜3か月続けたい：90日（ここからコスパが安定しやすい）
半年のプロジェクト：180日
1年近く固定で遊ぶ：365日（またはVPS系の長期）

「月額表示」に惑わされないコツ

サービスによっては「月額◯円〜」と書かれていますが、これは 契約期間ぶんを月割りした表示のことがあります。
実際の支払いは 期間ぶんを前払い になるケースがあるので、ここだけ確認しておくと事故りにくいです。

見るべきポイント

料金表示が「月額（換算）」なのか「請求額（前払い総額）」なのか
長期にしたときの“1か月あたり”がどれくらい下がるか
キャンペーン割引は「初回だけ」なのか「継続も」なのか

Satisfactoryは“メモリ前提”で費用が決まりやすい

Satisfactoryはゲーム特性上、人数だけでなく 工場規模（自動化量） で負荷が跳ねます。
そのため「とりあえず最安」より、最初から余裕ある構成（目安：16GB以上） を選んだほうが、結果的にムダが出にくいです（プラン変更・引っ越しの手間が減る）。

💡コスパ最適化の考え方：
“安いプランで我慢”より、快適に遊べる最低ラインを切らない ほうが、トータルの満足度と手戻りが少なくなります。

オプション（ストレージ・イメージ）の使いどころ

オプションは闇雲につけるとムダになります。
逆に、刺さる場面だけ 使うと「安定運用」と「引っ越し」が一気にラクになります。

ストレージ増設が向くケース

ストレージ（ディスク）増設は、ざっくり言うと “置き場所が足りない問題” の対策です。

増設を考えるサイン

バックアップを複数世代残したいのに、容量がカツい
ログやバックアップが溜まり、整理が追いつかない
複数ワールド・複数ゲームを同じVPSで回したい

判断のコツ

「今すぐ足りない」より 3か月後も足りるか で決める
（工場が育つほど、セーブや運用データが増えがちです）

イメージ保存が向くケース（“復旧を速くする保険”）

イメージ保存（スナップショット系）は、ストレージ増設とは別で、主に 「戻せる」 を強化します。

こういう人に刺さります

アップデート前に丸ごと退避して、失敗したらすぐ戻したい
環境を複製して「本番／検証」を分けたい
引っ越し（乗り換え）のときに、手順を簡単にしたい

ムダになりやすい例

バックアップをほとんど取らない
そもそも短期（3日〜30日）で終わる予定
ワールドが軽く、復旧に困っていない

✅おすすめの使い方（運用が一気にラク）

大きな更新前：イメージ保存 → 更新 → 問題があれば即ロールバック
乗り換え前：イメージ保存（構成を保管）＋ワールドデータ退避

解約・乗り換え前にやること（データ退避チェック）

解約・乗り換えで一番多い事故は、「ワールドはあるのに戻せない」 です。
“退避→復元テスト”までやって、はじめて安全と言えます。

データ退避チェックリスト（この順でやると失敗しにくい）

1）最終プレイ日時を決める

参加者に周知（突然止めると「最新の作業が反映されてない」事故が起きがち）
できれば最終日は 短めに遊んで 終了する（保存・終了を丁寧に）

2）バックアップを作る（世代を分ける）

最低でも 2世代
- 「最新」
- 「1つ前（保険）」
大工事や更新の直後なら もう1世代 追加しておくと安全

3）バックアップを“サーバー外”に出す

ローカルPCへダウンロード（これが最重要）
バックアップが大きい場合、ブラウザのファイルマネージャでは制限に引っかかることがあるため、必要なら FTPで退避 します

4）復元テスト（時間がない人ほどここだけはやる）

新しい環境（乗り換え先）を用意
バックアップをアップロード／配置
管理者だけ先に入ってロード確認
保存→再起動→再ログインまで確認
→ ここまで通れば「実戦復旧」ができます

5）引っ越しに必要な情報を控える

接続情報（IP/ポート）
管理者パスワード／プレイヤー用パスワード
公開範囲のルール（身内限定なら、共有フローも含めてメモ）
変更した設定（ゲーム設定・運用ルール）

「解約」そのものの注意点（損しないために）

解約は、手続き後も 利用期限日までは使える 形になっていることがあります
→ “最後にバックアップ取る日”を、期限内に必ず確保
プラン変更で下げた場合、差額返金がない 等の条件がある場合があります
→ 「試してから長期」はOKでも、「長期で払ってから下げる」は損になりやすい
規約上、支払済み料金の返還が行われない旨が明記されているケースがあります
→ 前払い期間を伸ばすほど、やめたときのリスクも増えるので
“30日→90日→180日”の段階式 が安全です

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

よくある質問（検索されやすい論点を先回り）

何人まで遊べる？（目安と増強ライン）

結論としては、「4人までは安定しやすい」→「それ以上は“工場規模”と“サーバー性能”で決まる」です。
Satisfactoryは、人数よりも ベルト量・自動化の密度・建築の集中で負荷が跳ねます。

目安の考え方（初心者向け）

まずは 4人想定で安定運用を作る（再起動・バックアップ・ポート・運用ルール）
次に「重さの兆候」が出るかを見て、人数を増やす or プランを上げる

人数を増やす前に見る“増強サイン”

✅ 全員が同時にラグる（個人回線ではなくサーバー側の可能性が高い）
✅ オートセーブのたびに引っかかりが増える
✅ 再起動しても改善しない／改善がすぐ戻る
✅ CPU・メモリ使用率が高止まり（監視画面で確認できるなら最優先で見る）

増強ラインの実務イメージ

4人：まずここを安定させる（運用ルールとバックアップが整えば快適になりやすい）
5〜8人：“工場分散・物流整理”が前提（詰め込み型だと急に重くなる）
9人以上：プレイスタイル次第で難度が上がる（工場の作り方とサーバー増強がほぼ必須）

🔎補足：プレイヤー上限は“増やす方法”が紹介されている一方で、公式に推奨される運用とは言いづらいため、増やすなら「戻せるバックアップ」「増やす前の安定版セーブ」を必ず用意してからがおすすめです。

MODは使える？（注意点と運用の考え方）

結論は、“やろうと思えば可能。ただし運用難度は上がる”です。
特にDedicated ServerでMODを使う場合、更新のたびに壊れやすいので、「最小構成・固定運用」が基本になります。

まず理解しておく2種類

クライアント側だけのMOD：見た目・UI系など（全員に同じものが必要とは限らない場合がある）
サーバー側にも入れるMOD：建築物追加・ゲーム挙動変更など
→ 基本的に サーバーと参加者全員が同じMOD構成で揃っていないと入れないことが多い

Dedicated Serverでの一般的な運用イメージ

PCに Satisfactory Mod Manager（SMM） を入れる
サーバーに SFTP などでアクセスできる環境を用意する
SMMの「サーバー管理」から、サーバーへMODを反映して再起動する
（= “サーバーへファイルを置ける”ことが前提）

注意点（ここで事故りやすい）

⚠️ ゲーム本体のアップデート直後は、MOD側（SML含む）が追随していないことがある
→ いきなり更新しないで、まずはバックアップ＆様子見が安全
⚠️ MODを外すと、ワールドが壊れたり、アイテムが参照できなくなることがある
→ “MODありセーブ”と“MODなしセーブ”を分けて世代管理すると復旧が速い
⚠️ XServerのサービス形態によっては、サーバー内部のファイル操作（SFTP/SSH）ができず、サーバー側MOD運用が現実的でない場合がある
→ その場合は「MODなし運用」か、自前構築（VPS）へ寄せるのが現実解です

公開サーバーにできる？（安全な公開手順）

結論：できます。が、初心者はまず “身内限定の安全運用”を完成させてからが失敗しません。
公開＝「知らない人が入る可能性がある」なので、“守り”と“復旧”が必須です。

安全な公開手順（最低限）

管理者パスワードを設定（管理権限は絶対に共有しない）
プレイヤー用パスワードを必ず設定（初期状態で無効のことがあるため注意）
接続情報の公開範囲を決める
- 本当に公開：募集掲示板など（荒れやすい）
- 半公開：Discord参加者だけ（現実的で管理しやすい）
ルールを先に決めて固定表示（荒らしというより“善意の事故”を防ぐ）
- 他人設備の解体禁止、資材箱ルール、大工事の事前共有、再起動タイミングなど
バックアップを強化（毎日＋大工事前）
- 公開運用の最強の防衛は「巻き戻せること」です

公開に踏み切らない方がいいケース

バックアップを取っていない／復元手順を試していない
管理者が不在の時間が長い（トラブル時に止められない）
そもそもサーバー負荷がギリギリ（荒らし以前に崩れやすい）

PC版（Steam/Epic）で違いはある？

結論：Dedicated Server運用なら、Steam/Epic混在でも参加自体は成り立ちやすいです。
サーバー側の導入がSteam/SteamCMDベースでも、Epic版プレイヤーが参加できることが明記されています。

ただし、体感で差が出やすいのは「版ズレ」と「連携（アカウント周り）」です。

混在運用で気をつけること

✅ “同じブランチ（EA / Experimentalなど）” を揃える
✅ アップデート日は サーバー更新→接続確認→集合 の順に固定する
✅ 招待ベースのホスト方式より、Dedicated Serverの方が「混在」が安定しやすい

必要なポート番号は？（変更したい場合は？）

結論：基本は UDPの3本セットを押さえればOKです。
代表的には次の構成がよく使われます。

UDP 7777：ゲーム用
UDP 15000：ビーコン用
UDP 15777：クエリ（一覧表示など）用

※環境や症状によっては「TCPも開けたら解決した」という報告もあるため、UDPでダメなときの追加候補として覚えておくと良いです。

XServerで“開ける場所”は2段階になりがち

XServer側：パケットフィルター（許可ポートの設定）
VPS系：OS側FW（ufw等）でも同じポートを許可
→ 片方だけ開けて「開けたのに繋がらない」が起きやすいです。

ポートを変更したい場合の考え方

Dedicated Serverは、起動オプション（例：-Port / -ServerQueryPort / -BeaconPort）で変更する運用が一般的です
変更したら、必ずセットでやること：
- フィルター/FWの許可ポートを変更
- 参加者に「入力するポート」を周知
- 複数インスタンス運用なら、3点セットで番号を揃えて衝突回避（例：A=7777/15000/15777、B=7778/15001/15778）

XServer GAMEs 公式サイト
XServer VPS for Game 公式サイト
XServer VPS 公式サイト

まとめ

Satisfactory×XServerは、結論から言うと “正解は1つではなく、優先順位で決まる” です。
選ぶ基準はシンプルで、あなたが何を優先したいかに尽きます。

1）3サービスの違いは「手軽さ」と「自由度」のバランス

XServer GAMEs
最短で始めたい人向け。 テンプレ・管理画面が分かりやすく、初めての専用サーバーでも進めやすい。
まず動かしてみたい、運用に時間をかけたくない人の第一候補。
XServer VPS for Game
ゲーム用途の管理を楽にしつつ、VPSの強みも取りたい人向け。
ひとつのVPSで柔軟に運用したいが、ゲーム寄りのパネルで迷子になりたくない人に相性が良い。
XServer VPS
自由度・拡張性を最優先したい人向け。
自前構築（SteamCMD、サービス自動起動、更新自動化、ログ集約、FW設計など）まで含めて作り込みたいならこれ。
その分、学習コストと運用責任は増える。