Clash 運用ログの読み方:ログレベル・主なエラーの意味と原因特定手順

ログレベルと読み方の順序

mihomo コアを採用したクライアントは、起動時および稼働中に継続してログを出力します。ログレベルは通常 silent、error、warning、info、debug の5段階に分かれ、設定ファイルの log-level フィールドで制御します。レベルには包含関係があり、info を選ぶと info・warning・error の3種類が同時に出力され、debug を選ぶとすべての情報が含まれるため、データ量が最も多く最も詳細になります。

問題を調査する際、最初から debug ログを見るのはおすすめしません。情報量が多すぎるとかえって原因特定が遅くなります。合理的な順序は次の通りです。まず起動段階に error レベルの赤いエラーが出ていないかを確認し、コアが正常に起動できているかを見ます。次に接続要求時の warning を確認し、ネットワーク層の問題かルール層の問題かを判断します。最後に前の二つの手順で手がかりが見つからない場合のみ、debug レベルに切り替えて該当リクエストを再現し、ドメイン解決、ノード選択、ルールマッチの順序が想定どおりかを一行ずつ確認します。

頻出エラーの逐条解説

以下のエラーはログ内で最も頻繁に見られるもので、発生条件を理解することは文言を暗記するより有用です。

DNS 解決失敗

ログに「resolve host failed」や「dns resolve error」といった内容が出る場合、通常は設定内の nameserver が正常に応答していない、あるいは対象ドメインがそもそも解決対象範囲に含まれていないことを意味します。この種の問題は主に3つの場面で発生します:カスタム DNS サーバーに到達できない、DNS over HTTPS のアドレスが誤っている、そしてルールで特定ドメインに no-resolve を設定しているにもかかわらず外部への解決が必要になっている、というケースです。確認方法としては、まずシステム標準のネットワークツールで nameserver 一覧のアドレスが利用可能かを個別にテストし、次にルールセット内の対象ドメインのマッチタイプが正しいかを確認します。

ハンドシェイクタイムアウト

「handshake timeout」や「dial tcp timeout」といったエラーは、クライアントとプロキシノードの間で接続を確立する段階でタイムアウトが発生し、実際のデータ転送にまだ入っていないことを指します。よくある原因には、ノードのサーバーがすでにオフラインになっている、サブスクリプションリンク内のポート情報が古い、ローカルネットワークが特定ポートを制限している、そしてノードが位置する地域のネットワーク経路自体が不安定である、などが挙げられます。この種のエラーに遭遇したら、まずサブスクリプション内の他のノードに切り替えてテストしてください。複数のノードで同様にタイムアウトする場合は、問題がサブスクリプション自体ではなく端末側のネットワーク環境にある可能性が高いです。

ルール未マッチとフォールバック戦略

ログ内で特定のドメインが最終的に MATCH や FINAL ルールに対応するポリシーグループに落ち着くケースが頻発する場合、それより前のすべてのルールにマッチしなかったことを意味します。これは必ずしもエラーではありませんが、そのドメインが本来特定のルールを通るべきだった場合は、ルールの順序やマッチタイプの記述が誤っていることを示します。mihomo のルールマッチは上から下への順序マッチであり、一度いずれかのルールにマッチすると以降の比較は行われません。したがって範囲の広いルールは範囲の狭いルールより後に配置する必要があり、そうしないと狭いルールが有効になる機会が永久に失われます。

接続拒否とポート競合

「connection refused」の多くは対象ポートで待ち受けているサービスが存在しない、あるいはローカルのプロキシポートが他のプログラムと競合していることを意味します。起動段階でログにポートが既に使用中と表示された場合、まず複数のクライアントインスタンスが同時に起動していないか、あるいはシステム内の他のツールが同じミキシングポートを占有していないかを確認してください。

ログから設定の問題を特定する手順

ログのエラー自体は単なる現象にすぎず、本当に必要なのはその現象と設定ファイル内の具体的なフィールドを対応させることです。実行可能な調査手順は次の通りです:

1. エラーが発生した段階を確認する——コア起動時に発生したのか、それとも特定の接続要求を発行した際に発生したのかで、調査すべき範囲は全く異なります。
2. エラーに関わるドメインまたは IP を記録し、設定ファイルに戻ってこのドメインが一致しうるルール項目を検索し、マッチタイプが想定どおりかを確認します。
3. ノードの問題が疑われる場合は、ポリシーグループ内で単一のノードのみに切り替えてテストし、ポリシーグループ内の複数ノードのローテーションによる干渉を排除します。
4. ログが DNS 層のエラーを示している場合は、dns 設定ブロック内の nameserver、fallback フィールドを個別に検証し、必要であれば一時的にパブリック DNS アドレスに変更して比較テストを行います。
5. 問題を特定したら、一度に一箇所だけ設定を変更して再起動して検証し、複数箇所を同時に変更してどの変更が問題を解決したのか判断できなくなる事態を避けます。

ログの可読性を高める設定の勧め

日常利用では log-level を info に保つことをおすすめします。このレベルであれば重要な接続状態を確認できる一方、大量のデバッグ詳細に埋もれることもありません。クライアントが画面内で直接運用ログを確認できる機能を備えている場合は、画面内のリアルタイムログパネルを優先的に利用してください。通常は時系列順にスクロール表示されるため、手動でログファイルを開くより直感的に把握できます。断続的な問題に遭遇した場合は、まず再現手順を固定し、再現前後のタイムスタンプを記録してから、その時間帯でログを絞り込むと、探す範囲を大幅に短縮できます。

また、ルールセットやサブスクリプション内容を更新した後は、新しいルールが想定どおりの順序で有効になっているかを確認するため、一度ログをあらためて観察することをおすすめします。実際の利用中に振り分け結果がおかしいと偶然気づいてから遡って調査するのではなく、設定変更後の固定手順としてログ確認を組み込むことで、ルールの順序やフィールドの誤字による問題の大部分を事前に発見できます。