まずログの出所と接続段階を確認する

Clashのログは「ノードの良し悪し一覧」ではありません。Webページへのアクセスひとつでも、ドメインの名前解決、ルール照合、プロキシサーバーへの接続、プロトコルのハンドシェイク、接続先サイトへのアクセスが発生することがあります。エラーが起きた段階によって対処方法は異なります。赤いログを見てすぐにサブスクリプションを更新すると、原因究明に役立つ情報を失いかねません。

まず、クライアントのログとコアのログを区別します。クライアントのログには、画面表示、設定のダウンロードや更新、権限に関する問題などが記録されます。Clashやmihomoのコアのログには、設定の読み込み、待ち受けポート、DNS、接続処理などが記録されます。クライアントがmihomoを使っていても、すべてのエラーがmihomoに起因するとは限りません。調査時はクライアントとコアのバージョンを両方記録し、「最新版」とだけ書かないようにしましょう。

  • 起動直後に失敗する：まず設定の解析、ポリシーの参照、ポートの競合、権限に関するメッセージを確認します。接続先サイトを調べるのはその後です。
  • 起動するがWebページを開けない：対象ドメインの接続ログを探し、ルールと通信の経路を確認します。
  • サブスクリプションの更新だけ失敗する：設定のダウンロードに使うネットワーク、サブスクリプションURLの状態、HTTPレスポンスを確認します。プロキシ接続の障害とは限りません。
  • ブラウザーで失敗するのに関連ログがない：まず通信がクライアントに届いているか確認してから、ノードを調べます。システムプロキシですべてのアプリの通信を捕捉できるとは限らず、TUNでもルートから除外されている場合があります。

ログレベルの変更方法：まずinfo、必要なときだけdebug

クライアントの「ログ」画面を開き、レベルのプルダウンメニューやフィルター項目を探します。画面上のフィルターは一部のログを非表示にするだけで、コアが出力するログレベルを変更しない場合があります。詳細なログが必要なら、実行中の設定で log-level が変更されていることを確認してください。

Clashの一般的なコアとmihomoでは、silent、error、warning、info、debug などのログレベルを使用します。通常は info から始め、調査が必要なときだけ debug に変更して、問題を一度再現したら元に戻します。詳細ログは出力量が増えるほか、アクセス先のドメインが記録されることがあります。

設定を変更する手順

  1. 現在の設定をバックアップし、クライアントが永続的な上書き、設定のマージ、ローカル設定の編集のどれに対応しているか確認します。
  2. トップレベルに log-level: debug を設定します。同じ項目がすでにある場合は値を変更し、重複して追加しないでください。
  3. クライアントの設定再読み込み機能で変更を適用します。コアの再起動が必要な場合は、画面の案内に従ってください。
  4. ログパネルを開き、warningまたはerrorだけが表示されている状態ではないことを確認します。失敗する操作を一度だけ行い、その前後約30秒のログを保存します。
  5. ログを収集したら log-level: info に戻し、アクセス記録が大量に出力され続けないようにします。
# トップレベル項目の例。既存の設定にマージしてください
log-level: debug

上記は完全な設定ではありません。サブスクリプションから生成されたファイルを直接編集すると、次回の更新時に上書きされることがあります。クライアントに上書き機能がある場合は、永続的な上書きを優先してください。メニューの場所はクライアントのバージョンによって異なるため、特定のクライアントの「設定」メニューをすべてのClashクライアント共通の入口として案内しないでください。

接続ログで確認する項目

まず時刻を確認し、次に接続先、ルール、エラーを見ます。接続ログには [TCP] や [UDP] の表示が含まれることがあります。match や using は通常、適用されたルールや使用された出力先を示します。出力内容はコアによって異なるため、すべてのログに全項目が含まれるとは限りません。

