Clash実行ログの読み方：よくあるエラーの意味と問題特定の考え方

ログがトラブル対応の第一級資料である理由

「ページが開けない」「サブスクリプションが使えない」「特定のアプリだけ繋がらない」といった問題に遭遇したとき、多くの人はまずノードを切り替えたりクライアントを再起動したりして、数回試してうまくいかなければ諦めてしまいます。しかし、こうした問題の答えは、実はすでにログに書かれていることが多いのです。Clash内核（オリジナルのClashでも、現在より広く使われているClash Meta / mihomo内核でも）は、通信を処理するたびに1行のログを記録します。どこから来た通信が、どのルールを通り、最終的にどこへ接続しようとし、接続が成功したか失敗したか、失敗した場合の具体的な理由は何か、というところまで書かれています。

つまり、ログは「ネットが繋がらない」という曖昧な現象を、具体的な段階に分解してくれます。ローカルからリクエストが出ていないのか、DNS解決がうまくいっていないのか、ハンドシェイクの段階で対象またはノードに拒否されたのか。ログの読み方を身につければ、トラブル対応は「当てずっぽうの試行」から「手がかりに基づく特定」に変わり、効率が明らかに上がります。

ログレベルと確認方法

Clashのログはいくつかのレベルに分かれており、低い順から debug、info、warning、error、silent となります。レベルが低いほど、記録される内容は詳細になります。

• debug：DNSクエリの1回1回、接続の試行の1回1回まで、内部の動作がほぼすべて記録されます。難しい問題を調査する際に最も有用ですが、出力量が非常に多くなります。
• info：日常使用で推奨されるレベルで、接続確立・ルールマッチ・接続終了といった重要な節目が記録され、画面が流れすぎることもありません。
• warning / error：異常が発生した接続のみを記録するため、日常的には静かですが、トラブル対応時には情報量が少なくなります。

多くのGUIクライアントでは、ログパネルはメイン画面のサイドバーやフッターのタブに配置されており、タイトルは通常「ログ」や「Logs」と表示されます。画面上でレベルを直接切り替えられるのが一般的です。具体的な問題を調査する際は、一時的に debug レベルに切り替え、問題を再現させたあとで info に戻すことをおすすめします。長期間 debug のままにするとログファイルが増えすぎてしまいます。

よくあるログ項目の対照表

ログの形式は内核のバージョンによって多少異なりますが、核心となる情報は共通しています：時刻、レベル、プロトコル種別、送信元アドレス、宛先アドレス、マッチしたルールとポリシー、そして成否の結果です。以下、エラーの種類ごとに解説します。

接続系エラー：connection refused / timeout

[TCP] 192.168.1.5:51234 --> example.com:443 match RuleSet(proxy) using ノードA
dial tcp 203.0.113.10:443: connect: connection refused

connection refused は、3ウェイハンドシェイクの要求が対象側に明確に拒否されたことを示します。通常は対象ポートでサービスがリスニングしていない、ノードのサーバー側が停止している、あるいはノード自体に障害が発生していることを意味します。i/o timeout（タイムアウト）はこれとは異なり、リクエストを送った後、拒否も応答もされなかったことを示します。回線の混雑、対象サーバーの無応答、あるいはノードが接続しているネットワークが帯域制限やブロックを受けている場合によく見られます。この2つの違いは重要です。拒否されている場合は基本的にノードを切り替え、タイムアウトの場合はまず回線の品質を疑うべきです。

DNS解決エラー：no such host

dial tcp: lookup example.com: no such host

このログは接続確立の前段階で出力され、ドメイン名の解決自体が成功していないことを示しています。ノードへの接続にはまだ到達していません。よくある原因は、DNSサーバーが利用不可、設定ファイル内の nameserver の記載ミス、あるいは特定のDNSモードと連動する必要のある振り分けルールを使っているのに fake-ip や enhanced-mode を対応させて有効化していない、といったケースです。ほとんどのドメインでこのエラーが出るならまずDNS設定自体を確認し、一部のドメインだけであれば、そのドメインが特定のDNSサーバーで実際に解決異常を起こしている可能性が高くなります。

