Clash Verge Revのログの見方｜よくあるエラーの意味と原因の切り分け

リクエストを一度再現し、同じ時刻のログを確認する

Clash Verge Revのログから、設定が読み込まれたか、ドメインが名前解決できたか、どのルールに一致したか、プロキシノードに接続できたかなど、障害が発生した段階を判断できます。赤いエラー表示があっても、すべての接続が止まっているとは限りません。エラーが1件あっただけで、サブスクリプションが無効だとも断定できません。まず操作内容を特定し、その時刻付近のログを確認しましょう。

クライアントとmihomoカーネルでは、担当する処理が異なります。サブスクリプションのダウンロード、画面操作、サービス管理などはクライアントログに記録されることがあります。一方、プロキシ接続、ルール照合、DNS処理は主にカーネルログに記録されます。「サブスクリプションの更新に失敗する」場合は更新操作の表示を、「ブラウザーでページを開けない」場合はカーネルの接続ログを優先して確認してください。

サイドバーから「ログ」を開き、現在時刻を控えます。ほかのダウンロードや速度測定は一時停止してください。
問題が起きるWebサイトを1つだけ開いて一度更新します。複数のタブを同時に開くのは避けましょう。
ログから該当時刻のドメイン名、ポート、エラー内容を探します。検索欄があればキーワードを入力し、なければ必要な部分をコピーしてテキストエディターで検索してください。
「接続」画面で接続先、適用されたルール、プロキシチェーンを確認します。短時間の接続はすぐに消えることがあるため、その場合は記録済みのログを参照してください。

ログレベルの切り替え方：通常はinfo、原因調査時はdebug

ログレベルは記録の詳しさを決めるもので、接続を直接修復する設定ではありません。「ログ」画面の上部にログレベルの選択項目があるか確認してください。その機能に対応したバージョンでは、info から debug に一時的に切り替えられます。画面にフィルターしかない場合は、「受信済みログの絞り込み」と「カーネルのログレベル変更」を区別しましょう。表示を絞り込むだけでは、記録されなかった詳細が後から追加されることはありません。

レベル	記録される内容	用途
`silent`	ログ出力を無効化	発生中の問題の調査には不向き
`error`	エラー	明確な失敗だけを記録するため、前後の手がかりを見落としやすい
`warning`	警告・エラー	異常の確認向け。一部の接続処理は表示されない
`info`	情報・警告・エラー	通常利用と初期調査
`debug`	デバッグ情報を追加	DNS、ルール、接続の問題を短時間で再現して調査

画面にログレベルの設定がない場合

mihomoで対応する設定項目はトップレベルの log-level です。設定を変更する場合は、まずバックアップを取り、使用中のバージョンが対応する上書き・マージ機能から次の1行を追加して、設定を再読み込みします。サブスクリプション更新で上書きされる元の内容だけを編集したり、編集しただけで変更が適用されたと思い込んだりしないでください。

log-level: debug

問題を再現して詳細なログが記録されることを確認し、設定が反映されたか確認してください。調査後は info に戻します。デバッグログにはアクセス先のドメイン、LAN内のアドレス、プロキシ名などが含まれることがあります。長時間有効にしたまま、ログ全体を公開するのは避けてください。

接続タイムアウト：ノードと接続先のどちらで発生したか確認する

i/o timeout、context deadline exceeded、connect: connection timed out は、いずれも処理が制限時間内に完了しなかったことを示しますが、発生箇所はそれぞれ異なる可能性があります。エラーの前後に dial tcp があれば、接続先のIPアドレスとポートを確認しましょう。timeoutという文字だけを見てDNSを変更するのは避けてください。

dial tcp 203.0.113.10:443: i/o timeout
context deadline exceeded

ここで使っている 203.0.113.10 はドキュメント用の例示アドレスであり、接続可能なノードのテストには使えません。実際のログにあるアドレスがプロキシサーバーのものなら、端末からノードまでの経路を確認します。リクエストが DIRECT に一致している場合は、接続先Webサイトのアドレスかもしれません。複数段のプロキシチェーンを使っている場合は、どの区間で失敗したかも確認してください。

同じ接続先で条件を比較する

1つのノードだけタイムアウトする：同じプロキシグループで、利用可能と確認済みの別ノードに切り替え、同じURLにアクセスします。問題が解消した場合は、元のノードのアドレス、ポート、サービス状態、ネットワーク到達性を優先して確認してください。
複数のノードがすべてタイムアウトする：端末のネットワーク、ポータル認証、ファイアウォール、プロキシサーバーのアドレス解決を確認します。複数のノードが同じドメインを共有している場合は、共通の接続先に問題がある可能性もあります。
1つのWebサイトだけタイムアウトする：ルールと通信の出口を確認します。接続先サービスの障害、出口側の制限、ルーティングの異常でも同じ症状が起こります。
速度測定は成功するのにWebページを開けない：速度測定では通常、設定されたテスト用URLにのみアクセスします。任意のWebサイト、UDP通信、すべてのプロトコルで利用できることを保証するものではありません。

