IPv6 デュアルスタックでも Clash TUN で実 IP が見えたり、地域だけおかしい？OS で IPv6 を抑え、mihomo の DNS と分流を IPv4 と同じ枠組みで校正する（2026）

1. TUN をオンにしても足りない典型：デュアルスタックの「二本線」

TUN は、ざっくり言えばカーネルのルーティングテーブルに仮想インタフェースを差し込み、トラフィックをユーザー空間のコアへ引き上げる仕組みです。そのため HTTP(S) のシステムプロキシを無視するアプリでも、経路次第では同じ rules: に載せられる、というのが実務上の利点になります。ところが IPv6 が有効なままだと、アプリやブラウザは AAAA レコードを握った瞬間にIPv4 のルール評価とは別の経路へ進みやすくなります。

代表的なのが Happy Eyeballs です。IPv6 と IPv4 の両方に接続を張り、先に応答した方へ流す、という方式はユーザ体験には優しい一方で、Clash 側で IPv4 だけ整備していたつもりでも、IPv6 が先に応答してしまうと、意図しない「直結側」の出口番号が観測されます。診断サイトによってIPv4 と IPv6 の表示欄が別々になっている場合、「片方だけプロキシ」「片方だけ自宅 ISP」のように見えるのは、この力学が関係します。

つまり TUN は入口を広げる部品であり、IPv6 という第二経路まで同じルール思想で噛み合わせたかは別問題です。TUN モードの解説で述べているとおり、例外プロセスやプラットフォーム固有の穴と合わせて、「IPv6 をどこで止めるか／コアに載せるか」をセットで決めるのが安定運用の近道です。

2. 症状の見立て：実 IP・DNS 漏えい・地域の食い違い

まずウェブの IP チェックで「IPv4 は海外ノード、IPv6 は国内 ISP」のように二重表示になるケースは、IPv6 ルートがコア外に残っているサインです。次に、ストリーミングやクラウド API だけ地域制限がおかしい場合、ドメイン単位のルール不足というより、名前解決がクライアント独自経路（DoH 等）に逃げている、またはIPv6 の名前と実接続の評価が一致していない可能性が高くなります。

「DNS が漏れている」という表現は曖昧ですが、実務では （a）クエリが Clash の DNS フロントに届いていない、（b）fake-ip とルール評価のホスト名が噛み合っていない、（c）IPv6 の逆引きや別リゾルバが並走している、の三つに大別できます。（a）（b）は Sniffer と SNI の稿で触れた TLS の実名復元と相性がよく、（c）は IPv6 を OS で無効化するか、mihomo の DNS セクションでIPv6 を生成しない・無視する方向へ寄せるのが筋です。

切り分けの順番としては、同じテストホストを IPv4 のみ／IPv6 のみに固定して比較するのが最も素直です。ブラウザ拡張や端末ポリシーで DoH が固定されている場合は、OS 全体の設定と食い違うため、コンソールツールとブラウザで挙動が分岐します。サブスクリプション導入でまず購読が載っている前提でも、IPv6 は別問題として観測される点に注意してください。

3. OS／カーネル側で IPv6 を段落どおりに抑える

正攻法は二つあります。（A）IPv6 を完全にオフにして一本化するか、（B）IPv6 を残したまま優先度やルーティングだけコア側へ寄せるかです。法人端末では（A）がポリシーにより禁じられることもあるため、まずは組織ルールを確認してください。家庭回線では（A）の方が検証が早く、トラブルの切り分けにも向きます。

Windows 11 では「設定」→「ネットワークとインターネット」→該当アダプタのプロパティから インターネット プロトコル バージョン 6（TCP/IPv6）のチェックを外すのが分かりやすいです。ネットワーク毎に記憶されるため、Ethernet と Wi‑Fi の両方を見落とさないことが重要です。また、モバイルホットスポットやテザリングは別プロファイルになるので、症状が「外出先だけ」になると切り分けやすくなります。

macOS ではシステム設定のネットワーク詳細か、ターミナルからインタフェース単位で一時的に無効化する方法があります。Wi‑Fi と有線の優先順位、VPN プロファイル、iCloud プライベートリレーなどが絡むと、見かけだけ TUN が効いているように見えることがあります。macOS での Verge Rev 初回設定と合わせて、ネットワーク拡張の許可範囲を確認してください。

Linux（デスクトップ）はディストリビューションごとに既定が異なり sysctl や NetworkManager で IPv6.disable_ipv6 を触る例が多いです。サーバ用途のドキュメントと開発マシンの手順は混同しやすいため、自分のディストロの公式手順を正にしてください。WSL やコンテナからホストの Clash を参照している場合は、WSL2 の稿の住み分けも意識すると、IPv4/IPv6 の取り違えが減ります。

4. mihomo 側：TUN スタックと DNS セクションの噛み合わせ

mihomo / Clash Meta 系では、コアのバージョンと GUI のラッパーによって既定値が異なります。大切なのは、「TUN セクションで IPv6 をどう扱うか」と「DNS で AAAA をどう扱うか」が同じ方針かどうかです。片方だけ IPv6 を切っても、もう片方が AAAA を返し続けると、先述の二本線問題が残ります。

