1. 症状の読み方（IPv4 と IPv6）
Clash で IPv6 をオンにした途端、中国本土向けのウェブサービスだけ読み込みが重くなったり、IP チェック系サイトで「HTTPS の出口はノードなのに別行では実回線」「デュアルスタックがおかしい」と表示されたりする場合、まずは同一ホストに対して IPv4 と IPv6 のどちらで繋いでいるかを分けて考えます。多くのサイトは AAAA レコードを返し、OS はハッピーアイボール等で先に決まった方へトラフィックを載せます。IPv4 だけを想定して書いた GEOIP や IP-CIDR だけでは、実際には IPv6 アドレスで評価されており、意図しない PROXY や逆に遠回りの DIRECT に落ちている、という非対称が起きえます。
ここでいう「漏れ」は、ブラウザの WebRTC だけが抜けるタイプ（WebRTC／DNS 記事）とは層が異なります。IPv6 が別 NIC／別ゲートウェイへ直行している、あるいは DNS が返す宛先アドレスファミリと Clash がルールマッチに使う情報がずれている、といった話です。症状を一度に直そうとせず、名前解決 → 実際の宛先 IP（v4/v6）→ ヒットしたルールの順でログに書き写すと整理が早いです。
2. インタフェース束ねとデュアルスタック
TUN や透明プロキシ系のクライアントでは、どの物理／論理インタフェースから外に出すかを YAML や GUI で指定します。Mihomo 系では interface-name や routing-mark、BIND 系のキーが文脈によって現れ、ここがIPv6 有効な NICと実際にプロキシが張っている NICで食い違うと、Ping は通るがブラウザだけ遅い、といった分裂が起きます。Wi-Fi と有線、および VPN アダプタが同居している環境では特に、既定ゲートウェイの IPv6 が OS 側でプロキシとは別ルートを指していることがあります。
実務のチェック項目としては、(1) OS のネットワーク詳細で IPv6 のゲートウェイがどこか、(2) Clash のログで dial や bind に関する行がないか、(3) ルータ側で IPv6 パス MTU やフィルタが変になっていないか、を並べます。TUN と Windows のルート記事では IPv4 中心に書いていますが、「カーネルに載せたトラフィックが別スタックへ逃げる」という発想はそのまま転用できます。
3. DNS と AAAA の優先順位
DNS が返すのが A だけか AAAA も含むかで、アプリケーションが張るソケットの種類が変わります。Clash の dns ブロックで fake-ip を使っている場合でも、上流から返るレコードの組み合わせと、クライアントがどのアドレスでコネクションを張ったかは別問題です。enhanced-mode や prefer-h3、DoH の選択など、実装とバージョンでキー名が異なるため、ここでは手順の骨格だけに留めます：(1) 問題のドメインを dig または GUI の DNS ログで見て AAAA がいつ付与されるか確認、(2) OS／ブラウザの「IPv6 を優先」設定がプロキシより先に効いていないか、(3) fake-ip 記事のとおり fake-ip-filter に国内 CDN を足すべきか検討、です。
中国本土向け CDN は IPv6 のエッジが混在しやすく、同名でも経路だけ IPv6 が混むと RTT が跳ねます。一度 IPv4 のみで名前を解くテスト（環境に応じて）と、IPv6 を許容したうえでルールを整えるテストを分けると、ボトルネックが DNS かルールかが判別しやすくなります。
# Conceptual — key names depend on your Mihomo / Meta version
dns:
enable: true
ipv6: true
enhanced-mode: fake-ip
nameserver:
- tls://...4. GEOIP／IP-CIDR6 とルール順
GEOIP,CN のようなルールは、コアとデータベースの実装次第で IPv4／IPv6 の両方を扱うことがありますが、一部の古いルールセットでは IPv4 前提に見える記述が残ることがあります。その結果、中国本土向けサイトにIPv6 で張ったコネクションだけがデフォルトの MATCH に落ち、海外ノードへ無駄に迂回したり、逆に DIRECT を期待していたのに別策略へ割り当てられたりします。GEOIP と DIRECT の記事とセットで、IP-CIDR6 を明示的に補うか、ルールプロバイダをIPv6 対応が明記された版へ更新するかを検討してください。
rules: は上から順です。広い RULE-SET が細かい追記より上にあると、IPv6 向けの例外が一生効きません。ログで「どのルール名がヒットしたか」を確認し、必要なら追記ルールを上へ移動するか、サブルールを分割します。
| ログ・画面のサイン | まず疑う層 |
|---|---|
宛先が 240 始まりなど IPv6なのに GEOIP が効いていない |
IP-CIDR6 不足、ルール DB の更新、評価順 |
| HTTPS は速いが別ホストだけ遅い | そのホストだけ AAAA／別 CDN、分流ルールの取りこぼし |
| 診断サイトで出口が混在 | ブラウザが複数接続を張り、ルールがホストごとに分岐 |
5. TUN・システムプロキシとスタックのずれ
システムプロキシのみのとき、アプリによっては IPv6 のソケットがプロキシ設定を無視する実装があります。TUN モードはカーネルレベルでトラフィックを捕捉するため、IPv4／IPv6 を同じポリシースタックに載せやすい反面、既存 VPN や企業ポリシーとルート競合しやすいというトレードオフがあります。TUN のトラブルシュート記事で全体断を潰したうえで、本稿の IPv6 の話に戻ると安全です。
また、ブラウザの Secure DNS が有効だと、名前解決だけがプロキシ外に出て AAAA と A のバランスが変わり、結果としてIPv6 だけ別出口に見えることがあります。検証時だけ Secure DNS をオフにし、Clash の DNS と単一化する対照実験は有効です。
6. ログと検証サイトの見方
Mihomo／Meta 系では接続ログに タイプ（TCP／UDP）、宛先ホスト／IP、マッチしたルール、チェーン先が並びます。問題が出ているドメインについて、(1) IPv4 で張った接続と IPv6 で張った接続でルールが変わらないか、(2) 同じホスト名でもアドレス種別で別ルールに落ちていないかを比較してください。外部の IP 診断サイトはフィーチャーフラグや並列テストが多く、一行だけ見て結論を出さないのがコツです。
セルフチェックの例：(1) 現行クライアントへ更新、(2) IPv6 を一時オフにした対照、(3) TUN とシステムプロキシのどちらで再現するか、(4) ルールプロバイダの更新、(5) 別ノードでの再現性、(6) dns と fake-ip の整合。これでも改善しない場合は、ISP 側の IPv6 経路や MTU、キャリアグレード NAT の癖まで疑う段階に入ります。
- コアと GUI を最新に：IPv6 周りの修正は継続的に入ります。
- ログを宛先 IP でフィルタ：IPv6 のみ遅いかを特定。
- GEOIP／RULE-SET を更新：データが古いと誤マッチ。
- ルール順を再確認：上位の広いルールに吸われていないか。
- DNS を単一路に：DoH と Clash の二重解決を避ける。
7. まとめ
Clash IPv6 を有効にしたあとにだけ現れる「中国向けサイトの遅さ」や「診断サイトの変な表示」は、IPv4 だけを前提にしたルール・DNS・OS 設定とのギャップとして説明できることが多いです。インタフェース束ねとAAAA の扱い、GEOIP／IP-CIDR6 とルール評価順、TUN と DNS を順にそろえれば、プロキシ漏れと誤解される現象か、単なる迂回や RTTかがはっきりします。
設定の細部はコアのバージョンで差があるため、常に公式ドキュメントとリリースノートを正とし、ログの実名でルールを追記してください。長期的には IPv6 を無効のまま固定せず、期待する経路に合わせてルール側を IPv6 対応へ育てるのがおすすめです。
プロファイル全体の組み立て方は ドキュメント概要と合わせて読むと、dns と rules の責務分担が掴みやすくなります。