Rustサーバーの立て方入門｜公開・接続・管理まで／初心者でも迷わない手順まとめ

2026年2月13日

Rustで「自分たちのサーバー」を立てられたら、遊び方の自由度が一気に上がります。
身内だけの平和な環境にしたり、ワイプの周期やルールを自分たちで決めたり、必要ならModで便利機能を足したり。

ただ、いざ「Rustサーバー立て方」で調べると、情報が多すぎて迷いがちです。

「レンタルとVPSと自宅PC、結局どれが簡単で安いの？」
「SteamCMDって何？どこまでやれば動くの？」
「起動したのに、外部から友達が入れない…ポートって何を開けるの？」
「サーバー一覧に出ないのはなぜ？ queryportって必要？」
「管理者権限（ownerid/moderatorid）ってどう付ける？再起動で消えない？」
「ワイプって何を消すの？失敗したら戻せる？」
「uMod/Oxideを入れたいけど、更新で壊れたって話が怖い…」
「重い・ラグいの原因はCPU？メモリ？設定？どこから見直すべき？」

こうした疑問の多くは、実は「順番」を間違えなければ、かなりの確率でスムーズに解決できます。
逆に言うと、最初から設定を盛ったり、いきなり外部公開に突っ込んだりすると、原因が混ざって沼りやすいんですよね。

この記事では、初心者でも迷わないように “最短で開通 → 安定運用” の流れで、Rustサーバーの立て方を体系的に整理します。

まず結論：あなたに合う「立て方」はこの3つ（レンタル／VPS／Windows自宅）
失敗しない基礎知識（専用サーバーとホスト型、ポートの考え方、スペックの目安）
立て方の手順（テンプレ型→本命のVPS→Windows検証）
参加方法（IP直指定／お気に入り／一覧に出ない時の確認）
管理と運用（権限付与、よく使うコマンド、ワイプの型）
Mod導入（uMod/Oxideの導入と“壊れない更新順”）
トラブルシュート（起動しない／繋がらない／重い／Modが動かない）
料金とスペック（人数別の現実ライン）
最後に「10分チェック」で今日やることが分かる

公式情報（Facepunch公式Wiki等）の前提も踏まえつつ、できるだけ再現性の高い手順に絞って解説していくので、
「まずは友達と遊べる状態にしたい」という方は、このまま順番どおりに進めてみてください。

あわせて読みたい

Rust用レンタルサーバーおすすめ比較｜迷ったらこの基準で決める最短ルート Rustでマルチを遊び始めると、だいたい一度は「自分たちのサーバーが欲しい」と思います。ただ、いざレンタルサーバー（VPS）を選ぼうとすると、候補が多すぎて迷いがち…

まず結論：あなたに合う「立て方」はこの3つ

Rustのサーバーは、「どれくらいの人数で」「どれくらいの期間」「どこまで自由に設定したいか」で最適解が変わります。
初心者が最短で失敗しにくいのは、基本的に レンタル（テンプレ）→慣れたらVPS の順です。

手軽さ最優先：レンタル（ゲーム特化テンプレ）で立てる

こんな人に向いています ✅

とにかく早く遊びたい（管理やコマンドは避けたい）
ポート開放・Linux操作・更新作業が不安
まずは少人数で試して、必要なら後で強くしたい

何がラク？（初心者目線のメリット）

申し込み後、テンプレが入った状態で用意されるので
「サーバー起動→IP確認→接続」が最短で済みます
ブラウザ管理画面から設定できるサービスも多く、黒い画面（コマンド）をほぼ使わないで進められます
お試し期間・短期プランがあるサービスだと、合うかどうかを小さく検証できます

注意点（ここでつまずきやすい）⚠️

Rustは軽いゲームではないので、低スペックだと重い/不安定になりやすいです
→ 公式サポートで「4GB以上必須」「快適さ重視なら8GB以上推奨」と明示されているサービスもあります
テンプレ型はラクな反面、サービスによっては
自由な改造（細かい起動オプション、特定構成、特殊MOD運用など）に限界があります

迷ったらこの選び方

まずは レンタルで“動く状態”を作る
「人数が増えた」「MODを本格導入したい」「細かく最適化したい」
となったらVPSへ移行すると、遠回りになりにくいです

あわせて読みたい

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

自由度・拡張性重視：VPS/専用サーバーで立てる

こんな人に向いています ✅

MOD（uMod/Oxide）やカスタム設定をしっかり運用したい
ワイプ運用、バックアップ、自動更新などを自分のやり方で固めたい
長期運用するので、最終的にコスパと安定性を詰めたい

何が増える？（できること）

root権限で自由度が高い（構成・最適化・監視・自動化）
systemdなどで落ちても自動復旧、cronで自動更新など、運用が強くなる
複数サーバーを立てたり、検証環境を作ったりもしやすい

初心者が不安になりがちなポイント（でも避けて通れない）

ポート開放（ゲーム用/Query/RCON/Rust+など、用途ごとに整理が必要）
SteamCMDでの導入・更新（更新で落ちる、手順が崩れる等の対策）
セキュリティ（SSH、RCON、FW設定など）

Rust公式の情報では、サーバーは用途別に複数ポートが関わります。
初心者はまず 「ゲームポートで接続できる状態」→次に「Query/RCON/Rust+」の順で広げると事故りにくいです。

費用感の目安（考え方）

月額はプラン次第で幅がありますが、Rustはメモリが効きやすいため
「少人数なら4GB〜」「安定させるなら8GB〜」が現実的なスタートラインになりやすいです
人数が増える・マップを重くする・MODを盛るほど、CPU/メモリ/ストレージI/Oが効いてきます

あわせて読みたい

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

検証・ローカル用途：自宅PC（ローカル限定）で立てる

こんな人に向いています ✅

まずは1人〜身内だけで検証したい（公開サーバーではない）
MOD構成や設定を、本番の前に試したい
「サーバーの仕組み」を理解してから、VPSやレンタルに進みたい

メリット

追加費用がかからない（電気代やPC負荷は別）
失敗してもすぐやり直せるので、学習に向く

デメリット（ここが決定的）⚠️

PCを落とすとサーバーも止まる（24時間運用に不向き）
自宅回線・ルータ設定・NATの影響で、外部公開が一気に難しくなります
PC側の負荷で、ゲームプレイと同居すると重くなりがち（特に人数が増えると顕著）

結論

ローカルは「学習・検証」には最高
「友達と安定して遊ぶ」「長期運用する」なら、レンタル or VPSが結局ラクです

比較早見：費用・難易度・安定性・24時間稼働・改造のしやすさ

スクロールできます

立て方	費用感	難易度	安定性	24時間稼働	改造（自由度）
レンタル（テンプレ）	低〜中（短期お試しありのことも）	◎	○〜◎	◎	△〜○
VPS/専用サーバー	中〜高（構成次第で最適化可）	△	○〜◎	◎	◎
自宅PC（ローカル）	ほぼ0円（ただしPC負荷/電気代）	○〜△	△	△	○〜◎

迷ったときの最短ルート 🧭

迷うなら：レンタル（テンプレ）
「自由にやりたい」「MODや自動化を本気で」：VPS
「まず勉強・検証だけ」：自宅PC（ローカル）

失敗しないための基礎知識（ここを読むだけで詰まりにくい）

Rustサーバー構築で迷いやすいのは、「何を作ろうとしているか（専用サーバー？ホスト？）」「どの版のRustか（PC/Console）」「どの程度の負荷を想定するか（人数・マップ・MOD）」「ネットワークで何を開けるべきか（ポート・FW・NAT）」の4点です。
この章は、その“地図”を先に渡すパートです。

「専用サーバー」と「ホスト型マルチ」の違い

まずここを混同すると、手順をいくら読んでも噛み合いません。Rust周りでよく出てくる言葉を、初心者向けに整理します。

専用サーバー（Dedicated Server）

24時間動かす「サーバー用のRust」を別途起動して、みんながそこに参加する方式
管理者設定（ワイプ、ルール、RCON、MODなど）を細かく触れる
レンタル（テンプレ）でもVPSでも、この方式が基本

ホスト型マルチ（ホストが部屋を立てる／参加者がホストに繋ぐ）

いわゆる“ホストが進行役”の形で、ホスト側の環境に引っ張られやすい
一般に「ホストが落ちると終わる」「安定性・自由度が落ちる」ことが多い

初心者が迷わない判断基準

「友達と長く遊ぶ」「マルチで安定させたい」→ 専用サーバー一択
「一時的な検証だけ」→ ローカルで専用サーバーを立てる（自宅PC）もアリ

対応プラットフォーム注意（Steam版/Console版の前提整理）

同じ“Rust”でも、PC（Steam）とConsole Editionでは、サーバーの立て方の前提が違います。

PC（Steam版）

自分でDedicated Serverを立てられる（レンタル／VPS／自宅PCいずれも可能）
公式Wikiが「サーバーの作り方・設定項目・ポート」まで公開している
MOD（uMod/Oxide）などの拡張も前提として情報が豊富

Rust Console Edition（PS/Xbox）

“コミュニティサーバー”はあるが、基本は 第三者サービスでレンタルして運用する形が中心
PC版と同じノリで「SteamCMDで自前構築」というより、提供元の管理パネルで設定していく

