なぜログが問題調査の第一級資料なのか
Clash系クライアント(オリジナルコアおよびmihomoコアを含む)は動作中、接続確立・ルールマッチ・DNSクエリ・プロキシ選択といった各ステップの実行結果を構造化されたテキストログとして継続的に出力します。「ネットにつながるかどうか」という曖昧な現象の説明に比べ、ログは特定の1本の接続、1回のクエリについての具体的な失敗原因を示してくれます。これが公式ドキュメントやコミュニティのトラブルシューティング手順で「まずログを見る」ことが繰り返し強調される理由です。
多くのクライアント(Clash Verge、Clash for Windows系派生版、mihomo party など)はメイン画面に「ログ」または「Logs」タブを備えており、一部はレベル別フィルタやキーワード検索にも対応しています。コマンドラインでコアを実行する場合、ログはそのまま標準出力に表示され、設定ファイル内の log-level フィールドで指定ファイルへの出力を制御することもできます。どのクライアントを使う場合でも、ログの形式とよくあるエラーの種類を理解しておけば、調査時間を「再起動を繰り返して運を試す」から「具体的な箇所を特定する」まで短縮できます。
ログレベルの設定方法とどのレベルを見るべきか
Clash設定ファイルの log-level フィールドは出力の詳細度を決定します。粗い順から細かい順に、よくある値は以下の通りです。
- silent:ログを一切出力しません。本番環境で完全にサイレント動作させる場合のみ使用し、問題調査時には使わないでください。
- error:接続失敗や設定解析エラーなど重大な問題のみ記録します。情報量が最も少なく、途中経過を見逃しやすくなります。
- warning:errorに加え、潜在的な異常の警告を出力します。例えばルールセットの読み込みに時間がかかりすぎている、証明書の期限が近いなど。
- info:デフォルトで推奨されるレベル。プロキシ選択結果、DNSクエリの概要、接続の確立と切断を記録し、情報密度が適度で日常的なトラブル対処には十分です。
- debug:最も詳細な実行内容を出力します。各ルールのマッチ試行過程、プロトコルハンドシェイクの具体的なバイト交換の概要まで含まれます。難しい問題を調査する際に一時的に有効化し、日常的に長期使用することは推奨されません(ログ量が多く、性能に影響する可能性があります)。
設定方法は YAML 設定ファイルで次のように指定します。
log-level: info具体的なエラーを調査する際は、一時的にレベルを debug に変更し、問題を再現させた後に info へ戻すことを推奨します。長期間 debug のままだと過剰なログファイルがディスク容量を消費してしまいます。
頻出エラーを一つずつ解説
DNS解決失敗系
この種のログには通常 dns resolve failed、no such host といった記述が含まれ、クライアントがドメイン名をIPアドレスへ解決しようとして失敗したことを示します。よくある原因は以下の通りです。
- 設定ファイル内のDNSサーバーアドレスの記載ミス、またはそのサーバーが既に無効になっている;
fake-ipモードを有効化しているが、対象ドメインが誤って直接接続(direct)グループに分類されており、実際のDNSリクエストがプロキシ経路を通っていない;- DoH/DoTなどの暗号化DNSを使用する場合、上流の暗号化DNSサーバー自体がプロキシ経由でしかアクセスできず、「鶏が先か卵が先か」というデッドロックが生じている;
- ドメイン自体が存在しない、または期限切れになっている場合。これはクライアント側の問題ではなくドメイン側の問題です。
特定手順:まず設定内の nameserver フィールドが有効なアドレスかどうかを確認し、次にそのドメインに対応するルールグループが想定通りのノードにマッチしているかを確認します。暗号化DNSのデッドロック問題であれば、DNSサーバーアドレスに対して個別に直接接続を設定するか、安定して利用可能な出口ノードを指定します。
ハンドシェイクタイムアウト系
ログに handshake timeout、dial tcp: i/o timeout、または context deadline exceeded が表示される場合、クライアントはすでにプロキシノードへの接続確立を試みているものの、規定時間内にTLSハンドシェイクまたはTCP接続確立が完了していないことを示します。この種のエラーの原因は3つの層に分けられます。
- ノード側:サーバーがオフラインになっている、ポートが一時的にブロックされている、またはサーバーが所在する地域のネットワーク品質が悪い;
- プロトコルパラメータ側:クライアントとサーバー間の暗号化方式や転送プロトコル(WebSocketパス、gRPCサービス名など)の設定が一致しておらず、ハンドシェイク要求の形式が相手側に受け入れられない;
- ローカルネットワーク側:ローカルの出口ネットワーク自体が対象ポートに対して速度制限や干渉を行っている場合。特に一部の通信事業者による特定ポートへのQoSポリシーでよく見られます。
特定手順:まず同一サブスクリプション内の別ノードでテストします。すべてのノードでタイムアウトが発生する場合、問題はローカルネットワーク側にある可能性が高いです。特定のノードのみタイムアウトする場合は、そのノード自体の状態やプロトコルパラメータの記載ミスを優先的に疑います。
ルール未マッチ系
ログに match RuleSet(...) または final rule が表示されているものの、プロキシの振り分け先が想定と異なる場合、これはエラーではなく、ルールマッチ処理は機能しているが結果がユーザーの想定していたグループではないケースです。よくある原因は以下の通りです。
- ルールファイルは上から下へ順にマッチするため、前方にあるより広範なルールが先にマッチし、後方の精密なルールが実行されない;
- ルールセット(rule-provider)が更新されておらず、古いバージョンのドメイン/IPリストを使用し続けている;
- 最終フォールバックルール(
MATCH)が想定外のグループを指しており、前方のルールにマッチしなかったすべての通信がここに落ちてしまう。
特定手順:debugレベルのログを有効化した上で、具体的なドメインに対して1回接続を発生させ、ログ内でそのドメインを検索し、実際にどのルールにマッチし、どのプロキシグループに落ちているかを確認します。その上でルールファイルを1行ずつ順序に沿って照合します。
接続拒否・プロトコルエラー系
connection refused は対象ポートで待ち受けているサービスが存在しないことを示し、通常はサーバー側で設定されたポートとクライアントに記載されたポートが一致していない、またはサーバー側のサービスが起動していないことが原因です。invalid header、unexpected EOF といったプロトコル層のエラーは、多くの場合クライアントとサーバー両端の暗号化方式や難読化パラメータ(obfsの種類など)が一致していないことを指しており、サブスクリプション内のプロトコル関連フィールドを一つずつ照合する必要があります。
エラー種別ごとに問題の根本原因を特定する実用的な手順
エラーログを1件手に入れたら、あらゆる可能性を一つずつ試すのではなく、次の順序で調査範囲を絞り込むことを推奨します。
- ステップ1、エラーが発生した段階を区別する。DNS解決段階か、ハンドシェイク接続段階か、それともルールマッチ段階か?ログ内のキーワード(resolve / dial / handshake / rule)は通常すでに段階を示しているため、まず段階別に分類することで無関係な方向を大半排除できます。
- ステップ2、単一ノードの問題かどうかを判断する。同一サブスクリプション内の別ノードに切り替えて再試行します。問題が解消すれば、そのノードのサーバー側の状態やパラメータの問題であることを意味します。解消しなければステップ3へ進みます。
- ステップ3、ローカルネットワークの問題かどうかを判断する。一時的にプロキシをオフにして対象サイトへ直接アクセスする、または携帯のテザリングなど別のネットワーク環境でテストし、ローカルの通信事業者やルーターのポリシーによる干渉を排除します。
- ステップ4、設定ファイル自体を照合する。DNS設定、ルールの順序、rule-providerの更新時刻、サブスクリプションが最新版かどうかを確認します。「ノードの問題に見える」ケースの多くは最終的に設定ファイルの期限切れやフィールドの記載ミスに行き着きます。
- ステップ5、ログレベルを上げて問題を再現する。前の4ステップで特定できなかった場合、
log-levelを一時的に debug に調整し、障害を1回完全に再現させ、関連するログの断片を保存してさらなる分析やコミュニティへの相談に利用します。
日常的にログを確認する際の実用的な習慣
- 接続に問題が発生したらまずタイムスタンプを確認し、障害発生の具体的な時刻を特定してから、前後数秒分のログのコンテキストを遡ります。長いログを目的なく探し回るのは避けましょう。
- クライアントのログ画面のキーワードフィルタ機能を活用し、問題のあるドメインやIPを直接検索することで、関連するすべてのログ行を素早く特定できます。
- ルールを変更した後は、一度debugレベルで新しいルールが確実に想定通り機能しているか検証し、その後infoレベルに戻して長期運用することを推奨します。
- TUNモードでの問題は、システムのネットワークスタックとコアのログの両方が関わることが多いです。TUNモードで接続できない場合は、Clash自身のログだけでなく、クライアント側に個別のTUN状態表示がないかも確認しましょう。
- 直近で正常に動作していた設定ファイルのバックアップを保持しておくと、アップデート後に突然エラーが増えたような場合に、設定差分を直接比較して変更点を特定できます。
ログの読み方を身につければ、多くの接続系の問題は数分以内に具体的な箇所を特定でき、考えられる修正方法をすべて試す必要がなくなります。