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

Clash Verge Rev で macOS のモバイルホットスポット接続時に TUN から通信できない場合の修正方法

Mac を iPhone のインターネット共有につなぎ、直接接続は正常なのに Clash Verge Rev の TUN が空のインターフェースを示す場合は、外部接続に使うアダプターを調べ、継続して適用される上書き設定で固定します。項目、DNS、実際のリクエストを確認し、異常時は上書きを解除して元の設定に戻します。

  • Clash Verge Rev
  • macOS
  • モバイルホットスポット
  • TUN
目次

Macがスマートフォンのテザリングで直接接続できるのに、TUNを有効にするとページが開けない場合、後から出るDNSエラーは出口のアダプターが見つからないためかもしれません。起動ログを残し、システムの経路から実際にテザリングに使われているアダプターを確認してから、一時的にインターフェースを固定するか判断します。

テザリングの直接接続は正常なのに TUN のログでインターフェースが空になる

Intel MacをiPhoneのインターネット共有に接続し、Clash Verge Rev TUNを無効・有効にして、直接接続はできるのにプロキシでは接続できないか確認します。公式issue #7576の環境はクライアントv2.5.2とMihomo v1.19.29です。ほかのMacでは、同じログが出る場合にだけ続けてください。

重要なのは Web ページにタイムアウトと表示されることではありません。TUN の起動直後に get empty name、<invalid>、interface not found が順に現れ、その後で dns resolve failed が表示される点です。これは、出口の自動検出時に空のインターフェースが最初に取得され、その結果 DNS とプロキシ接続に利用可能な出口がなくなったことを示します。

モバイルホットスポット使用時の TUN 送信経路
  1. iPhone のインターネット共有Mac に現在のネットワーク出口を提供する
  2. macOS の物理ネットワークインターフェースroute コマンドで実際の interface を表示する
  3. Mihomo TUNそのインターフェース経由で DNS 問い合わせと接続を行う
  4. 対象の Web サイト名前解決、ルール照合、アクセスを完了する

自動検出の第二段階で空の値を取得すると、その後の DNS と送信はすべて失敗します。インターフェースの固定が適用できるのは、このログの特徴がある場合だけです。

システムルートから、ホットスポットが現在使用しているネットワークインターフェースを調べる

まず TUN を無効にし、macOS を直接接続できる状態へ戻してから、ターミナルでグローバルアドレスへのルートを調べます。コマンド出力の interface が、その時点でホットスポットのトラフィックを実際に処理している物理ネットワークインターフェースです。他人のスクリーンショットから名前を推測しないでください。

現在のデフォルト出口を表示し、interface の後にある値を記録する
route -n get 223.5.5.5

ローカルで実際に得た結果だけを記録する

  1. 直接接続できることを確認する

    TUN とシステムプロキシを無効にし、ブラウザで通常の Web ページを開きます。障害発生中のルートを読み取らないようにしてください。

  2. interface の行を探す

    issue の報告者には en0 と表示されましたが、Wi-Fi、USB ネットワークアダプター、Ethernet では別の名前になる可能性があります。

  3. もう一度実行する

    モバイルホットスポットを切断して再接続した後にもう一度調べ、インターフェース名が変わっていないことを確認してからオーバーライドへ書き込みます。

ログからインターフェースと権限のどちらを調べるか選ぶ

症状判定内容次の手順
TUN を無効にすると、システムの直接接続がすぐに復旧する少なくともノードとシステムネットワークが同時に失敗しているわけではない出口インターフェースの確認を続ける
ログの先頭に get empty name または <invalid> が表示される自動検出で出口をすぐに取得できていない現在の物理ネットワークインターフェースを調べる
ログには operation not permitted だけが表示されるこれは権限またはサービスモードの問題です出口インターフェースを変更しないでください
システムプロキシと TUN のどちらでも接続できないノード、サブスクリプション、カーネルの障害である可能性があるまず共通する障害を解決する

Mergeで出力先のネットワークインターフェースを指定し、自動検出を無効にする

Mihomo の interface-name は最上位の送信インターフェースで、auto-detect-interface は tun の配下に置きます。現在の Profile の Merge またはオーバーライド設定を開き、この二つのキーだけを追加してください。issue にある TUN、DNS、IPv6 の設定一式はコピーしないでください。以前から動作している設定まで置き換わるおそれがあります。

