さくらのVPSのローカルネットワーク｜3台の配置で変わる接続条件

Webサーバーを2台にして、DBは別の1台にまとめたい。せっかく分けるなら、置き場所も離したほうが安心……と考えたくなります。

ただ、さくらのVPSの標準ローカルネットワークは同一ゾーン内の接続です。WebとDBを閉域でつなぐことと、ゾーンを分けて置くことは、そのまま両立する前提にしないほうがいい。自分なら台数を決める前に、「どのサーバーから、どの相手へ通信したいか」を2本の線にします。

この記事ではWeb1・Web2・DBの3台を例に、必要な通信が残る配置、設定の受け持ち、つながらないときの調べ方まで整理します。実機で構成した体験談ではなく、公式条件に照らした構成案です。

閉域でつなぎたいなら、リージョン名だけで決めない

同一ゾーンでWebとDBを接続する構成なら、標準ローカルネットワークが候補になります。公式マニュアルには、同一ゾーンが対象で、スイッチ接続後もOS側のプライベートIP設定が必要とあります（2026-10-23確認）。接続条件と設定項目を公式資料で確認しており、実機の通信は試していません。

「同じ東京ならつながるだろう」と、リージョン名だけで構成を決めないこと。比較する単位はマニュアルに書かれたゾーンです。申し込みや現在の契約の表示で、各サーバーのゾーンを一つずつ照合します。

ここで決めたいのは、サーバーの性能ではなく通信経路です。WebからDBへつなぐたびに標準のローカルネットワークを使いたいのか、それとも置き場所の分散を優先して別の接続方式を検討するのか。料金だけ見て3台を選んでから、この分岐へ戻るのはつらいです。

Web2台とDB1台なら、必要な線はまず2本

Web1→DBとWeb2→DBの2本を必須とする場合、3台を同じゾーンに置けば両方が同一ゾーンの条件を満たします。Web同士の直接通信は、この例では必須にしていません。

A・B・Cは説明用の異なるゾーン名です。実在する提供ゾーン一覧ではありません。「条件を満たす」は同一ゾーンという前提だけの判定で、接続成功を意味しません。

CodexがPythonで必須の2組だけを列挙し、始点と終点のゾーン名が一致する本数を数えました。入力は表の配置、判定式は「Webのゾーン＝DBのゾーン」です。公式マニュアルの同一ゾーン条件を使っています（確認日2026-10-23）。

発見は「3台なら何組つなげるか」ではありません。DBを別ゾーンへ移すと、必要な2本がまとめて条件外になることです。一方、Web2だけ移すとWeb1の経路は残り、Web2の経路だけ考え直すことになります。どちらも「3台を分散する」構成ですが、困る箇所が違います。

Web1とWeb2の間でデータ同期などが必要なアプリなら、その線も追加して判定します。逆に、その通信を使わない構成でWeb同士の組まで数えても、導入判断は進みません。まずアプリが必要とする線を描く。この順番が役に立ちます。

スイッチをつないだ後にも、OSとアプリの設定が残る

同一ゾーンの条件を満たしていても、管理画面の操作だけで作業を完了にしません。設定を次のように分けると、誰が何を確認するかが見えます。

最初の2行は公式の接続手順に対応し、後半はアプリ構成に合わせて決める設計項目です。どのDB製品にも通用する設定値や、実行済みの手順を示した表ではありません。

スイッチの公式手順は追加・削除を扱っています（2026-10-23確認）。スイッチの追加・削除の条件を確認したもので、稼働中の構成を変更して確かめた記録ではありません。

自分ならこの表を、そのまま引き継ぎのメモにします。「接続済み」とだけ書くと、管理画面まで済んだのか、アプリからデータを読めるところまで済んだのかが伝わりません。「スイッチ接続済み、OS設定は未着手」のように、止まっている場所が分かる書き方にします。

DBの接続先を変えるときも、旧設定を控えてから対象を一つずつ確認する構成案です。DBの種類やOSが未確定のまま、よく分からないコマンドをまとめて流す方法は選びません。