まずタイムアウト時間を大幅に延ばすのは避けましょう。待ち時間を延ばしても、エラーが表示されるまでの時間が変わるだけです。誤ったノードアドレスを修正したり、遮断された通信経路を復旧したりすることはできません。

DNS名前解決エラー：名前解決できない場合とDNSサーバーに届かない場合を区別する

no such host、DNS resolve failed、DNS上流サーバーのアドレスを含むタイムアウトが発生した場合は、まず名前解決に失敗したドメインを確認します。プロキシサーバーのドメインを解決できないと、多くのWebサイトが利用できなくなることがあります。特定のWebサイトだけで失敗する場合は、そのドメインを中心に調べてください。

キーワード・症状	考えられる意味	最初に確認すること
`no such host`	今回の名前解決で利用可能な結果が得られなかった	ドメインの入力ミス、ドメインの有効性、現在の名前解決経路
DNSリクエストがタイムアウト	上流サーバーから時間内に応答が返ってこない	DNSサーバーへの接続可否、上流への接続経路
`connection refused`	DNSサーバーのアドレスまたはポートへの接続が拒否された	ローカルDNSサービスの起動状態、待ち受けアドレスとポート
プロキシサーバーのドメインだけ解決できない	プロキシ接続を確立する前の名前解決に問題がある	ノードのドメイン解決とプロキシへの依存関係

システムのDNSテスト結果は、カーネルのDNSテスト結果と同じとは限らない

比較のためにシステムコマンドを使えます。以下のコマンドはドキュメント用の例示ドメインを問い合わせます。

nslookup example.com

システムの名前解決に成功しても、そのコマンドで使われた経路から結果が返ったことしかわかりません。mihomoでは、独自の dns.nameserver、暗号化DNS、ドメイン別のポリシー、プロキシサーバー専用の名前解決設定を使うことがあります。その結果を直接置き換えて考えることはできません。ブラウザー独自のセキュアDNSが別の経路を使っている場合もあります。

TUNを有効にしている場合は、DNSリダイレクトが想定した通信を処理しているかも確認してください。Fake-IPモードでは、接続情報に設定済みの合成アドレス範囲が表示されても、必ずしも異常ではありません。たとえば 198.18.0.0/16 はFake-IP用アドレスプールとしてよく使われます。最終的な接続先は、ドメインとの対応関係やルールと合わせて判断してください。このアドレスだけを見てDNS設定全体を削除しないでください。

設定ファイルの解析エラー：行番号からインデントを確認し、次にフィールド参照を調べる

設定の読み込みエラーは、通常、接続が確立する前に発生します。よくあるメッセージは yaml: line 12: did not find expected key、フィールドの型不一致、ルールが参照するプロキシグループの不存在などです。この場合、ノードを何度も切り替えても解決しません。まず設定を解析し、カーネルの検証を通過させてください。

インデントとフィールド型のエラー

# 誤った例：nameserver の階層が一致していない
dns:
  enable: true
 nameserver:
    - 1.1.1.1

# 正しい例：同じ階層のフィールドをそろえ、リストを nameserver の下に置く
dns:
  enable: true
  nameserver:
    - 1.1.1.1

YAMLのインデントにはスペースを使い、Tabを混在させないでください。行番号は解析器が問題を検出した位置を示していることが多く、実際の原因は前の行にある場合もあります。コロンの付け忘れ、閉じていない引用符、リストのインデント誤りなどを確認しましょう。エラー行だけでなく、前後数行も合わせて読んでください。

フィールドの型：mixed-port: 7897 にはポート番号を指定します。リスト型のフィールドを、ひと続きの文字列に変更することはできません。
名前の参照：ルールで指定するポリシー名は、実在するプロキシまたはプロキシグループと一致させる必要があります。プロキシグループ名を変更した場合は、rules 内の参照も確認してください。
ルールプロバイダー：RULE-SET で参照する名前は、rule-providers 内で定義されている必要があります。ダウンロードの失敗と、名前が存在しない問題は別々に確認してください。
設定の読み込み元：サブスクリプション更新後にだけ失敗する場合は、エラー表示と更新前の設定を残してください。そのうえで、サブスクリプションの応答内容に問題があるのか、ローカルの上書き設定と新しい設定が競合しているのかを切り分けます。

ポートの接続拒否と競合：エラーに表示されたアドレスがどちら側のものか確認する

connection refused は接続が明示的に拒否されたことを示します。アドレスが 127.0.0.1:7897 なら、まずリモートノードではなく、ローカルのプロキシが待ち受けているかを確認してください。クライアントの「設定」で現在の混合ポートを確認し、カーネルが正常に動作しているか確かめます。アプリにプロキシポートを手動入力している場合も、同じ値にしてください。

connect to 127.0.0.1:7897: connection refused
listen tcp 127.0.0.1:7897: bind: address already in use

