Clashのログの見方：よくあるエラーの意味と切り分け手順

まずログの出所と時間範囲を確認する

Clashクライアントの「ログ」には、異なる2つの層の情報が含まれる場合があります。GUIクライアントはサブスクリプションのダウンロード、設定の切り替え、コアの起動、システムプロキシの設定を担当します。一方、Clash Meta（mihomo）などのコアは、DNS、ルール判定、接続確立、プロキシグループの選択、TUN経由の通信処理を担当します。両方のログが同じ画面に表示される場合は、まずエラーがどの層で発生したかを確認してください。

たとえば、サブスクリプションへのリクエストが403を返す場合は、通常クライアント側の設定更新処理に属します。一方、ルールに一致したドメインへの接続がタイムアウトする場合は、コアの実行段階の問題です。最後の1行だけを切り出すと、結果を原因と取り違えやすくなります。障害が発生した時刻から少し前にさかのぼり、最初の異常と、その直前に記録された最後の正常なログを確認するのが基本です。

ログ行に含まれる主な情報

• 時刻：サブスクリプションの更新、ノードの切り替え、TUNの有効化など、ユーザー操作とログを正確に対応付けるために使います。
• レベル：debug は詳細な処理経過、info は正常な状態、warn は注意が必要ですが必ずしも処理を中断しない状態、error は現在の処理が失敗したことを示します。
• モジュール：設定の読み込み、DNS、インバウンドリスナー、プロキシへのダイヤル、ルール判定、TUNなどが代表的です。
• 対象：ドメイン、IPアドレス、ポート、ネットワークインターフェース、設定ファイルのパス、プロキシグループ名などが該当します。
• エラーチェーン：1つのエラーが複数の短いフレーズで構成されることがあります。通常は左から右へ処理の流れを示し、末尾にOSやネットワークライブラリが返した直接の原因が記録されます。

切り分ける前に、最小構成で障害を一度再現します。現在のログを消去するか位置を覚えておき、1つの操作だけを実行して、その範囲のログを保存してください。Webページが開けない場合に、同時にサブスクリプションを更新したり、モードやDNSを変更したり、ノードを切り替えたりするのは避けます。一度に複数の条件を変えると、ログから因果関係を判断できなくなります。

起動と設定解析のエラー：まずファイル、次にポートを確認する

コアを起動できない状態では、DNS、ルール、ノードのテストをしても意味がありません。この段階では、まず設定ファイルを読み込んで解析できるか確認し、その後に待受ポート、コントロールポート、ファイル権限、関連リソースを確認します。GUIに表示される「起動に失敗しました」は集約された状態にすぎず、本当の原因は通常、その直前の数行に記録されています。

設定の構文とフィールドのエラー

よくあるログには yaml、unmarshal、invalid config、field not found、または行番号・列番号が含まれます。YAMLはインデントに依存するため、Tab文字、階層のずれ、閉じていない引用符、リスト形式の誤りが読み込みを妨げます。次のルールはリストの階層内に記述する必要があります。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

未知のフィールドが示された場合は、その設定が対象としているコアの種類とバージョンも確認します。Clash Meta（mihomo）がサポートする一部のフィールドは、旧版Clashの設定機能には含まれません。逆のケースもあります。ファイル拡張子が .yaml だからといって互換性があると判断せず、フィールド名、プロキシプロトコル、ルールセットの記法、DNS設定の構造を確認してください。

ポートがすでに使用されている

address already in use は、指定した待受アドレスとポートが別のプロセスですでに使われていることを示します。対象になりやすいのは mixed-port、port、socks-port、external-controller です。終了していない古いコア、別のプロキシアプリ、同じポートを同時に待ち受ける複数の設定が原因になることがあります。

まず、Clashまたはmihomoのプロセスが重複していないか確認し、次に他のプロキシソフトを確認します。ポートの変更は最後に行ってください。変更後は、ブラウザー、ターミナルの環境変数、LAN内の端末に設定したプロキシポートも更新する必要があります。コアが起動しても、アプリが古いポートへ接続し続ける可能性があるためです。

権限とファイルパスの問題

