目次
ログから TUN のループストームが発生していることを確認する
この記事で扱うのは、Windows で起きる明確な一連の症状だけです。Clash Verge Rev のシステムプロキシは利用できていたのに、TUN を有効にするとログへ reject loopback connection が連続して表示され、verge-mihomo.exe からノードへのダイヤルが繰り返し失敗します。その後 CPU 使用率が大きく上昇し、深刻な場合はカーネルが thread exhaustion を報告してクラッシュします。
公式 issue #7764 には、サービスモード、Clash Verge Rev v2.5.2、Mihomo v1.19.29 および v1.19.30 で、この障害の連鎖が記録されています。報告者は最終的に、自動検出で v2rayN の Wintun 仮想ネットワークアダプターが選ばれていたことを確認しました。実際のイーサネットインターフェースへ手動で固定すると、ループログ、CPU の異常、スレッド枯渇がすべて止まりました。
これは、複数の仮想ネットワークアダプターを搭載した一台のパソコンで得られた、原因から解決までの確認結果です。すべての TUN タイムアウトがインターフェース選択に起因するわけではありません。ログに reject loopback がない場合、または TUN を無効にしてもシステムプロキシが失敗する場合は、サブスクリプション、ノード、DNS、サービスモードを先に確認してください。
三つの兆候で問題の範囲を限定する
| 兆候 | この問題で見られる症状 | 一致しない場合 |
|---|---|---|
| きっかけとなる操作 | TUN を有効にして数秒後から始まる | システムプロキシも失敗する場合は、共通する経路を先に確認する |
| ログの中心となる内容 | verge-mihomo.exe がノードへダイヤルし、reject loopback を繰り返す | 一般的なアプリだけがタイムアウトする場合は、同じ障害ではありません |
| リソース使用量の変化 | CPU 使用率が急上昇し、thread exhaustion が発生する場合がある | リソース使用量が安定している場合は、最初のエラーに沿って切り分けを続ける |
- verge-mihomo.exe現在のプロキシノードへ送信ダイヤルを開始する
- 誤って選択された仮想ネットワークアダプターauto-detect-interface が実際の物理的な送信経路を使用していない
- Mihomo TUNカーネル自身のダイヤルが再び TUN へ入る
- ループの検出と再試行reject loopback が続き、CPU 使用率とスレッド数が急速に増える
送信インターフェースを現在のデフォルトルートが使用する物理ネットワークアダプターへ固定すると、カーネルのダイヤルが自身の TUN へ戻らなくなり、ループログとリソースストームが同時に止まるはずです。
TUN を無効にして、まずパソコンを安定した状態へ戻す
ログが大量に繰り返されている場合は、まず TUN を無効にしてください。同時にノードを切り替えたり、DNS を変更したり、カーネルを何度も再読み込みしたりしないでください。CPU 使用率が下がるのを待ち、元の Profile とノードのままシステムプロキシを有効にして、Web ページへ一度アクセスします。システムプロキシが復旧すれば、サブスクリプションとノードには利用可能な基盤が残っており、障害は TUN の送信先選択に集中していると判断できます。
画面がすでに応答しない場合は、まずタスクマネージャーから Clash Verge Rev を通常終了し、Windows のシステムプロキシが停止済みのローカルポートを参照し続けていないことを確認します。直接接続を復元してから、アプリのログ、現在の実行設定、ネットワークアダプター一覧をエクスポートしてください。設定のコピーからは、サブスクリプションの token、ノードのアドレス、パスワードを必ず削除します。
ロールバック可能な調査基準を作る
TUN を無効にする
新しいループダイヤルを止め、CPU 使用率とログへの書き込みが正常へ戻るまで待ちます。
システムプロキシを検証する
元の Profile とノードを変えず、システムプロキシだけを有効にして新しいリクエストを一度送ります。
現在の Merge を保存する
使用中のオーバーライドと最終設定をコピーし、以後は送信インターフェースに関する二つのフィールドだけを変更します。
最初のログ部分を残す
クライアント、カーネル、Windows の各バージョンと、最初の reject loopback 前後で機密情報を伏せた内容を記録します。
現在実際に通信している物理ネットワークアダプターを特定する
TUN を無効にしたまま、PowerShell で表示可能なネットワークアダプターと IPv4 のデフォルトルートを同時に確認します。Get-NetAdapter の Name は後で入力するインターフェース名です。Get-NetRoute からは、現在どのネットワークアダプターがデフォルトの送信先を担当しているかが分かります。無線ネットワークは Wi-Fi、有線ネットワークはイーサネットまたは Ethernet と表示される場合があるため、必ず手元の端末で得た結果を使用してください。
Get-NetAdapter -Name * |
Format-Table Name, InterfaceDescription, Status, LinkSpeed, ifIndex
Get-NetRoute -DestinationPrefix "0.0.0.0/0" |
Sort-Object RouteMetric |
Format-Table InterfaceAlias, NextHop, RouteMetric, InterfaceMetric結果から誤った候補を除外する
| 結果 | 判定内容 |
|---|---|
| Status が Up で、デフォルトルートが同じ InterfaceAlias を使用している | 現在の実際の送信先として優先的に検討する |
| 名前または説明に Wintun、TAP、VMware、VirtualBox が含まれている | 仮想アダプターの場合は、LinkSpeed だけで選択しない |
| ネットワークアダプターは Up だが、現在のデフォルトルートがない | 仮想マシン、VPN、LAN のいずれかだけに使われている可能性がある |
| Wi-Fi とイーサネットの両方にデフォルトルートがある | 使用していない方を先に切断し、実際の送信先をもう一度確認する |
自動選択の結果をデフォルトルートと照合する
先ほど保存した実行設定と今回の起動ログを開き、auto-detect-interface が有効か、Mihomo が実際に採用した送信インターフェースはどれかを確認します。システムのデフォルトルートが物理的な Wi-Fi またはイーサネットであるのに、ノードへのダイヤルが Wintun、TAP、VMware のインターフェースへバインドされたとログに表示される場合に限り、公式 issue の根本原因と一致します。
仮想ネットワークアダプターが公称する高速な速度だけで判断しないでください。#7764 の環境では vgate0 が 100 Gbps と報告したため、自動検出が誤った送信先を選択しました。インターフェースに関する証拠が揃ってからオーバーライドを追加します。選択結果を確認できない場合は、名称を推測するのではなく、ネットワークアダプター一覧と最初のログ部分をプロジェクトのメンテナーへ提出してください。
デフォルトルートはイーサネットだが、実行ログでは vgate0 が使われている
インターフェースの誤選択に一致するため、最小限のオーバーライドへ進みます。
デフォルトルートと Mihomo が同じ物理ネットワークアダプターを使用している
既知の根本原因とは一致しないため、この記事の設定を適用するのを止めます。
ログに dns resolve failed だけが表示されている
まず DNS の経路を確認し、reject loopback の問題として扱わないでください。
ほかの VPN を無効にすると問題が解消する
競合するソフトウェアとネットワークアダプターを記録し、インターフェースを固定する必要はありません。
Merge では送信インターフェースだけを固定する
Mihomo の公式設定では、interface-name はトップレベルの送信インターフェース、auto-detect-interface は tun の下に置く項目として定義されています。現在の Profile の Merge またはオーバーライドを開き、この二つのフィールドだけを追加してください。issue にある TUN と DNS の設定全体をコピーせず、物理ネットワークアダプター名を tun.device へ記述しないでください。
interface-name: "以太网"
tun:
auto-detect-interface: false変更を最小限に保つ
インターフェース名が完全に一致することを確認する
スペース、ハイフン、言語表記まで一致させ、InterfaceDescription を Name の代わりに使用しないでください。
保存して設定検証を実行する
interface-name はトップレベルに置き、auto-detect-interface は tun の下でスペース二つ分だけインデントします。
ほかのフィールドは変更しない
元のノード、ルール、DNS、stack、strict-route を引き続き使用し、一度に二つ目の変数を加えないようにします。
カーネルを完全に再起動する
新しい実行設定に二つのオーバーライド値が含まれていることを確認してから、制御された TUN テストを一度行います。
一回の制御されたテストでインターフェースの修正を検証する
カーネルを再起動したらログを先に開き、その後 TUN を有効にします。テスト画面を見える状態に保ち、通常の HTTPS リクエストを一つ送ってください。reject loopback が再び大量に表示されたら、直ちに TUN を無効にします。実際に修正できたかは、ログ、CPU、カーネルの稼働、実際の接続がすべて変化したことで判断し、TUN のスイッチが有効なままかだけを見ないでください。
公式 issue の報告者は、物理イーサネットへ固定した後、ループストームが完全に消え、CPU 使用率が正常へ戻り、v1.19.29 と v1.19.30 のどちらでもスレッド枯渇が再発しないことを確認しました。上流の issue #3122 は、その後 Mihomo カーネルの変更不要として終了しています。したがって、この事例を新しいカーネルバージョンで修正済みの問題として記載すべきではありません。
インターフェース修正の完了基準
- TUN を有効にしても、新しい reject loopback connection が表示されない
- タスクマネージャーで verge-mihomo.exe の CPU 使用率が安定している
- カーネルが動作し続け、thread exhaustion や繰り返す reload がない
- 同じノードで新しい HTTPS リクエストを一度完了でき、接続記録にも表示される
- TUN を無効にすると、システムの直接接続がすぐに復旧する
ループが消えた後、残った DNS エラーは別に対処する
#7764 ではインターフェースの問題を解決した後、別の DNS 設定エラーも明らかになりました。その一つは DoH ドメインのブートストラップループでした。メンテナーは、報告者による proxy-server-nameserver の初期判断も訂正しています。issue にある DoT、nameserver-policy、DNS 設定例全体を自分の設定へコピーしないでください。
reject loopback が消えて CPU 使用率も正常なのに、Web ページで dns resolve failed が続く場合は、検証済みのインターフェース用オーバーライドを残し、同じノードでドメインの名前解決と直接アクセスを比較します。DNS に関する証拠が明確な場合だけ、該当する上流またはポリシーを変更してください。切り分け済みの二つの障害を再び混同しないようにします。
インターフェース修正後に現れる次のエラー
| 症状 | 対処方法 |
|---|---|
| 接続記録にドメインがあり、ノードへのダイヤルも正常 | インターフェースの問題は解決済みなので、実際のサービス検証を続ける |
| dns resolve failed だけが表示される | DNS の上流、ブートストラップ、proxy-server-nameserver を確認する |
| 引き続き reject loopback が表示される | TUN を無効にし、実際のインターフェース名と実行設定をもう一度照合する |
| 設定の検証に失敗する | オーバーライドを取り消し、トップレベルのフィールドと YAML のインデントを確認する |
ネットワークを切り替えたらインターフェースを更新し、無効になった場合は完全に元へ戻す
自動検出を無効にすると、Mihomo は手動で指定したネットワークアダプターを使い続けます。有線接続から Wi-Fi、モバイルホットスポット、USB ネットワークアダプターへ切り替えると、元のインターフェースがデフォルトルートを担当しなくなる場合があります。ネットワーク切り替え後に TUN が再び機能しなくなった場合は、まず TUN を無効にして読み取り専用の確認を繰り返してください。古いインターフェース名をすべてのネットワーク環境へ恒久的に残さないようにします。
オーバーライドが機能しない場合は元の状態へ戻す
TUN を無効にする
Windows の直接接続が復旧したことを確認してから Merge を編集します。
二つのフィールドを削除する
トップレベルの interface-name と、今回追加した tun.auto-detect-interface を削除します。
元の Profile を再読み込みする
システムプロキシを使い、元のサブスクリプション、ノード、ルールが引き続き動作することを確認します。
機密情報を伏せた証拠を残す
実際のネットワークアダプター一覧、最初のエラー、実行設定の差分を提出し、サブスクリプションやノードの認証情報は公開しないでください。
六つの項目で Windows の TUN が復旧したことを確認する
最終確認リスト
- システムプロキシを利用でき、TUN を有効にしても元のリクエストを正常に完了できる
- 新しいログに reject loopback、thread exhaustion、カーネル置換のループがない
- 実行設定の interface-name が、現在のデフォルトルートのインターフェースと一致している
- タスクマネージャーで一定時間確認しても、CPU 使用率とスレッド数が増え続けない
- ノードを切り替えるか新しい接続を開始すると、接続画面に想定したルールと出口が表示される
- TUN を無効にしてクライアントを終了すると、Windows の通常のネットワークが復旧する