2026年6月6日

IPv6 onlyサーバーへ移行する方法｜WordPressを止めずにIPv4を外す手順と注意点

IPアドレス・ルーティング

WordPressのサーバーをIPv6 onlyにするときは、いきなりIPv4を外すのではなく、まずデュアルスタック（IPv4とIPv6の併用）でIPv6側を動かし、「外から入ってくる通信」と「サーバーから出ていく通信」の両方がIPv6だけで成り立つことを確かめてから切り替えます。この記事では、移行前の棚卸し、IPv4しか持たない閲覧者への対応、外向き通信（WordPress本体の更新・外部API・メール）の扱い、切り替えと戻し方までを順に説明します。

IPv6 onlyにすると何が変わるか

IPv6 onlyとは、サーバーにグローバルなIPv4アドレスを割り当てず、IPv6アドレスだけで通信する構成です。クラウド事業者の多くがパブリックIPv4を有料化・制限する方向にあり、アドレス管理を簡単にしたいという理由で検討されることが増えています。

ただし影響は二方向あります。

入ってくる通信: IPv6を使えない閲覧者（一部の企業ネットワーク、古いルーター、IPv6未対応の回線など）は、サーバーへ直接到達できなくなります。
出ていく通信: WordPressが接続する先（更新サーバー、プラグインの配布元、決済や外部API、SMTPサーバー）がIPv4しか持っていないと、そこへ接続できなくなります。

この2つを別々に解決するのが移行の中心です。どちらか一方だけを確認して切り替えると、「サイトは見えるのにプラグインが更新できない」「お問い合わせメールが届かない」といった障害になります。

移行前の棚卸し

まず、今のサーバーがどんな通信をしているかを洗い出します。作業はバックアップを取ってから、可能ならステージング環境で先に行います。

# 割り当て済みのIPv6アドレスと経路
ip -6 addr show
ip -6 route show

# IPv6で外へ出られるか
ping -6 -c 3 www.google.com
curl -6 -sI https://api.wordpress.org/ | head -1

# 現在待ち受けているポート（[::] や :: で待ち受けているか）
ss -tlnp

curl -6 が失敗する場合、サーバーにIPv6の経路が無いか、ファイアウォールで止まっています。待ち受けポートの一覧で 0.0.0.0:443 だけが出ていて [::]:443 が無い場合は、Webサーバーが IPv6 で待ち受けていません。

次に、外向き通信の宛先を一覧にします。WordPress本体とプラグインの更新、テーマやプラグインが使う外部API、メール送信用のSMTPサーバー、バックアップの転送先、監視サービスなどです。それぞれについて、宛先ホスト名がAAAAレコードを持っているかを確認します。

# 宛先ごとに AAAA があるか（何も返らなければIPv4のみ）
dig +short AAAA api.wordpress.org
dig +short AAAA smtp.example.com

AAAAが無い宛先は、後述のNAT64を用意しない限り、IPv6 onlyのサーバーからは使えません。この一覧が、移行できるかどうかの判断材料になります。

手順1：デュアルスタックでIPv6側を動かす

IPv4を残したまま、IPv6で受け付けられる状態を作ります。

Nginxなら、listen をIPv6にも書きます。

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

Apacheは Listen 443 のようにアドレスを指定しない書き方なら、通常はIPv6でも待ち受けます。Listen 0.0.0.0:443 のようにIPv4を明示している場合は書き換えが必要です。

ファイアウォールもIPv4とIPv6で別のルールを持っていることが多いので注意します。ufwなら /etc/default/ufw の IPV6=yes を確認し、nftablesやiptablesを直接使っている場合は ip6tables 側（または inet ファミリーのテーブル）にもHTTP・HTTPS・SSHの許可を入れます。IPv4では許可しているのにIPv6は全部閉じている、という状態は珍しくありません。

その後、DNSにAAAAレコードを追加します。TTLは事前に短くしておくと、問題があったときに戻しやすくなります。追加後は、IPv6で外部から到達できるかを確認します。

# 別のIPv6が使える端末から
curl -6 -sI https://example.com/ | head -1

手順2：IPv6だけで動くかを確認する

デュアルスタックのまま、サーバー内部の通信がIPv4に頼っていないかを確認します。