permission denied は対象パスと合わせて判断します。設定ディレクトリへのアクセスに失敗する場合は、ディレクトリ権限やファイルの使用中状態が原因になりがちです。TUNインターフェースの作成に失敗する場合は、管理者権限、システム拡張機能、ネットワークサービスの権限が関係することがあります。no such file or directory は、設定が参照するルールセット、GeoIPデータベース、証明書ファイルなどの不足を示すことが多いエラーです。ログに記録された完全なパスを確認し、現在開いているメイン設定ファイルだけを調べないようにしてください。

サブスクリプション更新エラー：ダウンロード失敗と解析失敗を分ける

サブスクリプションの更新は、「リクエスト送信、レスポンス取得、内容の識別、設定生成、設定読み込み」という段階で進みます。画面上はどの段階でも更新失敗と表示される可能性がありますが、対処方法は異なります。まずHTTPステータス、レスポンスタイプ、解析結果を記録し、ネットワーク、サブスクリプションの権限、形式の互換性のどれを確認するか判断します。

ブラウザーでサブスクリプションURLを開けても、クライアントで更新できるとは限りません。ブラウザーとクライアントでは、ネットワーク経路、User-Agent、DNSの結果、プロキシ設定が異なる場合があります。切り分けでは、ブラウザーの画面だけで判断せず、クライアントが実際に記録したステータスコードとレスポンスを確認してください。

「サブスクリプションの内容が空」と「設定内に利用可能なノードがない」は区別する必要があります。サブスクリプションによっては、proxies、proxy-groups、rules を含む完全なClash設定を返します。一方、汎用ノードリストだけを提供し、クライアント側で変換が必要な場合もあります。変換器がプロトコルフィールドを認識できないと、ノードが一部しか生成されなかったり、プロキシグループを生成できなかったりします。元のレスポンスタイプに関する情報を残し、サブスクリプションがClashまたはMihomo形式を明示的に提供しているか確認してください。

DNSエラー：名前解決の失敗か接続の失敗かを判断する

DNSログは接続エラーの前に現れることが多いものの、ドメインにアクセスできない原因が常にDNSとは限りません。まず、対象IPアドレスを取得できているか確認します。名前解決のタイムアウト、上流DNSへの到達不能、空のレスポンスが出ているなら問題はDNS段階にあります。IPアドレスを取得した後にダイヤルのタイムアウトやTLSエラーが出ている場合は、プロキシ経路を確認します。

よくあるDNSログの意味

• no such host：システムリゾルバーまたは指定した上流DNSが利用可能なアドレスを返していません。ドメイン名の入力ミスの可能性もあります。
• i/o timeout：上流DNSへ問い合わせを送信したものの、時間内にレスポンスを受信できませんでした。上流アドレス、ネットワーク経路、ファイアウォールを確認します。
• connection refused：対象のDNSサービスアドレスには到達していますが、該当ポートが接続を受け付けていないか、ローカルの転送サービスが動作していません。
• server misbehaving：上流DNSのレスポンスに異常があります。プロトコルの非互換、レスポンス形式の問題、中間ネットワークの干渉などが考えられます。
• fake-ip に関するログ：ドメインがFake-IPのマッピング処理に入ったことを示します。これ自体はエラーではないため、後続のルール判定と実際の接続結果を確認してください。

Fake-IPモードでは、アプリはまず予約済みアドレス範囲のマッピングIPを受け取り、コアがそのマッピングからドメインを復元してルールを適用します。対象アドレスがFake-IPの範囲にあるからといって、遠隔サーバーの実アドレスと判断してはいけません。LANサービス、時刻同期、ゲーム、特殊プロトコルなどに問題がある場合は、fake-ip-filter で対象ドメインを除外する必要があるか確認します。ただし、多数のドメインを無条件にフィルターへ追加するのは避けてください。

TUNを有効にすると、DNSがハイジャックやリダイレクトを経由することもあります。そのため、システム設定に表示されるDNSサーバーが、実際に使用される上流DNSとは限りません。Clashの dns.enable、待受アドレス、nameserver、fallback、ポリシー型DNSの設定に加え、TUNのDNSハイジャック設定も確認します。ポート53がローカルの名前解決サービスで使われている場合、通常はWebページへアクセスした時点ではなく、起動時に待受失敗がログへ出力されます。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上記はフィールドの関係を示すための例です。実際の設定では、現在のネットワーク環境とコアのドキュメントに基づいて上流DNSを選択してください。DNSを変更する際は一度に1項目だけ変更し、同じドメインで繰り返しテストします。拡張モード、上流プロトコル、TUNのハイジャックを同時に切り替えると、ログの変化を原因と結び付けにくくなります。