項目・内容確認すること
時刻とプロトコル直前に失敗した操作に対応していますか？TCPとUDPで挙動に違いはありますか？
送信元アドレスリクエストは現在の端末または想定したアプリからのものですか？バックグラウンド更新やLAN内の別端末からではありませんか？
接続先ドメインとポート接続先サイトの443番ポート、DNSの53番ポート、それともプロキシサーバー自体のポートですか？
ルールとポリシープロキシを使う想定なのにDIRECTに一致していませんか？REJECTで拒否されていませんか？ポリシーグループでは実際にどのメンバーが選択されていますか？
エラーの末尾接続失敗の直接の原因は名前解決、タイムアウト、接続拒否、それともプロトコルや証明書のエラーですか？

DIRECT は直接接続で通信することを示し、リクエストの成功を意味しません。REJECT はポリシーによる拒否を示し、意図したブロック結果の場合もあります。ログにプロキシグループ名が表示されていても、接続の詳細画面やポリシー画面で実際に選択されたノードを確認してください。自動選択のグループでは、テストのたびにメンバーが変わることがあります。

dial tcp、timeout、接続切断の違い

dial tcp：後続のアドレスと原因を確認する

dial tcp 192.0.2.10:443: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp: lookup proxy.example on 127.0.0.1:53: no such host

dial tcp はTCP接続を開始していることを示すだけで、これ自体が障害の結論ではありません。例にある 192.0.2.10 は文書用のサンプルアドレスです。実際のログでは、そのアドレスがプロキシサーバーか、直接接続する接続先かを確認します。プロキシサーバーへの接続自体に失敗しているなら、接続先サイトの振り分けルールを変更しても通常は解決しません。

  • connection refused：接続が明示的に拒否されています。ポートでサービスが待ち受けていない、ポート番号の誤り、ファイアウォールによる拒否などがよくある原因です。ユーザー名やパスワードの誤りとは限りません。認証は通常、接続確立後に行われます。
  • i/o timeout：ネットワークの読み書きが制限時間内に完了しませんでした。パケットロス、接続先から応答がない、出口側の制限、プロトコル処理の停滞などが考えられます。外側のエラーメッセージと合わせて発生箇所を確認してください。
  • network is unreachable：端末または現在のネットワークに利用可能なルートがありません。認証情報を変更する前に、ネットワークインターフェース、デフォルトルート、IPv6で接続可能かを確認してください。

context deadline exceeded：処理全体のタイムアウト

期限付きの処理が制限時間内に完了しなかったことを示します。DNSリクエスト、ヘルスチェック、接続確立の途中で発生する場合があります。この文言だけではノードを特定できません。DNSモジュールからの記録か、プロキシへの接続処理からの記録かなど、前後の情報を残し、同じ時刻のほかの接続ログと照らし合わせてください。

EOF、connection reset by peer：接続確立後に切断

EOF は読み込み時に接続の終了を検出したことを示し、connection reset by peer は接続先からリセットを受け取ったことを示します。サーバーによる切断、プロトコルの不一致、中間ネットワーク機器の干渉などが考えられます。毎回ハンドシェイク中に発生する場合は、ノードの種類、ポート、TLS設定、トランスポートのパラメーターを確認してください。アイドル接続の終了時にたまに発生するだけで、実際のアクセスに問題がなければ、このログだけで障害と判断する必要はありません。

DNS解決失敗：ノードのドメイン、接続先ドメイン、DNSリゾルバーを切り分ける

lookup、no such host、DNS request failed が表示されたら、まず名前解決しようとしているドメインを書き留めます。ノードのサーバードメインが解決できない場合、そのノードを使うすべてのリクエストに影響します。特定の接続先ドメインだけが失敗する場合は、そのドメインの記録と名前解決の経路を先に確認します。

