Clashの実行ログの見方：よくあるエラーの意味とトラブル対処の手順

LOG LAYERS

まずログがどの層のものか判断する

Clashクライアントで「接続失敗」と表示されたとき、画面の通知は通常、最終的な結果しか示しません。実行ログには、どの段階で失敗したかが記録されています。分析を始める前に、クライアントの画面層、プロキシコア層、OSのネットワーク層という3つの情報を区別しましょう。クライアントは設定管理、トレイメニュー、システムプロキシの切り替えを担当します。Clash、Clash Meta、または使用中のmihomoコアは、ポートの待ち受け、ルール解析、プロキシ接続の確立、DNS処理を担います。OSはネットワークアダプター、ルーティング、ファイアウォール、権限、ローカルポートを管理します。3層のどこで失敗しても、画面上では「接続できない」と表示される可能性があります。

同じコアログでも、クライアントによって表示形式が異なる場合があります。時刻、ログレベル、モジュール名を残すものもあれば、メッセージ本文だけを表示するものもあります。mihomoのバージョン更新後は、フィールド名や表現が変わることもあります。そのため、エラー文を一文丸ごと検索するのではなく、設定ファイルのパス、待ち受けアドレス、ポート番号、ドメイン、ノード名、ネットワーク種別、システムエラーなど、安定している対象を抜き出して確認してください。

warningやerrorが単独で出ただけでは、すべてのプロキシ通信が停止したとは限りません。たとえば特定のノードの接続タイムアウトは、その接続または該当するプロキシグループだけに影響する場合があります。予備DNSサーバーの1台が失敗しても、別のサーバーが名前解決を完了できることがあります。影響範囲を判断するときは、エラー対象、発生頻度、後続に成功記録があるかを同時に確認してください。

REPRODUCE FIRST

発生順に問題を再現する

有効なログ分析には、明確な再現手順が必要です。クライアントを何時間も動かした後、設定更新、遅延テスト、バックグラウンドアプリの通信が混在した記録から原因を推測するのは避けましょう。現在のログを消去するか開始時刻を記録し、問題を引き起こす操作を1つだけ実行する方法が確実です。これにより、ユーザー操作とログの時刻を対応付けられます。

1. 現在の環境を記録する。クライアント名、コアの種類、OS、使用中の設定ファイル、プロキシモード、TUNの有効・無効を確認します。クライアントまたはコアを更新した直後なら、更新前後の状態も記録してください。
2. 無関係なテストを停止する。自動速度テスト、設定の自動更新、継続的に接続を発生させるアプリを一時的に停止し、ログのノイズを減らします。
3. まずはログ量を抑えて開始する。最初はinfoレベルで再現し、接続失敗の結果しか確認できない場合だけdebugへ一時的に切り替えます。原因を特定したら通常のレベルに戻し、ログが急増しないようにします。
4. 操作は1つだけ実行する。たとえばサブスクリプションを1回更新する、特定のWebページを開く、ノードを1回切り替える、TUNだけを有効にする、といった操作です。
5. 最初の異常を特定する。操作した時刻から下へ追い、最初に現れたwarning、error、明らかなタイムアウトを見つけます。その前にある設定やルーティング情報も確認してください。
6. 変数を1つだけ変更して再試行する。各回でノード、ポート、DNS、実行モードのいずれか1項目だけを変更します。そうしないと、どの変更が効果をもたらしたのか確認できません。

ログの時系列は、エラーの件数よりも重要です。たとえば最初に設定解析の失敗、続いてコントロールポートへの接続失敗、最後に画面でコアが実行されていないと表示された場合、根本原因は最後のコントロールポートエラーではなく、最初の設定エラーである可能性が高いでしょう。また、TUNの初期化に失敗した後もシステムプロキシ経由でアプリが通信できるなら、プロキシコアは正常で、透過的な取り込み経路だけが確立されていないと考えられます。

クライアントを起動
→ 設定を読み込む
→ DNSとルールを初期化
→ ローカルプロキシポートを待ち受け
→ TUNを初期化（有効な場合）
→ アプリの接続を受け付ける
→ ルールを照合
→ ノードを選択
→ リモート接続を確立

この流れを確認の順番として利用できます。エラーが発生した段階と、その前提となる手順を先に対処し、いきなりノードの変更やクライアントの再インストールに進まないでください。