「閉域だから大丈夫」で、通信許可の設定を飛ばさない

利用するNICとIPの種類によって、管理画面のパケットフィルターが受け持つ範囲は変わります。公式パケットフィルター資料ではNIC1のIPv4が対象で、NIC1をローカル接続へ変えても設定が反映され、OSのファイアウォールと重複する可能性が示されています（2026-10-23確認）。パケットフィルターの対象範囲を確認しており、個別アプリの許可設定や安全性は検証していません。

ここは二つに分けて考えたいところです。つながらないからといって、何でも許可する設定へ変えない。一方で、NIC1以外にも管理画面の同じ保護が効く、とも思い込まない。実際に使う経路と、設定の担当範囲を対応させます。

たとえばWeb1はDBへ接続でき、Web2だけ接続できないとします。配置表の2行目なら、先に疑うべきはWeb2が別ゾーンになっている点です。両方が同じゾーンなら、次にWeb2のOS設定、アプリの接続先、許可する送信元の指定などを見比べる候補が出ます。これは原因を断定した診断結果ではなく、確認を進める順番です。

管理画面の設定とOSの設定を別々の人が触るなら、片方を直したことをもう片方へ伝える必要があります。閉域であることは、設定の責任を一つにまとめてくれません。

つながらないときは、配置からアプリへ順に戻る

接続に失敗したら、まず「本来使いたい経路」を見直します。次の流れは実測済みの復旧手順ではなく、設定確認のための案です。

1. 必須の線が同一ゾーン内かを確認する。条件外なら、IP設定の変更より先に配置か接続方式を考え直す。
2. 対象サーバーのNICと接続先スイッチを照合する。似たサーバー名や古い構成図との取り違えがないかを見る。
3. OSのローカル側設定と、予定したIPアドレスを照合する。具体的な操作は利用中のOSの手順に合わせる。
4. アプリが参照する接続先と、DB側の受け付け方を確認する。名前で指定している場合は、想定する相手を指しているかも確認する。
5. 経路に関係する通信許可を確認する。設定を変えたら、一度に全部変えず、変更点と結果を残す。

ネットワークの確認ができても、アプリの接続先や認証が合わなければ目的の処理は終わりません。最終確認は「何か応答した」ではなく、そのWebアプリが必要なDB処理を行えるかに置きます。読み取り・書き込みなど、何を試すかはアプリごとに決めてください。

戻し方も先に用意します。スイッチを削除して作り直す前に、接続先やアプリ設定の変更を戻せないかを確認します。公式手順上、接続中のスイッチは削除できません。切断そのものが他の通信へ影響しないかを見ずに進める作業ではありません。

Webを2台にしても、DBが止まる問題は残る

この例のDBは1台です。Webを2台に分けても、DBを使う処理の再開方法まで自動で用意されたわけではありません。

表で確認したのは配置と接続条件だけ。別ホストへの配置、障害の影響範囲、可用性の保証を判定した表ではありません。場所を離す目的があるなら、その目的に必要な接続方式、データの持ち方、切り替える担当まで別途検討します。

自分がこの構成を選ぶなら、目的はまず「WebとDBの役割を分けて管理したい」に置きます。「止めたくない」が最優先なら、台数の表だけで契約を決めず、止まった相手をどう置き換えるかまで確認します。役割分担と停止への備えを、一つの言葉にしないことです。

新しいサーバーを足す前に、希望する場所の受付を確かめる

2026-10-23に確認した公式の受付告知では、同日15:30から石狩リージョンのみ新規申し込みを再開し、東京・大阪は停止継続とされています。受付状況は更新されるため、必要なゾーンを申し込めるかは契約時に確かめてください。

既存サーバーと同じゾーンへ足す計画なら、「どこかで1台借りられる」だけでは条件を満たせません。構成図の空欄へ希望のサーバーを置けるかを先に確認します。

標準ローカルネットワークで必要な相手がつながる配置を選び、設定の受け持ちまで書いておく。3台という台数より、その2枚のメモが契約後の自分を助けてくれます。