データベース接続: wp-config.php の DB_HOST が localhost（UNIXソケット）や 127.0.0.1 の場合、同じサーバー内の通信なので外部のIPv4を外しても影響はありません。別サーバーのデータベースにIPv4アドレスで接続している場合は、IPv6アドレスかホスト名に変える必要があります。
外向きHTTP: WordPressの外部通信は wp_remote_get() などのHTTP APIを通り、名前解決の結果に従って接続します。宛先がIPv6を持っていればIPv6で接続できます。
SSL証明書の更新: Let's EncryptはIPv6でHTTP-01の検証に対応しており、AAAAレコードがある場合はIPv6側へアクセスしてきます。IPv6側の80番ポートが閉じていると更新に失敗するので、certbot renew --dry-run で確認します。
メール送信: IPv6からメールを直接送る場合、IPv6アドレスの逆引き（PTR）、SPF、DKIMの設定が無いと受信側に拒否されやすくなります。外部のメール配信サービスをSMTPやAPIで使っている場合は、その接続先がIPv6に対応しているかを棚卸しの結果で確認します。

管理画面の「サイトヘルス」も確認しておくと、外部への接続（WordPress.orgとの通信やループバックリクエスト）の失敗に気付けます。

手順3：IPv4しか持たない閲覧者への対応

IPv6の普及は進んでいますが、閲覧者の一部は今もIPv4しか使えません（2026年10月現在）。サーバーのIPv4を外しても閲覧者を取りこぼさないためには、前段にデュアルスタックの仕組みを置くのが一般的です。

CDNやリバースプロキシを前に置く: CloudflareなどのCDNでプロキシを有効にすると、閲覧者はCDNにIPv4・IPv6のどちらでも接続でき、CDNからオリジン（あなたのサーバー）へはIPv6で接続する構成にできます。オリジンがIPv6のみでも動くかは、各サービスの説明を確認してください。
ロードバランサーにIPv4を残す: クラウドのロードバランサーだけにIPv4を持たせ、背後のサーバーをIPv6 onlyにする方法です。対応状況はクラウドごとに違います。

CDN経由にした場合、WordPressが受け取るアクセス元IPはCDNのものになります。セキュリティプラグインやログで本来の閲覧者のIPを使いたい場合は、Webサーバー側でCDNが付けるヘッダーから実IPを復元する設定（Nginxの real_ip モジュールなど）を入れます。

手順4：IPv4しか持たない宛先への対応（NAT64/DNS64）

棚卸しでAAAAの無い宛先が見つかった場合の選択肢は3つです。

その宛先をIPv6対応の別サービスに替える
NAT64/DNS64を使う
その宛先がある限りIPv6 onlyは見送る

NAT64/DNS64は、IPv4しか無い宛先について、DNS64がIPv6アドレス（64:ff9b::/96 などのプレフィックスにIPv4を埋め込んだもの）を合成して返し、NAT64装置がIPv4に変換して中継する仕組みです。主要なクラウドでは、IPv6 onlyのサブネット向けにDNS64とNAT64を組み合わせて使える機能を提供しているところがあります。公開されているDNS64リゾルバもありますが、変換を行うNAT64の経路が別途必要なので、DNS64だけを設定しても通信はできません。

# DNS64が効いていれば、IPv4のみのホストにもAAAAが合成されて返る
dig +short AAAA ipv4only.arpa

ipv4only.arpa はDNS64の検出用に用意された名前で、DNS64を使っていれば合成されたIPv6アドレスが返ります。

手順5：IPv4を外す

ここまで確認できたら、IPv4を外します。順番は次のとおりです。

作業前にサーバー全体のバックアップ（スナップショット）を取る
管理用のSSHがIPv6で接続できることを確認する。作業場所の回線がIPv4のみだと、IPv4を外した瞬間に入れなくなります。クラウドのWebコンソールやシリアルコンソールなど、ネットワークに頼らない入口があるかも確認しておきます
DNSのAレコードを削除する（CDN経由ならCDN側のオリジン設定をIPv6に切り替える）
古いTTLが切れるまで待ってから、サーバーからIPv4を外す
外部からの表示、管理画面へのログイン、プラグイン更新、問い合わせフォームのメール送信、予約投稿（WP-Cron）、バックアップの転送を一通り試す

問題が出たときに戻せるよう、外したIPv4アドレスを一定期間保持できるか（クラウドで予約しておけるか）も事前に確認しておくと安心です。

まとめ

IPv6 only化は「入ってくる通信」と「出ていく通信」を分けて考える
まずデュアルスタックでIPv6側の待ち受け・ファイアウォール・AAAAレコードを整え、IPv6だけで動くことを確認する
IPv4しか持たない閲覧者にはCDNやロードバランサーなどデュアルスタックの前段で対応する
AAAAの無い外部サービスはNAT64/DNS64か代替サービスで解決し、解決できなければ見送る
IPv4を外す前にバックアップと、IPv6で入れる管理経路を用意する