Rustプライベートサーバー入門|立て方・参加方法・設定・非公開運用まで
Rustを身内で遊びたいと思ったとき、こんな悩みはありませんか?
「公式サーバーだと強い人が多くて、練習する前にボコボコにされる…」
「友達とだけ遊べる“プライベートサーバー”って、どうやって立てるの?」
「VPSとかLinuxって難しそう。レンタルで簡単にできる方法はある?」
「自宅PCで立てたいけど、ポート開放とか回線の設定が不安…」
「第三者を入れたくない。非公開にしたり、ホワイトリストにしたりできる?」
「サーバー一覧に出ない/友達が接続できない時は、どこを見ればいい?」
Rustのプライベートサーバーは、やり方がいくつかあります。
しかも「立てる」だけで終わりではなく、参加方法の共有、ルール設定、非公開運用(第三者を入れない工夫)、アップデートやバックアップまで押さえると、身内サーバーは驚くほど安定します。
この記事では、初心者でも迷わないように、
- まず結論:プライベートサーバーの作り方は3ルート(レンタル/VPS/自宅PC)
- 接続の基本(F1コンソール・直打ち・お気に入り)
- つまずきやすいネットワーク設定(port / firewall / NAT)
- 非公開・招待制の作り方(“パスワード頼み”にしない考え方)
- 運営をラクにする管理者設定とRCON
- よくあるトラブルの切り分け
…までを、実際の運用目線でわかりやすく整理します。
「最短で身内サーバーを立てたい人」も、「コスパ重視でVPSに挑戦したい人」も、「自宅PCでまずローカル運用したい人」も、この記事を読み終える頃には、自分に合うルートと最短手順が決まるはずです。

まず結論:プライベートサーバーの作り方は3ルート(おすすめも提示)
Rustの「プライベートサーバー(身内だけで遊ぶサーバー)」は、手軽さと自由度のトレードオフで選ぶと失敗しにくいです。
最初に押さえたいのは、Rustはサーバー側の負荷が軽くない点。公式の目安として、空きメモリ12GB・空き容量15GB(SSD推奨)が挙げられています。
つまり「とりあえず低スペで無料運用」は、思った以上に詰まりやすいです。
最短:ゲーム用レンタル(テンプレ)で即日立てる
結論:初心者が一番迷いにくいルートです。管理画面からテンプレを選ぶだけで、数分〜当日中に動かせます。
こんな人に向きます ✅
- まずは身内で遊べればOK(運用は最小限にしたい)
- Linuxやコマンド操作が不安
- 短期〜中期(数日〜数ヶ月)で遊ぶ可能性が高い
イメージ(やること)
- サービスで「Rust」を選ぶ
- プラン(メモリ)を決める
- 起動 → 参加(IP/ポートで接続)
- 必要なら「再起動」「バックアップ」だけ覚える
メリット
- 設定が少ない(初心者でも躓きにくい)
- だいたい自動更新や管理機能が揃っている
- 回線やポート開放を自分で抱えにくい(自宅運用より安全)
注意点(ここだけは先に知る)⚠️
- 「完全に外部から見えない(絶対入れない)」は、設定次第です
→ “非公開化”には別途工夫(例:公開範囲、問い合わせポート、ホワイトリスト相当の仕組みなど)が必要になるケースがあります。 - 料金はキャンペーンや契約期間で変動しがち
→ 公式ページ表示の金額を必ず確認しましょう。

自由度とコスパ:VPS/クラウドで手動構築する
結論:少し勉強してでも「自由にカスタムしたい」なら最適です。
MOD導入、細かい制限、ログ管理、バックアップ自動化など“やれる幅”が一気に増えます。
こんな人に向きます ✅
- MOD(プラグイン)を入れたい、細かく設定を触りたい
- 長期運用したい(半年〜)
- 将来、他のゲームサーバーにも流用したい
- 軽いサーバー管理(更新・再起動・障害対応)を覚える気がある
イメージ(やること)
- VPSを契約 → OSセットアップ(Linuxが多い)
- SteamCMD等でサーバー導入 → 起動オプション設定
- FW(ファイアウォール)・ポート許可
- 自動更新/自動再起動/バックアップ(できれば)を整備
メリット
- 自由度が最大(運営ポリシーを作りやすい)
- “自分用テンプレ”が完成すると、次から速い
- 同スペックならレンタルより安くなる場合も(※比較が大事)
注意点 ⚠️(初心者が詰まりやすいポイント)
- 最初の壁はだいたいここ
- ポート・FW設定
- 自動更新の仕組み
- メモリ不足(起動できない/途中で落ちる)
- “安いプランでとりあえず”は危険
→ Rustは設定次第でメモリ消費が増えます。最初から余裕あるプランで始める方が結果的にラクです。