en0 を前の手順で確認した実際のインターフェースへ置き換え、Merge を保存する
interface-name: en0
tun:
  auto-detect-interface: false

ここでの en0 は例にすぎません。また、tun.device へ指定しないでください。公式ドキュメントによると、macOS の TUN デバイス名は utun で始まります。一方、interface-name は Mihomo がトラフィックを実際に外部へ送信するインターフェースを指し、用途が異なります。

再起動後にインターフェースのエラー、DNS、ページ表示を確認する

同じ順序で検証する

  1. 現在の設定を再読み込みする

    元の Profile と元のノードが引き続き選択されていることを確認し、サブスクリプション、DNS、プロキシモードを同時に変更しないでください。

  2. TUN を再び有効にする

    今回の起動位置からログを読み始め、<invalid> または interface not found が引き続き表示されるか確認します。

  3. 二種類のリクエストを送信する

    同じノードで新しい DNS 問い合わせと HTTPS リクエストを行い、接続画面に対応するドメイン、ルール、実際の出口が表示されるか確認します。

  4. TUN を無効にして比較する

    システムの直接接続が引き続き復旧することを確認し、一度キャッシュにヒットしただけの状態を修正完了と誤認しないようにします。

空のインターフェースと interface not found がどちらも消え、Web ページが復旧する

インターフェースの固定により、今回の自動検出失敗を回避できています。ネットワーク切り替え時の検証へ進んでください。

引き続き interface not found と表示される

インターフェース名が誤っているか、すでに変わっています。TUN を無効にしてからシステムルートを調べ直してください。

インターフェースのエラーは消えたが、引き続き dns resolve failed となる

DNS フィールドの追加を中止し、オーバーライドを取り消してから、独立した DNS の問題として調査してください。

設定の検証に失敗する

interface-name が最上位にあり、tun 配下のインデントが半角スペース二つになっているか確認します。

最終確認リスト

  • システムプロキシを無効にして TUN だけを有効にすると、ブラウザとターミナルの両方で新しい接続が発生する
  • ログに get empty name、<invalid>、interface not found が表示されなくなった
  • 接続ページに、想定したドメイン、ルール、プロキシまたは直接接続の出口が表示される
  • 同じホットスポットを切断して再接続した後も、インターフェース名とオーバーライドが一致している
  • TUN を無効にするとシステムの直接接続がすぐに復旧し、Mac の再起動は不要

インターフェースを固定した後は、ネットワークを切り替えるたびに再確認する

インターフェースを手動で指定すると、自動検出は停止します。モバイルホットスポット環境を一時的に安定させるには有効ですが、ホットスポットから自宅の Wi-Fi、USB ネットワーク、Ethernet へ切り替えると、元のインターフェースがデフォルト出口ではなくなる可能性があります。更新を忘れると、TUN が有効でも新しい接続を確立できない状態が再発します。

ネットワーク変更後の対処

問い合わせ結果対処方法
interface とオーバーライドの値が同じ現在の設定を維持し、DNS と Web ページを続けてテストする
interface が別の名前に変わっているTUN を無効にし、interface-name を更新してからカーネルを再起動する
今後、ネットワークを頻繁に切り替える必要がある固定インターフェースのオーバーライドを削除して自動検出へ戻し、問題が再発するか確認する
別の VPN または TUN を同時に実行している一つずつ無効にしてテストし、固定値でルーティング競合を覆い隠さない

効果がなければオーバーライドを削除し、元の設定へ戻す

正しいインターフェースを固定しても失敗する場合、現在の障害は自動検出だけに起因するものではありません。入手元が不明な DNS、ルート、スクリプトの設定を追加せず、まず変更前の Profile へ戻してください。

今回のインターフェース上書き設定を取り消す手順

  1. TUN を無効にする

    システムの通常のネットワークが復旧するのを待ってから Merge を変更し、以前のカーネルが障害のあるルートを使い続けないようにします。

  2. 二つのオーバーライドキーを削除する

    最上位の interface-name と、今回追加した tun.auto-detect-interface を削除し、変更前の内容へ戻します。

  3. 元の Profile を再読み込みする

    元のノードとルールを維持し、システムプロキシで一度アクセスして、基本的な接続が引き続き利用できることを確認します。

  4. 機密情報を除去したログを残す

    macOS、クライアント、カーネルのバージョンと、TUN を有効にした後の最初のエラーを記録し、該当する公式 issue へ提出します。

参考資料