サーバー移転のあとで「一部の人にだけ古いサイトが見える」「自分の環境では直っているのに問い合わせが旧サーバーに届く」という状態になったら、AAAAレコードのTTLや宛先の設定漏れを疑います。DNS側で直せるのは宛先とTTLの値までで、すでに配られたキャッシュは消せないため、復旧は「DNSを直す」「旧サーバー側で受け止める」「分かれてしまったデータを戻す」の3つを並行して進めます。この記事では、WordPressサイトの移転でこの状態に陥ったときの見分け方と、具体的な直し方を順に説明します。
TTLの基本的な考え方（長すぎ・短すぎの直し方）は別記事で扱っているため、ここでは「移転後に起きてしまった誤設定の後始末」に絞ります。
症状から誤設定を見分ける
AAAAレコードはIPv6アドレスを返すレコードです。IPv6が使える回線の利用者は、多くの場合AAAAの宛先に先に接続します。そのため、次のような症状は「Aは新サーバー、AAAAは旧サーバー」という食い違いの典型です。
- スマートフォンの回線では古いサイト、会社のIPv4だけの回線では新しいサイトが表示される
- 移転後に投稿したはずのコメントや問い合わせが、新サーバーのWordPressに見当たらない
- 新サーバーで Let's Encrypt の証明書発行が失敗し、エラーに旧サーバーらしき応答が出る
- 旧サーバーのアクセスログに、移転後もIPv6アドレスからのアクセスが続いている
まず、IPv4とIPv6で別々に接続して、どちらが旧サーバーにつながっているかを確かめます。
curl -4 -sI https://www.example.com/ | head -n 5
curl -6 -sI https://www.example.com/ | head -n 5応答ヘッダーの Server や、旧サーバーと新サーバーで違う値（キャッシュ系のヘッダーなど）を比べると見分けやすくなります。手元の回線がIPv6に対応していない場合は、IPv6が使えるサーバーから実行します。
次に、権威DNSがいま何を返しているかと、キャッシュDNSに何が残っているかを分けて確認します。
dig +short NS example.com
dig @ns1.example.net +norecurse +noall +answer www.example.com A www.example.com AAAA
dig @8.8.8.8 +noall +answer www.example.com AAAA権威DNSのAAAAが旧サーバーのアドレスのままなら、宛先の更新漏れです。権威DNSは新しいアドレスなのに公開DNSが古いアドレスを返すなら、キャッシュが残っている状態で、2列目の数字（残り秒数）が切れるまで続きます。
誤設定のパターンと直し方
作業の前に、DNSの管理画面のエクスポートやゾーンファイルのコピーを取っておきます。
AAAAの宛先を変え忘れていた
最も多いのがこれです。移転の手順書がAレコードだけを前提にしていて、レンタルサーバーやDNSサービスが自動で作ったAAAAが残っていた、という経緯がよくあります。
新サーバーがIPv6に対応しているなら、AAAAを新サーバーのアドレスに変えます。対応していない、または設定に自信が無いなら、AAAAを削除してIPv4だけで運用するのも妥当な選択です。削除した場合、「AAAAは存在しない」という応答もSOAレコードの値をもとにキャッシュされるため、あとで追加し直すときは反映が遅れて見えることを覚えておきます。
宛先を直すときに、TTLを短めの値（300秒程度）にしておくと、この先さらに修正が必要になったときの待ち時間を減らせます。落ち着いたら平常時の値に戻します。
AAAAのTTLだけ下げ忘れていた
移転前にAのTTLだけを下げ、AAAAは86400秒などのまま宛先を変えたケースです。権威DNSの値は正しくても、キャッシュには古いAAAAが最大で元のTTLの分だけ残ります。いまからAAAAのTTLを下げても、残っているキャッシュには効きません。待つ間は、次の「旧サーバー側で受け止める」で影響を小さくします。
TTLの単位を取り違えていた
管理画面によっては、TTLを秒ではなく分や時間の選択肢で入力します。「60」を分のつもりで秒の欄に入れた、またはその逆、という取り違えは画面だけ見ていると気づきにくいものです。BINDのゾーンファイルでは 1h や 1d のような単位付きの表記も使えます。どの画面で設定しても、最後に dig で権威DNSに問い合わせ、秒数で意図どおりかを確かめるのが、取り違えに気づく近道です。なお、極端に長いTTLは、キャッシュDNS側の上限で短く丸められることがあります。
旧サーバー側で受け止める
キャッシュが切れるまでの間、旧サーバーには一部の利用者が来続けます。旧サーバーを止めてしまうと、その利用者にはサイトが表示されないか、IPv4への切り替えを待つ分だけ遅くなります。次のどれかで受け止めます。
- 新サーバーへ転送する: 旧サーバーのWebサーバーをリバースプロキシにして、リクエストを新サーバーへ渡します。利用者には新しいサイトが表示され、投稿やコメントも新サーバーに入ります。もっとも影響が小さい方法です
- メンテナンス表示にする: 転送の設定が難しい場合は、旧サーバーのWordPressをメンテナンス表示にして書き込みを止めます。WordPressはルートに
.maintenanceファイルがあるとメンテナンス画面を出す仕組みを持っていますが、更新処理のための一時的なものなので、プラグインやWebサーバーの設定で503を返すほうが扱いやすいこともあります - 書き込みが起きる機能だけ止める: コメント、問い合わせフォーム、ECの注文など、データが旧サーバーに残ってしまう機能を優先して止めます
旧サーバーのWordPressが動いたままだと、WP-Cron による予約投稿やメール送信が旧サーバーからも走り、通知が二重に届くことがあります。旧サーバー側で不要な予約処理が動いていないかも確認しておきます。
旧サーバーにIPv6でアクセスが来ているかは、アクセスログのクライアントアドレスに : が含まれるかで判断できます。
sudo awk '$1 ~ /:/' /var/log/nginx/access.log | tail -n 20この行数が減っていけば、キャッシュが切れて新サーバーへ移っている目安になります。
分かれてしまったデータを戻す
食い違っていた期間に旧サーバーへ書き込まれたデータは、新サーバーには自動では移りません。WordPressで確認したいのは次のようなものです。
- コメント（承認待ちを含む）
- 問い合わせフォームの送信内容（フォーム系プラグインがデータベースに保存している場合）
- 会員登録やWooCommerceなどの注文
- 管理者が旧サーバーで編集した投稿
旧サーバーのデータベースのバックアップを取ってから、該当期間の差分を確認します。件数が少なければ手で入力し直すのが安全です。データベースの行を直接新サーバーへ流し込む方法は、IDの重複や関連テーブルの不整合を起こしやすいため、ステージング環境で試してから行います。
証明書の発行や更新が失敗していたら
Let's Encrypt のHTTP検証は、AAAAがあるとIPv6を優先して接続します。IPv6でつながらない場合はIPv4に切り替える場合もありますが、旧サーバーが応答を返してしまうと切り替わらずに検証が失敗する、と案内されています。AAAAを直し、権威DNSとキャッシュの両方で新しいアドレスになったことを確かめてから、更新を試します。
sudo certbot renew --dry-run本番の発行を繰り返すとレート制限にかかることがあるため、まず --dry-run で確かめます。
直ったことを確かめる
新サーバーのIPv6アドレスに直接つないで、DNSの状態に関係なく新サーバーが正しく応答するかを確かめます。--resolve に指定するアドレスは、新サーバーのものに置き換えてください。
curl -6 -sI --resolve www.example.com:443:[2001:db8::20] https://www.example.com/ | head -n 1あわせて、curl -4 と curl -6 の両方で新サーバーの応答になること、WordPressの管理画面にIPv6の回線からログインできることを確認します。各社の公開DNSにキャッシュの消去を依頼するページもありますが、効くのはその公開DNSを使う利用者だけです（2026年10月現在）。
次の移転で同じことを起こさないよう、手順書には「AとAAAAの両方の宛先とTTLを、移転前に権威DNSで確認する」という項目を入れておきます。
まとめ
- 一部の人だけ旧サイトが見えるときは、
curl -4とcurl -6で接続先を分けて確かめる - AAAAの宛先の変え忘れ、TTLの下げ忘れ、単位の取り違えのどれかを、権威DNSへの
digで切り分ける - 残ったキャッシュは消せないので、旧サーバーで転送かメンテナンス表示にして受け止める
- 旧サーバーに入ったコメントや注文は、バックアップを取ってから新サーバーへ戻す
- 証明書の更新は、AAAAを直してから
--dry-runで確かめる