自宅PC:ローカル運用(公開するなら設定が増える)
結論:身内だけで短時間遊ぶならアリ。ただし「公開」を絡めると難度が上がるルートです。
こんな人に向きます ✅
- まずはお金をかけずに試したい
- 自分のPCスペックに余裕がある
- “身内だけ”で、時間を決めて遊ぶ(常時稼働しない)
メリット
- サーバー代が実質かからない(=金銭コストが低い)
- 自分のPCなので自由に触れる
注意点 ⚠️
- 公開(外から参加)するなら、急にやることが増えます
- ルーターの設定(ポート開放)
- 回線品質や上り速度の影響
- IPの扱い(固定IPでない場合の対策)
- 常時稼働は負担が大きい
→ 電気代、PC負荷、再起動、アップデート、トラブル対応…意外と手間です。
あなたに合う選び方(人数×期間×MOD×手間で判断)
迷ったら、次の順で決めるのが早いです。
1)人数(同時接続)
- 2〜5人:レンタルでもVPSでもOK(ただし低メモリは避ける)
- 6〜10人:メモリに余裕がほしい(設定・マップ次第で差が出る)
- それ以上:VPS/クラウド(設計前提)か、上位プランのレンタルが無難
2)期間
- 数日〜数週間:👉 ゲーム用レンタルが最速(時間課金系も相性良い)
- 数ヶ月以上:👉 VPS/クラウドも検討(運用が馴染むと強い)
3)MOD(プラグイン)
- 使わない:レンタルでも十分
- 使う/増やす予定:👉 VPS/クラウドが楽(管理の融通が利く)
4)あなたの“触れる手間”
- できるだけ触りたくない:👉 レンタル
- 学びながらでも触れる:👉 VPS/クラウド
- ローカルで試したい:👉 自宅PC(ただし公開は難度UP)
最後に、超シンプルな早見表を置いておきます👇
| 目的 | いちばん合うルート | 理由 |
|---|---|---|
| とにかく今日遊びたい | ゲーム用レンタル | 設定が少なく最短 |
| 身内サーバーを長期で育てたい | VPS/クラウド | 自由度と拡張性が高い |
| まず無料で試運転したい | 自宅PC | 料金ゼロで検証できる |
「プライベートサーバー」とは?公式/コミュニティとの違いを整理
「Rustのプライベートサーバー」は、“身内で遊ぶために、参加者や見つかりやすさをコントロールしたサーバー”のことです。
大事なのは、Rustのサーバー一覧に「プライベート」という専用タブがあるわけではなく、コミュニティ(またはModded)サーバーを“プライベート運用”するイメージだという点です。
まずは混乱しやすい用語を、ざっくり表で整理します。
| 区分 | ざっくり言うと | 運営者 | ルール/設定の自由度 | “身内だけ”にしやすさ |
|---|---|---|---|---|
| 公式(Official) | いわゆる公式運営のサーバー | 公式側 | 低い(基本バニラ) | 低い |
| コミュニティ(Community) | 一般プレイヤー/団体が運営 | 個人/コミュニティ | 中(基本バニラ中心) | 中〜高 |
| Modded(Modded) | プラグイン等で遊び方を変えた | 個人/コミュニティ | 高い | 高い |
| プライベート運用 | 上のどれかを“身内向け”に調整 | 立てた人 | 設定次第 | 設計次第(工夫が必要) |
ポイントだけ先に言うと、初心者が「身内だけで遊びたい」なら、基本は“コミュニティ or Modded をプライベート運用”が現実的です。
(公式サーバーは、あなたが「参加者を選ぶ」ことができません)
プライベートで得られるメリット(身内運用・ルール自由・練習向き)
プライベートサーバーの価値は、ひとことで言うと “ストレス要因を自分で減らせる”ことです。
メリット(初心者に効く順)
- 身内だけで安心して遊べる
野良トラブルを避け、会話しながら学びやすい🙂 - 練習が圧倒的に捗る
建築、リコイル練習、モニュメント攻略、ファーム手順などを「やり直し前提」で試せます - ルールを自分たちに合わせられる
例:ワイプ周期、PvE寄り・初心者保護、まったり進行、イベント開催など - 運営が透明(=納得感が高い)
自分(または信頼できる友人)が管理者なら、理不尽に感じにくい
ただし注意
「身内サーバー=必ず外部から見えない」ではありません。
Rustは標準で“強いホワイトリスト前提”ではないため、本気で“招待制”にするには工夫(設定や仕組み)が必要です。
この点は後の章(非公開化・参加制限の具体策)でしっかり扱うのが大切です。
注意点:運用コスト(管理/回線/セキュリティ)は自分持ち
プライベートサーバーは「自由」なぶん、面倒も自分に返ってきます。
ここを知らずに始めると、途中で疲れてやめやすいです。
運用で発生するコスト(ざっくり)
- お金:レンタル/VPS料金、バックアップ費用(プラン次第)
- 時間:更新、再起動、設定変更、ログ確認、トラブル対応
- 回線:自宅運用だと上り帯域や安定性の影響を受ける
- セキュリティ:外部公開するなら“狙われにくい設計”が必要(特に自宅)
初心者が最初につまずきやすい作業
- アップデートで起動しなくなる → バージョン差分・更新順の確認
- 「一覧に出ない」「見つからない」→ サーバー表示条件/ポート周りの見落とし
- 参加できない → ファイアウォール/ルーター/NATの壁(自宅運用で多い)
現実的な割り切り(おすすめ)
- 初心者はまず ゲーム用レンタル(テンプレ)で“運用の全体像”に慣れる
- 慣れてから VPS/クラウドに移行(自由度アップ)
この順番だと、途中で詰まって挫折しにくいです。
規約・マナー面の注意(“怪しい募集/改造/不正”に近づかない)
プライベートサーバーは自由度が高い反面、ルールの一線を越えやすい領域にも近づけてしまいます。
SEO的にもE-E-A-T的にも、ここは明確に線引きしておく方が安全です。
避けるべきこと(当たり前だけど重要)
- チート・ハック・不正ツールの利用や助長
- 不正行為を“許容するサーバー”の宣伝・参加募集
- 規約違反になり得る改造や、他者に害を与える行為
Facepunchの規約・ガイドラインでは、チート/ハック等の不正行為を禁止する方針が明確です。
また、サーバー運営や改造(MOD/プラグイン)に関しても、ガイドラインの範囲で行うことが推奨されています。
マナーとして押さえると良いポイント
- 募集するなら「運営方針」「管理者の権限範囲」「禁止事項」を明記する
- 身内でも、ログ・バックアップ・権限管理は最低限やる(揉め事の予防)
- コミュニティ運用でプラグインを使う場合、サーバーの分類(Community/Modded)に関する指針も確認しておくと安心
料金とスペックの目安:失敗しない最低ラインを先に知る
Rustのプライベートサーバーは、「人数」よりも“世界の重さ(マップ/建築/AI/設定)”で急に重くなるのが特徴です。
先に“最低ライン”を押さえておくと、あとからプラン変更や引っ越しで苦労しにくくなります。
負荷が決まる要素(マップサイズ/人数/建築量/プラグイン数)
Rustサーバーの重さは、だいたい次の掛け算で決まります。
- マップサイズ(worldsize)
大きいほどメモリ消費・セーブデータ・探索範囲が増えて重くなります。
特に6k(6000)級は目に見えて負荷が上がりがちです。 - 同時接続人数
人が増えるほど、同期・戦闘・移動・アイテム処理が増えます。
ただしRustは「人数だけ」より、下の要因が効くことも多いです。 - 建築量(拠点の数・大きさ)
“建て込むほど”サーバーは重くなります。身内サーバーでも、長期運用で急に重くなる原因No.1になりがち。 - AI・イベントの密度
NPC・動物・ヘリ等の要素が多いほどCPUに効きます。 - プラグイン/Mod・カスタムマップ
便利にするほど処理は増えます。
「最初は快適→プラグイン追加→徐々に重い」は定番ルートです。
💡初心者向けの考え方
“まず軽い設定で安定させて、足りなければ増やす”より、Rustは逆がラクです。
最初から余裕あるメモリ(例:16GB)で始めて、設定を攻める方がトラブルが減ります。
必要スペック早見(CPU・メモリ・SSD・回線)
まず公式目安として、Rust Wikiではサーバー要件に 「空きメモリ12GB」「空き容量15GB(SSD/NVMe推奨)」が挙げられています。
ここで重要なのは “空き(free)” という点です。
- VPS/レンタルの「16GBプラン」を借りても、OSや常駐プロセスで一部は消費されます
- なので現実的には、16GBは“最低ライン寄り”、余裕を見るなら32GBが安心、という発想になります
少人数バニラ運用→中規模→MOD多めの目安
「身内で遊ぶ」前提の、ざっくり早見です(迷ったらこれでOK)。
| 想定 | 目安メモリ | CPUの目安 | ストレージ | こういう運用に向く |
|---|---|---|---|---|
| 少人数・バニラ中心(短期) | 16GB | 4コア以上(できれば高クロック) | SSD/NVMe | 2〜6人、マップ小さめ、建築控えめ |
| 中規模・長期(拠点が育つ) | 32GB | 6〜8コア以上が安心 | SSD/NVMe | 6〜15人、建築多め、イベント活発 |
| MOD多め・カスタム要素 | 32〜64GB | コア数+クロック重視 | SSD/NVMe | プラグイン追加前提、カスタムマップ、運営を凝る |
CPUは“コア数だけ”より体感の差が出ます。
Rustは処理が集中する場面(戦闘・襲撃・拠点密集)で、1コア性能(クロック/世代)が効きやすいので、同じメモリなら「CPU強め」を優先すると後悔しにくいです。
回線は“上り”が大事📶
自宅運用だと上りが細いと苦しくなります。レンタル/VPSなら回線品質は比較的安定します。
Ping/リージョンの考え方(日本から快適にするコツ)
日本から遊ぶなら、体感の差が出やすいのはここです。
- 可能なら 日本リージョン(東京など) を選ぶ
- 日本リージョンがなければ、次点で アジア近距離(例:シンガポール)
- 北米・欧州はPingが上がりやすく、PvPやヘリ等の体感が落ちやすい
目安としては、身内プレイでも
- Pingが低いほど快適(特に戦闘)
- そしてPing以上に、“ブレない安定性”が重要です(突然のラグが一番つらい)
費用内訳(サーバー代・電気代・IP/DDNS・バックアップ)
費用は「月額いくら?」だけで見ない方が失敗しません。
プライベート運用で実際に効いてくる内訳を、現実ベースで整理します。
1)サーバー代(レンタル/VPS)
- 料金体系は主に2つ
- 月額(長期割引パス等):長く遊ぶほど安くしやすい
- 時間課金:遊ぶ日だけ起動するスタイルに強い
例として、ConoHa for GAMEは
- 時間課金と長期割引パスの両方を用意しており、プランごとの月額・時間単価が表示されています。
- Rustテンプレート側では「推奨メモリ:8GB以上」という案内もありますが、公式要件(空き12GB)を踏まえると、安定重視なら16GB以上を起点に考えるのが安全です。
2)電気代(自宅PC運用のとき)
- レンタル/VPSなら基本ゼロ(料金に含まれる)
- 自宅PCの場合は地味に効きます
ざっくり計算はこれだけでOKです👇
- 消費電力(W)÷1000 × 稼働時間(h) × 電気料金単価(円/kWh)
例)100Wで24時間×30日稼働
- 0.1kW × 720h = 72kWh → あとは単価を掛けるだけ
3)IP/DDNS(主に自宅運用)
- 自宅回線はIPが変わることが多いので、外部から入れるならDDNSを検討
- VPS/レンタルは固定IPが基本(※サービス仕様による)
4)バックアップ
- 「ワールドが飛んだ」「設定を壊した」「巻き戻したい」が起きたときの保険です
- 目安は次のどちらか
- サービス側の自動バックアップ機能
- 自前で定期バックアップ(世代管理)
💡身内サーバーほどバックアップは価値があります
「次に集まれる日」が限られていることが多いので、復旧に時間を溶かすと満足度が落ちやすいです。
方式別のメリデメ:レンタル/VPS/自宅PCを比較して決める
Rustのプライベートサーバーは、「ラクさ」→レンタル、「自由」→VPS、「費用ゼロ寄せ」→自宅PCの順で考えると迷いにくいです。
ただしRustは公式目安として空きメモリ12GB・空き容量15GB(SSD/NVMe推奨)が挙げられており、低スペック前提だとどの方式でも詰まりやすい点だけ先に押さえておきましょう。
まずは全体像を一枚で整理します。
| 方式 | 立ち上げ難易度 | 自由度 | 運用の手間 | “身内だけ”にしやすさ | 代表的な費用感 |
|---|---|---|---|---|---|
| レンタル(テンプレ型) | 低い | 中 | 低い | 中〜高(サービス機能次第) | 月額/時間課金(サービスごと) |
| VPS(自分で構築) | 中〜高 | 高 | 中〜高 | 高(設定で強くできる) | 月額(構成で変動) |
| 自宅PC | 中(公開するなら高) | 高 | 高 | 中(回線/公開範囲で左右) | サーバー代ゼロ+電気代等 |
レンタル(テンプレ型)が向く人/向かない人
一言でいうと:初心者の“最短ルート”です。
管理画面でRustテンプレを選び、プランを決めて起動するだけで形になります。
向く人 ✅
- まずは今日〜今週中に遊びたい
- Linuxやコマンド操作は避けたい(設定に時間を溶かしたくない)
- “身内で遊べればOK”で、運用は最小限にしたい
- 短期〜中期(数日〜数ヶ月)で、使わない日は止めたい(時間課金が合う)
向かない人 ⚠️
- プラグインや細かい運営ルールをガッツリ作り込みたい
- バックアップ方式、ログ監視、再起動制御などを完全に自分流にしたい
- 料金や仕様がサービス依存になるのが気になる(“できる/できない”が出やすい)
レンタルを選ぶときのチェックリスト(失敗しにくい)
- 料金タイプ:時間課金があるか/長期割引があるか
- バックアップ:自動バックアップや復元機能はあるか
- サーバー操作:再起動・更新・設定変更が管理画面で完結するか
- リージョン:日本から遊ぶなら近いロケーションが選べるか
- 性能表記:メモリだけでなく、CPUコア数やストレージ種別が明記されているか
💡判断のコツ
「最初の1回」をレンタルで成功させると、Rustサーバーの流れ(更新/再起動/参加方法)が体感で分かります。
そのあとVPSへ移行するのが、結果的に一番ラクになりがちです。

VPSが向く人/向かない人(Linux運用できるかが分岐)
一言でいうと:自由度と拡張性を取りにいく方式です。
Rustは“運営の工夫”で快適性が変わるので、VPSは育て甲斐があります。
向く人 ✅
- MOD/プラグイン導入、独自ルール、ログ管理などを自分で最適化したい
- 長期運用で、拠点が育って重くなる前提で考えたい
- 将来的に別ゲームや別用途にも使い回したい(運用スキルが資産になる)
- トラブル時に「なぜダメか」を切り分けて直すのが苦じゃない
向かない人 ⚠️
- なるべく触りたくない(更新・再起動・障害対応が負担)
- SSH/ファイアウォール/プロセス管理などが不安で、学ぶ時間も取りづらい
- “遊ぶ時間”より“整備の時間”が増えるのは避けたい
VPSで初心者が詰まりやすいポイント(先回り)
- ポート/ファイアウォール:開けるべき場所が分からない
- 自動更新:アップデート後に起動しない/不整合が起きる
- メモリ不足:起動はするが途中で落ちる、カクつく
- バックアップ未整備:ワールド破損や設定ミスで巻き戻せない
💡VPSを選ぶコツ
RustはCPUも効きますが、まずはメモリに余裕を持つと安定しやすいです。
「必要最低限」より、“あとで重くなる未来”込みで選ぶのが正解に近いです。