ここだけ覚えればOK ✅

検索キーワードの「rust サーバー立て方」は、多くが PC（Steam版）の話
もしConsole版でやりたいなら、記事を読む前に「Console Edition向けか」を必ず確認すると時間が無駄になりません

必要スペックの目安（人数・マップサイズ・MOD有無で変わる）

Rustサーバーは「何人で」「どれくらいの世界を」「どれくらい改造するか」で要求が大きく変わります。
ここでは“外さない目安”を、判断ルールとしてまとめます。

まずは結論：スペックは「人数×マップ×MOD」で考える

ざっくり言うと、負荷はこう増えます。

人数が増える → CPUとメモリの要求が上がる（同時処理が増える）
マップが大きい（worldsizeが大） → メモリとディスク使用量が増える
MOD/プラグインが多い → メモリ・CPU・ディスクI/Oが増えやすい

特にレンタルのテンプレ型は、サービス側が「最低ライン」「推奨ライン」を明記していることがあるので、初心者はそこを“下限”として見るのが安全です。

目安の作り方（初心者向けの現実的な基準）

メモリ（RAM）

“動く”だけなら4GBでも可能とされるケースはありますが、Rustは余裕が少ないと不安定になりやすいです
初心者が「まず快適に」を狙うなら、8GB以上を基準に考えるのが無難です
これはゲームテンプレ提供側が「4GB以上で利用可」「快適に遊ぶなら8GB以上推奨」としている例があるため、判断材料として使いやすいです

ストレージ（SSD推奨）

体感差が出やすいのは SSD（できればNVMe）
マップ生成・セーブ・ログ・バックアップで、遅いストレージは“引っかかり”の原因になります
ディスク容量は、マップサイズやバックアップの取り方で増えるので
「本体＋ワールド＋バックアップ」で余裕を見て確保が安全です

CPU

Rustサーバーは、状況によって 単コア性能の影響が大きいと言われる場面があります
そのため「コア数が多い＝勝ち」よりも、まずは 新しめ世代のCPUでクロック・IPCが高い構成を優先すると失敗しにくいです

CPUは“コア数”より“単コア性能”が効きやすいケース

初心者がよくやりがちなのが、CPU選びを「コア数だけ」で決めてしまうことです。
Rustサーバー運用では、

プレイヤーが密集する拠点戦
NPCやイベント、建築物が多いエリア
MODで処理が増えている状態

などで、1つの処理が詰まると全体が重く感じることがあります。

選び方のコツ（迷ったらこれ）

“古い多コア”より、“新しい世代のそこそこコア”
まずは 2〜4コア帯でも、単コアが強い構成を優先（規模が上がったら増強）

メモリ/ストレージ（SSD・NVMe）で体感が変わるポイント

メモリで体感が変わる瞬間

人数が増えたときに、突然ラグが出る
マップ生成・ワイプ後に不安定
MOD導入後にカクつきが増えた

こういうとき、原因が「CPU」より先に「メモリ不足」なこともあります。
“ギリギリで動いている”状態だと、少し条件が変わっただけで破綻しやすいのがRustの怖いところです。

ストレージで体感が変わる瞬間

ワールド保存（セーブ）時に引っかかる
起動時間が長い
ログやバックアップが重い

初心者のおすすめ運用

まずSSD（可能ならNVMe）
バックアップは「毎回フル」より、まずは
- ワールドデータ
- 設定ファイル
- MOD/プラグイン
  を優先して保存対象を絞ると、容量も手間も爆発しません

ネットワーク要件：ポート・FW・NATで詰まる原因トップ3

Rustサーバーの“接続できない”は、原因がほぼこの3つに集約されます。
逆に言えば、ここだけ順番に潰せばほとんど解決します。

トップ1：必要なポートを開けていない（またはプロトコル違い）

Rustは、用途ごとにポートの役割が分かれます
最低限は ゲーム接続用ポート（server.port） と サーバー一覧/問い合わせ用（server.queryport） をセットで考えるのが基本です
さらに管理用に RCON（rcon.port） が絡みます（外部公開するなら特に注意）

初心者はまず、次の順で確認すると詰まりにくいです。

server.port（ゲーム接続） が外から届くか
server.queryport（サーバー一覧に出すため） が外から届くか
必要なら rcon.port（管理用） を追加で開けるか

トップ2：ファイアウォール（FW）やクラウド側の制限で止められている

OS側（UFW/Windows Firewall）で許可していない
VPSならクラウド管理画面側（セキュリティグループ等）で塞いでいる
“ルータは開けたのに繋がらない”は、だいたいここ

チェックのコツ ✅

「ルータ（またはクラウド）」「OSのFW」どちらも確認
片方だけ開けても通らないケースが普通にあります

トップ3：NAT/CGNATでそもそも公開できない（自宅回線で多い）

ルータのポート開放をしても、上位の回線側で共有NAT（CGNAT）だと外から届かないことがあります
自宅PCで公開しようとして詰まる最大要因がこれです

回避策（初心者が取りやすい順）

レンタル（テンプレ）やVPSに切り替える（最短で確実）
回線・契約プランを見直す（固定IPオプション等）
どうしても自宅でやるなら、まずは“同一LAN内だけ”で動作確認してから外へ広げる

【最短】レンタルでRustサーバーを立てる手順（テンプレ型）

テンプレ型（ゲーム特化レンタル）は、「申し込むだけでサーバーが自動構築される」のが最大の魅力です。
ここでは、どのサービスでも共通する“迷いポイント”を先に潰しつつ、最短で「遊べる状態」まで持っていく流れをまとめます。

あわせて読みたい

プラン選び：人数・メモリ・課金方式（時間課金/長期割引）で決める

テンプレ型のプラン選びは、細かい理屈よりも 「失敗しない基準」で決めるのが正解です。
迷ったら、次の順で決めるとブレません。

1) まず“人数”でメモリの最低ラインを決める
Rustは更新や設定次第で必要メモリが増えやすいので、初心者はギリギリ運用を避けるのが安全です。

2〜4人の身内サーバー：まずは 8GB を基準（軽め設定なら下もあり得るが不安定リスク）
5〜10人くらい：8GB以上（安定を取りたいなら上げる）
MODを入れる/マップを大きくする/長期運用：最初から 余裕あるメモリで始めると後悔しにくい

💡公式テンプレでも「利用できる下限」と「快適推奨」が分かれていることが多いので、初心者は推奨寄りで考えるのが無難です。

2) つぎに“課金方式”を決める（ここが一番差が出る）
テンプレ型はだいたい次の2種類です。

時間課金（使った分だけ）
- ✅短期イベント・連休だけ遊ぶのに強い
- ⚠️長期間つけっぱなしだと割高になりやすい
長期割引（1ヶ月/3ヶ月/12ヶ月など）
- ✅“毎日遊ぶ”“24時間稼働”なら総額が下がりやすい
- ⚠️途中でやめると「最初から長期にしなきゃよかった」となりがち

3) 最後に“地域（リージョン）/ストレージ/サポート”で微調整

友達の居住地に近いリージョンほど、遅延が減って快適
ストレージは SSD（できればNVMe） だと保存・再起動が体感で楽
初心者ほど、障害時に頼れる 公式サポート/FAQの厚さが安心材料になります

申し込み〜起動確認までの流れ（迷う画面だけ先に潰す）

テンプレ型の申込みは、画面数が多く見えても「迷うのは数か所だけ」です。
ここでは“詰まりやすい画面”に絞って説明します。

アカウント作成と「Rustテンプレ」の選択

よくある流れ

アカウント作成（メール認証など）
テンプレート一覧から Rust を選択
メモリ（プラン）を選ぶ
課金方式（時間課金 or 長期割引）を選ぶ
申込み確定 → 自動構築 → 起動

ここだけ注意 ✅

Rustには PC版/Console版があるので、申込み画面で「どちら対応か」を必ず確認
同じテンプレでも、プランによって推奨メモリが明記されている場合は、それを優先

rootパスワード設計（強度/控え方/再発行の考え方）

テンプレ型でも、SSH（管理用ログイン）や管理画面用に強いパスワードが必要になることがあります。
ここで手を抜くと、後から困ります。

おすすめの作り方（迷ったらこれ）

16文字以上、英大文字/英小文字/数字/記号を混ぜる
可能なら パスワード管理ツールに保存（紙メモより安全）
ゲーム内の管理パス（RCON等）と使い回さない（漏えい時の被害が増える）

“再発行できるから大丈夫”と思わないほうがいい理由

再発行の手間で、結局「復旧まで遊べない」時間が出ます
共同運営だと、誰が何を管理しているかが曖昧になりがちです

💡運用が安定するコツは、「ログイン情報は1か所に集約して、共有は最小限」です。

IPアドレス・サーバー名・ポートの確認

構築が終わったら、まずは接続に必要な情報を“控える”ところから始めます。
最低限、次の3点はメモしておくと後で迷いません。

サーバーのIPアドレス
ゲーム接続用ポート（例：28015など）
管理や機能追加で使うポート（Query/RCON/Rust+ など）

