目次
TUN による通信断が DNS 設定の経路にあるか確認する
Clash Verge Rev の issue #8122 には、macOS の一台で v2.5.6、サービスモード、Mihomo v1.19.31 を使用した際の不具合が記録されています。TUN を有効にすると、それまで直接接続で開けていたサイトもドメイン名では開けなくなり、報告者は実行時設定に dns.enhanced-mode: redir-host しか残っていないことを確認しました。
この issue は現在も未解決で、詳細な再現報告は一件、ほかに短い同症状の報告が少数あるだけです。すべての Mac やサブスクリプションに影響すると断定はできません。
報告者は当初、「DNS オーバーライド」を無効にしたためアプリがサブスクリプションの dns を削除したと推測していました。
プロジェクトのメンバーは issue のコメントで、より具体的な経路を示しています。基本設定の config.yaml に不完全な dns セクションが残り、実行時設定の生成時にサブスクリプションの DNS を上書きします。その残存部分には enable: true がないため、カーネルの DNS が使えなくなります。
公式の拡張設定ドキュメントも、DNS オーバーライドを無効にしてもアプリ自体はサブスクリプションの dns を変更しないと明記しています。この記事では確認可能な残存設定に絞って調べ、報告者の当初の推測をプロジェクトの結論として扱いません。
この手順が当てはまるのは、TUN を無効にすると通常の通信または同じノードを使うシステムプロキシが機能し、TUN を有効にするとドメインの名前解決に失敗し、さらに基本設定と実行時設定に該当する差分がある場合です。
最初のログが operation not permitted、get empty name、interface not found のいずれかなら、または同じノードがシステムプロキシでも使えないなら、権限、送信インターフェース、ノードの問題を先に切り分けてください。DNS は変更しません。
似た通信断を先に切り分ける
| 確認できた証拠 | 最初に判断する内容 |
|---|---|
| 実行時設定の dns が enhanced-mode だけで、基本設定の config.yaml にも同じ残存部分がある | この記事で扱う設定の上書き経路をさらに確認する |
| TUN のスイッチがすぐ戻る、またはログに operation not permitted が出る | まず macOS のサービス権限を確認する |
| ログに get empty name / interface not found が先に出る | まず現在の送信インターフェースを確認する |
| システムプロキシと TUN の両方で同じサイトへアクセスできない | まず Profile、ノード、共通の DNS 障害を調べる |
まず通信を復旧し、三つの設定ファイルを比較できるよう保存する
まず TUN を無効にし、macOS の通常の通信がすぐ戻るか確認します。システムプロキシがもともと使えていたなら、当面はその方式だけを利用できます。アプリを終了しても通信できない場合は、システムのネットワーク設定に古いプロキシや DNS が残っていないか確認してください。試すために故障中の TUN を何度も有効にしないでください。
変更する前に、元のサブスクリプションまたは Profile、基本設定の config.yaml、アプリが生成した実行時設定を別々に保存し、クライアントとカーネルの現行バージョンを記録します。
基本設定は通常 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yaml にあります。実際の場所は自分の端末のアプリデータ領域またはファイルマネージャーで確認してください。
基本設定を、サブスクリプションのファイル、dns_config.yaml、生成された実行時設定と混同しないでください。
サブスクリプションや設定にはノードの認証情報が含まれる場合があります。バックアップは端末内の安全な場所に保管し、公開する報告には伏せ字にしたコピーだけを使います。
同じネットワークで三つの状態を記録します。TUN を無効にしたときドメインを名前解決できるか、TUN を有効にした直後の最初の DNS または TUN のログ、再び無効にしたとき通信が戻るかです。これにより、ブラウザーのキャッシュ、ノードの障害、システム権限ではなく、DNS を引き受ける経路で問題が起きているか判断できます。
元に戻せる基準状態を確保する
問題を起こす TUN を無効にする
まずシステムの直接接続か元から使えていたシステムプロキシを復旧し、通信できない状態で設定をまとめて変更しないでください。
元のファイルを保存する
サブスクリプション、基本設定の config.yaml、実行時設定を別々にバックアップし、ファイルの場所と変更前の dns セクションを記録します。
最初のエラーを記録する
TUN を有効にする前後のログを書き出し、macOS、クライアント、カーネルのバージョンを記録します。
残存する dns セクションがサブスクリプションを上書きしているか判断する
まず元のサブスクリプションの dns が完全か確認します。特に enable: true、nameserver、および自分が設定したほかの名前解決項目を見てください。次に基本設定の config.yaml に dns.enhanced-mode: redir-host だけ、あるいは同様の不完全な項目が残っていないか確認します。
最後に、アプリが生成した実行時設定が元のサブスクリプションの DNS ではなく、その残存部分に似ているか調べます。三つを比較する前に、「DNS オーバーライド」が無効という理由だけで設定を削除してはいけません。
Mihomo の公式ドキュメントでは、dns.enable はカーネルの DNS を有効にするかどうかを指定し、nameserver などの名前解決項目も説明しています。TUN の dns-hijack は DNS クエリをカーネルに渡します。
実行時設定に利用可能な DNS 経路がないのに TUN がクエリを引き受けると、ドメインへのアクセスは失敗する可能性があります。通常の直接接続やシステムプロキシは使えていたのに、TUN へ切り替えると全サイトが開けなくなる理由はこれで説明できます。ただし #8122 と同じ事例かどうかは、自分の端末の設定差分で判断してください。
Clash Verge Rev の公式ドキュメントによると、v2.5.5 以降、拡張設定に書いた dns フィールドは規則に従って対応する値を上書きします。設定画面、グローバル拡張、サブスクリプションごとの拡張、アプリによる書き戻しには適用順序があります。元のサブスクリプションが正しくても、後段の設定元が最終結果を変えることがあります。基本設定の config.yaml に残存部分がないなら、自分の拡張設定とスクリプトを調べ、今回の issue の手順を無理に当てはめないでください。
元のサブスクリプションの DNS は完全だが、基本設定と実行時設定はともに不完全
バックアップ後、基本設定にあると確認できた残存部分だけを処理する。
元のサブスクリプション自体に enable または nameserver がない
元の設定をサブスクリプション提供元へ確認し、基本設定の上書きと決めつけない。
基本設定は正常なのに、実行時設定が変わっている
グローバル/サブスクリプションの拡張、スクリプト、アプリ設定の適用順序を確認する。
実行時設定の DNS は完全だが、まだ通信できない
DNS 上流の到達性、ルール、ノード、インターフェース、サービスログを調べる。
残存部分を確認した場合だけ、基本設定からその部分を削除する
三つのファイルを比較して上記の経路が確認できた場合に限り、#8122 で示されたプロジェクトメンバーの方法を試します。まずメニューバーのプロセスも含めて Clash Verge Rev を完全に終了します。基本設定の config.yaml をバックアップ済みと確認してください。
次にテキストエディターで、そのファイル内に残存すると確認できた最上位の dns セクションだけを削除します。ほかのキーとサブスクリプションの原文は残してください。config.yaml 全体、dns_config.yaml、Profile、アプリのデータディレクトリを削除したり、再生成される実行時設定を直接編集したりしないでください。
保存後に Clash Verge Rev を起動し、TUN はまだ無効のままにします。実行時設定に元のサブスクリプションで想定した DNS フィールドが戻ったか確認し、まず設定の検証とシステムプロキシ経由の実際の HTTPS リクエストを行います。ここまで正常な場合だけ、短時間 TUN を再度有効にして試します。
報告者は完全な DNS 設定をグローバル Merge に入れる方法で一時的に回避しました。しかし公式ドキュメントでは拡張設定が優先順位に従ってサブスクリプションを上書きします。他人の DNS やルール一式をコピーすると、LAN、組織の DNS、ノードの名前解決方針まで変わるおそれがあります。この記事ではグローバル Merge への注入を一般的な修復方法とはしません。組織管理の端末や一括配布された設定なら、管理者へ連絡してから対応し、管理下の設定を独断で変更しないでください。
変更を最小限にする手順
アプリを完全に終了する
TUN を無効にしてメニューバーからも終了し、アプリが同じファイルへ書き込み続けないようにします。
バックアップと対象を確かめる
基本設定の config.yaml の実際の場所と不完全な dns セクションを確認し、元のサブスクリプションが別に保存されていることを確かめます。
残存部分だけを削除する
サブスクリプションを上書きしていると確認できた、基本設定の最上位の dns マッピングだけを削除します。ほかの設定や生成ファイルには触れません。
検証してから TUN を有効にする
再起動後に実行時設定とログを確認し、システムプロキシが正常に動いてから、時間を限って TUN を試します。
再起動後、名前解決が本当に復旧したか検証する
再生成された実行時設定で、dns.enable と nameserver が元のサブスクリプションまたは拡張設定で想定した値と一致するか確認してください。画面上の DNS オーバーライドのスイッチだけでは判断できません。同じ Profile とノードに固定し、システムプロキシと TUN の各モードで同じ実際の HTTPS サイトを開き、接続記録とログで名前解決の成功を確認します。
さらにアプリを完全に終了して再起動し、TUN のテストを繰り返します。そのセッション中だけ動く場合は、起動時に書き戻す設定元がまだ残っている可能性があります。TUN を無効にした後、Mac 全体の再起動なしに通常の通信が戻ることも確認してください。
DNS テストページに特定のアドレスが表示されること、TUN のスイッチが点灯したままであること、遅延テストに数値が出ることのどれか一つだけを成功基準にしないでください。目的のドメインを名前解決でき、ページ全体が読み込まれ、接続記録が想定どおりで、再起動後も維持されてはじめて、復旧を確認できます。
復旧後の確認リスト
- 元のサブスクリプション、基本設定の config.yaml、変更前の実行時設定の非公開バックアップを復元できる
- 基本設定にあると確認できた残存 dns セクションだけを削除し、ほかのキーは上書きしていない
- 再起動後の実行時設定には想定した enable と nameserver が残り、enhanced-mode だけにはなっていない
- 同じ Profile とノードで、システムプロキシと TUN の両方から実際の HTTPS リクエストが完了する
- 接続記録とログに今回の DNS 障害が再発せず、TUN を無効にすると通常の通信がすぐ戻る
- アプリをもう一度終了・起動しても有効で、見知らぬ DNS 設定やスクリプトをコピーしていない
まだ失敗する場合のロールバックと上流への報告
残存部分を削除した後に設定の検証が失敗する、以前の振り分けが変わる、または TUN で通信できないままなら、まず TUN を無効にします。次に基本設定の config.yaml を変更前のバックアップから復元し、アプリを再起動します。古い設定では今回の DNS 障害が再発する可能性がありますが、復元する目的は元の設定と調査用の証拠を残すことです。当面の通信には、検証済みのシステムプロキシか、DNS を引き受けない通常のネットワークを使ってください。
実行時設定に完全な DNS があるのにドメインが開けないなら、nameserver 自体への到達性、現在のネットワークに組織の DNS があるか、ほかの VPN/TUN が動作していないか、最初のカーネルエラーを別途確認します。エラーを消すためにシステムの安全対策を無効にしたり、すべての Profile やアプリのデータディレクトリを削除したり、適当なパブリック DNS に切り替えたりしないでください。
#8122 へ報告する場合は、macOS、Clash Verge Rev、Mihomo のバージョン、TUN とシステムプロキシの比較、三つの設定に含まれる dns 関連部分の伏せ字にした抜粋、再起動前後の結果を添えます。報告者の説明と、プロジェクトメンバーが指摘した残存設定の判断は分けて記録してください。現時点で、同様のすべての通信断が修正済みと保証できる正式版の告知はありません。
復元できない場合の戻し方と完了基準
- TUN を無効にし、システムの直接接続か元から使えていたシステムプロキシが復旧している
- 基本設定の config.yaml を変更前のバックアップから復元でき、サブスクリプションと拡張設定も失われていない
- 元のログと設定は端末内に保管し、token、パスワード、個人情報を含むパスを除いたコピーだけを共有する
- 今後のバージョンや設定の変更は、公式 issue、ドキュメント、Release で得られる新たな証拠に基づいて決める
