Clash ログの読み方:info/warning/error レベルとよくあるエラーの意味まとめ

ログレベルとは何か、まず正しく設定する

Clash カーネル(オリジナルの Clash であれ Mihomo こと Clash Meta であれ)は共通のログレベル体系を採用しており、詳細な順に debug、info、warning、error、silent があります。設定ファイルでは log-level フィールドに対応し、多くのクライアントでも設定画面に同名のスイッチがあります。日常的な確認は info にして接続が正常に確立されているか見るのがおすすめで、具体的な問題が起きたときだけ一時的に debug に切り替えてより細かいハンドシェイクの過程を確認しましょう。対応が終わったら元に戻すのを忘れずに。debug レベルはログ量が非常に多く、常時オンにするとディスクを消費し、読みにくくなります。

log-level: info
# 接続トラブル調査時に一時的に変更
log-level: debug

4つのレベルの区分は適当に決められたものではなく、意味を正しく理解しておくとログを見た瞬間に注目すべきかどうか判断できます。

• debug:最も細かい粒度で、DNS 解決の詳細、ハンドシェイクの過程、コネクションプールの状態などを含み、通常運用時はノイズが非常に多くなります。
• info:各接続のルールマッチ結果、使用ノード、宛先アドレスを記録します。日常的な監視にはこのレベルが最適です。
• warning:異常が発生しているものの、カーネルが自力での対処を試みている状態を示します。例えば特定ノードのヘルスチェックに失敗しても、他に利用可能なノードが残っている場合などです。
• error:明確な失敗結果です。接続の確立に失敗しており、通常は人手による対応が必要です。

クライアントの GUI にあるログパネルでは、多くの場合レベルごとに色分けされ、warning は黄色、error は赤色で表示されるのが一般的です。これはデザインシステムにおけるセマンティックカラーの使い方と同じ考え方で、色はあくまで優先度の目印であり、具体的な原因はテキストの内容を確認する必要があります。

接続系エラーを1つずつ解説

このカテゴリのログは、カーネルが宛先サーバーやプロキシノードとの TCP/UDP 接続を確立しようとする段階で出力され、「接続できるかどうか」を調べる際に最初に確認すべき内容です。

dial tcp timeout

カーネルが接続を開始した後、タイムアウト時間内に何の応答も受け取れなかったことを示します。よくある原因は3つあります。宛先サーバー自体の応答が遅い、またはすでにダウンしている場合。選択中のプロキシノードから宛先サーバーまでの経路でパケットロスが発生している場合。ローカル環境からプロキシサーバーまでの回線自体が不通の場合(ノードのサーバー期限切れやブロックなど)。調査の順番としては、まず同じプロキシグループ内の別ノードで同じ宛先アドレスをテストしてみましょう。ノードを変えた途端に復旧するなら、そのノード側の問題であり、ローカル設定の問題ではありません。どのノードに変えてもタイムアウトするなら、ローカル環境からプロキシサーバーの出口までの基本的な接続性を確認してください。

connection refused

こちらは timeout とは異なり、相手側が接続要求を明確に拒否していることを示します。つまり回線自体は通っているものの、宛先ポートでサービスがリッスンしていない、またはファイアウォールによって能動的に拒否されている(破棄ではなく)状態です。ログのこのエラーが 127.0.0.1 と何らかのローカルポートを指している場合、多くはカーネル自体が正常にリッスンを開始していないか、mixed-port の設定を変更した後にクライアント画面が同期更新されていないことが原因です。mixed-port の設定値と、実際にそのポートでプロセスがリッスンしているかどうかを確認する価値があります。

no route to host

これはネットワーク層のエラーで、システムのルーティングテーブルに宛先 IP への経路が存在しないことを示します。TUN モードを有効にした際にルーティングテーブルが壊れたり、既存のシステムルーティングと競合したりすると、このログが非常によく出ます。TUN サービスを再起動する、または他のネットワークツールが同時にデフォルトルートを奪っていないか確認することで、多くの場合解決します。

i/o timeout と EOF