テンプレ型は「必要ポートが最初から設定済み」のことも多いですが、初心者はまず “ゲーム接続できる情報”だけ確実に把握すればOKです。
（サーバー一覧表示やRust+は、動作確認後に追加で整えるのが安全）

接続方法：IPで入る／サーバー名で探す（おすすめはどっち？）

結論から言うと、最初は IP接続がおすすめです。
サーバー名検索は便利ですが、初心者が最初に詰まりやすいポイントでもあります。

IP接続がおすすめな理由 ✅

サーバー一覧に反映されるまで時間がかかることがある
フィルタ設定やタグで検索に引っかからないことがある
似た名前のサーバーが多いと見失いやすい

基本の手順（最短）

Rustを起動
コンソールを開く（F1など）
client.connect IP:PORT で接続
入れたら お気に入り登録して、次回以降は迷わない

サーバー名で探すのが向く場面

公開サーバーとして運用していて、参加者が「検索で入りたい」
サーバー名・タグ・説明文を整えて、一覧から見つけやすくしたい

💡初心者のおすすめ順は、
IPで接続確認 → お気に入り登録 →（必要なら）名前検索運用 です。

Rust+（公式コンパニオン）を使う場合の確認ポイント

Rust+は便利ですが、テンプレ型でも「条件が揃っていないと動かない」ことがあります。
初心者は、次の順に確認すると迷いません。

確認ポイント（上から順に）

サーバーが起動していて、ゲームには接続できるか
→ Rust+は“まずゲームが安定して動く”のが前提です
Rust+用のポートが外部から到達できるか（TCP）
→ Rust+は専用の仕組みで通信するため、ゲーム用とは別の到達性が必要になる場合があります
管理画面でRust+関連の設定が有効になっているか
→ サービスによっては「Rust+対応」や「追加設定」がまとまっていることがあります

つまずいたときの“ありがち原因”

ルータ/NATの都合で外部到達できない（自宅運用に多い）
FW（ファイアウォール）でTCPが閉じている
使うポート番号を変更していて、Rust+側が追従できていない

✅コツ：Rust+は「いきなり全部やる」と沼りやすいので、まずは
ゲーム接続が安定 → 次にRust+ の順が失敗しにくいです。

レンタル運用のコツ：停止・再作成・バックアップの現実解

テンプレ型は「立てるのが楽」な一方で、運用で差が出ます。
初心者が押さえるべきポイントは、実は3つだけです。

1) 停止・再起動の“ルール”を決める

Rustは更新が頻繁なので、定期的な再起動が安定につながることがあります
共同運営なら「誰が」「いつ」「どう止めるか」を決めておくと事故が減ります

2) “再作成（再構築）”は最終手段にする

テンプレ型はワンクリックで再作成できる場合がありますが、
ワールドや設定が消えることがあるので要注意です

💡おすすめの考え方

軽い不調 → 再起動
設定を大きく変えたい → バックアップを取ってから変更
どうしても直らない → 再作成（その前に必ず退避）

3) バックアップは「全部」より「戻せる最小セット」
初心者がハマりやすいのが、“バックアップの沼”です。最初はこれで十分です。

ワールドデータ（セーブ）
設定ファイル（server.cfg 等）
（MOD運用なら）プラグイン/設定

さらに余裕が出たら、サービスのスナップショット機能や自動バックアップを活用すると、運用が一気に楽になります。

✅起動後の10分チェック（これだけやれば安心）

ゲームに接続できる
友達が外部から接続できる
サーバー情報（IP/PORT/パスワード類）を控えた
バックアップの手段（自動 or 手動）を1つ確保した

【自由度MAX】VPS/専用サーバーで立てる手順（本命）

VPS/専用サーバーでRustを立てる方法は「自由度が高い反面、詰まりどころも多い」です。ここでは Linux（Ubuntu LTS想定） を軸に、インストール → 公開 → 自動運用 まで、初心者でも迷いにくい順番でまとめます。

あわせて読みたい

構成の選び方：SteamCMD直置き / LinuxGSM / Docker（結局どれが楽？）

結論、迷ったらこの選び方が安全です。

SteamCMD直置き（おすすめ：仕組みを理解したい人）
✅ 公式に近い手順で分かりやすい／自由度MAX
⚠️ 自動更新・常駐・バックアップは自分で組む必要あり
LinuxGSM（おすすめ：運用をラクにしたい人）
✅ 起動・停止・更新・ログ管理などが一式まとまる
⚠️ “Rustの設定そのもの”は結局理解が必要（便利ツール枠）
Docker（おすすめ：環境を分離したい人/複数鯖を管理したい人）
✅ 依存関係が壊れにくい／再現性が高い
⚠️ ネットワークや永続化（ボリューム）で初心者が詰まりやすい

💡 最短で安定運用を作るなら：SteamCMD直置き＋systemd（常駐）＋タイマー（更新）
💡 ラクさ最優先なら：LinuxGSM

ステップ0：事前準備（OS・ユーザー・依存パッケージ）

推奨OS（例：Ubuntu LTS）と“root運用しない”理由

OSは Ubuntu LTS のような長期サポート系が無難（更新で壊れにくい）
rootでゲームサーバーを動かさないのは超重要
- 侵入されたとき被害が最大化する
- ファイル権限が雑になり、バックアップやログ整理が後で地獄になる

✅ 基本方針：
「管理はsudo可能なユーザー」＋「サーバー実行は専用ユーザー」 に分ける

サーバー用ユーザー作成と権限設計（ログ/バックアップが楽になる）

例（方針だけ覚えればOK）：

admin（あなた）…SSHでログインして操作する用（sudo可）
rust（実行ユーザー）…Rustサーバーのプロセスを動かす用（sudo不要）

運用がラクになるディレクトリの分け方（おすすめ）：

/opt/rust/ …サーバー本体（SteamCMDで入る場所）
/opt/rust-data/ …設定・セーブデータ・バックアップ（守るべき場所）

📌 ポイント：
「本体（更新される）」と「データ（守る）」を分離すると、事故率が下がります。

ステップ1：必要ポートを整理して開ける（ここが接続失敗の9割）

ゲーム用ポート（UDP）とRCON（TCP）の役割

Rustサーバーは、用途ごとにポートが分かれます。まずは “最低限” から。

server.port（UDP）：プレイヤーが接続する本命ポート
server.queryport（UDP）：サーバー一覧に載るために必要（公開なら重要）
rcon.port（TCP）：遠隔管理（RCONツールやWebRCON）
Rust+（TCP）：公式コンパニオン（Rust+）連携

✅ まずは server.portだけ で接続成功させる → 次に query/RCON/Rust+ を開ける、が最短です（焦ると沼ります）。

server.queryportの注意：サーバー一覧に出すための前提

見落としがちですが、サーバー一覧（ブラウザ）に表示したいならqueryportが必須です。

server.queryport は 未指定だと「max(server.port, rcon.port) + 1」 が自動採用される
server.port と server.queryport は 両方UDPで、同じ番号にできない
2023年2月の更新で、この挙動が整理されています（昔の情報に注意）

例（分かりやすく固定する）：

server.port = 28015/udp
rcon.port = 28016/tcp
server.queryport = 28017/udp（明示）

FW（UFW/iptables）とクラウド側フィルタの二重チェック

🔥 ここが「開けたのに繋がらない」トップ原因です。

チェックはこの順番が鉄板：

OS側FW（UFW/iptables）で許可したか
VPSのセキュリティグループ/ファイアウォールでも許可したか
3.（自宅回線なら）ルーターのポート開放/NATができているか

確認コマンド例（覚えなくてOK）：

“待ち受けてるか” → ss -lunpt（UDP/TCPのLISTEN確認）
“外から届くか” → 別回線（スマホテザリング等）で接続テスト

ステップ2：SteamCMDでRust Dedicatedをインストールする

インストール先の決め方（更新・容量・バックアップ都合）

Rustは更新頻度が高いので、場所の設計が大事です。

本体：/opt/rust/（更新で変わる）
データ：/opt/rust-data/（守る）
ログ：/var/log/rust/（肥大化しやすいので分けると良い）

💡 ディスクは SSD/NVMe推奨。ワールドサイズや人数が増えるほど、I/Oが効いてきます。

AppID/更新コマンドの基本（validateの使いどころ）

Facepunch公式Wikiに沿う形で、Linux例をそのまま使うのが最短です（AppIDは 258550）。

# 例：作業用フォルダへ
cd /opt
mkdir -p rust steamcmd
cd steamcmd

# SteamCMDを取得して展開
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
tar xvfz steamcmd_linux.tar.gz
chmod +x steamcmd.sh

# Rust Dedicatedを取得（anonymousログイン必須）
./steamcmd.sh +force_install_dir ../rust +login anonymous +app_update 258550 validate +quit

+login anonymous が無いとサブスクエラーになることがあります
validate は 壊れた/欠けたファイルの修復に強い反面、毎回やると時間がかかります
- 普段：app_update 258550
- 事故時：app_update 258550 validate

ステップ3：起動パラメータとserver.cfgで“設定を分離”する

コツは、コマンドラインは最低限、細かい設定は server.cfg に逃がすことです。

コマンドライン：ポート、identity、RCONなど“起動の骨格”
server.cfg：人数やサーバー名など“中身の設定”