CONFIG PARSER

設定解析とコアの起動エラー

設定エラーは通常、コアが正式にポートを待ち受ける前に発生します。よくあるキーワードは parse、yaml、unmarshal、invalid config、field、duplicate、not found です。この種のエラーが出ているときにノードやシステムプロキシをテストしても意味がありません。コアが動作可能な設定をまだ読み込めていない可能性があるためです。

YAML構造を解析できない

YAMLではインデントで階層を表します。Tabの使用、リスト項目の階層の不一致、コロンの後の空白不足、閉じられていない引用符などがあると解析が停止します。ログには通常、行番号と列番号が示されますが、実際の問題が表示行の前にある場合もあります。たとえば前の行の文字列が閉じておらず、解析器が次の行で初めて構造の不正を検出するケースです。

proxies:
  - name: Example
    type: ss
    server: example.test
    port: 443

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Example

確認時はまずインデントがすべてスペースで統一されていることを確認し、エラー行の前後数行を確認します。ノード名にコロン、シャープ記号などYAML上の意味を持つ文字が含まれる場合は、設定の提供元が正しく引用する必要があります。手動編集後にエラーが出た場合は、いったん変更を戻し、元の設定が読み込めるか確認してください。

フィールドは存在するが現在のコアでは非対応

Clashの設定がすべてのコアバージョンで完全に共通しているわけではありません。mihomoだけが対応するフィールドもあり、古いコアでは未知のフィールド、型エラー、必須パラメータ不足として報告されることがあります。逆に、クライアントのコアを更新した後に古いフィールドが警告を引き起こす場合もあります。この場合はクライアントの製品名だけでなく、実際に呼び出されているコアを確認してください。設定がmihomo向けなら、対応する構文を扱えるクライアントとコアのバージョンを使用します。

参照先のオブジェクトが存在しない

プロキシグループが存在しないノードを参照している、ルールが未定義のプロキシグループを指している、ルールセットのパスを読み込めない、といった状態では、読み込みに失敗したり一部機能が使えなくなったりします。エラーに記載されたオブジェクト名を重点的に照合し、大文字・小文字、空白、全角文字を確認してください。名前は完全一致が必要で、同じように見える前後の空白でも参照に失敗することがあります。

LISTENER STATUS

ポート競合とシステムプロキシのエラー

ポートエラーでよく見られるキーワードは address already in use、bind、listen、permission denied、connection refused です。Clashコアは通常、HTTP、SOCKS、mixedポート、外部コントロールポートを待ち受けます。別のコアインスタンス、古いクライアントプロセス、その他のネットワークツールが同じアドレスを使用していると、新しいプロセスは待ち受けを完了できません。

address already in use は、指定したアドレスとポートが別のプロセスに使用されていることを示します。まず同種のクライアントをすべて終了し、タスクマネージャーやシステムのプロセス一覧にコアプロセスが残っていないか確認します。ウィンドウを閉じるだけでは不十分です。クライアントによってはトレイで動作を続けるためです。残留プロセスがないことを確認して再起動し、それでもポートが使用中なら未使用のポートに変更し、そのポートを利用するブラウザーやアプリの設定も更新します。

permission denied は、待ち受け位置と合わせて判断します。通常のローカル高位ポートには特別な権限は必要ありませんが、システムのセキュリティポリシー、ファイアウォール規則、制限された実行ディレクトリが操作を妨げることがあります。ログがTUN、ルーティング、サービス登録に言及している場合はシステム権限の問題であり、プロキシノードを何度も変更して対処するものではありません。

connection refused がどの方向の接続で出たかも重要です。クライアント画面から外部コントロールポートへの接続が拒否された場合、コアが起動していない、コントロールアドレスが一致していない、またはコアが終了したことを示す場合があります。プロキシコアからリモートサーバーへの接続が拒否された場合は、対象アドレスには到達できるものの、リモート側の該当ポートが接続を受け付けていない状態です。同じ表現でも障害箇所はまったく異なるため、ログの送信元アドレス、宛先アドレス、モジュール名を確認してください。

システムプロキシの有効化に失敗しても、コアのポートが動作していないとは限りません。まずログでローカルプロキシの待ち受けが成功していることを確認し、次にOSのプロキシ設定が該当ポートを指しているか確認します。ブラウザーを手動設定すれば接続できるのに一般のアプリが接続できない場合は、システムプロキシの設定、アプリがシステムプロキシに従うかどうか、アプリ自身のネットワーク設定に問題がある可能性が高いでしょう。

