接続トラブルシューティング · Clash 技術ブログ

Clash Verge Rev：macOS TUN の DNS 障害

macOS 版 Clash Verge Rev で TUN を有効にした後、ドメイン名でサイトを開けない場合は、サブスクリプション・実行時設定・基本設定の DNS を比較し、dns セクションが残っていないか確認します。バックアップ後、公式の案内に従って残存部分を削除し、動作を検証します。

本文を読むブログへ戻る
  • Clash Verge Rev
  • macOS
  • TUN
  • DNS
  • config.yaml
目次
執筆者
Clash 公式
公開日
更新日時
読了時間の目安
約 9 分

サブスクリプションの名前解決設定が揃っていても、仮想アダプターを有効にするとドメイン名でアクセスできなくなることがあります。アプリが使うのは統合後の設定なので、どの設定が名前解決を変更したかを確認します。通常の接続手段を確保し、サブスクリプション、基本設定ファイル、実行時設定を保存してから、確認済みの残存フィールドを処理するか判断します。

TUN を有効にすると名前解決できない：実行設定の dns は欠けていない？

この手順が当てはまるのは、TUN を無効にすると通常の通信または同じノードを使うシステムプロキシが機能し、TUN を有効にするとドメインの名前解決に失敗し、さらに基本設定と実行時設定に該当する差分がある場合です。

アプリが使うのは統合後の設定です。基本 config.yaml に不完全な dns ブロックが残っていると、サブスクリプションの名前解決設定を上書きする可能性があります。下の表で DNS の残存設定、権限、インターフェース、ノードの問題を区別してから、三つのファイルを保存して比較してください。

名前解決、権限、インターフェースのエラーを区別する

確認できた証拠最初に判断する内容
実行時設定の dns が enhanced-mode だけで、基本設定の config.yaml にも同じ残存部分があるこの記事で扱う設定の上書き経路をさらに確認する
TUN のスイッチがすぐ戻る、またはログに operation not permitted が出るまず macOS のサービス権限を確認する
ログに get empty name / interface not found が先に出るまず現在の送信インターフェースを確認する
システムプロキシと TUN の両方で同じサイトへアクセスできないまず Profile、ノード、共通の DNS 障害を調べる

TUN を無効にして通信を戻し、サブスクリプション、基本ファイル、実行設定を保存する

まず TUN を無効にし、macOS の通常の通信がすぐ戻るか確認します。システムプロキシがもともと使えていたなら、当面はその方式だけを利用できます。アプリを終了しても通信できない場合は、システムのネットワーク設定に古いプロキシや DNS が残っていないか確認してください。試すために故障中の TUN を何度も有効にしないでください。

変更する前に、元のサブスクリプションまたは Profile、基本設定の config.yaml、アプリが生成した実行時設定を別々に保存し、クライアントとコアの現行バージョンを記録します。

v2.5.7/v2.5.8では、Profiles（サブスクリプション）ページで現在のサブスクリプションのカードを右クリックし、Edit Fileを選びます。Profileの原文を確認してコピーし、保存せずに閉じてください。Edit Infoはサブスクリプション情報のフォームで、ファイルの原文を表示する画面ではありません。

基本設定は通常、~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev/config.yamlにあります。端末のアプリ用ディレクトリやファイルマネージャーで実際の場所を確認してください。ここで確認するのは基本設定であり、dns_config.yamlや実行用の設定ではありません。

統合後の設定は、同じページの右上にあるView Runtime Configの文書アイコンで確認できます。このウィンドウには、アプリが生成した統合後の設定が読み取り専用で表示されます。サブスクリプションの原本や基本config.yamlとは異なるため、基本ファイルを実行用の設定と取り違えないでください。

サブスクリプションや設定にはノードの認証情報が含まれる場合があります。バックアップは端末内の安全な場所に保管し、公開する報告には伏せ字にしたコピーだけを使います。