server.identityの意味（データ保存場所・複数鯖運用の鍵）

server.identity は 保存先フォルダ名の基準になります。

1台で複数サーバーを回すなら identity を分ける
バックアップも identity 単位で取れるようになる

例：
server.identity "main" → .../rust/server/main/ 配下にデータがまとまるイメージ

サーバー情報（hostname/description/headerimage/url）の最適化

見た目は軽視されがちですが、“参加者が迷わない”＝運用コスト削減です。

おすすめの書き方：

hostname：何のサーバーか一言で（JP/ENも入れると親切）
description：
- ワイプ周期（例：毎週/隔週）
- ルール（PvP/PvE、フレンド限定など）
- Discord等があるなら案内

📌 注意：盛りすぎると通報やトラブルの元。実態と一致させるのがE-E-A-T的にも安全です。

マップ設定（seed/worldsize）と負荷の関係

重要なのはここです👇

worldsize が大きいほど メモリ/ディスク/保存時間が増える
人数が増えるほど CPUが先に詰まりやすい

初心者の安定重視なら：

まずは worldsizeを控えめ＋人数も控えめ
ラグが無いのを確認してから拡張

RCON設定（rcon.port/password/web）と安全な公開範囲

RCONは便利ですが、漏れたら終わりです。

パスワードは 長く・ランダム（使い回さない）
可能ならFWで 管理者IPだけ許可（全開放しない）
rcon.web 1 が推奨されるケースが多い

ステップ4：自動起動・自動更新（落ちても戻る運用）

systemdで常駐化：自動再起動/ログ追跡の基本

「SSHを閉じたら止まった」を防ぐ最短手段が systemd です。

運用の考え方：

Rust起動は start.sh にまとめる
systemdはその start.sh を常駐実行
落ちたら自動で起動し直す（Restart設定）

💡 これだけで安定度が一段上がります。

cron/タイマーで更新：更新タイミングと再起動手順

Rustは更新が多いので、更新は “止めて→更新→起動” が安全です。

おすすめの更新フロー：

サーバー停止
SteamCMDで更新（必要ならvalidate）
サーバー起動
接続テスト（最低1回）

✅ 更新は人が少ない時間帯に。
✅ “自動更新で勝手に落ちる”より、手順を固定した方が事故りません。

Mod導入時の注意：更新で“バニラに戻る”問題の回避

プラグイン（例：Oxide/uMod）を入れる場合はここが地雷です。

SteamCMDを起動スクリプトに入れると、更新時にファイルが上書きされて バニラに戻ることがある
対策：
- 更新用スクリプトを分ける
- 更新後にプラグインを再適用する手順を固定する
- もしくは運用をLinuxGSM側に寄せて管理しやすくする

ステップ5：監視・ログ・バックアップ（長期運用で差が出る）

ログ出力とローテーション設計（肥大化対策）

ログは放置すると必ず肥大化します。

-logfile でファイルに出す（追跡が楽）
systemd/journald も併用すると「落ちた理由」が見やすい
週1〜でローテーション（logrotate）を組むと安心

📌 “ディスク満杯で落ちる”は本当に多い事故です。

バックアップ対象の決め方（ワールド/設定/プラグイン）

最低限これだけ守ると復旧が速いです。

サーバー設定：server.cfg、起動スクリプト
セーブデータ：identity配下（ワールド・プレイヤー情報）
プラグイン類：設定・データ一式（使っている場合）
Rust+を使うなら：companion.id を含むフォルダは特に慎重に扱う（無闇に消さない）

スナップショット運用と「戻し手順」まで用意する

バックアップは「取る」だけだと半分です。

戻す手順を1回リハーサルしておく
VPSのスナップショット＋ファイルバックアップの二段構えだと強い

ステップ6：パフォーマンス最適化（ラグ・TPS・カクつき対策）

saveinterval/ワールドサイズ/最大人数のチューニング指針

体感改善に効きやすい順：

最大人数を控える（CPU負荷が素直に下がる）
worldsizeを小さめに（メモリと保存が軽くなる）
保存周り（セーブ間隔・バックアップ頻度）を現実的に

🧠 目安として、Rustは要求が重めなので RAMは余裕を持つのが正解に近いです。

回線最適化（遅延対策の基本・必要ならBBRも検討）

同地域に近いリージョンのVPSを選ぶ（体感差が大きい）
ルーティングが悪い/遠距離ならBBR等を検討（ただし副作用もあるので慎重に）

まずは “場所”と“帯域” を疑うのが先です。

ディスクI/Oが詰まる兆候と対処

兆候：

カクつきが周期的（保存タイミングに一致）
CPUは余ってるのに重い
iowaitが高い

対処：

SSD/NVMeへ（最優先）
worldsize・人数・バックアップ頻度を見直す
ログ肥大化やディスク満杯もチェック

ステップ7：セキュリティ（荒らし・漏えい・乗っ取りを防ぐ）

SSH：鍵認証・fail2ban・不要ログイン経路を閉じる

最低ライン：

SSHは 鍵認証に寄せる
パスワードログインを無効化（可能なら）
fail2ban等でブルートフォース対策
OS更新をサボらない（地味に一番効く）

RCON：強パスワード＋アクセス制限（可能ならIP制限）

RCONは 全開放しない（できれば管理者IPのみ）
パスワードは 長いランダム文字列
WebRCONなどを使う場合も、公開範囲を最小に

DDoS対策：できること/できないことを切り分ける

現実的にできる範囲：

DDoS対策付きのVPS/回線を選ぶ
FWで不要ポートを閉じる（開けるのは必要最低限）
いざという時の避難策（IP変更、サーバー非公開化）を決めておく

WindowsでRustサーバーを立てる（自宅・検証・小規模向け）

自宅PC（Windows）でRustサーバーを立てるのは、身内で遊ぶ／検証する用途なら十分現実的です。
ただし、外部公開（不特定多数に開放）までやると セキュリティ・回線・運用負担が一気に上がります。まずは 「ローカルで動かす → 少人数で外部公開」 の順で段階的に進めるのが安全です。

入手ルート：SteamCMD方式と配布ファイル方式の違い

Windowsでの入手ルートは大きく2つです。結論、基本はSteamCMDが無難です。

SteamCMD方式（おすすめ）

✅ 公式の導入方法として情報が揃っている
✅ 更新（アップデート）に強い
✅ ベータブランチ等の切り替えもできる（検証に便利）

向いている人：

少しでも長く使う
友達と継続して遊ぶ
更新に追従したい

配布ZIP方式（“とりあえず動かす”向け）

Facepunchが用意した「Rust_server.zip」で、展開してRun_DS.batをいじるだけで起動まで持っていけるタイプです。
ただし注意点もあります。

⚠️ 仕組みが古く、説明どおりに自動更新が効かない前提がある
⚠️ 中でSteamCMDを叩く構成になりがちで、運用の理解が浅いままだと詰まりやすい

向いている人：

まずは“起動するもの”を見たい（学習用）
LAN内だけで試したい
後でSteamCMD方式に移行する前提

迷ったら：SteamCMDで入れる → 起動バッチ（.bat）で管理が最短で安定します。

起動バッチの作り方：設定を迷わない“最小構成→拡張”手順

ここでは SteamCMD方式を基準に、「最小構成で起動 → 必要な分だけ設定を足す」流れにします。
（いきなり設定を盛ると、原因不明の接続失敗になりがちです）

1）フォルダを作る（例）

C:\steamcmd\（SteamCMD本体）
C:\rustserver\（Rust Dedicated Server本体）
C:\rustserver\logs\（ログ置き場）

SSD/NVMe推奨です。空き容量とメモリにも余裕があるほど安定します。

2）SteamCMDでRust Dedicatedを入れる（更新にも使う）

SteamCMDを展開して steamcmd.exe を起動し、以下を順に実行します。

force_install_dir C:\rustserver
login anonymous
app_update 258550 validate
quit

✅ ポイント

login anonymous がないと失敗することがあります
validate は時間がかかる代わりに不整合に強いです
- 普段の更新は validate を外して速くする、という運用もできます

3）最小起動バッチ（start_min.bat）を作る

C:\rustserver\start_min.bat を作り、まずはこれで起動します。

@echo off
cd /d C:\rustserver

RustDedicated.exe -batchmode -nographics ^
+server.port 28015 ^
+server.level "Procedural Map" ^
+server.seed 1234 ^
+server.worldsize 3500 ^
+server.maxplayers 10 ^
+server.hostname "My Private Rust (JP)" ^
+server.identity "server1" ^
+rcon.port 28016 ^
+rcon.password "ChangeThisToALongRandomPassword" ^
+rcon.web 1 ^
-logfile "logs\rustserver.log"

✅ 最初はこれだけでOKです（説明・画像・URLなどは後で足す）
✅ 起動後、コンソールが流れ続けて最終的に待機状態になれば成功

4）接続テスト（ここが最重要）

まずは 同じPC から繋いで動作確認します。

Rustクライアント起動 → メニューで F1（コンソール）
次を入力：

connect localhost:28015

別PC（同一LAN）からなら connect 192.168.x.x:28015 のように サーバーPCのLAN IP を指定します。

外部公開の前に、必ず「ローカル接続で成功」させてください。
ここが通っていない状態でポート開放を触ると、原因が混ざって沼ります。