i/o timeout は接続確立後の読み書き段階で多く発生し、接続自体は成立しているもののデータ転送が途中で切れたことを示します。ノードの帯域不足や、中間機器による長時間接続の強制切断でよく見られます。EOF は相手側が能動的に接続を閉じたことを示し、たまに1〜2回出る程度なら通常問題ありません。同じノードで頻発する場合は、そのノードを一時的にプロキシグループから外すことを検討してください。

ルールマッチログの読み方

info レベルでは、新しい接続ごとに「マッチしたルールタイプ + 使用ポリシー」といった形式のログが1行出力されます。これはエラーではありませんが、「なぜこのサイトはプロキシを経由しなかったのか」「なぜ速度がおかしいのか」を調べる重要な手がかりになります。

[TCP] example.org:443 match DomainSuffix(example.org) using PROXY
[TCP] cn.example.com:443 match GEOIP(CN) using DIRECT
[TCP] 10.0.0.5:8080 match Match() using REJECT

1行目は、この接続がドメインサフィックスルールにマッチし、PROXY ポリシーグループ経由になったことを示します。2行目は、宛先 IP が中国本土のアドレスと判定され、GEOIP ルールにより直接接続(DIRECT)になったことを示します。3行目は、具体的なルールに一切マッチせず、フォールバック用の MATCH ルールに落ちたことを示していますが、このフォールバックルールのポリシーが REJECT、つまり直接拒否になっています。本来正常にアクセスできるはずの接続が大量にフォールバックルールに落ちて拒否されている場合、多くはルールの並び順に問題があるか、フォールバックルールが本来 DIRECT であるべきなのに誤って REJECT と書かれているケースです。設定ファイルの rules の最終行を確認すると、この種の問題は最も見つけやすいです。

ノード・プロキシグループ関連の警告

単発の接続エラーとは別に、Clash はプロキシグループのヘルスチェック結果を定期的に出力します。この種のログレベルは通常 warning で、接続が完全に失敗したことを意味するわけではありませんが、注意しておく価値があります。

• health check failed / url-test のタイムアウト:プロキシグループに自動速度テスト(url-test や fallback タイプ)が設定されている場合、あるノードがテスト用アドレスへのリクエストを設定時間内に完了できないと、カーネルはそのノードを利用不可としてマークし、一時的にスキップして次回のチェックで再試行します。たまに1〜2回発生する程度なら正常な範囲の揺らぎです。
• all proxies unavailable / no proxy available:プロキシグループ内のすべてのノードが利用不可と判定された状態で、このグループ配下の接続はすべて失敗します。原因としては、サブスクリプションのノードが全体的に期限切れになっている場合もあれば、テスト用アドレス自体がお使いの回線環境で不通になっており、すべてのノードが誤って失敗と判定されている場合もあります。まずグループ内の任意のノードに手動で切り替えて直接テストしてみましょう。手動なら接続できる場合は、速度テストロジックの誤判定なので、テスト用アドレスや実行間隔を調整すると改善します。
• proxy group has no selected proxy:ポリシーグループ内に選択可能なノードが1つもない状態です。多くはサブスクリプション解析後のノード一覧が空になっているケースで、サブスクリプション管理画面に戻ってノード数とフィルタルールを確認し、ノードが全部除外されていないか確認してください。

DNS 関連ログと調査の考え方

接続の問題に見えるエラーの多くは、実は DNS の解決に失敗していることが根本原因です。ログに could not resolve host が出る、または名前解決が異常に遅い場合は、まず設定ファイルの dns フィールドが有効になっているか、使用している上流の DNS サーバーに到達できるかを確認しましょう。fake-ip モードを有効にしている場合、一部のアプリが仮想 IP をうまく処理できないと、ログ上では宛先アドレスへの接続異常として表れることがあります。この場合は通常、fake-ip-filter に該当ドメインを例外として追加し、そのトラフィックが仮想アドレスではなく実際の IP 解決を使うようにする必要があります。

全体的な調査の流れは3ステップにまとめられます。まずレベルを見て深刻度を判断し、error なら即対応が必要です。次にエラー文の内容を見て、ネットワーク層の問題(timeout、refused、no route)なのかロジック層の問題(match、health check)なのかを判断します。最後に前後の宛先アドレスやノード名と合わせて考え、「プロキシ全体が壊れている」と漠然と疑うのではなく、具体的なノード・ルール・ローカル回線のどこに問題があるのか正確に特定します。