• HOME
  • IPv4のみのサーバーをデュアルスタックに切り替える手順｜AAAA追加前の確認と切り戻し方

2026年6月5日

  • シェア
  • ツイート

    • 2026年6月5日

    IPv4のみのサーバーをデュアルスタックに切り替える手順｜AAAA追加前の確認と切り戻し方

    IPv4だけで動いているWebサーバーをデュアルスタック（IPv4とIPv6の併用）に切り替えるときは、「サーバー側でIPv6を通す → Webサーバー・ファイアウォール・関連サービスをIPv6に対応させる → AAAAレコードを入れずに動作確認 → TTLを下げてからAAAAを追加 → 監視と切り戻しの準備」の順に進めます。DNSにAAAAレコードを入れた時点で、IPv6を使える利用者はIPv6側に来るようになるため、その前にIPv6側の経路がすべて整っている状態を作っておくのがこの作業の要点です。この記事では、稼働中のサイト（WordPressを含む）を止めずに切り替える流れと、各段階の確認方法を説明します。

    デュアルスタックの考え方そのものや、トンネル・変換方式との違いは別記事で扱っています。ここでは「すでにIPv4で動いている本番環境を切り替える作業」に絞ります。

    切り替えで起きやすい問題を先に知っておく

    IPv6の設定ミスは、サイト全体が見えなくなる形ではなく、「一部の利用者だけ遅い・つながらない」形で表に出ることが多いのが厄介な点です。

    • IPv6側だけ経路が切れている: 最近のブラウザはHappy Eyeballs（IPv6とIPv4をほぼ同時に試し、早くつながった方を使う仕組み）を実装しているため、IPv6が壊れていても数百ミリ秒の遅れでIPv4に切り替わり、管理者が気づきにくくなります。一方、この仕組みを持たないクライアント（一部のスクリプトや古い機器）はタイムアウトまで待ちます。
    • ファイアウォールがIPv4用だけ設定されている: iptablesとip6tablesは別々のルールです。IPv4側だけ絞り込んでいて、IPv6側が全開放または全遮断のまま、という状態が起こります。
    • IPアドレスで制限している設定が抜ける: 管理画面のIP制限、.htaccess の Require ip、セキュリティプラグインの許可リストなどがIPv4のアドレスしか持っていないと、IPv6で来た自分自身が締め出されたり、逆に制限をすり抜けたりします。

    このため、作業はAAAAレコードを入れる前の準備に時間をかけ、DNSの変更は最後に回します。

    手順1：サーバーにIPv6アドレスと経路があるか確認する

    まず、サーバーにグローバルIPv6アドレスが割り当てられ、外へ出られるかを確認します。VPSやクラウドでは、管理画面でIPv6を有効にしないと割り当てられないサービスが多くあります。

    # グローバルアドレス（scope global）があるか
ip -6 addr show scope global

# デフォルト経路があるか
ip -6 route show default

# 外部へのIPv6疎通（Google Public DNS のIPv6アドレス）
ping -6 -c 4 2001:4860:4860::8888

# HTTPSでの外向き通信
curl -6 -sI https://www.google.com | head -n 1

    fe80:: で始まるアドレスはリンクローカルで、外部からは届きません。グローバルアドレスが無い、または経路が無い場合は、OSの設定より先に契約しているサービス側の設定（IPv6の有効化、サブネットの割り当て）を確認します。クラウドではVPCやサブネットにIPv6のCIDRを関連付け、ルートテーブルにIPv6のデフォルト経路を追加する、といった作業が別途必要なことがあります。

    外向きの通信が通ったら、手元のIPv6が使える回線から、サーバーのIPv6アドレスへpingやSSHが届くかも見ておきます。

    手順2：ファイアウォールをIPv6でもそろえる

    次に、IPv4と同じ方針のルールがIPv6にもあるかを確認します。使っている仕組みごとに確認場所が違います。

    # ufw: IPv6のルールも管理する設定になっているか
grep IPV6 /etc/default/ufw
sudo ufw status verbose   # (v6) と付いた行があるか

# firewalld: IPv4/IPv6を同じゾーン設定で扱う
sudo firewall-cmd --list-all

