464XLATの環境から接続できない場合の対処｜サーバー側とクライアント側の切り分け

464XLAT の回線（IPv6 だけで接続し、IPv4 は変換して通す方式）からサイトに接続できない場合、原因の多くは変換の仕組みそのものではなく、サーバー側の IPv6 設定の不備か、変換を前提にしていない通信の作り方にあります。この記事では、464XLAT の仕組みを簡単に押さえたうえで、症状から原因を絞り込む順番と、それぞれの確認・修正方法を説明します。WordPress サイトの運用者が「スマートフォンの回線からだけ表示できない」と問い合わせを受けた場面を主に想定しています。

464XLAT の仕組み

464XLAT（RFC 6877）は、IPv6 だけのネットワークで IPv4 の通信も使えるようにする方式です。2つの変換装置で成り立っています。

• CLAT（端末側）: 端末やルーターの中で、アプリが出した IPv4 パケットを IPv6 に変換します
• PLAT（事業者側）: NAT64 装置で、IPv6 パケットを IPv4 に戻してインターネットへ送ります

あわせて、DNS64 という仕組みが使われることが多く、AAAA レコードを持たないサイトに対して、変換用のプレフィックス（よく使われるのは 64:ff9b::/96）を付けた AAAA を合成して返します。携帯電話の回線で広く使われており、Android は CLAT を標準で備えています。ほかの OS の対応状況は更新が続いているため、利用している OS の情報を確認してください（2026年10月現在）。

この構成で大事なのは、相手のサイトに AAAA レコードがあれば IPv6 で直接つながり、なければ変換を経由して IPv4 でつながる、という点です。つまり「AAAA があるかどうか」で通る経路が変わります。

まず症状を確認する

切り分けの前に、次の点を問い合わせた人に確認するか、自分で再現します。

• 携帯回線（Wi-Fi をオフ）だけで起きるのか、自宅の光回線でも起きるのか
• ページがまったく開かないのか、途中で止まるのか（画像だけ出ない、ログイン後だけ失敗するなど）
• 特定のアプリだけなのか、ブラウザでも同じなのか

まったく開かない場合と、途中で止まる場合とでは原因が違います。以下、可能性の高い順に説明します。

原因1: AAAA レコードはあるのに IPv6 で接続できない

最も多い原因です。DNS に AAAA レコードを登録しているのに、Web サーバーが IPv6 で待ち受けていない、またはファイアウォールで IPv6 の通信を止めている状態です。IPv4 で接続できる回線では問題が表に出ず、IPv6 を優先する回線からだけ接続できなくなります。

確認方法

# DNS に AAAA があるか
dig AAAA example.com +short

# IPv6 で実際に接続できるか（IPv6 が使える別の環境から）
curl -6 -sv https://example.com/ -o /dev/null

# サーバー上で、443番を IPv6 で待ち受けているか
sudo ss -ltnp | grep ':443'

ss の結果に [::]:443 や *:443 がなく、0.0.0.0:443 だけの場合は IPv4 でしか待ち受けていません。

修正方法

Nginx なら、server ブロックに IPv6 の listen を追加します。設定を変える前にファイルのバックアップを取り、nginx -t で文法を確認してから再読み込みします。

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 status や nft list ruleset で IPv6 側にも 80/443 番の許可があるかを見ます。クラウドのセキュリティグループも、IPv6 の受信ルールが別項目になっている場合があります。

IPv6 での提供をすぐに整えられない場合は、壊れた AAAA レコードを削除するほうが、IPv6 の回線の利用者にとっては影響が小さくなります。AAAA がなければ、464XLAT の回線は変換経由の IPv4 で接続してくるからです。

原因2: 途中で止まる（MTU と ICMPv6）

ページの一部は出るのに、大きな画像や TLS の接続確立で止まる場合は、パケットの大きさの問題が疑われます。変換の途中では IPv6 のヘッダーが IPv4 より長いぶん、扱えるデータの大きさが小さくなります。経路の途中で大きすぎるパケットが出ると、本来は ICMPv6 の「Packet Too Big」が送り元に返り、小さく分けて送り直されます。ところが、サーバーやファイアウォールが ICMPv6 をまとめて遮断していると、この通知が届かずに通信が止まります。

確認と修正

# 経路上の MTU を確認する（IPv6 が使える環境から）
tracepath -6 example.com

サーバー側のファイアウォールで、ICMPv6 を一律に拒否していないかを確認します。IPv6 では、ICMPv6 の一部（Packet Too Big や近隣探索など）を止めると通信が成り立たなくなります。ICMPv4 と同じ感覚で「ping を止める」設定をすると起こりやすい失敗です。

原因3: ログインや送信だけ失敗する（共有アドレスと IP 制限）

変換を経由した通信は、事業者の NAT64 装置の IPv4 アドレスからサーバーに届きます。このアドレスは多くの利用者で共有されています。そのため、次のような問題が起こります。

• セキュリティプラグインや WAF が、ログイン失敗の回数を IP アドレス単位で数えていて、共有アドレス全体がブロックされる
• 管理画面に IP アドレスの許可リストを設定していて、利用者の実際のアドレスと一致しない
• アクセスログでは同じ IP アドレスから大量のアクセスがあるように見える

ブロックの記録が残っている場合は、セキュリティプラグインやサーバーのログで、該当する時間帯にどの IP アドレスが制限されたかを確認します。IP アドレス単位の制限は、しきい値を見直すか、二段階認証などアカウント単位の対策に重心を移すと、共有アドレスの影響を受けにくくなります。

原因4: アプリや設定に IPv4 アドレスが直接書かれている

URL や設定に http://203.0.113.10/ のような IPv4 アドレスが直接書かれていると、DNS64 による変換が働きません。CLAT がある端末では変換されて届きますが、CLAT を持たない端末や、DNS64 だけの環境では接続できません。

WordPress では、サイトアドレスや投稿本文、テーマの設定に IP アドレスが残っていないかを確認します。

wp option get home
wp option get siteurl
wp db search '203.0.113.10' --all-tables

見つかった場合は、データベースのバックアップを取ってから、wp search-replace を --dry-run 付きで実行し、件数を確かめてからドメイン名に置き換えます。

クライアント側で変換の状態を確かめる

利用者側の端末で 464XLAT が働いているかを確認するには、変換用のプレフィックスを調べる仕組み（RFC 7050）を使います。

dig AAAA ipv4only.arpa +short

64:ff9b::c000:aa のような結果が返れば DNS64 が働いています。何も返らない場合は、DNS64 を使わない構成か、端末が別の DNS を使っている可能性があります。端末で独自の DNS（公開リゾルバなど）を指定していると、DNS64 の合成が行われずに IPv4 だけのサイトへ接続できなくなることがあるため、回線の標準の DNS に戻して試します。

まとめ

• 464XLAT では、相手に AAAA があれば IPv6 で直接、なければ変換経由の IPv4 で接続する
• 最も多い原因は、AAAA があるのにサーバーが IPv6 で待ち受けていない、またはファイアウォールで止めていること
• 途中で止まる場合は、ICMPv6 の遮断による MTU の問題を疑う
• ログインだけ失敗する場合は、共有 IPv4 アドレスへの IP 単位の制限を確認する
• IP アドレスの直書きは、DNS64 だけの環境で接続できない原因になる

• AAAAレコードでIPv6に対応する方法
• DNS64とNAT64の仕組みと設定