5）設定を“増やす”ときは server.cfg に逃がす

起動バッチに全部書くと管理が破綻します。
コツはこうです。

.bat：ポート・identity・RCONなど「骨格」だけ
server.cfg：日々調整する設定（説明文、タグ、各種ルール等）

作る場所の目安：
C:\rustserver\rust\server\server1\cfg\server.cfg
（※ server.identity が server1 の場合）

server.cfgの例（※ここには + を付けません）：

server.description "Friends only / Weekly wipe"
server.url "https://example.com"
server.headerimage "https://example.com/header.jpg"

起動パラメータの読み方（何を変えると何が起きる？）

初心者が“触る頻度が高いもの”だけ、影響とセットで覚えると迷いません。

server.port（UDP）
👉 プレイヤーが接続するポート。まずはこれだけ通せば遊べます。
server.identity
👉 データ保存先の“フォルダ名”。これを変えると別サーバー扱いになります。
server.seed / server.worldsize
👉 マップ生成。worldsizeが大きいほど メモリ・ディスク・負荷が増えやすい。
server.maxplayers
👉 人数上限。上げるほど CPU/回線/メモリが厳しくなりがち。
rcon.port（TCP） / rcon.password / rcon.web
👉 遠隔管理。外部公開時は強パスワード＆必要ならアクセス制限が必須。
server.queryport（UDP）
👉 サーバー一覧（ブラウザ）に出すために重要。未指定だと自動で決まりますが、公開するなら明示して固定するのが安全です。
server.ip
👉 受け付けるIPを絞れます。LAN限定にしたいなら有効（外部公開を避けたいときに便利）。

💡 よくある“最初の拡張”例

公開で一覧に出したい → +server.queryport 28017 を追加
LANに閉じたい → +server.ip 192.168.x.x を追加
Rust+を使いたい → Rust+用TCPポートの到達性を確認（後述）

自動起動（スタートアップ登録）と更新時の動線

Windowsで「落ちても戻る」「再起動後に立ち上がる」を作るなら、スタートアップより タスクスケジューラが安定です。

✅ タスクスケジューラの作り方（考え方）

トリガー：
- 「ログオン時」または「PC起動時」
操作：
- start_min.bat を実行
開始（作業フォルダ）：
- C:\rustserver\ を指定（これがないと相対パスが崩れがち）

更新の動線（いちばん事故らない手順）

更新はシンプルに固定します。

サーバー停止（コンソールで quit 等）
SteamCMDで更新（update.batを作るとラク）
サーバー起動（start_min.bat）

update.bat の例：

@echo off
cd /d C:\steamcmd
steamcmd.exe +force_install_dir C:\rustserver +login anonymous +app_update 258550 +quit

🧩 MOD/プラグインを入れている場合の注意

SteamCMD更新で“素の状態に戻る”ことがあり得ます
更新後にプラグイン再適用が必要になるケースがあるので、運用フローに組み込むと安全です

FW/ルータ設定：外部公開する場合に追加で必要なこと

外部公開（友達が家の外から接続）する場合、追加で必要になるのは次の3点です。

Windowsファイアウォールで許可
ルーターのポート開放（NAT/ポートフォワード）
サーバーPCのLAN IP固定（DHCP予約など）

まず“最小”で開ける（最初に全部開けない）

最初は server.port（UDP）だけ で外部接続が通るか試すのが鉄則です。
それが成功してから、一覧表示やRCON、Rust+を足します。

外部公開で使うポートの全体像（目安）：

スクロールできます

種類	プロトコル	目的	最初に必要？
server.port（例：28015）	UDP	プレイヤー接続	✅必須
server.queryport（例：28017）	UDP	サーバー一覧表示	目的次第
rcon.port（例：28016）	TCP	遠隔管理	管理するなら
Rust+（デフォルト：28082など）	TCP	Rust+連携	使うなら

Rust+のデフォルトは「ゲームポート+67」または「RCONポート+67」の大きい方、という考え方です。
ポートを変えるときは Rust+側の条件（一定以上のポート番号など）もあるので、適当に小さい番号へ移さない方が安全です。

Windowsファイアウォール（受信規則）のコツ

最短はこれです。

RustDedicated.exe を アプリとして許可（UDP/TCP）
もしくはポート単位でルール作成
- UDP：28015（必要なら 28017）
- TCP：28016（必要なら Rust+のポート）

✅ “プライベートネットワークのみ許可”にしておくと事故りにくいです（外部公開するならルーター側で調整）。

ルーターのポート開放（NAT）のコツ

ここで詰まる原因トップ3はこれです。

サーバーPCのIPが変わった（DHCPで別IPになった）
UDP/TCPを間違えた（“両方”にしない方が安全な場合が多い）
ルーター二重（ONU＋ルーターなど）で別機器にも設定が必要

✅ 対策

サーバーPCのIPは DHCP予約で固定
まずは UDP 28015のみ を転送して外部接続テスト
うまくいったら query/RCON/Rust+ を足す

外部からの接続確認（現実的なやり方）

UDPはWebのポートチェックが当てにならないことがあります。
一番確実なのはこれです。

友達に connect 公開IP:28015 を試してもらう
もしくは自分のスマホをテザリングにして（別回線にして）接続する

Mod/プラグイン（uMod/Oxide）でやれること＆導入・更新

導入前チェック：バニラ運用と何が変わる？（メリット/デメリット）

uMod（旧Oxide）は、Rustサーバーに「プラグインを動かす土台（改造フレームワーク）」を追加する仕組みです。
入れると、サーバー側だけで機能拡張でき、参加者（クライアント）は基本的に追加導入なしで参加できます。

できること（代表例）

🛠️ 管理の自動化：自動リスタート、定期告知、権限管理、ログ強化
🎮 遊び方の拡張：イベント、PvE調整、経済、ショップ、テレポート、保護設定など
🔍 運用の見える化：管理コマンド、監視、簡易的な統計（プラグイン次第）

バニラとの違い（ざっくり早見）

スクロールできます

観点	バニラ（素のRust）	uMod/Oxide導入
導入難易度	低め	中（更新の手間が増える）
機能拡張	ほぼ不可	プラグインで自在
安定性	比較的安定	プラグイン次第で不安定要素が増える
更新対応	Steam更新だけ	Steam更新＋uMod更新＋プラグイン更新
セキュリティ	攻撃面が少ない	プラグイン分のリスクが増える

メリット（初心者にとっての“現実的な価値”）

運用がラクになる（毎回の作業を減らせる）
小規模でも「管理者が楽できる仕組み」を入れられる
“自分たち用ルール”を形にしやすい

デメリット（ここで後悔しがち）

⚠️ Rust本体の更新後、uModやプラグインが追従するまで待ち時間が出る
⚠️ プラグインを増やすほど、メモリ/CPU負荷とトラブル確率が上がる
⚠️ 不明な配布元のプラグインは、運用者自身がリスクを背負う（ソース確認できるかが重要）

✅ 判断のコツ

身内で快適にしたい：導入価値が高い
とにかく安定最優先：まずはバニラで運用を固めてから導入

導入手順：上書き・配置場所・起動確認

ここは“どの環境でも共通の型”で進めるのが安全です。レンタルでもVPSでも、基本は同じです。

0）まず必ずやる（事故防止）

サーバー停止
バックアップ（最低限これだけ）
- ワールド（identity配下）
- server.cfg（設定）
- 既に導入済みなら oxideフォルダ（プラグイン/設定）

1）uMod（Oxide for Rust）を入手

uModのRustページから、OSに合う版（Windows / Linux）を取得します
（Windows版をLinuxに入れる、などが一番多いミスです）

2）サーバー本体に“上書き配置”

ダウンロードしたzipを展開し、Rust Dedicated Serverのルートに上書きします
上書き後にサーバーを起動すると、初回起動で oxide/ フォルダが生成されます（生成されない場合は配置場所がズレている可能性が高いです）

3）起動確認（ここが最短チェック）

起動ログで、uMod/Oxideが読み込まれている旨の出力があるか確認
oxide/ フォルダができているか確認
ゲーム接続ができるか確認（まずはIP直打ちが確実）

4）プラグインを入れる（配置場所はここだけ覚えればOK）

プラグイン（多くは .cs）を入れる場所は原則ここです
- oxide/plugins/

5）プラグインの起動確認

サーバー再起動が一番確実
既に起動中なら、コンソールからリロードできる場合があります（プラグイン側の仕様によるので、基本は再起動が安全です）

💡 レンタル（管理パネル型）の場合
サービスによっては「Oxideを有効化」トグルがあることがあります。その場合は 手動で上書きしないで、提供手順に従った方がトラブルが減ります（自動更新の仕組みが別のため）。

更新の鉄則：ゲーム更新→Mod更新→プラグイン更新の順序

uMod運用で“壊れない人”は、例外なく更新順を守っています。
順番を崩すと、原因切り分けが一気に難しくなります。

鉄則の順番（これだけ覚える）

Rust本体（Dedicated Server）を更新（SteamCMD）
uMod/Oxide（Rust拡張）を更新（新しいzipで上書き）
プラグインを更新（最新版に差し替え）

