XServer VPSでポート開放してもつながらない｜3つの確認先と送信元の絞り方

パネルでポートを開けたのに、アプリが外から見えない。だからフィルターを全部OFFにする……その前に、確認したい場所があります。

XServer VPSのパケットフィルターは、通信を通すかを決める一つの層です。OS内のファイアウォールやアプリの待受まで、自動でそろえてくれる設定ではありません。公開する番号と、誰からの接続を通すかを決めたうえで、どこで止まるかを絞っていきます。

公開先と管理用の入口を分ける

Webを公開する場合でも、管理用のSSHまで同じ範囲に公開する必要があるとは限りません。必要なサービス、プロトコル、ポート、接続元を一組で書き出してから許可ルールを作ります。

XServer VPSは、パケットフィルターをONにして許可ルールを追加する方式です。OFFは全ポートへの通信を許可する状態で、セキュリティ対策を自分で行う必要があります。OS内のファイアウォールと動作が重複する可能性も、公式が案内しています。パケットフィルターの説明（2026-10-25確認）。

手動のルールではプロトコル、ポート番号、許可する送信元IPを指定できます。番号は1〜65535、ルールは最大20件です。これは実際のアプリを公開する際の上限確認であり、20件までなら安全という基準ではありません。

許可・OS・待受の3条件を並べる

パネルの許可、OSの許可、アプリの待受がそろう場合にだけ、外からの接続が成立する候補になります。DNSや経路が正常で、同じ宛先・プロトコル・接続元を確認する前提で、3条件の組合せを並べました。

Pythonで3つの真偽値を全列挙し、AND条件で8通りを計算しました。パネルだけを「あり」に変えても、残りがそろわなければ通りません。これが、全公開にしても直らないことがある理由です。

二層の設定に関する公式注意と接続前の準備を2026-10-25に照合した説明用モデルです。通信試験の成功率や、実測データではありません。最後の行でも、経路・DNS・接続先の違いなど、別の原因が残ることがあります。

フィルターの設定例は公開範囲の考え方を比べたもので、アプリの動作や安全性を実機で検証したものではありません。

ポート番号だけでなく、待っている場所を見る

たとえばアプリを3000番で動かす想定なら、パネルで3000番を許可しただけでは足りません。そのアプリが実際に動いているか、設定した番号で待っているか、どのネットワーク上で待っているかまで見ます。3000番は説明用の値で、XServer VPSが指定する共通の番号ではありません。

コンテナを使う場合も、コンテナ内部の番号と、VPS側へ公開した番号を区別します。ファイルを置けた、コンテナが起動した、外から画面を開けた。この三つは別の確認です。ファイル転送・アプリの起動・外からの接続は、それぞれ別の確認です。

対象アプリをどの名前・IP・ポートで開く予定なのか、最初に一行にしておくと、確認する相手が変わりません。「別のアドレスにはつながった」だけで完了にしないための、地味ですが使いやすいメモです。

SSHまで切れたときは、広げる前に戻す場所を決める

公式のSSH接続方法では、パケットフィルターONとSSHルール追加、接続先IPの確認を事前準備にしています（2026-10-25確認）。標準ポートは22で、変更した場合は変更後の番号を使います。

OSやアプリイメージで設定が違うことがあるため、手元の契約と待ち受けポートを先に確認してください。

送信元を限定している場合は、今作業している回線の出口が変わっていないかも見ます。外出先やVPN経由へ切り替えたのに、以前の接続元だけを許可していれば、同じパソコンでも条件が変わります。これは送信元指定の意味から考えた確認案です。

作業中の接続と、管理画面へ入る手段を残し、元のルールを控えてから変更します。何を許可したか分からなくなったら、ルールを次々足す前に、対象のサービスと接続元へ戻ります。

全公開を解決策にしない

OS内の設定、待受、プロトコルを判断できない人には、VPSのポート設計を自分で保守する運用は負担になります。アプリを置く目的だけなら、管理する範囲が小さい環境を検討する価値があります。

自分で続ける場合は、まず必要な入口だけを書き出す。次にパネル・OS・待受を同じ条件で確認する。一度つながった後も、試すために広げた設定が残っていないかを見てから作業を終えましょう。