# iptablesを直接使っている場合は、IPv6側を別に確認
sudo ip6tables -S

    ufwは IPV6=yes であれば、ufw allow 443/tcp のようなルールがIPv6にも作られます。iptablesを直接書いている環境では、ip6tablesにも同等のルールを書く必要があります。nftablesで inet ファミリーのテーブルを使っていれば、1つのルールセットで両方を扱えます。

    注意したいのがICMPv6です。IPv6では、近隣探索（IPv4のARPに相当）や経路MTU探索（Packet Too Big メッセージ）にICMPv6を使うため、ICMPを一律に遮断すると、接続はできても大きな通信だけ止まる、といった分かりにくい障害になります。pingへの応答を止めたい場合でも、ICMPv6全体は止めないようにします。

    クラウドのセキュリティグループやネットワークACLも、IPv4の 0.0.0.0/0 とは別に、IPv6の ::/0 を許可するルールが必要です。

    手順3：WebサーバーをIPv6で待ち受けさせる

    Webサーバーが :: でも待ち受けているかを確認します。

    sudo ss -tlnp | grep -E ':(80|443)\s'

    0.0.0.0:443 だけが表示され、[::]:443 が無い場合は、IPv6では待ち受けていません。

    nginxは、IPv4とIPv6の listen を別々に書きます。

    server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;
    # 以下、既存の設定
}

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

    HTTPからHTTPSへのリダイレクト用のserverブロックにも [::]:80 を入れ忘れないようにします。Apacheは Listen 80 のようにアドレスを省略していれば、通常IPv4とIPv6の両方で待ち受けます。Listen 0.0.0.0:80 のようにIPv4のアドレスを明示している場合は書き換えが必要です。

    設定後は構文チェック（sudo nginx -t や sudo apachectl configtest）をしてから再読み込みします。

    手順4：IPアドレスに依存する設定を洗い出す

    ここが見落としやすい部分です。IPv4のアドレスを前提にしている設定を探します。

    • アクセス制限: nginxの allow / deny、Apacheの Require ip、管理画面へのIP制限。自分の接続元IPv6アドレス（またはプレフィックス）を追加しておかないと、切り替え後に自分が入れなくなることがあります。
    • ログ解析とブロック: fail2banなどのログ監視型のツールは、IPv6アドレスを扱えるバージョンか、使っている設定（アクションやフィルター）がIPv6に対応しているかを確認します。
    • WordPress側: セキュリティ系や会員制のプラグインで、IP許可リストやログイン制限を使っている場合は、IPv6の扱いを各プラグインの説明で確認します。コメントやログに記録されるIPアドレスが長くなるので、独自のテーブルにIPを保存している場合は列の長さも見ておきます（IPv6の文字列表記は通常最大39文字、IPv4埋め込み表記を含めると45文字になります）。
    • メール送信: サーバーから直接メールを送っている場合、Postfixなどが切り替え後にIPv6で送信を始めることがあります。送信に使うIPv6アドレスの逆引き（PTR）と、SPFレコードへの ip6: の追加ができていないと、受信側で拒否されやすくなります。準備が整うまでは送信をIPv4に限定しておく方法もあります。
    • 証明書の更新: Let's EncryptのHTTP-01認証は、AAAAレコードがあるとIPv6での接続を優先して試みます。IPv6側の80番が正しく応答しないと、更新が失敗する原因になります。

    手順5：AAAAレコードを入れる前に動作確認する

    DNSを変える前に、IPv6アドレスを直接指定してサイトが表示されるかを確認できます。curl の --resolve を使うと、DNSを変えずに特定のアドレスへ接続できます（2001:db8::10 は説明用のアドレスです。実際のサーバーのアドレスに置き換えてください）。

    # IPv6アドレスへ直接つないで、証明書とレスポンスを確認
curl -6 -sI --resolve example.com:443:[2001:db8::10] https://example.com/

# HTTP→HTTPSのリダイレクトも確認
curl -6 -sI --resolve example.com:80:[2001:db8::10] http://example.com/

    ステータスコード、リダイレクト先、証明書のエラーが出ないことを見ます。ログイン画面や問い合わせフォームなど、重要なページもいくつか確認しておくと安心です。アクセスログに、テストした接続元のIPv6アドレスが記録されているかも確認します。

    手順6：TTLを下げてからAAAAレコードを追加する

    切り戻しを速くするため、AAAAを追加する前にTTLを短くしておきます。

    1. 追加予定のレコード（AAAAを置くホスト名）のTTLを、たとえば300秒程度に設定する。既存のAレコードを変える予定がないなら、AAAAを最初から短いTTLで作るだけでもかまいません
    2. 既存レコードのTTLを変えた場合は、元のTTLの時間が経つまで待つ
    3. AAAAレコードを追加し、反映を確認する
    dig AAAA example.com +short
dig AAAA www.example.com +short

# 権威サーバーに直接問い合わせる場合
dig AAAA example.com @ns1.example-dns.com +short

    www 付きと無しの両方、CDNやメール用のホスト名など、どのホスト名にAAAAを置くかをあらかじめ決めておきます。CDNを使っている場合は、利用者とCDNの間のIPv6はCDN側の設定で決まり、オリジンサーバーはIPv4のままでもかまわない構成が一般的です。その場合はオリジンのAAAAを追加する必要がないこともあるため、CDNの説明を確認してください。

    手順7：切り替え後の監視と切り戻し

    AAAAを追加したら、しばらくは次の点を見ます。

    • アクセスログの比率: IPv6アドレスからのアクセスが記録され始めているか
    • エラーログ: 403や接続エラーがIPv6の接続元に偏っていないか
    • 外部監視: 死活監視サービスを使っている場合、IPv6での監視を追加できるか確認する。IPv4だけで監視していると、IPv6側の障害に気づけません
    • 外部の確認サービス: IPv6での到達性を調べられるWebサービスで、外部から見た状態を確認する

    問題が出た場合の切り戻しは、AAAAレコードを削除するのが最も早い方法です。TTLを短くしておけば、利用者側のキャッシュが切れるまでの時間も短く済みます。原因が分かったら、IPv6側を直してから再度AAAAを追加します。

    なお、IPv6の提供状況やクラウド各社の設定画面は変わることがあるため、作業時点の各サービスの説明を確認してください（2026年10月現在）。

    まとめ

    • デュアルスタックへの切り替えは、AAAAレコードを入れる前にIPv6側の準備をすべて終えておくのが基本
    • サーバーのIPv6アドレスと経路、ファイアウォール（ip6tables・セキュリティグループ・ICMPv6）、Webサーバーの待ち受けを順に確認する
    • IP制限、ログ監視ツール、メール送信のPTRとSPF、証明書の更新など、IPv4前提の設定を洗い出す
    • curl --resolve でDNSを変えずに確認し、TTLを下げてからAAAAを追加する
    • 切り替え後はIPv6での監視を加え、問題があればAAAAを削除して切り戻す
    Views: 62

    お気軽にご相談ください

    お見積りへ お問い合わせへ
    閉じる
    ▲