なぜこの順番？（初心者向けに短く）

Rust更新で内部仕様が変わる
→ それに合わせてuModが更新される
→ さらにその上で、各プラグイン作者が追従する
という“積み重ね”構造だからです。

おすすめの更新フロー（テンプレ）

サーバー停止
SteamCMDでRust更新（普段はvalidateなし、異常時だけvalidate）
uModを最新に上書き
サーバー起動（この時点で「プラグインなし」でも起動できるか軽く確認）
プラグイン更新（差し替え）
再起動（または必要なリロード）
参加テスト

✅ コツ：更新直後に問題が出たら
「uModの問題」なのか「プラグインの問題」なのかを分けるために、まずプラグインを一旦退避（pluginsフォルダを空に）して起動確認すると、切り分けが速いです。

更新で壊れた時の切り戻し（バックアップ前提）

“切り戻し”は、順番を決めておくとパニックになりません。

切り戻しの基本手順

サーバー停止
oxide/plugins/ を別フォルダへ退避（プラグインを全停止）
サーバー起動して動作確認
- ここで安定する → 原因はプラグイン側の可能性が濃厚
1つずつプラグインを戻す（または重要なものから戻す）
問題のプラグインを特定したら、次のどれかで対処
- 最新版に更新
- 設定を見直す（最近追加した項目が地雷になりやすい）
- 一旦無効化して、作者更新を待つ

どうしても復旧しないとき（最短で戻す）

事前に取っておいたバックアップから、次を優先して復元
- ワールド（identity配下）
- 設定（server.cfg等）
- oxide（導入済みの場合）
“とにかく遊べる状態”を戻してから、機能を段階的に復活させるのが最速です

安全面の現実解

プラグインは「入れた分だけ管理責任が増える」ので、最初は
①必須（管理/権限）→②便利（告知/TP等）→③遊び拡張（経済/イベント）
の順で増やすと、トラブルが小さく済みます。

参加方法：友達を呼ぶ・サーバーに入る（接続で迷わない）

IP直指定で接続（client.connect）

サーバーに入るとき、いちばん確実なのが IP（＋ポート）を直指定する方法です。
「サーバー一覧に出ない」「検索で見つからない」ときでも、これなら入れます。

手順（最短）

Rustを起動してメインメニューへ
F1でコンソールを開く
次を入力してEnter

connect <IPアドレス>:<ポート>

例：

connect 203.0.113.10:28015

古い説明やホスティング業者のガイドでは client.connect と書かれることがありますが、まずは connect を使うのが迷いにくいです（同じ意味で扱われているケースが多いです）。

友達に渡す情報は「これだけ」でOK

トラブルを減らすため、コピペで渡せる形にしておくのがおすすめです。

接続先：IP:PORT（例：203.0.113.10:28015）
サーバーパスワード（設定している場合のみ）
参加ルール（身内限定／PvE寄り等、ひと言で）
（必要なら）Discord招待リンク

✅ 注意：管理用（SSH / RCON）のパスワードは渡さない
友達が必要なのは「ゲームに入るための情報」だけです。

“IP”の落とし穴（ここだけ押さえる）

同じ家の中（同一Wi-Fi）で試すとき：192.168.x.x などの ローカルIPでもOK
家の外の友達を呼ぶとき：192.168.x.x は使えません。必要なのは グローバルIP（公開IP）です
ポート（28015 など）を変えているなら、必ず :ポート を付ける

ついでに覚えると便利

接続情報をコンソールに残したくないときは、次のようなコマンドが用意されていることがあります。

connecthidden <IP:PORT>

お気に入り登録/履歴から入る

毎回コマンド入力しなくても、お気に入りに入れておけば次回以降が一気に楽になります。

Rustゲーム内で「お気に入り」に入れる

一度入れたサーバーは、サーバーブラウザの 履歴（History） に残ることが多いです
そこから お気に入り（Favorites） に追加しておくと、検索不要で入れます

💡コツ
最初は IP直指定で入る → お気に入り登録の順が一番スムーズです。

Steam側の「お気に入り」に入れる（サブルート）

「Rust内の一覧だと不安定」「別PCでも管理したい」場合は、Steamのゲームサーバー一覧を使う手もあります。

Steamの ゲームサーバー（Game Servers） 画面を開く
Favorites に IP と（必要なら）queryport を追加
そこから接続

📌 ここで混乱しやすい点
Steam側で登録するとき、求められるポートが “ゲーム接続ポート”ではなく“Queryポート” のケースがあります。
分からなければ、まずは Rust内の connect IP:PORT を正解にしておくのが安全です。

サーバー一覧に出ない時の確認（queryport/名前重複/起動状態）

「IP直打ちだと入れるのに、一覧に出ない」問題はかなり多いです。
焦らず、次の順番で確認すると切り分けが速いです。

1) まず起動状態（“そもそも動いてる？”）を確認

サーバーのコンソールが落ちていないか
再起動直後で、まだ登録処理が終わっていないだけではないか
自分（管理者）が connect で入れるか（入れないなら一覧以前の問題）

✅ ここで入れないなら

ポート開放（FW/NAT）
サーバー起動パラメータ
回線/VPS側FW
など“接続そのもの”の問題を先に疑います。

2) queryport（UDP）が正しく設定・開放されているか

一覧表示には queryport（UDP） が重要です。

server.queryport が未設定だと、自動的に別ポートが割り当てられることがあります
ホスティングの古いテンプレや古い設定だと、queryportが起動引数に入っていないことがあり、一覧に出ない原因になりがちです
OSのFWと、VPSのセキュリティ設定（クラウド側FW）の “二重” でUDPが許可されているか確認

💡おすすめの現実解
公開するなら、起動引数で queryportを明示して固定すると事故が減ります。例：

+server.port 28015
+server.queryport 28017

3) サーバー名の重複・検索条件で“見えなくなってないか”

意外と多いのがこれです。

サーバー名がありがちすぎて埋もれる（例：Rust Server など）
フィルター（地域、Ping上限、Modded/Community、満員除外など）で弾かれている
タブ違い（Community / Modded など）にいる

✅ 対策

サーバー名に 識別子（JP / 身内 / Wipe周期） を入れる
まずはフィルターをリセットしてから探す
“一覧で探す”のに固執せず、IP直指定→お気に入りに逃がす

4) “公開IP”が変わっていないか（自宅運用で多い）

自宅回線だと、プロバイダ都合で 公開IPが変わることがあります。
昨日まで繋がっていたのに今日は無理、というときはここを疑います。

友達に渡しているIPが古い
ルーター再起動でIPが変わった
DDNSを使っていない

管理者コマンドと運用ルーチン（毎週の作業が楽になる）

権限設定：ownerid/moderatoridの付与と保存

Rustサーバーの運用で最初にやるべきは、管理権限（Owner / Moderator）を正しく付けて、設定として保存することです。
ここが曖昧だと「コマンドが効かない」「再起動したら権限が消えた」などで詰まりやすくなります。

Owner / Moderator の違い（ざっくり）

ownerid（Auth Level 2）：最上位。基本的に“サーバー主”だけに付与
moderatorid（Auth Level 1）：運用補助向け。荒らし対応や軽い管理を任せる用

✅ 迷ったら

自分＝ownerid
信頼できる友達＝moderatorid（いきなりownerにしない）

付与に必要なもの：SteamID64

権限付与は SteamID64 を使います。
SteamプロフィールURLの末尾や、SteamID確認サイトで確認できます。

付与コマンド（RCON/サーバーコンソール）

サーバーに対して以下を実行します（ダブルクォートは環境によって不要な場合もあります）。

ownerid <STEAMID64> "ニックネーム" "理由"
moderatorid <STEAMID64> "ニックネーム" "理由"

例：

ownerid 7656119xxxxxxxxxx "Atsushi" "server owner"
moderatorid 7656119yyyyyyyyyy "FriendA" "trusted mod"

“保存”が超重要：server.writecfg

付与しただけだと、環境によっては 再起動で反映が戻ることがあります。
権限変更後は、必ず設定を書き出して固定します。

server.writecfg

🔁 よくある勘違いポイント

権限付与後、対象プレイヤーは再接続が必要なことが多いです
付与情報や設定ファイルは、server.identity 配下の cfgフォルダ側に保存される前提で考えると整理しやすいです

よく使う運用コマンド（保存・再起動・停止・設定書き出し）

「毎回ググる」を卒業するために、まずは“運用で使う最小セット”だけ覚えるのがコツです。
（※コマンドの入力先は、サーバーコンソール / RCON / 管理パネルのコンソールのいずれか）

まず押さえる“運用コマンド”早見表

スクロールできます

目的	コマンド例	使うタイミング
手動セーブ（ワールドの状態を保存）	`save`	再起動/停止の直前、重い作業の前
設定の書き出し（変更を永続化）	`server.writecfg`	権限付与・設定変更の直後
全体アナウンス	`sv say <メッセージ>`	再起動予告、ワイプ告知
状況確認（誰がいる/ID確認）	`players` / `status`	権限付与の前、荒らし対応時
キック/バン（基本）	`kick <ID/名前> <理由>` / `banid <ID> <名前> <理由>`	迷惑行為への即時対応
サーバー停止（保存して終了）	`sv quit`	メンテ、ワイプ、サーバー移行

