手順1：不通の「範囲」を言語化する（IPv4 単独と IPv6 が混じるとき）
まずは感情ではなくログに残る形へ落とします。プロキシの遅延テストは問題ない一方で、Firefox だけ、あるいは .jp のドメイン群だけタイムアウトするようなホスト粒度の差があれば、IPv6 の有効化と同時に起きたとは限っても強い関連が疑われます。逆にすべてのアプリやすべてのドメインで何も繋がらないなら、ルータ側の WAN、PPPoE の再接続、あるいは TUN と他 VPN の競合など、IPv6 より前の層を先に確認した方が早いです。デスクトップの TUN とシステムプロキシまわり が怪しいときの土台となるのは過去稿のとおりです。
同一マシンの別ブラウザ、シークレットウィンドウ、モバイル回線でのみ再現といった二分も試してください。環境側で IPv6 が「期待どおりのアドレス」ではなく、ULA のみ、あるいはプレフィックスがしばらくで切れる例では、名前解決以前にレイヤが揺れることがあります。ここでの目的はすべてを直すことではなく、「一部サイト」と「すべて」「ローカルのみ」を分離して再現プロファイルを確定させることです。
もし問題が「IPv6 を OS でオフにしたら直る」の一点に強く収束するなら、経路側の問題が強い証拠です。いっぽうオフでも残るときは、アプリ側のキャッシュや Fake-IP の残り香、上流 DNS の ECS 応答とのミスマッチなど、名前解決層にも焦点を広げます。
手順2：OS と NIC のIPv6状態（実アドレスと優先順位）
Clash が賢く動くにも OS がどのソースから IPv6 アドレスを取り、その優先順位がどうなっているかを把握しておく必要があります。デュアルスタックでは Happy Eyeballs 相当のような挙動で、体感がサイトごとにバラけることがあります。ループバック競合より前に、`ip addr`／Windows での適切なコンソール、あるいは端末ごとの状態画面で、アドレスとプレフィックスの寿命を一度眺めます。プレフィックスが短いとき、または RA が不安定な AP を跨いだときにも部分的不通になりやすく、プロキシの経路とは独立して追う価値があります。
WSL2 や仮想スイッチ、Docker Desktop のブリッジが噛んだ環境では、ホストとは別論理での IPv6 が混ざることもあります。ここでのミスポイントは「OS は IPv6 もってるね」で済ませることです。サイトが参照する名前解決先と、ブラウザが実際に開こうとした宛先タイプ IPv4 と IPv6 のどちらが先にタイムアウトしたか、開発者ツールのネットワーク列で読むと論点が明確になります。
このステップだけで問題が解けることはまれですが、この後に書くコアの IPv6 と合わせると、「端末側はもう大丈夫か」「まだ揺れるか」を切り離せます。揺れるなら OS 側のネットワーク診断を挟んでください。そのうえで、まだ上流の Fake-IP や DNS は触っていない段階なら、構成の切り分けがしやすくなります。
手順3：Clash / mihomo コアの IPv6 とプロファイルの論理オンオフ
多くの分岐において、アプリ側のプロファイルに ipv6: true/false のようなスイッチ（実装およびキー名はコアのバージョンに合わせてください）が存在し、アウトバウンドの IPv6 が効くかどうかが変わります。ここを「オンにしたので全部 IPv6」のように捉え過ぎると誤読しやすく、効くのは主にコアから外へ張る側の許可であり、アプリ側の IPv6 クエリ処理や DNS とルール評価順とは別のレイヤにある点に注意してください。コアごとの項目名やデフォルトはリリースノートで細かく動くので、定期的に見直すユーザーは Meta コアのアップデート概要 をあわせて確認するとよいです。
IPv6 がオフでもルール評価上はドメインベースだけで済むサイトが、そのうち AAAA が返ってきて IPv6 で落ちるサイトが混じるとき、オンオフだけで結果が反転しないこともあります。そこへ向けられているのが次のステップにある DNS と Fake-IP です。この段では「コアの IPv6 と OS の状態が両方そろっているか」を Yes/No に落とします。
# Illustrative YAML — adjust keys to your fork (mihomo / Clash Meta)
ipv6: true
# Some builds also expose per-profile or mixed-stack toggles; verify docs.断片が動く構成を保証するものではなく、論点確認用のサンプルである点は合わせておいてください。
手順4：DNS と AAAA 応答／Fake-IP フィルターの噛み合わせを見る
ユーザーの体感では「名前は解けるのに読み込めない」状態と「ずっと解決にも失敗」を混同しがちです。Fake-IP を使うとき、AAAA を返させるか、アプリ側にどの順で名前を渡すかはコアおよびクライアントの組み合わせで異なります。上流へ投げているリゾルバが応答しない AAAA で詰まる例、ECS で返るアドレス帯だけが異なる結果になる例があります。
一方で nameserver-policy で国内サフィックスを特定のリゾルバへばらす構成では、そのリゾルバが IPv6 のクエリにも十分対応しているか、レイテンシでフォールバックが長くなるか、アプリ側のタイムアウトが先に来ることがあります。ここでの実務的手法は、(1) まずクエリログが取れる状態にすること、(2) 問題サイトのクエリだけを切り出す、(3) 上流を切り替えて対照試験に回すという三段です。
ローカルの /etc/resolv.conf とクライアントの統合済み名前解決、ブラウザ内 DoH との二重競合にも注意してください。名前解決の入口が増えるほど、IPv6 の有効化とセットで問題が増幅しやすいです。この稿のねらいとはズレますが関連として、同じ名前解決周りには DNS 全般や Redir での読み込み順が厚い 前述の別稿 が橋になります。
手順5：分流ルールとポリシーの順——IPv6 宛にも効いているか
ここまでで「名前は取れているのに転送側でタイムアウト」となるなら、分流ルール とポリシーが IPv4 と IPv6 の両方について意図した出口を指しているかを疑う段です。GEOIP と IP-CIDR 系のセットが IPv4 に偏っており、IPv6 で落ちてくるだけが DIRECT のまま外に出ずにタイムアウトする構成は典型のひとつです。ルールの先頭にある DOMAIN-SUFFIX と後段の GEOIP が矛盾していないか、購読の Rule Provider の更新順で意図せず古いセットが載っていないかも含め確認します。YAML とポリシーの書き方 の体系を頭に置いたうえで、この稿では強調するのは「IPv6 のアドレス帯」をルールセットがカバーしているかという視点です。
ポリシーが PROXY と DIRECT を行き来しているとき、アプリ側の接続開始が複数ソケットに分かれると片方だけ想定外のポリシーに振り分けられることもあります。ログのアウトバウンド名と規則名を突き合わせ、問題が起きたドメインの実アドレス型が IPv6 だったかまで言語化できると恒久対処に跳びやすくなります。
| 症状のニュアンス | まず読むログの部位 |
|---|---|
| 海外サイトだけ読めない | GEOIP とルールセットの順、IPv6 が DIRECT のまま落ちないか |
| 国内のみ遅い | 国内向け名前解決ポリシーと AAAA、アプリ側のフォールバック順 |
| モバイルのみ再現 | 運用キャリアの IPv6 PDP／セグメント単位での遮断との噛み合わせ |
手順6：TUN モードとの重なり／スタック競合と最終まとめ
最後に TUN を有効にしている場合、スタック優先順と他 VPN とのアダプタ順序が競合し、結果として IPv6 のみ切断されるケースがあります。ウィンドウと macOS とで UI の名称は異なりますが、仮想アダプタのメトリックやサービス順を一度開けば、どのインタフェース経由でSYNが実際には出ようとしているか推測しやすくなります。ここでのよくある失敗は、「システムプロキシだけ切り替えたら大丈夫」という先入観で、TUN 経路のログを見ずに済ませてしまうことです。
以上の順は厳密に一本道ではなく、自分の構成で一番コストが小さい順に並べ替えても構いません。ただサイトが開かない系のときに多いのが、名前解決の入口とルール評価の出口のどちらか一方だけしか見ずに済ませがちという点であり、両方ログを残すだけでも再現調査が段違いに楽になります。TLS 側の細部が気になるときは証明書と SNI 周りの TLS の別稿 に横回りできますが、論点が IPv6 から動いているなら本章の順を優先する価値があります。
まとめると、この稿で押さえたいのは三段です。(1) 症状が全体かホスト粒度か、(2) Fake-IP と DNS と接続イベントの三本をログで並べられるか、(3) 分流ルール が IPv6 宛にも揃っているか。ここまで揃うと無用なオンオフ反復を避けられる割合が大きくなります。IPv6 と Clash が重なる領域は今後も厚くなるため、自分用のチェックリストに追記できる形での保存をおすすめします。
よくある質問（抜粋）
IPv6 を有効にした途端に一部サイトだけ開かなくなるのはなぜですか？
デュアルスタックでは名前解決と接続の両方が二本化され、どちらか片方だけ運用者の前提と異なるときにサイト単位で症状がばらけやすくなります。ISP 側の広告応答や一時障害だけでなく、アプリ側のフォールバック順と Clash の出口がそれぞれ別の問題を運ぶときに「別サイトは大丈夫」になります。IPv6 と Clash が重なる箇所をログで並べれば、体感でなく根因に近い推定ができるようになります。
Fake-IP モードは IPv6 とどう相互作用しますか？
Fake-IP はドメインでルールに乗せやすくする強力な選択ですが、IPv6 の AAAA や QUIC、HTTP3 などアプリ側の前提と干渉しやすいケースがあります。名前解決の入口を一度整理し、問題ドメインを fake-ip-filter に含めるべきか、あるいは redir に寄せるべきかを少数のクエリだけ切り離して検証すると、原因のレイヤまで距離が詰めやすくなります。
すべてを直す前に OS で IPv6 をオフでもよいですか？
切り分けの中間状態として許容されることもありますが、将来のサイトやサービスが IPv6 優先になりつつある前提では恒久策として単純なオフに頼らないほうが再発を防ぎやすいです。IPv6 と Clash の組み立てまで含めログに残していれば、そのオフ実験の意味も後から評価しやすくなります。
締めくくり
本稿では、Clash IPv6 周辺で起きやすい部分的不通へ向けて、OS のデュアルスタックの健全性、クライアント側の出口と名前解決との整合、およびTUN まで含めて疑う順序を並べました。いちどこの流れが手になじめば、「全体が繋がらない」と「サイトが一部だけ開かない」を短時間で二分する材料になります。mihomo フォークによりキー名称が変わっても、このスケジュールでの観察の仕方自体は転用できるはずです。クライアントの入手経路が一本化されている環境ほど検証ログの再実行が効きやすく、端末ごとの差異を吸収しやすくなります。
ほかの解説記事やテーマ別リストは技術コラムからどうぞ。