自宅PC運用の落とし穴(常時起動・故障リスク・回線制約)
一言でいうと:試すには良いが、公開や常時運用は急に難しくなる方式です。
“無料で始めたい”気持ちに合いますが、現実の運用コストが見えにくい点が落とし穴です。
メリット ✅
- サーバー代が実質ゼロ(すでにあるPCを使える)
- 自分のPCなので、環境を自由に触れる
落とし穴(ここで挫折しやすい)⚠️
- 常時起動の負担
電気代、PC負荷、熱、OS更新、再起動、ディスク圧迫が積み上がります。 - 故障リスク
ゲーミング用途のPCでも、24時間稼働は別物。突然落ちるとワールド破損の原因にも。 - 回線制約(特に上り)
自宅回線は上りが細いことが多く、人数や戦闘で体感が悪化しやすいです。 - 公開するなら設定が増える
ルーター設定(ポート開放)やIPの扱い、セキュリティ面の配慮が一気に必要になります。
自宅PCを選ぶならの現実的なおすすめ
- まずは身内だけ・短時間・試運転に割り切る
- “いけそう”と思ったら、レンタル(テンプレ)→VPSへ移行
この順番だと、遊びを止めずにスムーズです。
共通の流れ:Rustサーバー構築は「導入→設定→公開(または非公開)→接続」
ここでは、レンタル・VPS・自宅PCのどれを選んでも共通する“骨格”だけを、迷いにくい順番で整理します。
- 導入:サーバーファイルを用意する(SteamCMDが基本)
- 設定:起動オプションでサーバーの性格を決める(最初に固定すべき項目あり)
- 公開/非公開:通信の入口(ポート)をどう扱うか決める
- 接続:起動完了を確認して参加する(F1コンソールで接続)
サーバーファイル準備(SteamCMD/配布zip どちらでも)
初心者がまず躓かないコツは、「サーバーファイルの場所」と「設定データの場所」を分けて理解することです。
- サーバーファイル:RustDedicated.exe など“プログラム本体”
- 設定・ワールドデータ:
server.identity(サーバー内部名)配下に保存される“データ置き場”
レンタル(テンプレ型)を使う場合は、多くのケースで「サーバーファイルはすでに用意済み」です。
その場合は、次の “初回起動の設定” から読めばOKです。
SteamCMDの基本:AppID/更新/ブランチの考え方
SteamCMDは「サーバーファイルを取得・更新する道具」です。基本だけ押さえれば難しくありません。
- AppID:Rust Dedicated Server の識別番号(これを指定してダウンロードする)
- 更新(app_update):サーバーファイルを最新にそろえる操作
- トラブル時は validate を付けると、欠けたファイルの修復も期待できます
- ブランチ(beta):通常版以外(テスト版など)を使うための“系統”
- 初心者はまず 通常版(指定なし) が安全
- どうしても必要なときだけ、
-beta <ブランチ名>のように指定します(プラグイン互換の都合など)
最低限のイメージ(例)
※環境によりパスは変わりますが、“流れ”は同じです。
# 1) インストール先を決める
force_install_dir "C:\rustserver"
# 2) 匿名ログイン(専用サーバーはこれで取得できるケースが多い)
login anonymous
# 3) ダウンロード / 更新
app_update 258550 validate
# 4) 終了
quit
「配布zip」について
Facepunch側で“クイックインストール用zip”が案内されている情報もありますが、古い手順が混ざりやすい(仕様が変わっている)ため、初心者ほど SteamCMD(またはテンプレ)基準で考えるのが無難です。
初回起動に必要な設定(起動オプションの全体像)
Rustサーバーは、起動時のオプションで「このサーバーは何者か」を決めます。
最初に全体像を掴むと、設定が怖くなくなります。
| 区分 | 何を決める? | 最初のおすすめ |
|---|---|---|
| 表示(見た目) | サーバー名・説明 | シンプルに(長文は後で) |
| ワールド | マップ種類・サイズ・シード | 小さめ〜標準で開始 |
| 参加枠 | 最大人数 | 身内人数+少し |
| 管理 | RCON(遠隔管理) | 必ず強いパスワード |
| データ置き場 | identity | 1つ決めて固定 |
identity/hostname/description(表示名の設計)
- identity(内部名)
これが実は最重要です。server.identityを指定すると、設定やワールドデータがその名前のフォルダにまとまります。
つまり、同じサーバーファイルからでも identityを変えれば別サーバーとして並行運用できます。 - hostname(サーバー名)
サーバー一覧に出る“看板”です。身内用でも、後から探しやすいように- グループ名
- ルール(例:PvE寄り/練習用)
- ワイプ方針(例:月1)
のように、短く要点だけ入れるのがコツです。
- description(説明文)
ここは“ルール掲示板”として使えます。おすすめは 3行以内の箇条書き風。
例:- 初心者歓迎(身内)
- PvE寄り/襲撃は相談
- ワイプ:月1 など
seed/worldsize/level(マップを固定する・変える)
- level:どのタイプのマップか(例:Procedural Map など)
- seed:同じマップを再生成するための“種”
- worldsize:マップの大きさ(大きいほど重くなりやすい)
初心者のおすすめは、まず 「小さめ〜標準」で安定させること。
身内でも、建築が増えてくると後半に重くなりやすいので、最初から巨大マップにしない方がラクです。
maxplayers/PvE寄せ/スリーパー等(運営方針に直結)
- maxplayers(最大人数)
身内サーバーなら、まずは 「実人数+2」くらいが扱いやすいです。
無駄に大きくすると、想定外の参加(招待ミスなど)のリスクが上がります。 - PvE寄せ(戦闘ストレスを減らす)
Rustは基本PvP前提ですが、身内サーバーなら「襲撃は相談」「初心者保護」など、運営ルールでPvE寄りに寄せるだけでも体験が変わります。
いきなり細かい“禁止設定”を盛るより、まずはルールで回して、必要になったら設定で固める方が失敗しにくいです。 - スリーパー(ログアウト中の扱い)
ログアウト中のキャラが残るかどうかは、身内でも揉めやすいポイントです。- 残る:Rustらしい緊張感がある
- 残らない:不在時に荒れにくい
どちらを選ぶか、最初に合意して説明文に書いておくと安心です。
RCON(管理の入口:port/passwordの決め方)
RCONは 遠隔からサーバーを管理するための入口です。設定ミスすると危険なので、ここだけは丁寧に。
- port:RCONが待ち受けるポート(TCP)
- password:管理用パスワード(必ず強力に)
- web:接続方式(推奨の設定が案内されています)
初心者の安全運用ポイント
- パスワードは 長く・推測されないものにする(短い英単語はNG)
- RCONは 必要な人だけが使う
- VPSや自宅運用なら、RCONポートは ファイアウォールで接続元を絞る(身内PCやVPNなど)
server.cfgで設定を分離して管理(再現性と保守性を上げる)
起動オプションを全部コマンドに詰め込むと、後から地獄になります。
コツは、「起動コマンドは固定」「中身はserver.cfgで管理」です。
- 起動コマンドに置く:
- identity
- 必須ポート類(server.port / queryport / rcon など)
- RCON情報
- server.cfgに置く:
- hostname / description
- maxplayers
- そのほか運営方針に関わる設定
server.cfg の置き場所(超重要)rust/server/<server.identity>/cfg/server.cfg
この場所に置くと、起動時に読み込まれます。
書き方のポイント
- server.cfg内では、
+や-を付けません - 基本は
設定名 値の形 - ここに書いた内容は、起動コマンドより優先されやすい設計です
最小の例(イメージ)
server.hostname "My Friends Server"
server.description "初心者OK / 身内\nワイプ:月1"
server.maxplayers 8
タグ・説明文・特殊文字の注意点(表示崩れ対策)
身内サーバーでも「見つけやすさ」「誤参加防止」のために、表示まわりは整える価値があります。
- タグ(server.tags)
サーバーブラウザで絞り込み検索される“ラベル”です。
ただしタグにはグループ(排他)があり、同じグループのタグを複数入れると検索や表示が不安定になることがあります。
例:ワイプ周期(weekly/monthlyなど)は どれか1つにする、など。 - 説明文の改行・記号
環境や表示欄によっては、改行や特殊文字が崩れることがあります。初心者はまず- 1〜2行
- 記号は「/」「・」中心
- 絵文字は本文に留める(表示名には最小限)
のように“安全運転”がおすすめです。
- 起動→接続の確認(最短チェック)
起動ログで「起動完了」の旨が出るまで待ち、Rust側で F1コンソールを開いてconnect <IP>:<server.port>
の形式で接続します。同じPCならlocalhostで試すと切り分けが速いです。
ネットワーク設定:ポート/ファイアウォール/ルーターで詰まらないために
Rustサーバーで「接続できない」「サーバー一覧に出ない」は、だいたい ポート(どれを開けるか) と ファイアウォール(どこで止まってるか) と 自宅回線(NAT/CGNAT) のどれかです。
ここは順番が大事なので、①ポート整理 → ②OSファイアウォール → ③ルーター(自宅のみ) の順に潰すと迷いません。
開けるポートの整理(ゲーム用/RCON用/queryport)
まず「何を、どのプロトコルで開けるか」を固定します。Rustは UDPが主役で、RCONだけTCPが混ざります。
まずは“よくある例”で覚える(迷ったらこのセット)
| 用途 | 設定名 | 例(定番) | プロトコル | 目的 |
|---|---|---|---|---|
| ゲーム接続 | server.port | 28015 | UDP | プレイヤーが接続する入口 |
| サーバー照会(一覧表示) | server.queryport | 28017 | UDP | サーバーブラウザ表示に必要 |
| 遠隔管理(RCON) | rcon.port | 28016 | TCP | 管理ツールから操作する入口 |
ポイントは2つだけです。
server.portとserver.queryportは どちらもUDPで、両方が必要(一覧に出すなら)server.portとserver.queryportは 同じ番号にできない(必ず別にする)
queryportの“落とし穴”(2023年以降ここで詰まりやすい)
Rustはアップデートにより、server.queryport が重要になりました。
これを開け忘れると、起動はしているのにサーバー一覧に出ない、が起きます。
server.queryportを明示しない場合、既定で
「server.portまたはrcon.portの大きい方 + 1」 になります
(例:28015と28016なら、queryportは28017になりやすい)
💡初心者は、起動オプションにこう書いて“固定”するとラクです。
+server.port 28015
+rcon.port 28016
+server.queryport 28017
「公開」か「非公開」かで、開け方が変わる
- サーバー一覧に表示したい:
server.portとserver.queryportを開ける(UDP) - “身内だけで、一覧に出したくない”:
server.port(UDP)は開ける(招待メンバーが接続するため)server.queryport(UDP)は 開けない/遮断 すると、見つかりにくくできます
※ただし「完全な招待制」を作るなら、別途ホワイトリスト等の仕組みが必要です
Windows Defender Firewallで許可する手順
Windowsで詰まるのは、だいたい 「受信(Inbound)」が閉じているケースです。
おすすめは “ポート指定で受信規則” を作る方法。分かりやすく、壊れにくいです。
手順(GUI:一番確実)
- スタートで 「Windows Defender ファイアウォール(詳細設定)」 を開く
- 左の 受信の規則 → 右の 新しい規則
- 規則の種類:ポート
- UDP を選び、特定のローカルポート に
28015,28017 - 接続を許可する
- 適用するプロファイル(通常は プライベート、必要ならパブリックも)を選ぶ
- 分かる名前で保存(例:Rust UDP 28015-28017)
次にRCONを使うなら、同じ要領で TCP 28016 も作ります。
- TCP:
28016(RCON用) - UDP:
28015(ゲーム用)、28017(query用)
“プログラム許可”も追加すると安定する(任意)
環境によっては、ポート規則だけでなく RustDedicated.exe を許可した方がトラブルが減ります。
- 受信の規則 → 新しい規則 → プログラム
RustDedicated.exe(サーバー実行ファイル)を指定 → 許可
よくある落とし穴(Windows)
- 自分のPCからは繋がるのに、外から繋がらない
→ Windowsファイアウォール“だけ”開いても、ルーター側(ポート開放)が必要(自宅運用) - 自分の家のWi-Fiから「グローバルIP:port」で繋がらない
→ ルーターが NATループバック非対応のことがあります(後述)。LAN内では ローカルIP で試すのが確実です
Linux(firewalld/ufw)で許可する手順
Linuxはディストリビューションで方式が分かれます。
Ubuntu系は ufw、RHEL/CentOS系は firewalld が多いです。
ufw(Ubuntu系)で開ける
まず状態確認:
sudo ufw status
必要ポートを許可(例:28015/UDP、28017/UDP、28016/TCP):
sudo ufw allow 28015/udp
sudo ufw allow 28017/udp
sudo ufw allow 28016/tcp
反映・再確認:
sudo ufw reload
sudo ufw status
💡IP制限(RCONは特におすすめ)
RCONを“全世界”に開けるのは危険なので、可能なら管理者のIPだけ許可します。
sudo ufw allow from <あなたの固定IP> to any port 28016 proto tcp
firewalld(RHEL/CentOS系)で開ける
使用ゾーン確認:
sudo firewall-cmd --get-active-zones
ポート許可(例:publicゾーン、永続設定):
sudo firewall-cmd --zone=public --add-port=28015/udp --permanent
sudo firewall-cmd --zone=public --add-port=28017/udp --permanent
sudo firewall-cmd --zone=public --add-port=28016/tcp --permanent
sudo firewall-cmd --reload
確認:
sudo firewall-cmd --zone=public --list-ports
“開いてるか”の確認(Linuxの現場テク)
オンラインのポートチェッカーは UDPが判定しづらいです。
Linux側では、まず「待ち受けできてるか」を確認すると切り分けが早いです。
ss -lunpt | grep -E '28015|28016|28017'
- ここに出てこない → サーバー起動オプションや起動失敗の問題
- 出ているのに外から繋がらない → ファイアウォール/ルーター/回線(CGNAT)の問題
自宅回線の壁:NAT・固定IP・DDNSをどう考える?
自宅PC運用(または自宅に置いたLinux機)で「外部公開」する場合、ここが最大の関門です。
結論から言うと、“自宅のインターネットの出方”によっては、どれだけ設定しても公開できません。
NATで起きること(最低限の理解)
- 家の中のPCは、だいたい 192.168.x.x などの“宅内IP”
- ルーターが、宅内IPをまとめて 外(インターネット) に出しています(NAT)
- だから外部から家に入れるには、ルーターに
「このポートに来た通信は、このPCへ転送する」(ポート開放/ポート転送)
を設定する必要があります
「ポート開放できない」代表例:CGNAT
最近はIPv4不足の影響で、ISPが CGNAT(キャリアグレードNAT) を使うことがあります。
この場合、あなたの家のルーターのさらに外側にもNATがあり、家庭側でポート開放しても外から届きません。
ざっくり判定方法
- ルーターの「WAN側IP」と、外部サイトで見える「あなたのIPv4」が一致しない
→ CGNATの可能性が高い
対処の方向性(現実的)
- ISPに グローバルIPv4(固定/動的)の提供が可能か確認する
- できない/高いなら、VPS/ゲームレンタルに移す(初心者が一番ラク)
- どうしても自宅に置きたいなら、VPNやトンネルを使う設計を検討(難易度は上がります)
固定IPがない場合:DDNSで“住所”を固定する
自宅回線はIPが変わることが多いので、毎回IPを配るのは面倒です。
そこで DDNS(Dynamic DNS) を使うと、IPが変わっても 同じドメイン名でアクセスできます。
ただし注意点があります。
- DDNSは「名前の固定」であって「ポート開放の代替」ではない
CGNATで外部から入れない問題は、DDNSでは解決しません - ルーターが NATループバック非対応だと、家のWi-Fiから自分のDDNS名に繋がらないことがあります
→ 家の中では ローカルIP で接続する/ルーターの機能を確認するのが安全
手順A:ゲーム用レンタル(テンプレ)で最短セットアップ
ゲーム用レンタル(テンプレ型)は、「申し込み=ほぼ構築完了」に近いのが強みです。
初心者は「最初に決める項目」を絞るほど、失敗しにくくなります。