ログの手がかり意味と次の確認項目
no such host利用可能な結果が得られていません。ドメインが存在しない場合や、上位DNSサーバーから否定応答が返った場合によく発生します。表記、ドメインの状態、実際に使われたDNSリゾルバーを確認してください。
DNSリクエストがタイムアウトまずDNSの上位サーバーに到達できるか、プロトコルの設定が正しいか確認します。DoHを使う場合は、最初の名前解決でDoHサーバーのドメインをどう解決するかも確認してください。
127.0.0.1:53への接続に失敗端末の53番ポートでDNSサービスが実際に待ち受けているか確認します。ループバックアドレスは現在の端末を指し、ルーターやほかの端末を示すものではありません。
server misbehaving通常はDNSサーバーからのエラー応答に関連します。具体的な応答内容とほかのリゾルバーの結果を比べてください。ドメインが存在しないとすぐに断定しないようにしましょう。

システムの検索結果がクライアントのDNS結果とは限らない

たとえば nslookup example.com は通常、システムで選択されているリゾルバーに問い合わせます。クライアントが内蔵DNS、fake-ip、または個別のDNS上位サーバーを使っている場合、この結果がアプリで実際に使われる名前解決経路と一致するとは限りません。まず実行中の設定で待ち受けアドレスとポートを確認し、アプリのリクエストが捕捉されているか調べてください。

fake-ipモードで 198.18.0.0/16 のようなアドレスが表示される場合、設定で割り当てられたマッピング用アドレスの可能性があります。このアドレスだけを見てDNSエラーと判断しないでください。アプリに古いマッピングが残り、コアの再起動後にマッピングの状態が変わった場合は、該当アプリの接続を閉じ、クライアントが案内する方法でキャッシュを消去してから再度テストしてください。

mihomoの proxy-server-nameserver は、プロキシノードのドメイン解決に使用できます。この項目が必要かどうかは、コアのバージョンと現在のDNS設計に応じて判断してください。mihomo向けの項目を、対応していない旧式のコアに追加しないでください。また、DNS設定を一度にすべて置き換えず、まずどのドメインと上位サーバーで失敗しているか確認しましょう。

ポート、TLS、設定エラーの確認ポイント

address already in use：ローカルの待ち受けポートが使用中

起動ログに 127.0.0.1:7890 で待ち受けられないと表示された場合は、クライアントを2つ同時に起動していないか、前のコアプロセスが終了しているかを確認します。7890はよく使われる設定例です。実際の値は現在の mixed-port、port、socks-port を確認してください。

# Windows PowerShell：サンプルポートを待ち受けているプロセスを確認
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：サンプルポートのTCP待ち受けを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：サンプルポートのTCP待ち受けを確認
ss -ltnp 'sport = :7890'

プロセスを特定したら、アプリを通常の手順で終了してポートを解放するか、現在の待ち受けポートを変更します。PIDだけを見て、正体不明のプロセスを強制終了しないでください。ポートを変更した場合は、システムプロキシやアプリ側のプロキシアドレスも更新します。更新しないと「コアは正常なのにアプリが古いポートへ接続する」状態になります。

x509とTLS handshake：時刻、証明書、サーバー名を確認

x509: certificate has expired or is not yet valid が表示されたら、まず端末の日付、タイムゾーン、自動時刻設定を確認し、その後サーバー証明書の有効期間を確認します。証明書名が一致しない場合は、サーバーアドレス、TLSのサーバー名、プロバイダーが指定する設定を確認してください。TLS handshake timeout はネットワークの遮断やポートとプロトコルの不一致でも発生するため、証明書の期限切れと決めつけないでください。

設定の読み込み失敗：まず起動できる状態に戻す

YAMLの解析エラー、未定義のポリシー、プロキシグループの不足が発生したら、まず直近の変更を元に戻します。YAMLのインデントにはスペースを使い、タブを混在させないでください。ルールから参照するポリシー名は、実際に定義された名前と一致させます。コアが設定を読み込めていない場合、その後のWebアクセス失敗は単なる回線の問題ではありません。まず設定の読み込みとポートの待ち受けを成功させてから、接続のトラブルを調べます。

時系列に沿って再現する：一度に変えるのは1項目だけ

