二重スタックで「漏れる」ように見える理由

多くの環境では、端末は IPv4 と IPv6 の両方を同時に持ちます（二重スタック）。Clash は接続ごとにルールを評価しますが、アプリが IPv6 の宛先を選んだセッションは、IPv4 だけを想定したルールや DNS の整理と別レーンで動くことがあります。結果として「プロキシは有効なのに測速サイトでは ISP の IPv6 が見える」「一部ホストだけ意図しない出口」といった漏洩に見える現象が出ます。ここでいう漏洩は、文脈によって（1）トンネル外へ DNS クエリが出た、（2）トンネル外の物理インターフェースへトラフィックが出た、（3）Happy Eyeballs などで v6 が先に選ばれた、のいずれかを指します。切り分けは層を分けるのが早いです。

まず dns ブロックで AAAA レコードをどう扱うかと、ルールが IPv6 フローにマッチしているかを同じ表で見ます。詳細なキー名はコア版・GUI によって揺れるため、手元の アップグレード手順 に沿ってドキュメントと突き合わせてください。本稿の YAML は教育用の骨格です。

ℹ 先にログ：症状再現直後に、Clash の接続ビューで宛先が v4 か v6 か、DIRECT とプロキシのどちらに入ったかを並べます。ここで v6 だけ別出口になっていれば、DNS 以前にルーティング／ルールを疑う価値があります。

dns ブロック：ipv6 と名前解決

Clash Meta／Mihomo 系では、dns: 配下に ipv6: false のような指定があり、AAAA を返さない／使わせない方向に寄せられることがあります（実装と版で意味合いが異なるため、公式の説明を優先してください）。意図はシンプルで、アプリに IPv6 の宛先候補を渡さなければ、その分「v6 だけ別経路」という分岐が減ります。一方、すべてのトラフィックを IPv4 に寄せるわけではなく、OS が別経路で v6 を張るケースは残ります。enhanced-mode: fake-ip と併用する場合は、Fake-IP と LAN の例外や Sniffer の話とも線でつながります。

nameserver・fallback・fake-ip-filter の全体像は DNS 設定の実践記事 に譲ります。IPv6 の話題だけ抜き出すと、DNS が返すアドレス族とルールが見る情報がズレると、見かけ上の「漏洩」が増えます。ブラウザの Secure DNS や OS の Private DNS をオンにしたままだと、Clash の dns と二重化しやすい点も同じです。

dns: ipv6 sketch (verify keys for your core) 
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

ルール側：DIRECT・GEOIP と IPv6

ルールは上から順にマッチします。GEOIP,CN,DIRECT のような行は、対象となる IP の版（v4／v6）とデータベースの解釈に依存します。IPv6 の国内帯を直結に落としたい場合、IP-CIDR6 やルールプロバイダの v6 セットが不足していないかを確認します。逆に「国内は DIRECT、それ以外はプロキシ」の構成では、v6 の国内判定が抜けると意図せずプロキシへという見え方にもなります。設計の骨格は ルール分流のベストプラクティス に沿って、MATCH 行の意味まで含めて読み直してください。

下の例はイメージです。国コードやグループ名は環境に合わせて置き換え、実ログで増減させます。

rules: IPv6 awareness (illustrative) 
rules:
  - IP-CIDR6,2000::/3,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

TUN と二重スタックの境界

TUN はルーティング層でトラフィックを取り込みますが、すべての v6 が自動的に同じポリシーに乗るとは限りません。スタック優先、除外インターフェース、別 VPN との競合、分割トンネル的な設定が絡むと、「YAML は正しいのに一部だけ外に出る」が起きます。手順の全体像は TUN モードの深掘り を参照し、IPv6 のデフォルトルートがどこを指しているかを OS 側でも確認します。終了後にルートが残る症状は プロキシ終了後の接続障害 のチェックリストとも重なります。

OS で IPv6 を切る（概要）

Clash 側を整えても、OS がグローバル IPv6 を優先するままなら、テストサイトによってはキャリアの v6 が残って見えます。対策は大きく二つです。（1）ネットワークインターフェースで IPv6 を無効化する。（2）ルーター側で IPv6 をオフにする（環境による）。Windows・macOS・Linux ではメニュー名が異なりますが、目的は同じでアプリに v6 の宛先を選ばせないことです。社内端末ではポリシー違反になり得るため、許可を得てから操作してください。

検証：テストサイトとログ

ブラウザの拡張や別 VPN をオフにした状態で、信頼できるDNS 漏洩テストやIP 表示サービスを用い、Before／After を比較します。チェック項目は「表示される IP が期待の出口か」「DNS サーバ名がプロバイダのままか」「AAAA が関与していないか」です。結果は回線・ブラウザ・キャッシュの影響を受けるため、シークレットウィンドウとClash 再起動後の両方で試すとブレが減ります。

コアのログで DNS と proxy の行を並べると、名前解決がどのリゾルバに行ったかの当たりを付けやすくなります。TLS や timeout の読み方は 接続ログの記事 も併用してください。

ルーター運用での注意

OpenWrt やゲートウェイ手前で Clash 系を動かす場合、LAN 側の RA／DHCPv6 と dnsmasq／転送 が別レイヤーで効きます。ブリッジ後の GW・DNS をまとめる話は OpenWrt と OpenClash の記事 が近い文脈です。端末だけ直してもルータが v6 を配り続けると再発するため、どこで名前解決とデフォルトルートが決まるかを図にすると迷子になりにくいです。

⚠ 注意：本稿は自分が管理し、規約上問題のない回線・端末での経路整理を対象とします。第三者のネットワークや契約に反する設定変更は行わないでください。

まとめ

IPv6 二重スタックでは、DNS が返すアドレス族とルールがマッチする IP 版とTUN／OS のルートの三つがずれると、「プロキシしているのに測速では ISP の v6」といった見え方になります。Clash 側では dns の ipv6、ルールの v6 網羅、TUN の取り込み範囲を順に確認し、必要なら OS やルータで IPv6 を無効化して期待する挙動に寄せます。

単一のチェックボックスで直る話ではなく、層を分けてログを残すほど再現と修正が速くなります。

→ 手元のプロファイルで DNS とルールを同じ画面から試したい方は、Clash を無料ダウンロードし、接続ログと編集導線が追いやすいクライアントから検証を始めてください。