以下は構造の例です。キー名や階層は利用中のバージョンのドキュメントに合わせてください（コメントは説明用で、実機の YAML には不要です）。

# Example shape only — align keys with your mihomo / GUI export
tun:
  enable: true
  stack: system   # or gvisor — pick what your client documents
  auto-route: true
  strict-route: true
  inet6-address:
    - fdfe:dcba:9876::1/128  # example ULA; adjust/remove if IPv6 off OS-wide

dns:
  enable: true
  ipv6: false       # avoid generating IPv6 answers when OS IPv6 is disabled
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16

fake-ip を使う場合、HTTPS が IP レコードで評価に入るとドメインルールが空振りします。Sniffer の有無や override-destination の扱いはリリース差があるので、不具合が出たらデバッグログで「どの名前でマッチしたか」まで落とし込む運用が確実です。ルールルーティングの基本線を崩さず、DNS の fake-ip とセットで設計してください。

また、一部ブラウザが アプリ内 DoH を強制する場合、OS の DNS と完全に独立します。そのときは「Clash の DNS セクションで何をしたか」より先に、そのブラウザが握っているリゾルバを疑う段階に入ります。

5. 分流の校正：IP-CIDR6・ルール順・MATCH まで一本線

IPv4 だけの GEOIP と DOMAIN-SUFFIX に慣れていると、IPv6 のプレフィックスがルールの外に落ちる事象が起きやすくなります。典型は、海外のコンテンツ CDN が IPv6 宛ての応答を返し、IP-CIDR6 系の行が未整備のまま MATCH へ滑るパターンです。ルールプロバイダを使う場合も、IPv6 用セットが同梱されているか、あるいは自前で追記するかを確認します。

分流の「校正」とは、同じサービスについて IPv4 と IPv6 の評価結果が同じ策略名に着地する状態を指します。順序の基本は、広い GEOIP より具体的なサフィックスとプレフィックスを上に置き、最後に MATCH です。Discord や Steam のようなドメイン散在型とは別物ですが、発想は Discord の稿で述べた「名前の束ねと実接続の一致」と同じです。

rule-providers の更新失敗で古いセットに留まると、IPv6 側だけ別経路に見えることもあります。更新周りの切り分けは rule-providers と GEOIP の稿を参照してください。

# Example only — replace groups and prefixes for your network
rules:
  - IP-CIDR6,2001:db8::/32,REJECT   # placeholder documentation prefix
  - GEOIP,cn,DIRECT
  - MATCH,PROXY

上の 2001:db8::/32 は文書用の例示プレフィックスで、実ネットワークでは使いません。自宅 ISP が配っている実プレフィックスや、購読ルールに含まれる IP-CIDR6 行をログと照合しながら足し込むのが安全です。

6. 実測：チェックリストとログの見る順

推奨の順序は次のとおりです。（1）OS で IPv6 をオフにし、同じ診断ページを再測定して差が消えるか確認する。（2）IPv6 をオンに戻し、mihomo で TUN と DNS の IPv6 方針を揃えたうえでも差が残るかを見る。（3）コアのデバッグログで、問題のホストが 意図した策略名にマッチしているか、評価されている IP バージョンを追う。（4）ルールプロバイダと GEOIP データの更新日を確認する。

端末が複数ある場合、同じ出口ノード・同じルールでも IPv6 の有無で結果が分岐するので、比較実験は同一端末・同一ネットワークで行うのが鉄則です。社内回線では技術的に可能でもセキュリティポリシーに抵触する操作は避け、ネットワーク管理者の許可を得てください。

フェイルオーバや自動選択の挙動まで含めて調整したい場合は、url-test と fallback の稿も参照できます。IPv6 の有無で RTT の解釈が変わる点にだけ注意してください。

7. よくある落とし穴

第一に、「TUN をオンにしたから IPv6 も自動で安全」という誤解です。スタックや OS ポリシー、例外アプリによっては抜け道が残ります。Windows の UWP 系は専用稿の通りです。

第二に、DNS のページだけいじって TUN や OS IPv6 を放置するパターンです。ログ上、名前は綺麗でもトランスポートが IPv6 直結になり、地域判定だけおかしい、という見え方をします。

第三に、利用者の契約や法令に反する回避を助長する語りは避けます。本稿は正当な権限のあるネットワーク上で、意図した経路と名前解決を一致させるための一般的な整理です。

8. まとめ

IPv6 デュアルスタックは、Clash TUN を使うほど「IPv4 側だけ上手くいっているように見える」罠を増幅しやすい環境です。対策の芯はシンプルで、OS またはカーネルで不要な IPv6 を抑えるか、残すなら mihomo の TUN・DNS・ルールを同じ前提で校正するかの二段構えになります。Happy Eyeballs と DNS 漏えいの三分類を頭に置いておけば、見かけのランダムさがかなり減ります。

GUI とコアの組み合わせごとに既定が異なるのが実情なので、安定したクライアントから環境を揃えたい方は、まず公式の入手経路から最新版を取りましょう。無料で体験できるダウンロードページは → 無料で Clash をダウンロードして、意図した経路と名前解決をそろえる ところから始めるのがおすすめです。オープンソースの参照先やバグ報告は GitHub から可能ですが、インストーラの主経路は当サイトのダウンロードページに置いておくのが混乱が少ないです。