“再起動”は、Rust単体コマンドより 運用基盤（systemd/管理パネル/ホスティング機能）で行うのが事故りにくいです。
例：save → sv sayで予告 → 停止 → 起動（またはサービス再起動）

失敗しない「再起動」テンプレ（最小）

再起動の事故は、ほぼ「告知なし」と「セーブ忘れ」で起きます。

予告（1分前くらいでもOK）

sv say サーバーをまもなく再起動します（60秒後）

保存

save

停止（安全に落とす）

sv quit

起動（管理パネル/サービス側で開始）

✅ これだけで「落ちた」「ロールバックした」がかなり減ります。

ワイプ運用：頻度・手順・告知テンプレ（トラブル予防）

Rustは「ワイプ（リセット）」が前提のゲームなので、ルール化すると運用が一気にラクになります。
ワイプの種類は大きく2つです。

ワイプの種類（何が消える？）

マップワイプ：拠点・配置物・マップ上の状態がリセット（基本の“いつものワイプ”）
BP（ブループリント）ワイプ：プレイヤーの研究進行（設計図）もリセット（影響が大きい）

💡 どっちにするべき？

身内・短期で遊ぶ：マップワイプ中心が平和
競争感を戻したい／経済を締めたい：BPワイプをたまに混ぜる（月1や隔月など）

失敗しないワイプ手順（現実的な最短）

ワイプは「消す」より「戻せる」が大事なので、順番を固定します。

告知（最低でも前日、できれば数日前）
- ワイプ日時
- マップだけ/BPも含むか
- サーバー名や検索ワードが変わるか（変えるなら）
バックアップ（必須）
- server.identity 配下のデータ（ワールド/設定/必要ならプラグイン類）
- 「戻し方」までセットでメモ（どこを復元するか）
停止

sv say まもなくワイプのため停止します
save
sv quit

ワイプ実施（方式は環境で違う）
- ホスティング：管理パネルの「Wipe」ボタンがあることが多い
- VPS/自前：server.identity 配下の 該当データを削除して再起動
  - マップだけ：ワールド（.sav / .map など）を対象に
  - BPも：player.blueprints系のデータも対象に（影響が大きいので慎重に）
起動 → 動作確認（入れる/一覧に出る/ラグがない）
- まず管理者が入って確認
- 問題なければ告知して解放

告知テンプレ（コピペで使える）

① 事前告知（Discord向け）

📅 ワイプ日時：2/20(金) 21:00（JST）
🧹 種類：マップワイプ（BPは維持）
⏱ 停止時間：10〜20分予定
🔑 接続方法：IP:PORT（変更なし）
✅ 注意：再起動後は一度Rustを再起動すると入りやすい

② 当日告知（ゲーム内/Discord）

🛠️ これからワイプ作業に入ります。5分後に停止します！
🧷 大事なスクショ・座標は今のうちに！

③ 完了告知

✅ ワイプ完了！サーバー起動しました
🗺 seed/worldsize（変更した場合）
🧩 BPは維持/リセット（どちらか明記）

トラブルシュート：症状別チェックリスト（最短で原因へ）

起動しない／すぐ落ちる（ログの見方→原因切り分け）

まずは「原因を当てにいく」より、ログを残して→最小構成で再現させるのが最短です。

最短でやること（優先順）

ログをファイルに出す
- 起動オプションに -logfile を付けて、毎回ログが残るようにします（WindowsでもLinuxでも有効）。
  例：-logfile "logs\rustserver.log"
“最小構成”で起動できるか確認（まずはバニラで）
- いったん Mod/プラグインを外した状態（uMod/Oxideなし、または oxide を退避）で起動できるかを見ます。
  → ここで安定すれば、原因は Mod/プラグイン側に寄っている可能性が高いです。
SteamCMDで整合性を取り直す
- 自前運用（VPS/Windows自宅など）なら、SteamCMDの app_update 258550 validate が「壊れた／欠けたファイル」の修復に効きます。
- 併せて 空き容量不足がないか確認（更新途中で落ちる典型）。
ポート競合（既に使われている）を疑う
- サーバーが起動直後に落ちる場合、ポートが別アプリと競合しているケースがあります。
- server.port を一度変えて試す（例：28015→28025）。
設定を盛りすぎない
- 初回から worldsize や maxplayers を大きくすると、起動はしてもロードが長い／不安定になりやすいです。
  まずは小さめで起動→安定後に拡張が安全。

ログの“見どころ”（初心者向け）

最初にエラーが出た位置（末尾だけでなく、エラーの直前も見る）
“Missing / Failed / Exception / Could not” などの単語
何か変更した直後に発生していないか（更新・設定変更・プラグイン追加）

外部から接続できない（ポート・FW・NAT・クラウド側）

ここは「内側で入れるか → 外へ出す」の順に潰すと迷いません。

最短で切り分ける手順

同じPC/同一LANから接続できるか
- まずは connect localhost:28015（同一PC）
- 次に LAN内の別PCから connect 192.168.x.x:28015
  → ここで入れないなら、外部公開以前に サーバー起動やローカルFWの問題です。
IPが“公開IP”になっているか
- 友達に渡すのは 192.168.x.x ではなく グローバルIP（公開IP）。
- 自宅回線だと公開IPが変わることもあるので「昨日のIP」で案内していないか確認。
開けるべきポートを“目的別”に整理
- ゲーム接続（必須）：server.port（UDP）
- サーバー一覧表示（必要なら）：server.queryport（UDP）
- RCON（管理するなら）：rcon.port（TCP）
- Rust+（使うなら）：Companion用ポート（TCP）

✅ よくある落とし穴

“開放したつもり”でも、OS側FWとクラウド側FW（VPSのセキュリティ設定）の二重で止まっている
server.queryport を開けていないため 一覧に出ない（IP直打ちは可能でも、ブラウザ検索では見つからない）

Rust+を使う場合の追加チェック
- Rust+は Companion Server の TCPポートが外部から到達可能でないと機能しません。
- デフォルトは「ゲームポート+67 または RCONポート+67（大きい方）」になり、典型例だと 28082 になります。
- app.port を変える場合、10000以上でないとRust+バックエンドから到達できません。
- どのポートを使っているかは app.info で確認できます。
自宅ルーター（NAT）なら“外から”でテスト
- 同一LANから公開IPで試すと、ルーター仕様（NATループバック）で失敗することがあります。
- スマホテザリングなど別回線で試すのが確実です。

重い／ラグい（CPU/RAM/I/O/設定の当たり所）

「何が詰まっているか」を先に当てると、無駄な設定いじりを減らせます。

まず見るべき3点（優先順）

CPU（瞬間的に張り付く／常に高い）
- 人数が増えるほどCPUが先に苦しくなりやすいです。
- まず効くのは maxplayersを下げる、次に ワールドサイズを下げる。
RAM（メモリ不足→スワップ発生）
- スワップが動くと、体感が一気に“カクカク”になります。
- メモリが厳しそうなら、まずは
  - worldsizeを小さめに
  - プラグイン数を減らす
  - 同居プロセス（他ゲーム・常駐）を止める
    が安全です。
ディスクI/O（周期的なフリーズ／保存時に止まる）
- 「一定間隔で止まる」「セーブっぽいタイミングで固まる」はI/Oが濃厚。
- 対策は
  - SSD/NVMeへ（効果が出やすい）
  - worldsizeを下げる
  - ログ肥大化・ディスク満杯を防ぐ（ログ出力＋ローテーション）
    が現実的です。

症状→当たり所（早見）

常時重い：CPU or RAM不足（設定/人数/プラグインを疑う）
周期的に止まる：I/O（ディスク、セーブ、バックアップ）
ラバーバンド（巻き戻る）：回線/遅延 or サーバー処理落ち（CPU）
特定の時間帯だけ悪化：回線混雑（自宅回線／VPSの帯域）も疑う

Modが動かない（バージョン差・上書き・更新順序）

「Modが動かない」は、原因が 3つに分かれます：
(A) Oxide/uMod自体が読み込まれていない／(B) プラグインだけ死んでいる／(C) 更新順が崩れている

A：uMod/Oxideが読み込まれていない時

ログに uMod/Oxide の読み込み痕跡がない
oxide/ フォルダが作られない／起動しても増えない
→ まずは 配置場所（サーバー本体ルート）が合っているか確認。

さらに多いのがこれ👇

起動スクリプトにSteamCMD更新を組み込んでいて、毎回 バニラに上書きされる
- 結果：起動してもOxideが消えている（入れ直しても次回起動で消える）
- 対策：更新工程と起動工程を分離する／Oxideの再適用を更新手順に組み込む

B：プラグインだけ動かない時

uModは動いているが、特定プラグインがエラー
→ 切り分けの最短手順はこれです。

oxide/plugins/ を一旦退避（空にする）
サーバー起動して安定するか確認
重要なプラグインから 1つずつ戻す
問題のプラグインを特定したら
- 最新版へ更新
- 設定を初期化して再調整
- 互換性のある代替プラグインへ
  のどれかにします。

C：更新順が崩れている時（いちばん壊れやすい）

更新の鉄則はこれだけです。