DNS PIPELINE

DNSクエリと名前解決の異常

DNSの問題は、Webページでドメインが見つからない、一部のサイトだけ使えない、TUNを有効にするとすべてのドメイン接続がタイムアウトする、ログに lookup、resolve、no such host、timeout、SERVFAIL が繰り返し表示される、といった形で現れます。分析ではまず、「ドメインからアドレスを取得できていない」のか、「アドレスは取得できたが、その後の接続に失敗している」のかを区別します。ログに宛先IPが表示され、接続処理の段階に進んでいるなら、根本原因は通常、最初の名前解決ではありません。

従来のDNS、DNS over HTTPS、DNS over TLSでは必要な経路が異なります。暗号化DNSサーバー自体をドメイン名で指定している場合、コアはbootstrapやデフォルトリゾルバーを使って先にサーバーアドレスを取得する必要があります。この事前解決に失敗すると、その後のクエリを送信できません。DNSサーバーのドメイン名に対するクエリがログで繰り返しタイムアウトする場合は、デフォルトリゾルバー、ネットワーク到達性、設定内のnameserver-policyを確認し、単にプロキシノードだけを変更しないでください。

Fake IPモードでは、アプリがまず予約アドレスを受け取り、コアが内部マッピングから元のドメインを復元してルールを適用します。予約アドレスが表示されても、名前解決エラーとは限りません。確認すべきなのは、マッピングが存在するか、対象ドメインが正しく取り込まれているか、Fake IPに適さないLANドメインやデバイス検出用ドメインを除外する必要がないかです。Redir Hostモードでは名前解決結果をそのままアプリへ返すため、障害ログの現れ方が異なります。

DNSタイムアウトの切り分け順

1. 設定が正常に読み込まれ、DNSモジュールが初期化済みであることを確認する。
2. すべてのサーバーで失敗しているのか、特定の予備サーバーだけなのか確認する。
3. クエリが直接接続とプロキシ経路のどちらを使っているか、関連ポリシーが循環依存になっていないか確認する。
4. DNSサーバーのアドレスとプロトコル形式が現在のコアでサポートされているか確認する。
5. TUNを無効にしてシステムプロキシで再試行し、問題が取り込み経路だけに存在するか判断する。
6. 名前解決に成功した後もTLS、接続タイムアウト、ルーティング失敗が続いていないか確認する。

TUN DEVICE

TUNモードの起動失敗

TUNモードは仮想ネットワークアダプターとシステムルートを使って、より多くのアプリ通信を取り込みます。そのため権限、ドライバー、ネットワークインターフェース、ルーティングテーブルが関係し、通常のシステムプロキシよりエラー範囲が広くなります。よくあるキーワードは tun、interface、route、adapter、device、service、operation not permitted です。

最初に判断するのは、「コア全体が失敗している」のか「TUNの初期化だけが失敗している」のかです。ローカルのHTTPまたはmixedポートが正常に待ち受け、TUNを無効にするとシステムプロキシが動作するなら、ノード、ルール、基本的なコアはおそらく利用可能で、障害は仮想ネットワークアダプター経路に集中しています。この場合は、クライアントが要求するサービスコンポーネント、実行権限、他のVPN、仮想マシン、ネットワークフィルターツールを確認してください。

インターフェースの作成に失敗した場合は、まず仮想ネットワークアダプターを作成する可能性のある他のプログラムを完全に終了し、クライアントを再起動します。ルートの追加に失敗した場合は、同一サブネットの競合、古いルートの残留、権限不足を確認します。指定したネットワークインターフェースが見つからないとログに示される場合は、設定で固定されたインターフェース名が変わっている可能性があります。ノートPCを有線から無線へ切り替えた場合や、ネットワークデバイスを再インストールした場合、インターフェース識別子が変わることがあります。

macOS、Windows、LinuxではTUNの実装と権限モデルが異なるため、別のプラットフォーム向けのコマンドをそのまま適用できません。デスクトップクライアントにサービスモードや補助サービスがある場合は、まずそのコンポーネントが正常に動作しているか確認します。Linux環境ではTUNデバイスとネットワーク管理権限も確認してください。どのプラットフォームでも、まずクライアント自身が提供する有効化・無効化の操作でテストし、複数の取り込みツールを同時に重ねないことが大切です。