接続・ハンドシェイク・タイムアウトのエラー：プロキシ経路を区間ごとに確認する

ルールによってポリシーとノードが選択されると、コアはプロキシサーバーへ接続し、そのプロキシサーバーが対象へアクセスします。ログ上のタイムアウトは、ローカルからノード、ノードから対象、プロキシプロトコルのハンドシェイク、TLSハンドシェイクのいずれの段階でも発生します。切り分けの鍵は、エラー直前に記録された出力名、対象アドレス、ネットワーク種別を確認することです。

connection refused

接続拒否は、対象ホストがポートを利用できないことを明確に返した状態です。対象がプロキシノードのアドレスなら、ノードのポート、サービスの状態、プロトコル設定を確認します。対象がローカルのコントロールポートなら、クライアントが接続するコントロールアドレスが正しいか確認します。タイムアウトは応答が時間内に返らない状態ですが、接続拒否はネットワークが何らかのホストまで到達したものの、そのポートが接続を受け付けなかった状態です。

i/o timeout と context deadline exceeded

これらは、処理が制限時間を超えたことを示します。まず既知の動作ノードへ切り替え、同じ対象へ接続をテストします。複数のノードで同時にタイムアウトするなら、ローカルネットワーク、DNS、システムファイアウォール、プロキシモードを確認します。1つのノードだけで発生する場合は、そのノードの経路を優先して調べます。通常のWebサイトは利用できるのに特定サイトだけタイムアウトする場合は、そのドメインが不適切なポリシーへ割り当てられていないか確認してください。

EOF、接続リセット、TLSハンドシェイクの失敗

EOF は、想定されていたデータの受信が完了する前に接続が閉じられたことを示します。この1行だけでは原因を特定できません。リモート側による切断、プロキシプロトコルのパラメーター不一致、トランスポート層の設定差異、中間ネットワークによるリセットなどが考えられます。connection reset by peer は、通信相手または経路上の機器が接続をリセットしたことをより明確に示します。

TLSエラーでは、システム時刻、証明書のドメイン、SNI、ノードのトランスポート設定、対象サイトを確認します。証明書名の不一致がログに出ている場合、証明書検証を長期的に無効化して隠すのではなく、サーバー名とノードパラメーターを確認してください。システム時刻のずれによって、証明書がまだ有効でない、または期限切れと誤判定されることもあります。

UDPとTCPで挙動が異なる場合

ノードでWebページを開けても、主なTCP経路が利用できることしか確認できません。音声、ゲーム、QUIC、一部のDNSリクエストはUDPに依存します。UDP接続で失敗する場合は、ノードのプロトコルとサーバーがUDPをサポートしているか、プロキシグループが対応ノードを選択しているか、システムファイアウォールが関連トラフィックを許可しているかを確認します。切り分けでは一時的にアプリをTCPへフォールバックさせ、障害がUDP経路だけに存在するか判断できますが、最終的には実際の設定を修正してください。

ルール判定・プロキシモード・TUN：ログが正常でも経路が誤っている場合

明確な error が出ない障害もあります。接続自体は成功しているのに、誤ったノードを経由したり意図せず直接接続したりする場合は、ルール、モード、通信の取り込み範囲に問題がある可能性があります。この場合はログレベルを一時的に debug へ変更し、ドメイン、プロセス、ルール種別、プロキシグループ、最終出力先の関係を確認します。テストが終わったら通常のレベルへ戻し、ログ量が増え続けないようにしてください。

現在のプロキシモードを確認する

• ルールモード：ルールを上から順に判定し、一致したルールの指定ポリシーを使用します。細かな振り分けの問題は、基本的にこのモードで確認します。
• グローバルモード：すべての通信をグローバルポリシーへ渡し、通常の振り分けではルールリストを使用しません。ノードの接続性をテストするには便利ですが、ルールが正しいかどうかは検証できません。
• ダイレクトモード：通信を対象へ直接接続します。ルールモードへ戻し忘れると、ノードが正常でも想定したプロキシ接続は発生しません。

