IPv4では見えるサイトに、AAAAを一つ足す。

作業は小さく見えます。でも、IPv6の住所を持つことと、その住所から同じサイトが使えることは別です。自分なら、DNSを公開する前に、IPv6の待受と許可設定を確かめます。

ConoHa VPS 3.0の公式案内では、IPv6は標準で17個使え、初期状態でOSに設定されているのは1個です。まずその1個で、必要なサイトへ届くことを確認する。複数の住所をOSへ足す作業は、その後で十分な場合もあります。

17個の割り当てを、17個の公開済みサイトと読まない

VPS 3.0では17個のIPv6が利用できますが、追加分を使うにはOS側の設定が必要です。管理画面で確認したIPアドレスとプレフィックス長を使い、自分が必要な分だけ設定します。

段階 確認するもの まだ分からないこと
管理画面に割り当てがある 自分のVPSに割り当てられたIPv6とプレフィックス長 OSがそのアドレスを使っているか
OSに設定されている インターフェースのアドレスと経路 WebサーバーがIPv6で待ち受けているか
Webが待ち受けている IPv6側のアドレス・ポートで応答すること 外部から許可されているか
外部から接続できる 必要なホスト名・証明書・画面の一致 公開DNSが同じアドレスを返すか
AAAAを公開した 公開名とIPv6の対応 その後も両方の経路が使えるか

IPv6の公式ドキュメントを2026-10-28に確認しました。ConoHa VPS 3.0の案内です。2.0や別サービスに同じ初期設定があるとは考えないでください。

OS設定の例も、使っているOSに合わせて読みます。公式例を別のディストリビューションへそのまま貼る前に、現在のネットワーク管理方式と設定の戻し方を確かめておきます。

住所が17個あっても、VPSが17台になるわけではありません。同じサーバーの停止から守るための冗長化と、アドレスを使い分けることは分けて考えます。

IPv4だけの待受は、IPv6の接続に答えなかった

Linuxのループバックで待受を分けた検証では、IPv4専用の待受はIPv6へ答えず、IPv6専用の待受はIPv4へ答えませんでした。両方へ答える構成は、両方の待受を用意したときです。

CodexがPythonのsocketで、127.0.0.1と::1に接続しました。IPv6側は IPV6_V6ONLY=1 を明示し、IPv4を兼ねない条件に固定しています。

実際に起動した待受 IPv4から接続 IPv6から接続
IPv4専用 成功 失敗
IPv6専用 失敗 成功
独立したIPv4・IPv6の両方 成功 成功

これは「IPv6の待受は必ずIPv4を拒否する」という一般則ではありません。OSやアプリの設定によって、IPv6のソケットがIPv4も受ける構成はあります。だからこそ、設定ファイルの記号だけで決めず、使いたいアドレスの種類ごとに応答を確かめます。

待受の検証はLinuxのループバック内だけです。ConoHaの公開経路、DNS、セキュリティグループ、TLSの実動作を測ったものではありません。IPの割り当てとOS設定の区分は公式IPv6ドキュメントを2026-10-28に照合しました。

「同じポートを開けた」は、どちら側の話か

外部のIPv6が通らないときは、OSへ届くまでのルールと、OSの中のルールを分けて見ます。さらに、通った先でWebサーバーが待っているかを確認します。

ConoHa VPS 3.0のセキュリティグループは、許可する通信を指定する方式です。ネットワークごとの許可が必要で、OS内部のファイアウォールも別に確認するよう案内されています。

セキュリティグループの許可だけでは、OSの設定やWebサーバーの待受まで動きません。セキュリティグループの公式説明を2026-10-28に確認しました。

IPv4で制限していた相手を、IPv6でも同じように選ぶ

独自ルールを作っているなら、通信方向、IPv4かIPv6か、ポート、IP/CIDRを一組で確認します。IPv4の接続元だけを限定したつもりでも、IPv6の別ルールが広く許可していれば、同じ制限にはなりません。

一方、ConoHaが用意する IPv4v6-Web はTCPの80・443向けです。用意済みのグループ名を見ずに「IPv4の許可だからIPv6は通らない」と決めつけるのも早いです。実際にどのグループが対象VPSへ付いているかまで見ます。