申し込み前チェック(リージョン/課金単位/バックアップ/再インストール)
まずは“契約前に決めると戻りが少ないもの”から確認します。ここを飛ばすと、あとで面倒になりがちです。
チェックリスト(これだけでOK)
- リージョン(場所)
日本から遊ぶなら、なるべく近いリージョンを選ぶ(体感ラグが減ります)。 - 課金単位(時間課金 or 月額/長期割引)
- 週末だけ遊ぶ → 時間課金が合いやすい
- 毎日/長期で運用 → 長期割引(1ヶ月以上)が合いやすい
※「停止中も課金されるか」はサービスごとに違うので、必ず公式仕様を確認します。
- プラン(メモリ)
Rustは公式目安として空きメモリ12GBが挙げられます。レンタルの表記は“総メモリ”なので、初心者は 16GB以上を起点に考えると安定しやすいです。 - バックアップの有無と復元方法
- 自動バックアップ(世代数)
- 手動バックアップ(ボタン/ダウンロード)
- 復元(ワンクリックか、手順が必要か)
- 再インストールの仕様
“再インストール=初期化”になりやすいです。
ワールドや設定が消える条件を先に把握しておくと安心です。
失敗しやすい組み合わせ(避けるとラク)
- 「最安メモリ」+「長期運用」+「建築多め」
→ 途中から重くなって、プラン変更や引っ越しをしたくなりやすいです。
管理画面で作成→起動→初期設定(最小でOKな項目)
テンプレ型の良いところは、最初に触るべき設定が少ないことです。
初回は“遊べる状態にする”を優先して、細かい調整はあとで大丈夫です。
最小でOKな初期設定(優先順)
- サーバー名(hostname)
例:友達用Rust(練習)のように短く。 - 説明(description)
3行以内で十分です。- 身内のみ(招待制)
- ルール(PvE寄り/襲撃は相談 など)
- ワイプ方針(例:月1)
- 最大人数(maxplayers)
実人数+1〜2くらいが扱いやすいです。 - マップ関連(seed / worldsize / map)
初心者は 小さめ〜標準から。大きいほど負荷が上がります。 - RCON(管理用)
- 強いパスワードに変更(必須)
- 可能なら、管理者だけが触れるように運用ルールを決める
- “プライベート感”を上げる設定(できる範囲で)
サービス側に「公開/非公開」や「一覧表示」のような項目があれば、方針に合わせて設定します。- 一覧に出したくない:非公開/検索対象外があればON
- 一覧に出しても身内のみ:後述の参加制限(ホワイトリスト等)を検討
※テンプレ型はサービスにより項目名が違うため、表示される選択肢に合わせればOKです。
接続の基本(身内サーバーで一番ラク)
- サーバー一覧から探すより、IP:ポートを共有して直接接続の方が迷いにくいです。
- “誰かが入れない”ときの切り分けも早くなります。
アップデート/再起動/バックアップの運用ルール
身内サーバーが長続きするかどうかは、実はここで決まります。
難しいことは不要で、ルールを固定するだけで安定します。
おすすめ運用ルール(コピペで使えます)
- 更新前にバックアップ(最優先)
✅ アップデートや設定変更の前は、必ず1回バックアップ - 更新後は再起動
✅ 「更新 → 再起動」で反映が安定しやすい - 定期再起動(週1でOK)
✅ 長期稼働の小さな不調を減らしやすい - ワイプ方針を固定して共有
✅ 月1 / 2週間に1回など、最初に決めて説明文にも書く - 困ったときの“復旧手順”を決める
例:- いったん停止
- 直近バックアップに戻す
- 直らなければ再インストール(消える範囲を確認してから)
料金をムダにしない小ワザ
- 時間課金タイプなら、遊ばない日は停止で節約できることが多いです。
ただし、請求の考え方(停止中の扱い・上限など)はサービスで差があるので、公式の料金仕様だけは必ず見ておくと安心です。
手順B:VPSで手動構築(Linux例:安定運用まで)
ここでは「Ubuntu系(22.04/24.04想定)+SteamCMDで導入 → 起動スクリプト → systemd常駐」の流れで、初心者が“落ちにくい形”まで持っていきます。
(他ディストリでも大枠は同じで、パッケージ名やFWコマンドが変わるだけです)