ルールモードでは、ルールの数より順序が重要です。たとえば、広範囲の DOMAIN-SUFFIX を精密なルールより前に置くと、対象を先に取り込んでしまうことがあります。GEOIP、GEOSITE、ルールセット、最後の MATCH の位置によっても結果は変わります。意図しないルールに一致した場合は、設定内でそのルールを検索し、前にあるルールの適用範囲を確認してください。最後のプロキシグループだけを変更するのは適切とは限りません。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この順序では、api.example.com は先に直接接続され、それ以外の example.com のサブドメインはプロキシへ送られます。2つのルールを入れ替えると、精密なルールは一致する機会を失います。

TUNを有効にしてもアプリがログに現れない

アプリがリクエストを送ったのに、対応する接続ログがまったく出ない場合は、通信がコアへ入る前に問題がある可能性が高いです。TUNインターフェースが正常に作成されたか、デフォルトルートが追加されたか、自動ルート設定が有効か、他のVPN・仮想ネットワークアダプター・セキュリティソフトがルートの優先順位を変更していないかを確認します。アプリが独自のプロキシ設定を使う場合、その設定が古いポートを指していると、現在のTUN経路を迂回することもあります。

ログに operation not permitted、インターフェース作成失敗、ルート追加失敗が出ている場合は、実行権限とシステムのネットワーク機能を確認します。LinuxではTUNデバイス、ネットワークマネージャー、ルーティングテーブル、サービスアカウントの権限にも注意が必要です。WindowsとmacOSでは、仮想ネットワークアダプター、システム拡張機能、管理者の許可状態を確認します。クライアントによって実装方法が異なるため、ログに記録された実際のシステム操作の失敗を基準に判断してください。

再利用できる切り分け手順：最初の異常から設定項目へ

安定した切り分けでは、低レベルの状態から具体的なリクエストへ順に確認します。起動状態を飛ばしてノードを変更したり、DNSという文字を見ただけで設定全体を書き換えたりすると、通常は変数が増えてしまいます。次の手順は、起動できない、サブスクリプション更新に失敗する、Webページが開かない、一部のアプリだけ異常になるといった一般的なケースに適用できます。

1. 障害の範囲を記録する。すべてのWebサイト、特定のドメイン、特定のアプリ、TCP、UDP、またはTUN有効時だけ発生するのかを明確にします。
2. コアが動作していることを確認する。設定の読み込み、プロキシポートとコントロールポートの待受が成功しているか、権限エラーやファイル不足がないかを確認します。
3. 設定の出所を確認する。サブスクリプションを更新した直後なら、ダウンロードが成功したか、正しい形式のレスポンスか、新しい設定を解析できるかを先に確認します。
4. リクエストがコアへ入っていることを確認する。再現可能なテストを1回実行し、その時刻に接続ログが出るか確認します。ログがなければ、システムプロキシ、アプリのプロキシ設定、TUNのルートを調べます。
5. DNSの結果を確認する。ドメインの名前解決が完了しているか、Fake-IPのマッピングが現在のモードに合っているか、上流DNSがタイムアウトしていないかを確認します。
6. ルールとポリシーを確認する。現在のモード、一致したルール、プロキシグループ、実際に使用されたノードを確認し、誤った振り分けをノード障害と取り違えないようにします。
7. 接続段階を確認する。ローカルからノード、プロトコルのハンドシェイク、TLS、ノードから対象、UDP経路を分け、各段階で1つの条件だけを変更してテストします。
8. 直近の変更を戻す。最後に動作していた設定へ戻し、DNS、TUN、ルール、ノードの変更を1つずつ適用して、障害を引き起こした最小の差分を特定します。

有効な切り分け記録には、少なくともクライアント名とコア名、OS、障害発生時刻、現在のモード、TUNの有効・無効、再現手順、最初の異常ログ、一致したポリシー、これまでにテストした単一の変更を含めます。バージョン番号も重要です。フィールドの対応範囲、デフォルトの挙動、エラーメッセージは、コアやクライアントの更新によって変わることがあるためです。

ログ診断の要点は、できるだけ多くのエラー行を集めることではなく、処理の順序を組み立てることです。設定が読み込まれ、ポートが待受を開始し、サブスクリプションから設定が生成され、DNSが対象を返し、ルールがポリシーを選び、ノードが接続を確立し、TUNがどのアプリの通信をコアへ取り込むかを決めます。各ログをこの流れに戻して考えれば、「Clashが使えない」という曖昧な状態を、具体的なフィールド、ポート、上流サービス、ネットワークインターフェースの問題へ絞り込めます。