使い方 見るルール 避けたい取り違え
Webを一般公開 必要なIPv4・IPv6のHTTP/HTTPS経路 Webが通らないから、全ポートを公開する
SSHは管理者だけ 両方のアドレス版の接続元と管理ポート IPv4側だけ制限し、IPv6側を見落とす
管理画面を非公開 Web本体と管理用のポート・ホスト名の区分 サイト公開用の許可を管理画面にも広げる
OS内にもFWがある セキュリティグループとOS内の両方 片方を変更しただけで全部通ったと思う

ルールの設定項目は公式の操作案内で2026-10-28に照合しました。許可する相手と通信は用途ごとに決めます。管理用の接続を一律に公開するための例ではありません。

自分なら、管理用の接続とコンソールを確保したまま、一つずつ変更します。ネットワーク設定、許可ルール、DNSを同時に変えてしまうと、どこで通らなくなったのかが分かりにくくなるからです。

AAAAを足す前に、ホスト名を保ったまま接続する

公開前の確認では、ブラウザーにIPv6アドレスを直接入れるだけで終わらせません。使うホスト名を保って、証明書とサイトの応答を確かめます。

たとえば、IPv6の外部接続が使える自分の端末から、管理するサイトへ次のように確認します。site.example と文書用IPv6 2001:db8::10 は説明用です。自分のホスト名と実際の割り当てに置き換えてください。

curl --resolve 'site.example:443:[2001:db8::10]' https://site.example/

これは、そのコマンドの接続先を指定する方法です。公開DNSを書き換える操作ではありません。URLの名前をそのまま使うので、単にIPのURLを開く方法と違い、目的のホスト名でHTTPSを確かめられます。

curlの公式マニュアルの --resolve を2026-10-28に確認しました。コマンド例は自分が管理するホストと割り当てIPに置き換えて使います。公開経路の成功は手元の試験だけでは確かめられません。

ここでいう手元の試験は、上のループバック模型です。IPv6を使える外部回線からの確認は、公開経路を確かめるために行います。

プロキシやCDNを経由している場合も、何へ接続した結果かを先に見ます。CDNの正常応答を、直接のVPS経路の確認へ読み替えないようにします。

接続できなかったときは、設定を足す前に段階を戻る

IPv4では見えるのにIPv6だけ失敗するなら、まずIPv6を使える端末・回線で試しているかを確認します。そこが違うまま、VPSの設定を変え続けたくありません。

次に、管理画面のアドレスとOS設定、経路、待受、セキュリティグループ、OS内のFWを順に確認します。TCPに届いてから証明書や別サイトのエラーになる場合は、Host名やTLS側へ進みます。接続そのものの失敗と、届いた先の内容の違いを分けると、見る場所が絞れます。

公開した後も、IPv4・IPv6を別々に見る

AAAAを公開したら、通常の名前解決を使うIPv4・IPv6の両方で、必要な画面が使えることを確認します。片方が動いているだけで、もう片方も正常とはしません。

ConoHa DNSではAやAAAAを登録・編集できます。DNSを使うを2026-10-28に確認しました。DNSにアドレスを登録しても、そのアドレスへの接続が成功するとは限りません。

名前解決後の確認例は次の二つです。--resolve を付けた事前確認とは分けます。

curl -4 https://site.example/
curl -6 https://site.example/

-4・-6 はcurl公式マニュアルで確認した、使うIPの種類を分ける指定です。IPv6を利用できない端末で後者が失敗しても、それだけでVPSの障害とは決められません。

もし公開後にIPv6の経路だけ直せない問題が見つかったら、変更前のAAAA設定を控えておき、それを戻すか一時的に公開を見直します。すでに名前解決した端末やキャッシュには以前の値が残ることがあるため、DNSを戻せばその瞬間に全接続が切り替わるとは考えません。IPv4の経路は動く状態に保って、影響を確かめます。

使えると確かめてから、公開する

IPv6が必要で、外部経路と設定を管理できるなら、まず初期の1個で正しいサイトへ到達することを確認します。複数アドレスが必要な理由がある場合に、使う分だけ追加します。

IPv6を試せる回線もなく、待受や許可の区分も確かめられないなら、急いでAAAAだけ公開するのは勧めません。アドレスを増やしたことより、利用者へ渡した経路が使えることの方が先です。

自分なら、OS、待受、許可、ホスト名つきの外部試験、最後にDNS。この順で一つずつ確かめます。