もう1つのエラーは、待ち受けポートがすでに使用中であることを示します。Windowsでは、ターミナルで以下のコマンドを実行し、待ち受け中のプロセスとPIDを確認できます。

netstat -ano | findstr :7897

macOSと、lsof がインストールされたLinuxでは、同じTCPポートを待ち受けているプロセスを次のコマンドで確認できます。

lsof -nP -iTCP:7897 -sTCP:LISTEN

まずプロセスの所有者を確認し、見慣れないシステムプロセスを安易に終了しないでください。クライアントの混合ポートを 7898 に変更する場合は、ブラウザー拡張機能、ターミナルの環境変数、その他の手動プロキシ設定も合わせて更新します。システムプロキシを使うアプリでは、システムプロキシの状態を再確認し、古いポートを参照したままにならないようにしてください。

接続を拒否しているのがリモートノードのアドレスなら、ノードのポートとサービス状態を確認してください。同じエラーキーワードでも、アドレスによって確認対象が異なります。

TLSエラー、接続リセット、TUNの異常を見分ける

TLS証明書とハンドシェイクのエラー

x509: certificate has expired or is not yet valid が表示された場合は、まずシステムの日付、時刻、タイムゾーンを確認し、次にサーバー証明書の有効期間を確認します。certificate is valid for のようなメッセージは、証明書のドメイン名が一致していない可能性があります。ノードのサーバーアドレス、TLSのサービス名、サブスクリプションのパラメーターを確認してください。

TLS handshake timeout は証明書エラーとは異なり、通信経路の遮断、パケットロス、リモート側が想定どおりに応答しないことなどが原因として考えられます。証明書検証の無効化を万能な解決策として使わないでください。すべてのハンドシェイク失敗を解決できるわけではなく、認証の安全性も低下します。

接続リセットとEOF

connection reset by peer は、相手側または通信経路上の機器によって接続がリセットされたことを示します。EOF や unexpected EOF は、読み込み中に接続が終了したことを示します。接続先のサービス、プロキシサーバー、中間ネットワークのいずれも原因になり得るため、この語句だけで原因を特定することはできません。

Webページを閉じた後やダウンロードを終了した後にだけ記録され、実際の利用に問題がなければ、まず様子を見てもよいでしょう。同じアドレスへのアクセスが毎回すぐに失敗する場合は、接続先、使用ノード、発生時刻を記録し、ノードやネットワークを変えて比較してください。

TUNの作成失敗と権限の問題

仮想インターフェース、ルート設定、権限に関するエラーが出た場合は、まずクライアントのサービスモードが正常か、現在のシステムで仮想ネットワークインターフェースの作成が許可されているかを確認します。TUNが処理するのはネットワーク通信であり、ノード自体の障害を修復するものではありません。システムプロキシは正常でTUNだけ失敗する場合は、仮想インターフェース、ルート設定、ほかのVPNとの競合を重点的に確認してください。

テスト中はTUN、DNS、ノード、ルールを同時に変更しないでください。変更前の状態を記録し、一度に1つの項目だけを調整します。2つの通信方式の違いはクライアントの使い方ガイドを、フィールドの意味は応用設定を参照してください。

キーワードで原因を絞り込み、再現可能な調査記録を残す

役に立つ調査記録では、「どの操作が失敗したか」と「どのログが関係するか」を結び付けられます。まず接続先のドメイン名を検索し、同じ時間帯のエラーを確認する方法は、error だけで全体を絞り込むより効果的です。バックグラウンドのヘルスチェック、ルールセットの更新、ほかのアプリもログを出力するため、すべての異常を現在のWebページの問題だと決めつけないでください。

環境を記録：OS、クライアントの実際のバージョン、mihomoの実際のバージョン、システムプロキシとTUNの有効・無効を記録します。バージョンはクライアントに表示された情報で確認し、インストール時期から推測しないでください。
再現操作を固定：対象URL、発生時刻、アプリ名、具体的な症状を記録します。「ページの読み込みが終わらない」「プロキシ接続にすぐ失敗する」など、実際の状況がわかるようにしてください。
前後のログを残す：最初の失敗前後から、関係するログを10～20行ほどコピーします。時刻、エラーのキーワード、ポート、ルール情報は残してください。
条件を1つ比較：ノードだけを切り替えるか、ネットワークだけを変更し、復旧したかを記録します。設定を同時に書き換えた後で、特定のスイッチが有効だったと断定しないでください。
通常の状態に戻す：ログレベルを info に戻し、一時的なテスト設定を取り消して、最終的に動作した設定を保存します。

調査の順序は、設定が読み込まれたか → ローカルポートが待ち受けているか → ドメインを名前解決できたか → 想定どおりのルールに一致したか → ノードと接続先が通信できるか、のように固定できます。経路上で最初に失敗した箇所を解決してから、後続のエラーを確認してください。これにより、変更の繰り返しを減らし、同じ失敗から生じた複数のログを別々の障害と誤認するのを防げます。