OS初期設定(更新・ユーザー・SSH・権限)
最初にやることは「安全に運用できる土台づくり」です。Rust本体より、ここが雑だと事故ります。
1) OS更新と必須ツール
sudo apt update
sudo apt -y upgrade
sudo apt -y install wget tar screen ca-certificates
2) 専用ユーザーを作る(root直運用を避ける)
sudo adduser --disabled-password --gecos "" rust
3) サーバー設置先を作る(例:/opt/rust)
sudo mkdir -p /opt/rust
sudo chown rust:rust /opt/rust
4) SSHの基本(最低限)
- SSH鍵ログインを使う(可能なら)
- 可能なら rootログイン禁止・パスワードログイン禁止まで進める
※ここはVPSの初期設定ポリシーに合わせて無理なくでOK
SteamCMD導入→Rust導入→起動スクリプト作成
1) rustユーザーに切り替え
sudo -iu rust
cd /opt/rust
2) SteamCMDを配置してRustサーバーを取得(公式の基本形)
mkdir -p steamcmd server
cd steamcmd
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
tar xvfz steamcmd_linux.tar.gz
chmod +x steamcmd.sh
./steamcmd.sh +force_install_dir ../server +login anonymous +app_update 258550 validate +quit
よくある詰まりポイント:
No subscriptionが出る →+login anonymousを付け忘れの可能性が高いです。
3) 起動スクリプトを作る(“必須だけ”をコマンドに、細かい設定はserver.cfgへ)
/opt/rust/server/start.sh を作成します。
nano /opt/rust/server/start.sh
中身(コピペして、名前・パスワード・seedだけ変えればOK):
#!/usr/bin/env bash
set -euo pipefail
cd /opt/rust/server
mkdir -p /opt/rust/server/logs
exec ./RustDedicated -batchmode -nographics \
+server.identity "server1" \
+server.hostname "My Private Rust" \
+server.description "身内用 / 招待制\nルールは別途共有" \
+server.port 28015 \
+server.queryport 28017 \
+rcon.port 28016 \
+rcon.password "CHANGE_ME_LONG_PASSWORD" \
+rcon.web 1 \
+server.level "Procedural Map" \
+server.seed 12345 \
+server.worldsize 3500 \
+server.maxplayers 10 \
-logfile /opt/rust/server/logs/rust.log
権限付与:
chmod +x /opt/rust/server/start.sh
ここでのコツ
server.portとserver.queryportは 別番号にするserver.queryportは サーバー一覧表示に必要(固定しておくと切り分けが楽)- RCONパスワードは必ず強力に(短い英単語は危険)
4) server.cfgで“運営設定”を分離(更新しても管理しやすい)
Rustは rust/server/<identity>/cfg/server.cfg を起動時に読みます。
まずフォルダを作って(初回起動後に自動生成されることもあります)、設定を置きます。
mkdir -p /opt/rust/server/rust/server1/cfg
nano /opt/rust/server/rust/server1/cfg/server.cfg
例(最小):
server.maxplayers 10
server.hostname "My Private Rust"
server.description "身内用 / 招待制"
常駐化(systemd)と自動再起動
1) unitファイルを作成(rootで)
exit # rustユーザーから抜ける
sudo nano /etc/systemd/system/rust-server.service
中身(まずはこの形でOK):
[Unit]
Description=Rust Dedicated Server
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=rust
Group=rust
WorkingDirectory=/opt/rust/server
ExecStart=/opt/rust/server/start.sh
Restart=on-failure
RestartSec=10
# Rustはファイルディスクリプタを多く使うことがあるため余裕を持たせる
LimitNOFILE=100000
[Install]
WantedBy=multi-user.target
反映&自動起動:
sudo systemctl daemon-reload
sudo systemctl enable --now rust-server
sudo systemctl status rust-server --no-pager
2) “勝手に落ちる”を減らす運用小ワザ
- 自動再起動(上の
Restart=on-failure)で「落ちたまま」を防ぐ - 再起動が連発する場合は、まずログで原因確認(次章)
ログの見方(起動失敗・更新失敗の切り分け)
まず見る場所(これだけ覚えればOK)
- systemdの状態:
sudo systemctl status rust-server --no-pager
- 追いかけログ(リアルタイム):
sudo journalctl -u rust-server -f
- 追加でファイルログ(start.shで
-logfileを指定した場合):
tail -f /opt/rust/server/logs/rust.log
典型トラブルと“当たり”
- SteamCMDで取得できない
No subscription→+login anonymousの付け忘れが濃厚- ディスク不足 → 空き容量を確認(Rustは余裕が必要)
- 起動しているのにサーバー一覧に出ない
server.queryport未設定/未開放の可能性server.portとserver.queryportの UDP が外向きに通っているか確認
- 自分だけ繋がる/外から繋がらない
- VPS側FW(ufw/firewalld)やクラウド側セキュリティグループで落ちていることが多い
- 起動が遅いだけ
- 初回は数分かかることがあります。ログ内で起動完了のメッセージを待ってから判断
参考:更新手順(安定運用の型)
「更新で壊れた」を避けるなら、毎回この手順に固定すると強いです。
sudo systemctl stop rust-server
# (任意)バックアップ:identityフォルダを丸ごと退避
sudo -u rust tar czf /opt/rust/backup-server1-$(date +%F).tgz -C /opt/rust/server/rust server1
# 更新
sudo -iu rust bash -lc 'cd /opt/rust/steamcmd && ./steamcmd.sh +force_install_dir ../server +login anonymous +app_update 258550 validate +quit'
sudo systemctl start rust-server
sudo journalctl -u rust-server -n 50 --no-pager
手順C:Windows自宅PCでローカル運用(身内向け)
Windows自宅PCは、「まず身内だけで遊ぶ」→「いけそうなら外部公開(ポート開放)」の順にすると失敗しにくいです。
ここでは“ローカル運用”を主軸に、公開する場合の最低限もまとめます。
導入(zip展開/起動ファイル編集/初回起動)
Windowsでの導入は、実質つぎの2択です。
- 推奨:SteamCMDで入れる(更新が管理しやすい)
- 参考:Rust_server.zipの簡易導入(古い手順なので注意しながら使う)
方式1:SteamCMDで導入(推奨・いちばん無難)
フォルダ構成(例)
C:\steamcmd\(SteamCMD)C:\rustserver\(Rustサーバー本体)
手順
- SteamCMDを用意して起動(初回は自動で更新されます)
- SteamCMDの画面で、下を順に実行します
force_install_dir "C:\rustserver\"
login anonymous
app_update 258550 validate
quit
C:\rustserver\にRustDedicated.exeが入っていればOK
方式2:Rust_server.zipで導入(参考・“最短っぽい”が注意点あり)
Rust Wikiには「ローカルサーバー用のzip」が案内されていますが、2015年の手順で、記載どおりに自動更新しない等の注意が明記されています。
それでも試すなら、やることはシンプルです。
- zipを任意の場所に展開
Run_DS.bat(または同等のbat)を編集Run_DS.batを実行して起動
「更新も含めて安定運用したい」なら、最初からSteamCMD方式に寄せたほうが後悔が少ないです。
start.bat(起動ファイル)の作り方:初心者向けテンプレ
C:\rustserver\start.bat を作成して、次を貼り付けます。
(※CHANGE_ME と server1 と サーバー名 だけは必ず自分用に変えてください)
@echo off
set STEAMCMD=C:\steamcmd\steamcmd.exe
set SRVDIR=C:\rustserver
:update
%STEAMCMD% +login anonymous +force_install_dir "%SRVDIR%" +app_update 258550 validate +quit
:start
cd /d "%SRVDIR%"
RustDedicated.exe -batchmode -nographics ^
+server.identity "server1" ^
+server.hostname "My Private Rust" ^
+server.description "身内用 / 招待制" ^
+server.level "Procedural Map" ^
+server.seed 12345 ^
+server.worldsize 3500 ^
+server.maxplayers 8 ^
+server.port 28015 ^
+server.queryport 28017 ^
+rcon.port 28016 ^
+rcon.password "CHANGE_ME_LONG_PASSWORD" ^
+rcon.web 1 ^
-logfile "rustserverlog.txt"
goto update
ここだけ注意(つまずき防止)
server.identityは スペースや特殊文字なしがおすすめ(データ保存先の名前になります)server.port(ゲーム用)とserver.queryport(一覧/照会用)は 別の番号にする- 初回起動は数分かかることがあります。ログに 起動完了が出るまで待つ
公開するなら:ルーターのポート開放と注意点
「同じ家の中(LAN)だけ」で遊ぶなら、基本はポート開放なしでOKです。
家の外のフレンドも参加するなら、次の3点が必要になります。
1) ルーターでポート転送(ポート開放)
最低限はこの2つを“サーバーPCのローカルIP”へ転送します。
- UDP:
server.port(例:28015) - UDP:
server.queryport(例:28017)
RCONを外部から触る必要があるときだけ、TCPで rcon.port(例:28016)も検討しますが、むやみに公開しないほうが安全です(公開するなら接続元制限が理想)。
2) Windows Defender Firewallで許可
ルーターだけ開けても、PC側FWで止まることがあります。
最低限、上のUDPポートを「受信」で許可しておくと安心です。
3) 自宅回線の“できる/できない”問題
設定が合っていても、回線が CGNAT などだと外部公開できないことがあります。
その場合は、無理に粘るより
- VPSへ移す
- ゲーム用レンタルへ移す
のほうが、結果的に早く安定します。
フレンドの接続方法(F1コンソール/直打ち/お気に入り)
方法1:F1コンソールで直打ち(いちばん確実)
- Rustを起動
- サーバー一覧を探さず、F1 でコンソールを開く
- 次を入力(例)
- 同じPCで参加(ホスト自身の確認用)
client.connect localhost:28015
- 同じ家のフレンド(LAN内)
client.connect 192.168.0.10:28015
※192.168.0.10 はサーバーPCのローカルIP
- 家の外のフレンド(インターネット)
client.connect グローバルIP:28015
※グローバルIPが変わるならDDNSを使うと共有が楽です
「サーバー一覧に出ない」問題を回避できるので、身内運用ではこの方法が最強です。
方法2:お気に入りに入れてワンクリック化(Steam側で登録)
よく遊ぶなら、Steamのサーバービューアで登録しておくと便利です。
- Steam:表示(View)→ サーバー(Servers)→ Favorites → Add Server
- 入力するのは IP:queryport(ここがポイント)
server.queryport を明示していない場合は、サーバーが自動的に
「server.port か rcon.port の大きい方 + 1」を使う挙動があるため、最初から server.queryport を固定しておくと混乱が減ります。
「第三者を入れない」プライベート化:できること・できないことを先に理解
Rustの「プライベート化」は、ざっくり言うと次の 2つを別物として考えると迷いません。
- 参加者を制限する(第三者を“入れない”):入室の可否をサーバー側で判定する
- 露出を減らす(第三者に“見つけられにくくする”):サーバー一覧・外部サイト・配信などから情報が出ないようにする
そして最重要なのがこれです。
- できること:許可制(ホワイトリスト)で「入室を拒否」/露出対策で「見つかりにくく」する
- できないこと:IP/ポートが一度漏れたら“接続の試行”自体は止められない(=最終的には入室制限で弾く必要がある)
重要:標準機能だけで“パスワード保護”は前提にしない
結論から言うと、「パスワードをかければ万全」という発想は危険です。理由はシンプルで、
- Rustは標準で“強い許可制(ホワイトリスト)”が前提になっていないため、本気で第三者排除したいなら別の仕組みが必要になりやすい
- パスワードは、共有・流出・配信事故で一瞬で崩れます(「誰が漏らしたか」も追いにくい)
- さらに、パスワードがあっても サーバー情報の露出(一覧・外部サイト) とは別問題になりがち
なので考え方としては、
- 主役:許可制(ホワイトリスト)
- 脇役:隠し運用(露出低減)
- 補助:パスワード(使うとしても“追加の鍵”程度)
…この順番が一番事故りません。
入室制限の選択肢(おすすめ順)
まずは全体像を一気に掴めるように、比較表で整理します。
| 選択肢 | 第三者排除の強さ | 設定の難易度 | 向いているケース | 落とし穴 |
|---|---|---|---|---|
| ホワイトリスト(許可制) | ◎ | 中 | 身内固定、参加者が少ない | 導入(uMod)と更新運用が必要 |
| 隠し運用(露出低減) | △ | 低〜中 | 一覧に出したくない、荒らし回避 | IPが漏れたら試行はされる |
| maxplayers/skipqueueで管理者だけ | ○(条件付き) | 低 | “とりあえず誰も入れない状態”にしたい | 本格的な許可制ではない |
ホワイトリスト(uMod/Oxide)で許可制にする
「第三者を入れない」の目的に対して、一番まっすぐ効く方法です。
考え方はこうです。
- サーバー側で「許可された人だけ通す」
- 許可されていない人は、接続しようとしても 弾かれて入れない
最低限の流れ(やることは4つ)
- uMod(Oxide)を導入(プラグインを動かす土台)
- Whitelistプラグインを配置(例:
Whitelist.csを plugins フォルダへ) - サーバー再起動(またはプラグイン読み込み)
- 許可したい人に 権限を付与(Steam64IDで指定)
運用のコツ(初心者が詰まりにくいポイント)
- 参加者は Steam64IDで管理するとブレません(表示名は変わるので)
- 許可の付け忘れが多いので、最初は
- 「自分」
- 「テスト役のフレンド1人」
だけ登録して、入室できるか確認 → その後増やすのが安全です
- サーバー更新後はuMod側も追随が必要になることがあるので、更新の日は“入れない時間”が出る前提で予定を組むと平和です
補強アイデア(さらに事故率を下げる)
- “身内Discord”など、IP/ポート共有の場所を固定して、拡散しない
- バックアップ(ワールド/設定)は自動化しておく(戻せる=精神安定)
隠し運用:queryport遮断・非標準ポート・露出を減らす
これは「入室を拒否する」というより、そもそも見つけにくくするやり方です。
狙いは、サーバーブラウザや外部サイトが拾う情報を減らして、“野良の流入”を起こしにくくすること。
重要な前提
- Rustは server.queryport(照会用ポート) が開いていると、サーバー情報が照会されやすくなります
- 逆に、ここを塞げば「一覧に出る/外部が情報を取る」動きは抑えやすい一方で、IPとゲーム用ポート(server.port)が漏れていれば接続の試行は可能です
初心者向けの現実的なやり方
- 非標準ポートにする:デフォルトを避けて“雑なスキャン”に引っかかりにくくする
- queryportは“わざと分かりにくい番号”にして遮断:
例:queryportを高い番号に設定 → VPS/PCのファイアウォールでそのポート宛てを拒否 - 可能なら player listの露出を抑える設定も使う(スクレイピング対策)
ここでの注意点(地味に重要)
- queryportは、サーバー一覧表示に関わる挙動が変わった経緯があるため、
「server.portと同じにしない」「既定値が自動で決まる」 などのルールを理解してから触るのが安全です - “隠しているつもり”でも、配信・スクショ・ログの貼り付けでIPが出たら終わりなので、次の「情報漏えい対策」とセット運用が基本です
代替:管理者だけ入れる運用(maxplayers/skipqueue等の考え方)
これは「ホワイトリストが間に合わない」「一時的に完全封鎖したい」時の非常手段として便利です。
考え方
server.maxplayersを 0 にすると、通常のプレイヤーは入れなくなる- その代わり、管理者(admin) や skipqueue権限のあるユーザー は入れるようにする
使いどころ
- いったんサーバーを“封鎖状態”にして、設定を整えてから再開したい
- 配信事故などでIPが漏れた疑いがあり、とりあえず野良の侵入を止めたい
落とし穴(これを過信しない)
- これは“許可制”というより 「満員扱いで弾く」 近い運用です
- ちゃんとした身内運用に戻すなら、最終的には ホワイトリスト方式へ寄せた方が管理が楽です
情報漏えい対策(配信/Steamステータス/外部サイト)
プライベート運用が壊れる原因は、技術というより 情報の漏れがほとんどです。
ここはチェックリスト化しておくと強いです。✅
配信・録画での事故を防ぐ
- IP/ポートを画面に出さない(F1コンソールやサーバー一覧を映さない)
- どうしても接続操作が必要なら、“画面外で完結する接続”に寄せる
(例:キー1発で接続→画面には残さない、など)
Steamのステータス
- Steamの状態を 不可視(Invisible) にして、プロフィール経由で情報が追われるリスクを下げる
外部サイト・サーバー一覧
- queryportが開いていると、外部がサーバー情報を取りやすくなるため、
「一覧に出したい/出したくない」方針を決めて、ポートとFWを揃えるのが大事 - 「知らない人が接続を試みた」時点で、IPが漏れた前提で動く(対策:入室制限の強化、IP/ポートの変更検討)
運用で一番効くルール
- IP/ポートの共有は “身内の固定チャンネル”だけ
- 参加者が増えるほど漏れやすいので、人数が増えるなら ホワイトリストを必須化する
管理者設定:owner/mod権限とRCONを整えて運営をラクにする
権限の種類(owner/mod)と付与方法(users.cfg/RCON)
Rustの管理権限は、ざっくり 2段階です(身内運用だとこれで足ります)。
- owner(管理者):フル権限(AuthLevel 2相当)
- moderator(モデレーター):主に監視・対処向け(AuthLevel 1相当)
初心者向けの結論としては、こう考えると安全です。
- 自分:owner
- 手伝ってくれる友人:まずは moderator(必要になったらownerへ)
方法A:サーバーコンソール / RCONから付与(運用しながら追加できる)
- まず、対象ユーザーの SteamID64 を確認します。
代表的には、サーバーコンソールでusersを実行して、一覧から拾うのが確実です。 - 付与コマンド(どちらか)
- owner(管理者)にする
ownerid <SteamID64> "名前" - moderator(モデレーター)にする
moderatorid <SteamID64> "名前"
- owner(管理者)にする
- 付与後は再接続が必要なことが多いです。
「入ったのに権限が効かない…」は、だいたいこれが原因です。 - 取り消す場合(どちらか)
removeowner <SteamID64>removemoderator <SteamID64>
保存(重要)
最近は ownerid / moderatorid の反映が自動保存されるケースもありますが、環境によって挙動が揺れることがあります。
「確実に残したい」ときは、あとで紹介する server.writecfg(または writecfg)を実行しておくと安心です。
方法B:users.cfgを編集して付与(サーバー停止中に確実に反映)
サーバーを止められるなら、いちばんミスが少ない方法です。
- サーバー停止
users.cfgを開く- 目安:
rust/server/<server.identity>/cfg/users.cfg
- 目安:
- 1行ずつ追記(例)
ownerid 7656119XXXXXXXXXX "TomSmith" ""
moderatorid 7656119YYYYYYYYYY "Helper" "trusted friend"
- 保存してサーバー起動
ポイント
"名前"は分かりやすい表示用。空でも動くことがありますが、後で見返すなら入れておくと楽です。- 最後の
""はメモ欄として使えることがあります(環境により扱いが異なるので、用途は“控えめ”でOK)。
RCONでできること(運用で必須の操作に絞る)
RCONは、サーバーに「遠隔の管理コンソール」として接続する仕組みです。特にVPS運用だと必須級です。
RCONでできる“実用的なこと”
- プレイヤーの キック / バン / 解除
statusやusersで 接続状況・SteamID確認sayで 全体アナウンス(再起動告知など)save(またはserver.save)で 手動セーブserver.writecfgで 権限などの保存
RCONを安全に使うコツ(ここだけ守ると事故りにくい)
- パスワードは長く・推測不能にする(短い英単語は危険)
- 可能ならファイアウォールで 自分のIPだけ許可(外部に開けっぱなしにしない)
- Web版のRCONは便利ですが、サービスやツールによっては通信が安全でない場合があります。
使うなら「信頼できるツール」+「アクセス制限」をセットで考えるのが無難です。
最低限覚える管理コマンド(キック/バン/セーブ/ワイプ)
まずは“身内サーバーで本当に使うものだけ”に絞ります。
(※ サーバー側コマンドは、状況により サーバーコンソール/RCON専用だったり、ゲーム内F1で実行するなら sv を付ける必要があるものがあります)
よく使うコマンド早見表
| やりたいこと | コマンド例 | ひとこと |
|---|---|---|
| SteamID確認 | users / status | まずこれができると運営が一気に楽 |
| キック | kick <SteamID64> "理由" | 迷惑行為はまずキックでOK |
| バン | ban <SteamID64> "理由" | 確定でNGならban |
| 解除 | unban <SteamID64> | 誤BANの戻しに使う |
| 手動セーブ | save または server.save | 重要作業の前に1回やると安心 |
| 権限・一部設定の保存 | server.writecfg(or writecfg) | 主にusers.cfg系の保存で使うことが多い |
| 全体告知 | say "本文"(必要なら sv say) | 再起動前は告知が親切 |
ワイプ(wipe)の考え方:コマンドではなく「消して再生成」が基本
Rustの“ワイプ”は、ボタン1つの魔法というより 「保存データを消して、起動時に作り直させる」のが基本です。
なので最初にこれだけは徹底してください。
- ✅ 必ず停止してから作業
- ✅ バックアップを取ってから削除
- ✅ 何を消すかで意味が変わる(マップだけ / プレイヤーだけ / ブループリントだけ)
代表的なワイプの種類(身内運用での使い分け)
- マップワイプ(世界を作り直す)
建築や地形をリセットしたいとき向け - プレイヤーデータ系のワイプ(所持・状態の一部をリセット)
ルール変更で仕切り直したいとき向け - ブループリントワイプ(設計図をリセット)
“研究を最初から”にしたいとき向け(必要なときだけ)
ブループリントワイプの例(よくあるファイル名)
サーバーのidentityフォルダ内にある player.blueprints.*.db のようなファイルを削除して再起動、という形が一般的です。
(※ ファイル名や配置はホスティング/構成で変わるので、削除前にバックアップは必須)
カスタマイズ:サーバー方針を“楽しいルール”に落とし込む
PvE寄せ・初心者向け設定の考え方
「PvE寄せ」といっても、Rustは元々PvP前提のゲームなので、どこまで“安全”にするかを先に決めるほど失敗しにくいです。おすすめは、次の順で設計するやり方です。
1) まず「遊びの目的」を1行で決める(ブレ防止)
- 例:身内で建築と探索を楽しむ(対人ストレスは最小)
- 例:新規の練習用(撃ち合いはOK、レイドはNG)
- 例:平日はPvE、週末だけイベント的にPvP…など
2) “禁止したいこと”を先に列挙する(運用がラク)
- レイド(建物破壊)を禁止したい?
- チーム外のキルを禁止したい?
- 罠やタレットのキルはどうする?
- モニュメントだけPvPにする?(後述のZone系が便利)
3) 初心者救済は「ゲームモード」と「ダメージ制御」で作る
- 初心者におすすめの方向性:
- Softcoreでロストの痛みを減らす(完全なPvE化より挫折が少ない)
- PvE寄せは標準機能だけで“完璧”にしようとしない(ここが詰まりポイント)
- 必要ならTruePVE等の“ダメージ制御プラグイン”でガチガチに制限する
補足:PvE化でよくある勘違い(重要)
- 「パスワード付きで完全に入室制限」みたいな“標準機能だけの発想”だと、期待通りにならないことが多いです。
👉 入室制限(ホワイトリスト等)と、PvE/PvPのルール(ダメージ制御)は別物として設計するとスムーズです。
おすすめ構成(身内プライベートの“現実的最短”)
- ✅ まずは Softcore(初心者の脱落を防ぎやすい)
- ✅ PvE寄せは TruePVE(必要な範囲だけ“ダメージを止める”発想)
- ✅ モニュメントだけPvP等をやりたいなら Zone Manager(エリアごとにルールを切り替えやすい)
- ✅ 生活しやすさは、欲が出たら後から(採取量・精錬・初期キットなど)
ワイプ周期(練習用/長期用で最適が変わる)
ワイプは「やる/やらない」より、何を消すかといつ消すかで考えると、身内サーバーは揉めにくいです。
まず整理:ワイプは大きく2種類
- マップワイプ:建築・拠点・配置物・所持品などの“ワールド進行”がリセット
- BPワイプ:研究(ブループリント)の進行がリセット(サーバー方針で扱いが大きく変わる)
身内サーバーのおすすめパターン
| 目的 | マップ | BP | こうなる |
|---|---|---|---|
| 練習・短期イベント | 週1〜隔週 | 基本しない | 毎回フレッシュ、でも成長は残る🙂 |
| だらだら長期(拠点育成) | 月1 | しない | 建築が育つ。生活サーバー向き🏠 |
| “みんな同条件で最初から” | 月1(強め) | やる | スタートダッシュを楽しむ系🔥 |
「いつワイプするか」の決め方(迷ったらこの基準)
- 身内が 週末しか集まらない → 金土日に合わせる(体感が一番大事)
- 建築勢が多い → ワイプ間隔は長め(壊すより育てる楽しさ)
- PvP練習目的 → ワイプ間隔は短め(毎回動きが出る)
運用をラクにするコツ
- 事前に「次回ワイプは○日」と固定しておく(Discord固定メッセージ推奨)
- タグや説明文に「Weekly / Monthly」など“期待値”を揃える(参加者の認識ズレ防止)
MOD/プラグイン導入(何を入れると管理が楽になる?)
プラグインは入れ始めるとキリがないので、最初は“運営がラクになるもの”から入れるのが正解です。いきなり便利系を盛ると、アップデート時に壊れた時の切り分けが大変になります。
導入の基本方針(トラブルを減らす)
- ✅ 追加前にバックアップ(最低限)
- ✅ 1回に入れるのは1〜2個(問題が起きた時に原因を特定しやすい)
- ✅ Rust本体の更新に合わせて、プラグインも更新チェック
身内プライベートで“満足度が上がりやすい”定番セット
- 入室制限・プライベート性
- Whitelist系:許可した人だけ入れる(身内サーバーの安心感が段違い)
- PvE寄せ・ルール制御(ここが本丸)
- TruePVE:対人/建物/特定条件のダメージを制御して“方針通りのRust”に寄せる
- Zone Manager:エリアごとに「ここはPvP」「ここは安全」みたいな運用がしやすい
例:拠点周りは安全、モニュメントはPvP、など
- 生活系QoL(やりすぎ注意だけど満足度は高い)
- Gather Manager:採取量を調整(“社会人サーバー”の救済になりやすい)
- Furnace Splitter / Quick Smelt:精錬の手間や時間を軽くしてテンポを上げる
- Kits:新規参加者に最低限の装備を配る(参加ハードルを下げる)
“入れない方がいい”考え方(揉め防止)
- 競争が目的でないのに、強すぎる経済・報酬・課金要素を入れる
- ルールが複雑になりすぎて「結局なにがOK?」となる構成
👉 身内ほど、シンプルな方が続きます。便利系は“必要になってから”でOKです。
よくあるトラブル集:検索されやすい詰まりどころを先回り
まず最短で切り分けるために、「症状→最初に見る場所」だけ先にまとめます。
| 症状 | まずやること(最短) |
|---|---|
| 一覧に出ない/見つからない | 直打ち接続(F1)で入れるか → 入れるなら“一覧側(queryport/フィルタ)”が原因 |
| 接続できない | ホスト本人がlocalhost/LANで入れるか → 入れるなら“外部公開(FW/ルーター/NAT)”が原因 |
| 重い/カクつく | RAM不足(スワップ)とマップ/建築量を疑う → まずワールドサイズとプラグインを見直す |
| 更新後に起動しない | validate → それでもダメなら“Mod側(uMod/プラグイン)”を一旦外して起動確認 |
サーバー一覧に出ない/見つからない(フィルタ・設定・Ping)
「起動してるのに一覧にいない」は、原因がだいたい次の3つに分かれます。
- (1) そもそも“表示の場所”が違う(フィルタ問題)
- (2) queryport(照会用ポート)が通っていない
- (3) Ping/リージョン/反映待ちで見えづらい
まずはフィルタを疑う(意外とここが最多)
- タブがズレていないか(Official / Community / Modded)
- 検索欄に余計な文字が入っていないか
- Ping上限や「空きあり」などのフィルタが強すぎないか
- サーバー名が長いと探しづらいので、最初は短めのhostnameにするのも有効です
“直打ちで入れるか”で一気に切り分ける
一覧がダメでも、直打ちで入れればサーバー自体は生きていることが確定します。
- Rustで F1 → コンソール
- 次を入力(例)
client.connect グローバルIP:server.portclient.connect LANのIP:server.port
入れた場合は「一覧に出すための条件(queryportや照会)」側が怪しいです。
queryportが開いていないと“一覧に出ない”が起きやすい
Rustは ゲーム接続用(server.port)とは別に、照会用(server.queryport)が必要になる構成が一般的です。
- 一覧に載せたいなら、基本は
server.port(UDP)server.queryport(UDP)
の両方が外から到達できる必要があります
server.queryportを明示しない場合、想定外の番号に自動設定されることがあるので、初心者は明示して固定が安全です
例:server.port 28015 / queryport 28017 / rcon 28016
Steamのお気に入り登録は“queryport”を使うことがある
Steamの「Servers → Favorites」で登録するとき、入力すべきポートが server.portではなくqueryport になるケースがあります。
「お気に入りからだと反応なし」なら、IP:queryport を疑ってください。
反映待ち・Ping問題もある
- 起動直後は、一覧反映まで数分かかることがあります(特に再起動直後)
- 日本から遠いリージョンだとPingで埋もれやすいので、まずは近いリージョンを選ぶのが無難です
接続できない(ポート/Firewall/NAT/回線)
ここは「誰が・どこから」繋がらないかで答えが変わります。最短でいきましょう。
最速チェック(順番が重要)
- サーバーが起動しているか
- サーバーコンソール/ログにエラーが出ていないか
- VPSなら
systemctl status、Windowsならログファイルが伸びているか
- ホスト本人が入れるか(同じPC/同じLAN)
- ホストPC:
client.connect localhost:28015 - 同じ家の別PC:
client.connect 192.168.x.x:28015
→ これで入れるなら、サーバー本体はOK。次は外向きが問題です。
- ホストPC:
- ポート番号がズレていないか
- 起動オプション(またはserver.cfg)で指定した
server.port / server.queryport / rcon.port
と、開放したポートが一致しているかを確認
- 起動オプション(またはserver.cfg)で指定した
- OSファイアウォールが止めていないか
- Windows Defender Firewall:受信(Inbound)でUDPを許可
- Linux:ufw/firewalldに加えて、クラウド側のセキュリティグループも確認
- 自宅回線ならルーター(ポート転送)が必要
- ルーターで「UDP server.port」「UDP queryport」をサーバーPCに転送
- サーバーPCのローカルIPは、DHCP予約などで固定すると事故が減ります
“家の中からグローバルIPで繋げない”は故障じゃないことがある
ルーターが NATループバック非対応だと、家のWi-Fiから自分のグローバルIPへ接続できない場合があります。
この場合は、家の中では LANのIP で試してください(外のフレンドは繋がることもあります)。
どうしても外から繋がらないときはCGNATを疑う
設定が完璧でも、回線が CGNAT だと外部公開が難しいことがあります。
この場合は、現実解として
- VPSへ移行
- ゲーム用レンタルへ移行
が、時間を最も節約できます。
重い・カクつく(メモリ不足/建築量/プラグイン増えすぎ)
体感のカクつきは「クライアントPC」原因もありますが、身内サーバーだとサーバー側(RAM/CPU/IO)が主因になりやすいです。
まず疑うべき順番(初心者向け)
- メモリ不足(スワップ発生)
- VPSなら
free -hで空きが少なく、swapが増えていると一気に重くなります - Windowsでもメモリ逼迫は顕著に体感に出ます
- VPSなら
- ワールドサイズが大きすぎる
worldsizeを大きくすると、基本的に負荷は上がります
身内なら“標準〜やや小さめ”の方が安定しやすいです
- 建築量・エンティティ量の増加
- 拠点が巨大化すると後半ほど重くなりがちです
- 長期運用は「月1の軽いリセット」や「拠点ルール」で安定します
- プラグイン(Mod)が増えすぎ
- プラグインは“1個ずつ追加”が鉄則
- 不調が出たら、直近追加したものから外して原因を特定します
体感改善に効きやすい対処(優先度順)
- プラン(RAM/CPU)を上げる(レンタル/VPSなら最短の解決策)
- worldsizeを下げる(次のワイプで反映)
- 定期再起動(週1など)で長期稼働の不調を減らす
- プラグインを整理(“便利系”を盛りすぎない)
アップデート後に起動しない(整合性/更新手順/依存の更新)
更新後トラブルは、ほとんどが「更新手順」と「Modの追随」で説明できます。
まずは“validate”で整合性を取る
SteamCMD運用なら、まずはこれが最優先です。
- サーバー停止
app_update 258550 validate- 起動
ディスク不足や権限問題でも失敗するので、ログにエラーがあれば先に潰します。
Mod導入(uMod/Oxide)を使っているなら“切り分け”が必須
更新直後に起動しないとき、原因が
- Rust本体
- uMod本体
- プラグイン
のどれなのかを切り分けないと沼ります。
おすすめの切り分け順:
- プラグインだけ一時退避(pluginsフォルダを別名に)
- ダメなら uMod自体を一旦外して“バニラ起動”確認
- バニラで起動するなら、uMod/プラグイン側の更新待ち・更新が必要
“起動はするけど見えない”なら更新後のポート再確認も
アップデートを機に設定が変わって、queryportが通っていないなどで「動いてるのに見えない」が起きることがあります。
この場合は、起動ログ上は問題が出ないこともあるので、一覧に出ない系のチェックへ戻るのが早いです。
FAQ
何人まで快適に遊べる?
結論、「人数」だけで決まりません。Rustは マップサイズ(worldsize)・建築量(エンティティ)・プラグイン数で重さが変わり、同じ10人でも快適さが全然違います。
ただ、初心者が迷わないように “ざっくりの目安”を置くとこんな感じです。
| 目安の遊び方 | 想定人数 | マップ/ルールの目安 | 推奨の考え方(ざっくり) |
|---|---|---|---|
| 身内で練習・小さめ拠点 | 2〜6人 | worldsize小〜中 / プラグイン少 | まず安定重視。重くなりにくい設計にする |
| 友達グループで定期的に遊ぶ | 6〜12人 | worldsize中 / 建築増えがち | 最初は余裕ある構成に(後半ほど重くなりやすい) |
| “ほぼ公開”に近い運用 | 12人以上 | worldsize中〜大 / 管理が増える | サーバー側の性能・監視・運用ルールが必須 |
失敗しないコツ(初心者向け)
- まずは “想定人数の7〜8割”で快適になる設定にする(例:10人集まるなら、最初は8人基準で設計)
- worldsizeは控えめから始める(「広い=楽しい」は成立しやすいけど「広い=軽い」は成立しません)
- プラグインは「便利だから」と増やしすぎない(1〜2個ずつ追加が安全)
- Facepunch公式の目安として、サーバー作成ガイドでは 空きメモリ12GBが要件として挙げられています。身内運用でも、余裕を見て設計すると後半が楽です
友達にIPを知られたくない場合は?
ここは最初にハッキリさせると、期待違いが起きません。
- 原則:接続する以上、IP:ポートを完全に隠すのは難しいです
(相手が本気で調べれば、接続情報を把握できる可能性があります)
そのうえで、「目的」を分けると現実的に対処できます。
目的A:自宅回線(自分の家のIP)を知られたくない
→ これが一番多いです。解決策はシンプル。
- 自宅でホストしない(VPS / ゲーム用レンタルに寄せる)
→ 友達に知られるのは“サーバーのIP”で、あなたの自宅IPではなくなります ✅
目的B:サーバーの接続先そのものをできるだけ拡散させたくない
→ “完全に隠す”ではなく“漏れにくくする”発想が現実的です。
- ホワイトリスト(許可制)にする(入れない人は弾く)
- サーバー一覧に出さない(露出を減らす:queryportの扱い・タグ・表示方針)
- 共有は 固定チャンネル(Discord等)に限定、スクショ/配信でIPを映さない
目的C:どうしても“仲間内だけの閉域”にしたい
- Tailscale / ZeroTier 等のVPN(仮想LAN)で、閉域IPで遊ぶ方法があります
ただし、全員に導入が必要で、Rust側の運用も少し上級者向けです(手間は増えます)。
PC版とConsole版で“できること”は違う?
違います。特に「自前で構築できる範囲」と「MOD/プラグイン」が大きく異なります。
PC版(Steam)
- VPSや自宅PCで Dedicated Serverを自分で構築できる
- RCONや設定ファイルで細かい調整ができる
- uMod/Oxideなどで プラグイン運用(ホワイトリスト等)がしやすい
→ ただし、更新頻度が高いので“運用の手間”は増えます
Console版(Rust Console Edition)
- “自宅PCにサーバーを立てる”より、基本は 公式が案内するサーバーホスティング(提携サービス)で管理する形になりやすいです
- Community Serversとして、公開・非公開(プライベート)を含むサーバー運用が可能で、ホワイトリストのような仕組みも用意されています(提供範囲はサービス/仕様に依存)
ざっくり結論
- 自由度と拡張性は PC版が上
- 手軽さ(ホスティング前提の運用)は Console版が取り組みやすい
身内サーバーを公開サーバーに切り替えられる?
できます。ただし、公開にする瞬間から「技術」より「運用」が重要になります。やることは次の順が安全です。
PC版での切り替え手順(失敗しにくい流れ)
- 入室制限の方針を決める
- 完全公開:ホワイトリストを解除
- 準公開:Discord参加者だけ許可、など
- 一覧に出す/出さないを決める
- 一覧に出すなら、queryportを明示し、必要なUDPポートが外部から到達できる状態にする
- 説明文とルールを“短く明文化”
- ワイプ周期 / PvP可否 / レイド可否 / 禁止事項 / 連絡先(Discord)
- 最低限の管理体制を作る
- owner/modの分担
- バックアップ
- 通報/荒らし対応(キック・バン)
- 負荷対策
- 公開すると想定より人が増えやすいので、worldsize・最大人数・プラグインを現実的に見直す
Console版での切り替え
- ホスティング管理画面で private → public のように切り替えられる場合があります(サービス仕様に依存)。
公開にした瞬間に、荒らし対策・ルール掲示・管理者対応が必要になる点はPC版と同じです。
一次情報:公式・定番ドキュメント
Facepunch公式:サーバー作成/非公開・ホワイトリスト運用
Rustのサーバー運用で「迷ったらここに戻る」枠が、Facepunch公式Wikiです。特に “公式が想定している正攻法”(起動の考え方・ポート・表示・非公開運用の思想)がまとまっています。
まず読むべきページ(優先順)
- サーバー作成の全体像
SteamCMDでの導入、起動オプション、基本ポートなど「最低限の土台」を固める用途。 - 非公開・発見されにくい運用の考え方
「一覧に出さない」「露出を減らす」「DoS対策の考え方」など、“完全に隠す”ではなく“リスクを下げる”方向の一次情報。
ここだけ押さえるチェックリスト(初心者向け)
- “動く状態”の定義を合わせる
- 起動できる(サーバーが立っている)
- 接続できる(自分/友達が入れる)
- 一覧に出る(見つかる)
この3つは別問題なので、公式Wikiで整理してから作業すると詰まりにくいです。 - 非公開運用は「設定の工夫」だけでなく、露出(発見経路)を減らす発想が重要
→ “パスワードで完全防御”のような前提に寄せるより、公式が説明している考え方に乗る方が現実的です。
読み方のコツ
- まずはページ冒頭の「前提」「目的」を読む(手順だけ追うと誤解しやすい)
- その後に、あなたの方式(レンタル / VPS / 自宅PC)に合わせて
- 起動
- ポート
- 公開/非公開
の章だけ拾い読みするのが効率的です
SteamCMD(導入・更新の一次情報)
SteamCMDは「Rustサーバーは結局ここで入れる/更新する」という土台です。
特に、アップデート後に起動しない系のトラブルは、手順の根拠がSteamCMD側にあることが多いので、一次情報を押さえる価値が高いです。
一次情報として見るべき2点
- SteamCMD自体の公式説明(導入・基本コマンド)
OS別の導入、ログイン、インストール先の指定などの“原理原則”。 - Rust Dedicated Serverのページ(Rust用の具体例)
RustサーバーのApp IDや、更新・検証(validate)などが明確に書かれています。
初心者が詰まりやすいポイント(先回り)
- 「どこに入れたか」を曖昧にすると、更新対象がズレます
→force_install_dir(インストール先)を固定するのが基本 - 更新後トラブルは、まず validate(整合性チェック)を“公式手順として”試す
→ 変に自己流の対処を積むより、再現性が出ます
最低限の“公式どおり”の更新イメージ
login anonymous
force_install_dir <インストール先>
app_update 258550 validate
quit
※この手順自体は「SteamCMDの使い方」+「Rust Dedicated Serverの一次情報」を合わせたものです。
uMod/Oxide(Whitelist等のプラグイン)
「身内だけで遊びたい」「ホワイトリストで許可制にしたい」を“仕組みとして”作るなら、uMod(旧Oxide)系が定番です。
ただし、プラグイン運用は便利な反面、アップデート追随・依存関係・権限で詰まりやすいので、一次情報の読み順が重要です。
最短で迷わない読み順
- uModのRustページ(入手先)
Windows/Linuxで配布が分かれているので、まずここで自分の環境に合うものを確認。 - プラグイン導入の公式ドキュメント
「どこに置くか」「何をしてはいけないか(例:リネームしない)」など、初歩の事故を防げます。 - Whitelistプラグイン本体ページ
何ができるか、必要な権限(permission)が何かを一次情報で確認できます。
ホワイトリスト運用で“最低限”知っておくこと
- ホワイトリストは「プラグインを入れれば終わり」ではなく、権限(permission)を正しく付与して初めて動くタイプです
- まずは
- “Oxide/uModが正しく入っているか”
- “プラグインがロードされているか”
- “permission付与が反映しているか”
の順で確認すると、切り分けが爆速になります
運用ルール(トラブル予防)
- プラグインは最初から盛らず、1〜2個ずつ追加(原因特定が簡単)
- Rust本体更新後に不調が出たら、いったん プラグインを退避してバニラ起動確認
→ “本体かModか”の切り分けが最優先です
まとめ
Rustのプライベートサーバーは、結局のところ「何を優先したいか」で最適解が変わります。
- 最短で遊びたい → ゲーム用レンタル(テンプレ型)がラク
- 自由度とコスパを両立したい → VPSで手動構築(SteamCMD+常駐化)
- まずは身内で試したい → 自宅PCでローカル運用(公開するなら設定追加)
また、身内サーバーを快適に続けるコツは「立て方」よりも、次の3点を押さえることです。
- 接続の基本を固定する
一覧に出ない問題を避けるため、最初はIP:portの直打ち(F1)を基準にする - “第三者を入れない”は許可制で作る
標準機能のパスワードだけに頼らず、必要ならホワイトリスト(uMod/Oxide)で確実に制限する
露出を減らす(queryportや表示方針)考え方もセットで - 運用ルールを決めてラクにする
更新前バックアップ、再起動、ワイプ周期、管理者権限とRCON——
最初に型を作るほど、トラブルと手間が減る
もし途中で「一覧に出ない」「接続できない」「重い」「更新後に起動しない」といった問題が起きても、焦らなくて大丈夫です。
本記事で紹介したように “直打ちで入れるか”→“ポートとFW”→“NAT/回線”の順に切り分ければ、原因はかなりの確率で絞れます。
身内サーバーは、Rustをいちばん楽しくする近道です。
練習にも、建築にも、PvE寄せにも、イベントにも自由に使えます。
まずはあなたの条件(人数・期間・手間・非公開度)に合わせて、最適なルートを選び、今日から1つずつ整えていきましょう。