バックグラウンド同期、自動ヘルスチェック、アプリの再試行があると、ログはすぐに埋もれます。有効な再現に必要なのは大量のログではなく、ひとつの操作と短いログを対応づけることです。以下は繰り返し実行できる確認手順です。時刻は操作例です。

  1. 14:20:00、基準情報を記録。クライアントのバージョン、コアのバージョン、OS、ネットワークの種類、現在のモード、TUNの有効・無効、ポリシーグループで選択されているノードを書き留めます。
  2. 14:20:10、短時間のログ収集を開始。コアのログレベルをdebugに変更します。パネルの古い表示を消すか開始時刻を記録し、起動と設定読み込み時のエラーはそのまま残します。
  3. 14:20:20、接続先をひとつ開く。関係のないタブを閉じ、以前に接続できなかったURLをひとつだけ開きます。ブラウザーのエラー表示と、ログに記録された接続先のポート、ルール、出力先を記録します。
  4. 14:20:40、比較テストを一度行う。接続先、モード、ネットワークは変えず、ノードひとつだけを切り替えます。ノードのドメインをどれも解決できない場合は、ランダムに切り替え続けず、まずDNSを調べてください。
  5. 14:21:00、違いを整理。通信が取り込まれていないのか、誤ったルールに一致したのか、ノードへの接続に失敗したのか、接続後に接続先から異常な応答があったのかを確認します。失敗した段階を具体的に記録してください。

ログがない場合は、ログレベルではなく通信の取り込みを確認する

ローカルプロキシ経由のリクエストを比較用に使えます。以下のコマンドは、現在の設定で 127.0.0.1:7890 にHTTPまたはmixedプロキシが実際に用意されている場合に限り使用してください。Windows PowerShellでは、ほかのコマンドのエイリアスと混同しないよう curl.exe を使います。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

ここでの10秒は接続確立段階のタイムアウト上限、20秒はリクエスト全体の制限時間であり、速度の指標ではありません。このコマンドはHEADリクエストを使用します。サイトによってはHEADの処理が通常のWebページへのアクセスと異なります。明示的なプロキシ経由の経路を確認する用途には使えますが、ブラウザーでのアクセスの代わりにはならず、TUNがすべての通信を取り込んでいることも確認できません。

コマンドでは接続ログが出るのにブラウザーでは出ない場合は、ブラウザーのプロキシ拡張機能、システムプロキシ、アプリ固有の設定を確認します。TUNを有効にした後に問題が起きた場合は、まずルートとDNSの状態を記録し、オン・オフを一度だけ切り替えて比較してください。TUN、DNSモード、ノード、ルールを同時に変更すると、どの変更が影響したのか分からなくなります。

トラブル報告の作成：前後の情報を残し、機密情報を削除する

メンテナーやサービス提供者に報告する際は、最後の1行だけを切り取った画像より、失敗の前後約30秒の必要なログを共有するほうが役立ちます。テキストログは検索や比較に便利ですが、認証情報や個人情報が含まれていないか、必ず事前に確認してください。

  • 残す情報：正確な時刻とタイムゾーン、クライアントとコアのバージョン、エラー全文、接続先ポート、適用ルール、使用プロトコル、実施済みの単一項目比較。
  • 削除する情報：サブスクリプションURLの全体、認証トークン、パスワード、UUID、コントロールインターフェースのキー、公開する必要のないアクセス先ドメインや端末のパス。
  • 一貫してマスキングする：同じノードには別々のログでも同じ仮名を使い、関連が分からなくならないようにします。すべてのドメインやアドレスを同じ文字列に置き換えないでください。
  • 実ログと編集内容を区別する：どの情報が実際のログで、どの情報が再現手順なのか明記します。書き直した例をクライアントの実際の出力として扱わないでください。

最終的な説明は、「プロキシサーバーへのTCP接続がタイムアウトした」「ルールによって接続先がDIRECTに振り分けられた」「ノードのドメインを解決できなかった」のように具体的に書き、「Clashが使えない」だけで済ませないようにします。まず失敗した段階を特定し、対応するネットワーク、ルール、設定を確認すれば、その後の変更に明確な根拠を持たせられます。