ゲーム（Rust Dedicated）更新 → uMod/Oxide更新 → プラグイン更新

順番が前後すると「動いたり動かなかったり」「急にエラーが増える」状態になりがちです。

料金とスペックの目安（人数別の現実ライン）

Rustサーバーは、同じ「人数」でも マップサイズ（worldsize）・拠点の密度（エンティティ数）・Mod/プラグインの有無で負荷が大きく変わります。
ここでは初心者が迷いにくいように、まず「身内で遊ぶ」前提の 現実ラインをまとめます。

まず大前提として、公式情報の目安は次のイメージです。

最低ライン：空きRAM 8GB（小さめの運用向け）
安定寄りの目安：空きRAM 12GB以上（マップが大きいほど増える）
ストレージ：SSD/NVMe推奨（セーブや読み込みの体感差が出やすい）

1〜10人：まずはここから（小さく始めてスケール）

結論から言うと、身内10人までなら 16GBクラスがいちばん失敗しにくいです。
8GBでも動くケースはありますが、Rustは「ギリギリだと急に崩れる」ことがあるので、初心者ほど余裕を取りに行くのが安全です。

推奨スペック（目安）

RAM：16GB（最低でも12GBを目標）
CPU：高クロック寄りの2〜4コア相当（vCPU 4前後が無難）
ストレージ：NVMe 50〜100GB以上
回線：上り 10Mbps以上が最低ライン（余裕があるほど良い）

料金感（目安）

月額運用（24時間稼働）：1.2万〜1.6万円前後が“ちゃんと遊べる”現実ラインになりがち
- 例：国内VPSの16GBプラン帯
週末だけ遊ぶ：時間課金タイプなら 稼働時間に比例して安くできる（ただし毎週遊ぶなら月額の方がラク）

小さく始めてスケールするコツ ✅

最初は worldsizeを控えめにする（大きいほどRAM・I/Oが増えやすい）
Modは後回し（まずはバニラで安定運用→必要に応じて追加）
人数が増えたら、最初に触るのは 最大人数とワールドサイズ（“体感”に効きやすい）

10〜30人：メモリ・CPUの落とし穴

この帯からは「たまに重い」ではなく、ピーク時に一気にラグる問題が出やすくなります。
原因の多くは RAM不足か、CPUの頭打ち（特に単体性能）です。

推奨スペック（目安）

RAM：32GB寄り（最低でも16GB、ただし余裕が出にくい）
CPU：vCPU 6〜8以上（同世代で“強いコア”ほど有利）
ストレージ：NVMe 100GB以上（バックアップを含めるなら余裕を）

料金感（目安）

24時間運用：3万円前後〜が視野（32GB帯）
「まずは16GBで始めて、混み始めたら32GBへ」のスケール戦略が現実的

落とし穴（ここで詰まりやすい）⚠️

Mod/プラグイン増加 → RAMを食う → セーブ時に固まる
拠点が増えてエンティティが増加 → CPUとI/Oが同時に苦しくなる
「vCPUの数」だけ見て、世代が古いCPUを選ぶと伸びにくい
→ 体感は コア数より1コアの強さが効く場面が出ます

30人以上：構成・監視・バックアップが必須になる理由

30人を超えると、スペックを上げるだけでなく 運用設計が効いてきます。
ここをサボると「ある日突然落ちる」「復旧に時間がかかる」など、トラブル時の損失が大きくなります。

推奨スペック（目安）

RAM：32〜64GB
CPU：vCPU 8〜12以上（できれば性能の高い世代）
ストレージ：NVMe 100GB以上＋バックアップ領域（またはスナップショット前提）
回線：安定性重視（帯域より“落ちないこと”が重要）

料金感（目安）

24時間運用：3万円〜6万円超も普通にあり得る（32〜64GB帯）
大規模化するほど VPSより専用サーバー/上位インスタンスが現実的になることも

「必須になる理由」を一言でいうと

監視がないと：重くなっているのに気づけず、ピークで落ちる
バックアップがないと：ワイプ/更新/障害で“戻せない”
手順がないと：復旧が属人化して、再発時に詰む

最低限、これだけは用意すると安心です👇

定期バックアップ（ワールド・設定・プラグイン）
スナップショット運用（“戻し方”までセット）
ログ肥大化対策（ローテーション）
再起動・更新の定型手順（告知→save→停止→更新→起動→確認）

Rustサーバー立ち上げ「10分チェック」

今日やること（開通まで）

ゴール：とにかく“1回入れる”状態を作る（一覧に出すのは後回しでOK）

立て方を決める（迷ったらこれ）
- 身内でサクッと：レンタル（テンプレ）
- 本格運用：VPS/専用（SteamCMD＋常駐化）
- 検証：Windows自宅（まずLAN内）
最小構成で起動（盛らない）
- server.port（例：28015/UDP）だけ通す
- server.identity を決める（データ保存先の基準）
接続テストは“近い順”で
1. 同一PC：connect localhost:28015
2. 同一LAN：connect 192.168.x.x:28015
3. 外部：connect 公開IP:28015（スマホテザリング等の別回線で確認）
外部公開するなら最低限これだけ
- ルーターNAT（ポート開放）：UDP 28015をサーバーPCへ転送
- Windowsファイアウォール/OS側FW：UDP 28015許可
- （VPSなら）クラウド側FW：UDP 28015許可
友達に渡す“最小セット”を用意
- ✅ IP:PORT（コピペ用）
- ✅ パスワード（設定している場合のみ）
- ✅ ルール1行（身内限定、PvE寄り等）

明日やること（安定運用へ）

ゴール：落ちても戻る／迷子が出ない／運用が楽になる

一覧表示を安定させる（必要な人だけ）
- server.queryport を明示して固定（例：28017/UDP）
- OS側FW＋クラウド側FW（またはルーター）で UDP queryport も許可
- サーバー名を被りにくくする（JP/身内/ワイプ周期など）
管理権限を付けて“保存”する
- ownerid <SteamID64> "名前" "理由"
- moderatorid <SteamID64> "名前" "理由"
- 変更後は必ず server.writecfg（これを忘れると戻ることがあります）
ログを残す（トラブルが一瞬で解決しやすくなる）
- 起動時に -logfile を付けてファイル出力
- ログが肥大化しない置き場所（logsフォルダなど）を決める
再起動の型を作る（事故を減らす）
- 予告 → 保存 → 停止の順で固定
- 例：sv say 60秒後に再起動します → save → sv quit
Rust+を使うなら“先に疎通確認”
- Companion用TCPポートが外部から到達できるか（FW/フィルタも確認）
- app.info で現在の設定を確認（ポートを変えるなら条件にも注意）

長期で効くこと（バックアップ/更新/セキュリティ）

ゴール：壊れても戻せる／更新で死なない／乗っ取られない

バックアップは「取る」より「戻す」まで
- 対象（最低限）
  - ワールド（identity配下）
  - 設定（server.cfg、起動スクリプト等）
    -（Modあり）oxide/（plugins/config/data）
- 週1でもいいので 復元テストを1回やる（これが最強）
更新フローを固定（混乱を防ぐ）
- バニラ運用：Rust更新 → 起動確認
- uMod運用：Rust更新 → uMod更新 → プラグイン更新
- 事故ったら：プラグインを一旦退避して切り分け（原因特定が速い）
セキュリティは“3点セット”だけでも強い
- SSH（VPS）：鍵認証・パスワードログイン抑制・fail2ban
- RCON：強パスワード＋可能ならIP制限（全開放しない）
- FW：必要ポートだけ開ける（増やすときは目的を明確に）
“重い/ラグい”の予防策（効きやすい順）
- 最大人数を欲張らない（CPUが一番効く）
- worldsizeを適正に（RAM/I/Oに直撃）
- SSD/NVMe前提に（周期的フリーズ対策）
- ログ肥大化・ディスク満杯を潰す（意外と多い）

まとめ

Rustサーバーの立ち上げは、一見むずかしそうに見えますが、コツはシンプルです。
“最小構成で起動 → 近いところから接続確認 → 外部公開と運用を積み上げる”。この順番を守るだけで、失敗率は大きく下がります。

最後に、この記事の要点を短く整理します。

立て方は大きく3つ
- 手軽さ最優先：レンタル（テンプレ）
- 自由度と本格運用：VPS/専用サーバー（SteamCMD＋常駐化）
- 検証・小規模：Windows自宅（まずLAN内）
接続の基本は「IP直指定」が最強
- 一覧に出ない・検索で見つからない時も、connect IP:PORT なら入れる
- 外部接続は 公開IP／UDPポート／FW／NAT の順で切り分ける
一覧に出すなら queryport を意識
- 公開する場合は queryportを明示して固定すると事故が減る
- “入れるのに一覧に出ない”は、ほぼここかフィルターが原因
管理と運用は「型」を作ると一気にラク
- 権限付与後は server.writecfg で保存
- 再起動は「告知 → save → 停止 → 起動」のテンプレで事故を防ぐ
- ワイプは「バックアップ → 実施 → 動作確認 → 告知」の順で混乱を減らす
Mod（uMod/Oxide）は“更新順”がすべて
- ゲーム更新 → uMod更新 → プラグイン更新
- 壊れたらプラグインを退避して切り分けると復旧が速い