TUNを有効にするとネットワークが切れるが致命的なエラーがない

デフォルトルート、DNSの取り込み、ルールの結果を確認します。ログで接続がDIRECTに進んでいるのに、直接接続の通信が正しいインターフェースから送信されない場合は、出口インターフェースの自動検出に失敗している可能性があります。すべてのドメインクエリがタイムアウトするなら、まずDNS経路を対処します。LANデバイスだけに接続できない場合は、LANサブネットが誤って取り込まれていないか、プライベートアドレスのルールが想定どおり直接接続になっているか確認してください。

TUNの切り分けでは、比較用の条件を1つ用意することをおすすめします。TUNを無効にし、システムプロキシだけを有効にして同じ対象へアクセスします。システムプロキシでは成功してTUNだけ失敗するなら、ネットワークアダプターとルーティングを引き続き確認します。どちらのモードでも失敗するなら、DNS、ノード、リモート接続の層に戻って分析してください。

OUTBOUND CONNECTION

接続失敗、タイムアウト、TLSエラー

コアがルールマッチングを完了すると、選択した送信ノードを通じて対象へ接続します。この段階のログには通常、対象ドメインまたはIP、ポート、ネットワーク種別、プロキシグループ、ノード名、所要時間が含まれます。最も重要なのは、接続先がノードサーバーなのか、それともノード接続後に対象サイトへ接続しているのかを区別することです。ログのモジュール名とアドレスから、2つの経路を見分けられます。

i/o timeout または context deadline exceeded

タイムアウトは、制限時間内に処理が完了しなかったことを示すだけで、原因を単独で特定するものではありません。ノードサーバーに到達できない、パケットロスがある、DNSクエリの結果が返らない、対象サイトが応答しない、といった状況でタイムアウトが発生します。まずタイムアウトの対象を確認します。ノードサーバーのアドレスなら、同じサブスクリプション内の別ノードに切り替えて比較します。異なる地域の複数ノードが同時にタイムアウトするなら、ローカルネットワーク、DNS、ファイアウォールを優先的に確認します。特定の対象だけが失敗するなら、ルールの結果と対象への到達性を確認してください。

connection reset by peer

このメッセージは、接続確立後に相手側または経路上の機器によって接続がリセットされたことを示します。1回だけならネットワークの揺らぎやサーバー側による接続終了の可能性があります。継続して発生する場合は、ノードのプロトコル、ポート、トランスポート層のパラメータ、サーバーの状態を確認してください。resetだけを根拠にクライアントの障害と判断してはいけません。別のノードで同じ対象へアクセスするか、同じノードで別の対象へアクセスすると、範囲を素早く絞り込めます。

TLS handshake timeoutと証明書エラー

TLSハンドシェイクのタイムアウトは、経路品質の低下、対象への到達不能、プロトコルパラメータの不一致で発生しやすい問題です。証明書エラーではシステムの日付とタイムゾーンも確認してください。時刻が間違っていると、有効な証明書がまだ有効でない、または期限切れと判定されることがあります。ノード設定にサーバー名やトランスポート層のセキュリティパラメータが含まれる場合は、サブスクリプションから配布された内容を完全な状態で維持し、用途を理解しないまま手動で削除しないでください。

network is unreachableとno route to host

これらのログはルーティング層を示しています。現在のネットワークに対応するIPv4またはIPv6の出口がない、TUNのルートが確立されていない、指定インターフェースが利用できない、対象アドレスのネットワークに到達できない、といった可能性があります。IPv6で接続を試みているのにローカルネットワークのIPv6が安定していない場合は、DNSの結果とコアのアドレス選択を確認します。IPv4とIPv6の両方が失敗するなら、システムネットワークとルーティングの確認に戻ってください。

RULE MATCH

ルールマッチングとトラフィックの経路

接続自体にエラーがないのに、通信の経路が想定と異なることがあります。たとえばプロキシ経由にすべきドメインが直接接続になったり、LANアドレスがノードへ送られたり、プロキシグループが利用できないノードを選択したりするケースです。この種の問題では、errorだけを検索せず、ルールマッチングのログを確認します。debugまたは詳細な接続ログには通常、対象、ヒットしたルール、最終的なポリシーが表示されます。