ルールマッチ記録：通信の流れを確認する

[TCP] 10.0.0.8:60021 --> api.example.com:443 match DomainSuffix(example.com) using DIRECT

このタイプのログはエラーではなく「通信の流れを示す説明書」です。match の後にはヒットした具体的なルールが、using の後には最終的に使用されたポリシー（DIRECT直接接続、あるノード、またはポリシーグループ）が記載されます。本来プロキシを通るべきサイトなのにログで using DIRECT となっている場合、そのルールが有効になっていないか、直接接続のルールより後ろに配置されている可能性があります。逆に、本来直接接続すべき日本国内のアドレスがプロキシを経由している場合も、ここで即座に発見できます。ルールのマッチ記録は「設定が想定どおり動作しているか」を判断する最も直接的な証拠です。

TLSおよびハンドシェイク系エラー

remote error: tls: handshake failure
EOF

ハンドシェイクの失敗や、接続中に EOF（対象側が自発的に接続を切断）を受け取るケースは、ノードのトランスポートプロトコル設定とサーバー側の設定が一致していない（TLSパラメータやSNI偽装ドメインが合っていないなど）場合や、ノードのサーバー側自身が通信のクリーニング処理を行う際に誤判定してしまった場合によく見られます。この種の問題は通常ローカル側の設定ミスではないため、まずサブスクリプションやノードリストの中から別のノードに切り替えて検証することをおすすめします。複数のノードで同種のエラーが発生する場合は、改めてローカル設定ファイル内の対応するプロトコル項目の記載を確認してください。

時系列で問題を特定する：リクエスト開始からデータ返却まで

ログを手に入れたら、赤字を探して一気に流し読みするのではなく、次の順序で見ていくことをおすすめします。

1. リクエストがローカルで捕捉されているか。この接続の記録がログに出ているかを確認します。まったく記録がない場合、システムプロキシが有効になっていない、またはTUNモードが通信を正しく引き受けていない可能性があり、ノード側の問題ではありません。
2. DNS解決が成功しているか。no such host のような記録が出ていないか確認します。解決に失敗している場合、その後の接続段階はそもそも発生しません。
3. ルールマッチが想定どおりか。match と using フィールドが示すポリシーが本来意図したものかを確認します。ポリシーグループの選択ミスはノードの選択ミスより見落とされやすいです。
4. 接続が正常に確立されたか。connection refused、timeout、あるいはTLS関連のエラーが出ていないか確認します。この段階のエラーは基本的に「ノードを切り替える」か「回線を調べる」かに対応します。
5. 接続確立後に正常に終了しているか。正常なアクセスが終わった後には接続終了の記録があるはずです。接続が長時間ぶら下がったまま終了記録が出ない場合、対象サービスの応答が遅いだけで、ネットワーク層の問題ではないこともあります。

この5つのステップを頭の中で一通り確認するだけで、「繋がらない」という曖昧な表現を、ある具体的な段階にまで絞り込むことができます。

よくあるケースの対照速見表

調査時のいくつかの心得

ログは証拠の連なりとして見るべきものであり、「赤くなっている場所が壊れている」という単純な信号灯として見るべきではありません。複数のノードで同時に同じ種類のエラーが出ている場合は、たいていローカルの設定かDNSに原因があります。個別のノードだけに問題が出ている場合は、そのノード自体の状態が原因であることがほとんどです。まずログを見てから設定を変更する習慣をつけることで、試行錯誤の時間を大幅に節約できます。

ログの中で同じ種類のエラーが繰り返し発生し、すでにローカル設定やネットワーク環境の問題を排除できている場合は、公式のクイックスタートガイドに沿って基本設定をもう一度見直し、サブスクリプション・DNSモード・ルール設定がすべて推奨されるデフォルト状態になっているか確認してみるのもよいでしょう。