同じネットワークで三つの状態を記録します。TUN を無効にしたときドメインを名前解決できるか、TUN を有効にした直後の最初の DNS または TUN のログ、再び無効にしたとき通信が戻るかです。これにより、ブラウザーのキャッシュ、ノードの障害、システム権限ではなく、DNS を引き受ける経路で問題が起きているか判断できます。

三つの設定のうち、どれがサブスクリプションの 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 上流の到達性、ルール、ノード、インターフェース、サービスログを調べる。

Clash Verge Rev の issue #8122 には、macOS の一台で v2.5.6、サービスモード、Mihomo v1.19.31 を使用した際の不具合が記録されています。TUN を有効にすると、それまで直接接続で開けていたサイトもドメイン名では開けなくなり、報告者は実行時設定に dns.enhanced-mode: redir-host しか残っていないことを確認しました。

このissueは2026年10月2日にクローズされました。議論には詳しい再現手順と少数の同じ症状の報告がありますが、クローズされたことは汎用的な修正が確認されたことを意味しません。また、すべてのMacやサブスクリプションで同じ障害が起きるとも断定できません。

報告者は当初、「DNS 上書き」を無効にするとサブスクリプションの dns が削除されると考えていました。プロジェクトメンバーの説明は、基本 config.yaml の不完全な dns ブロックが統合時にサブスクリプションの DNS を上書きし、enable: true がないためコアの DNS が使えなくなる、というものです。

公式の拡張設定文書では、DNS 上書きが無効なら、アプリ自体はサブスクリプションの 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、再起動後のいずれでもドメインにアクセスできるか確認する

再生成された実行時設定で、dns.enable と nameserver が元のサブスクリプションまたは拡張設定で想定した値と一致するか確認してください。画面上の DNS オーバーライドのスイッチだけでは判断できません。同じ Profile とノードに固定し、システムプロキシと TUN の各モードで同じ実際の HTTPS サイトを開き、接続記録とログで名前解決の成功を確認します。

さらにアプリを完全に終了して再起動し、TUN のテストを繰り返します。そのセッション中だけ動く場合は、起動時に書き戻す設定元がまだ残っている可能性があります。TUN を無効にした後、Mac 全体の再起動なしに通常の通信が戻ることも確認してください。

DNS テストページに特定のアドレスが表示されること、TUN のスイッチが点灯したままであること、遅延テストに数値が出ることのどれか一つだけを成功基準にしないでください。目的のドメインを名前解決でき、ページ全体が読み込まれ、接続記録が想定どおりで、再起動後も維持されてはじめて、復旧を確認できます。

まだ失敗する場合のロールバックと上流への報告

残存部分を削除した後に設定の検証が失敗する、以前の振り分けが変わる、または TUN で通信できないままなら、まず TUN を無効にします。次に基本設定の config.yaml を変更前のバックアップから復元し、アプリを再起動します。古い設定では今回の DNS 障害が再発する可能性がありますが、復元する目的は元の設定と調査用の証拠を残すことです。当面の通信には、検証済みのシステムプロキシか、DNS を引き受けない通常のネットワークを使ってください。

実行時設定に完全な DNS があるのにドメインが開けないなら、nameserver 自体への到達性、現在のネットワークに組織の DNS があるか、ほかの VPN/TUN が動作していないか、最初のコアエラーを別途確認します。エラーを消すためにシステムの安全対策を無効にしたり、すべての Profile やアプリのデータディレクトリを削除したり、適当なパブリック DNS に切り替えたりしないでください。

#8122 へ報告する場合は、macOS、Clash Verge Rev、Mihomo のバージョン、TUN とシステムプロキシの比較、三つの設定に含まれる dns 関連部分の伏せ字にした抜粋、再起動前後の結果を添えます。報告者の説明と、プロジェクトメンバーが指摘した残存設定の判断は分けて記録してください。現時点で、同様のすべての通信断が修正済みと保証できる正式版の告知はありません。

参考資料