Clashのルールは設定された順番で照合され、通常は一致した時点で後続の確認を止めます。範囲の広いルールを前に置くと、後ろにある特定ドメイン向けのルールが上書きされることがあります。MATCHルールは、それまでに一致しなかった接続を処理します。誤ったポリシーに一致した場合は、設定内でそのルールの位置、ルールセットの内容、プロキシグループの現在の選択を確認してください。

プロキシグループ名は、実際のノードを意味するとは限りません。ログには、ある接続が「自動選択」というプロキシグループに渡され、その後グループが具体的なノードを選ぶ過程が表示されることがあります。切り分けでは、ルールが接続をどのグループへ送ったかだけでなく、そのグループが当時どのノードを実際に選択していたかも確認します。遅延テストの成功は、テスト時にテストURLへ到達できたことを示すだけで、すべての対象へアクセスできることや長時間接続が安定することを保証しません。

DIRECTも明確な送信ポリシーの1つです。DIRECTに一致して失敗した場合は、ローカルネットワーク、DNS、対象サイトを確認し、プロキシノードによる解決を期待しないでください。REJECTはルールが接続を明示的に終了したことを示し、ログの拒否は設定どおりの結果です。アプリがREJECT対象のドメインへ繰り返しアクセスすると大量の記録が残ることがありますが、これはコアの異常ではありません。

INCIDENT CHECKLIST

ログ収集とトラブル対処チェックリスト

クライアントのメンテナ、サブスクリプション提供者、その他の技術担当者へ報告する場合は、ログに十分な前後関係を含めつつ、機密情報を削除します。「接続失敗」とだけ表示された画面のスクリーンショットでは不十分で、数時間分のログ全体を送る必要もありません。再現操作の前後数十秒にわたる連続ログを残すと、通常は原因を特定しやすくなります。

合わせて記録する情報

• OSとバージョン、クライアント名とバージョン、実際のコアの種類とバージョン。
• 現在使用しているルールモード、グローバルモード、直接接続モード、システムプロキシとTUNの有効・無効。
• 問題が発生する前に行った操作。たとえば設定の更新、ノードの切り替え、スリープからの復帰、クライアントのアップグレードなど。
• 再現可能な操作手順、および問題が継続的に発生するのか、断続的に発生するのか。
• 最初の異常の前後にある連続ログ。最後の1行だけを切り取らない。
• TUNを無効にした場合、ノードを切り替えた場合、ネットワークを変更した場合の比較結果。

共有前に処理する内容

ログと設定には、サブスクリプションURL、認証パラメータ、ノードサーバーのアドレス、LAN内デバイスのアドレス、アクセス先ドメイン、ローカルファイルパスが含まれる場合があります。公開前にこれらを項目ごとに確認してマスクします。ただし、エラーの種類、ポートの範囲、プロトコルの分類、時系列は残してください。すべてのアドレスを同じ値に置き換えると、「ローカルかリモートか」「同じ対象か複数の対象か」といった重要な関係が失われます。

現象から根本原因へ進む固定手順

1. OS自体がインターネットへ接続できることを確認する。
2. 設定の解析が完了し、コアが起動段階で終了していないことを確認する。
3. ローカルプロキシポートとコントロールポートの待ち受けが成功していることを確認する。
4. DNSクエリが結果を返せることを確認する。
5. TUNを有効にしている場合は、仮想ネットワークアダプターとルーティングの初期化が成功していることを確認する。
6. 対象への接続が想定したルールとプロキシグループに一致していることを確認する。
7. プロキシグループが利用可能なノードを選択し、ノードサーバーへ接続できることを確認する。
8. 最後に対象サイト、TLSハンドシェイク、アプリ自身のプロキシ設定を確認する。

この順番の要点は、上流の依存関係から対処することです。設定が読み込まれていない段階でポートをテストせず、ポートが待ち受けていない段階でアプリのプロキシを確認せず、DNSが完了していない段階で対象への接続を判断せず、TUNが確立していない段階ですべてのタイムアウトをノードのせいにしないでください。毎回1つの条件だけを変更し、変更前後のログを比較として残すと、複数の設定を繰り返し切り替えるより早く根本原因を見つけられます。