よくある症状の置き場所
はじめに、「IPv6 まわり」を触ったあとに出やすい表現を揃えます。ブラウザでは ずっとスピナー、真っ白、DNS_PROBE_FINISHED_BAD_CONFIG や タイムアウト系、あるいは 日本語圏サイトは速いのに海外だけ遅いといった偏りが出ます。CLI ツールでは curl は通るのにブラウザだけ詰まる、逆に特定アプリだけ名前が引けない、というパターンも同じ土台（名前解決の経路の食い違い）に乗ることが多いです。
ここでのポイントは、「全部が壊れた」のではなく「一部ホストだけ」という偏りが出やすいことです。IPv4 だけの経路なら問題ない CDN エッジに対し、AAAA が返ってきた結果、IPv6 で張ろうとしてハングする、あるいは プロキシ内 DNS が返したアドレス族と、クライアント側アプリの想定が噛み合わない、といった切り分けに入ります。
なぜ「IPv6 を有効にした途端、一部だけ」不調になり得るか
大きく三層あります。第一に解像度です。名前に対して A（IPv4）と AAAA（IPv6）の両方が返ると、アプリや OS のスケジューラは状況に応じて 先に試す族を IPv6 側へ寄せることがあります。ところがご自宅回線・テザリング先・会社 VPN・または中継ノード側のどこかで、IPv6 の実パスだけが不安定、もしくは 広告フィルタ／境界装置が IPv6 を中途半端に扱うと、見かけは「そのサイトだけ遅い・開かない」になります。
第二にプロキシ内 DNSです。Mihomo の dns ブロックで prefer-ipv6 を true にすると、上流の応答を尊重しつつ IPv6 を優先する解決結果となりやすく、外の世界が二重化しているのに FakeIP や redir-host モードと整合が取れていないと、ルール照合や実接続先の見え方がずれます。FakeIP と逃がし経路の全体像は Meta コアの DNS 防リーク の稿で束ねています。
第三にルーティングと TUNです。システムが IPv6 を「ある」と宣告していても、既定ゲートウェイやプレフィックスが怪しい、TUN が IPv4 だけ吸っていて IPv6 は素通し、などの組み合わせで、DIRECT 判定のフローが IPv6 へ滑り、その先で詰まる、という形に落ち着くことがあります。
ステップ1：prefer-ipv6 を一時オフして再現が消えるか見る
まずは仮説を最短で潰します。dns の prefer-ipv6 を false に戻す（または行ごと一時コメントアウトする）だけで、症状が一気に緩むなら、優先族の寄せが原因だった可能性が高いです。GUI クライアントによっては「IPv6 を優先」に相当するトグルが別名で出るので、生成 YAML に同趣旨のキーが残っていないかも合わせて確認してください。
コツ：変更は一要素ずつ。prefer-ipv6 だけ戻して挙動が変わるかを見てから、次に FakeIP や ipv6: true を触ると、手戻りが少なくなります。
なお prefer-ipv6 は「必ず IPv6 に振る」魔法ではなく、解決結果の並びや採用のバイアスに近い挙動です。挙動の細部はビルドで差が出るため、最終的には利用中の Mihomo の版メモと合わせておくと安全です。
ステップ2：DNS デュアルスタック（nameserver と fallback）の噛み合わせ
次に、どの DNS に誰が聞きに行っているかを一列に揃えます。OS の検索ドメイン付きリゾルバ、ブラウザのセキュア DNS、VPN が注入したリゾルバ、そして Mihomo の nameserver／fallback——これらが共存すると、同じ FQDN で A と AAAA の中身だけ食い違うことがあります。対策の基本は、プロキシ配下の端末では コアが想定する経路に DNS を集約し、fallback-filter や geoip 系の除外条件が強すぎて 意図せず別ネームへ逃がしていないかを見直すことです。
FakeIP を使っている場合は、フィルタで直結に戻すドメインが多すぎないかも確認します。fake-ip-filter と LAN 直結 の稿は、ローカル名と海外名の住み分けを整理するのに役立ちます。IPv6 を有効にしたことで DIRECT に落ちるフローが増え、そこでローカル DNS とぶつかるパターンも起こり得ます。
ステップ3：FakeIP・Sniffer・HTTPS のメタデータを揃える
ログ上ドメインではなく IP だけが並ぶと、意図した DOMAIN 行より先に IP-CIDR6 や集合ルールに飲まれ、出口と族が期待とズレたまま IPv6 側へ張ることがあります。HTTPS でホスト名を復元する Sniffer や、ルール順の理解（先勝ち MATCH）をセットで当てると、IPv6 問題に見えていた事象が実は ルールの当たり先だった、と判明することも珍しくありません。
ステップ4：プロファイル全体の ipv6 とクライアント側のトグル
ipv6: false のまま部分的に DNS だけ IPv6 寄り、といった 設定の非対称も不具合の温床です。トップレベルの ipv6 と、TUN／システムプロキシ／仮想 NIC の表示を突き合わせ、コアが出しているスタックの宣言と、OS が実際に持っているプレフィックスが噛み合っているかを見ます。社内ポリシーで端末 IPv6 が故意に殺されている環境では、プロキシだけ IPv6 を急に有効にしても外に伸びないので、期待値を合わせるのが先です。
ステップ5：OS・回線・VPN 側の「IPv6 は見えるが通らない」
ブラウザを離れ、端末から 同一ホストへの到達性を族別に見ます（運用ポリシーと利用規約の範囲で）。典型的には、IPv4 のみで確実に通るホストに対し、IPv6 の経路だけブラックホールになるケースです。VPN を併用している場合は、スプリットトンネルが IPv6 を含んでいない、サードパーティ DNS が VPN 外に漏れている、などの組み合わせもあわせて疑います。
ここまで来ても特定ドメインだけおかしい場合は、コアの接続ログで、同一時刻帯の FQDN・命中ルール・出口名を揃えます。connection reset とログの読み方 の稿は、時刻とルールの突き合わせ方が近いので流用しやすいです。
運用向け短いチェックリスト
prefer-ipv6を一時オフし、症状が緩むかを最優先で確認する。nameserver／fallback／OS／ブラウザ／VPN の DNS が重複していないか整理する。- FakeIP 利用時は
fake-ip-filterとルール順を見直し、意図しないDIRECT増加を抑える。 - HTTPS が IP 表示中心なら Sniffer とルール順を含めてホスト名の可視化を揃える。
- プロファイルの
ipv6と OS の実パスの両方を確認し、片側だけ有効な「非対称」を解消する。 - 必要なら、症状ホストだけ A／AAAA の返答を別経路で突き合わせる（変更は最小範囲・短時間に）。
注意：公開 DNS や診断サイトへの大量クエリは避け、再現手順を決めたうえで短時間に絞ってください。職場端末では社内規程と承認フローを優先してください。
配布物とソースの見分け
コアの挙動差はリリースで変わります。Issue やリリースノートで IPv6 まわりの修正を当たるのは有効ですが、日常使用のインストール導線としては、このサイトの 公式ダウンロードページ を基点にすると取り違えが減ります。初回セットアップの流れは Windows でのセットアップ と併せて見ても矛盾しにくいです。
まとめ
Clash Meta／Mihomo で IPv6 か prefer-ipv6 を有効にしたあとに限ってサイトが怪しくなる場合、まずは 名前解決の族優先と プロキシ内 DNS の二重化、そして OS が IPv6 を実際に通せるかの順で切り分けると早いです。FakeIP やルール順、Sniffer まで含めた整合は、単なる「DNS リーク対策」とは少し角度が違うので、本稿の手順はそこを意識して組んであります。
仕上げとして、同じプロファイルでもクライアントによってログの見え方が違うため、GUI を変えずに一度だけでも 接続ログと YAML を往復できる状態にしておくと、IPv4／IPv6 をまたぐ不具合でも手戻りが減ります。迷ったら要素を一つずつ戻し、差分で効く場所を特定するのが安全です。
GUI クライアントや公式ビルドの取りまとめは、リリースノートと対応表が揃った入手導線を先に決めておくと運用が楽になります。