まずログの出所とエラー発生時刻を確認

Clashのログは単なるエラー一覧ではありません。設定の読み込み、ポートの待ち受け、DNSリクエスト、ルール判定、外向き接続が記録されています。原因を調べるときは、リクエストがコアに届いたか、どのポリシーに振り分けられたか、どの段階で接続に失敗したかを確認しましょう。赤いエラーを1行見ただけで全ノードを切り替えると、ポートや名前解決の問題と、接続先サービスの障害を混同しかねません。

この記事は、ClashまたはClash Meta（現名称：mihomo）コアを使用するクライアントを対象としています。クライアントやコアのバージョンによって、ログの形式やメニュー名は異なる場合があります。まずクライアントの「バージョン情報」で両方のバージョンを確認し、「ログ」または「実行ログ」を開いてください。サブスクリプションの更新ログ、クライアント画面のログ、コアの実行ログは、それぞれ別のものとして扱いましょう。

  1. エラーが発生した現地時刻を、14:32:10のように秒単位で記録します。
  2. ダウンロード、動画再生など、継続的に通信するタスクを一時停止します。画面上のログ履歴を消去し、調べたいリクエストだけを1回実行してください。
  3. 操作の前後約10秒間のログを保存し、「接続」画面で対象ドメイン、宛先ポート、適用ルール、実際の出先を確認します。
  4. ルール、グローバル、直接接続のどのモードか、システムプロキシやTUNが有効かを記録します。テストごとに変更する項目は1つだけにしてください。

log-levelの変更：まずinfo、必要なときだけdebug

通常の調査では、まずinfoを使います。接続先、適用ルール、使用ポリシーの確認には、通常これで十分です。名前解決の過程やポリシープロバイダー、接続の詳細が分からない場合に限り、一時的にdebugへ切り替えます。silentではログが出ないため、調査には適しません。errorやwarningでは、成功した接続やルールの情報が省略される場合があります。

設定と反映状況を確認

クライアントの設定で「ログレベル」を探します。項目がない場合は、クライアントが対応する設定編集または上書き機能から、トップレベルのフィールドを変更してください。以下はコア設定で使う値です。警告レベルはwarningと記述し、画面上の略称から設定値を推測しないでください。

# トップレベルの設定；調査後にinfoへ戻す
log-level: debug
mode: rule
  • 保存後、クライアントに設定の再読み込み機能があれば実行します。コアの再起動が必要と表示された場合は指示に従い、起動時にエラーがないことを確認してください。
  • リモートサブスクリプションの更新で直接編集した内容が上書きされる場合があります。クライアントが対応する永続的な上書き機能を優先して使いましょう。
  • 再現操作は1回で十分です。該当する時間帯のログを出力し、debugを何時間も有効にしたままにしないでください。終了後はinfoに戻します。

デバッグログには、アクセス先のドメイン、ローカルアドレス、ノード名、設定ファイルのパスが含まれることがあります。外部に共有する前に、サブスクリプションのトークン、認証情報、コントロールAPIのキー、個人用ディレクトリの情報を削除してください。一方で、原因特定に必要なエラーの種類、ポート、ポリシーの関係は残しましょう。

接続ごとに宛先・ルール・出先を確認

ログ全体の先頭から推測するのではなく、対象ドメインやポートを検索します。Webページを1回開くだけでも、メインサイト、画像、API、解析用ドメインなどへのリクエストが同時に発生します。エラーが1件あっても、メインページへの接続に失敗したとは限りません。以下はTCP接続を簡略化した例です。

[TCP] 127.0.0.1:52144 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]
項目確認する内容
TCP / UDP通信プロトコルを確認します。ブラウザーはUDPベースのHTTP/3を使用する場合があります。
127.0.0.1:52144この例はローカル側の接続元と一時ポートを示しており、クライアントのプロキシ待ち受けポートではありません。
www.example.com:443接続先のホストとサービスポートです。今回の失敗操作に関係する宛先か確認してください。
DomainSuffix適用されたルールの種類です。ルールで指定されたポリシー名も確認します。
Proxy[Node-A]ポリシーグループと最終的に選ばれたノードの例です。実際には複数階層のポリシーチェーンが表示される場合があります。

using DIRECTと表示された場合は、ルールが無効だと決めつける前に、直接接続が想定どおりか確認してください。接続ログが示すのはルーティング先であり、リモートへのリクエストが成功したことまでは分かりません。その後のエラーや通信量、アプリの結果もあわせて判断しましょう。

dial tcp timeout：どの接続がタイムアウトしたかを見分ける

dial tcp、i/o timeout、context deadline exceededを検索すると、接続や処理のタイムアウトを調べられます。dial tcpはTCP接続の確立段階を示しますが、ほかのタイムアウトはDNS問い合わせ、TLSハンドシェイク、プロキシプロトコルのやり取りで発生することもあります。前後のログにある接続先アドレスと処理内容を確認してください。

ノードのアドレスとWebサイトのアドレスを区別

  • プロキシノードへの接続がタイムアウトする場合：エラーに表示されたアドレスが、ノードのサーバーとポートか確認します。ノードのドメイン名の名前解決、ポート、ネットワーク到達性、サブスクリプションの有効期限を確認し、同じポリシーグループ内の別の利用可能なノードも試してください。
  • Webサイトへの直接接続がタイムアウトする場合：接続ログがDIRECTで、宛先がWebサイトのアドレスなら、直接接続のネットワーク、接続先サービス、ルールの選択を確認します。ノードの設定だけを変更しても解決しません。
  • ノード経由でもWebサイトにアクセスできない場合：ノードへの接続は確立できても、宛先へのリクエストが失敗しています。同じノードでほかのサイトにアクセスできるか、別のノードで同じサイトにアクセスできるかを比較し、接続先側とノードの出口側のどちらに原因があるか絞り込みましょう。

connection refusedはタイムアウトとは異なります。接続先ポートでサービスが待ち受けていないなど、接続が明示的に拒否されたことを示す場合があります。中継機器から拒否されることもあります。connection reset by peerは接続がリセットされたことを示しますが、この1行だけでパスワードの誤りや特定のネットワーク干渉が原因だと断定することはできません。

DNS名前解決の失敗：2つの経路を切り分ける

DNSエラーは少なくとも、「プロキシノードのドメイン名を解決できない場合」と「接続先ドメインを解決できない場合」に分けて考える必要があります。前者ではプロキシ接続を確立する前に処理が止まります。後者は、現在のDNSモード、接続先の名前解決経路、上流のDNSリゾルバーに関係します。ログにあるlookup、no such host、DNS resolve failedや問い合わせタイムアウトは、その後に表示されるドメイン名とあわせて読んでください。

  1. ドメイン名と用途を確認する。ノードサーバーのドメイン名で失敗している場合は、ノード設定と、そのドメインが現在も有効かを確認します。
  2. エラー応答とタイムアウトを区別する。no such hostは、ドメインが存在しない場合や、有効なレコードが見つからない場合によく表示されます。問い合わせがタイムアウトする場合は、上流DNSへの接続性、通信方式、ルーティングを確認してください。
  3. リゾルバー起動時の依存関係を確認する。DoHの上流サーバーにドメイン名を指定している場合、リゾルバー自身のドメイン名を先に解決する必要があります。mihomoのdefault-nameserverやproxy-server-nameserverなどのフィールドにはそれぞれ用途があります。使用中のバージョンのドキュメントを確認し、すべてのアドレスを任意に入れ替えないでください。
  4. 設定を再読み込みして新しい接続で試す。DNS設定を変更したら、クライアントの対応機能でキャッシュを消去するかコアを再起動し、アプリの既存接続も終了してください。古い結果が判断に影響するのを防げます。

Fake-IPのアドレスだけで名前解決の異常とは限らない

Fake-IPを有効にすると、クライアントがアプリに設定済みアドレスプール内の仮想アドレスを返す場合があります。たとえば、よく使われる範囲は198.18.0.0/16です。後続の接続をドメイン名に対応付けるためのアドレスであり、WebサイトのグローバルIPではありません。このアドレスを見ただけでDNSの汚染と判断せず、接続がコアに取り込まれているか、ドメイン名との対応付けが有効かを確認してください。

システムのターミナルで実行したnslookupの結果が、コアで実際に使われる結果と一致するとは限りません。システムDNS、ブラウザーのセキュアDNS、コアのDNS、リモートプロキシでの名前解決は、異なる経路を通る場合があります。TUNを調べる際は、設定にenable: trueと書かれていることだけでなく、DNSハイジャックの設定とルーティングが実際に反映されているかも確認してください。

ルールが適用されない：モードと最初に一致するルールを確認

ルールモードではルールを上から順に評価し、通常は最初に一致したルールで出先が決まります。グローバルモードでは通常のルール一覧に従って接続ごとにポリシーを選びません。直接接続モードではそのまま接続します。そのため、「ドメインルールを書いたのに別のノードへ接続される」ときは、まずクライアントがruleモードになっているか確認してください。

# 例：Proxyは設定に存在するポリシー名にする
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

この例では、example.comとそのサブドメインは1つ目のルールに一致し、それ以外の未一致の接続はMATCH,DIRECTに進みます。適用範囲の広いルールを上に置くと、後続の詳細なルールに一致する機会がなくなることがあります。サブスクリプションの元ファイルだけでなく、クライアントで最終的に有効になっているルールを確認してください。

  • ログにIPアドレスしか表示されない場合：アプリがコアを経由せずに名前解決していないか、接続にドメイン名の情報が残っているかを確認します。IPアドレスだけでは、ドメインルールがどのサイトに属するか判断できません。
  • フォールバックルールに一致する場合：接続先が実際にはAPIやCDNのサブドメインではないかを確認し、ルールプロバイダーの読み込み成功と更新時のエラーもチェックしてください。
  • ルールは正しいのにノードが違う場合：ポリシーグループで現在選択されているノードを確認します。自動速度測定グループやフォールバックグループは、それぞれの仕組みに従ってメンバーを選びます。
  • 変更後も古いポリシーが使われる場合：対象の既存接続を終了してから再試行してください。ルールを再読み込みしても、既存の長時間接続がすぐに再ルーティングされるとは限りません。

mihomoのドメインスニッフィングは、対応するプロトコルと設定条件のもとでドメイン情報を補完できますが、暗号化された接続のすべてからドメイン名を復元できるわけではありません。スニッフィングの有効化をあらゆるルール問題の解決策と考えたり、特定サイトのために全通信をグローバルモードへ恒久的に切り替えたりしないでください。

接続ログがない：入口ポートと通信の取り込み方法を確認

アプリにエラーが出てもコアに該当する記録がない場合は、まずリクエストがクライアントに届いているかを確認します。システムプロキシの設定が適用されるのは、システムプロキシに従うアプリだけです。一部のコマンドラインツールやゲーム、独自のプロキシ設定があるアプリでは、個別の設定や適切なTUNによる取り込みが必要です。システムプロキシを有効にしても、すべてのTCP・UDP通信がコアに入るわけではありません。

明示的なプロキシ設定で比較テストする

実際に有効なローカル設定で混合ポートが7890の場合、以下のようにプロキシを明示してリクエストできます。このポート番号は例です。必ずクライアントに現在表示されている待ち受けポートに置き換えてください。ポートが0の場合や無効になっている場合は、そのまま使えません。

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

Windows PowerShellでは、環境によるコマンドエイリアスの違いを避けるため、コマンドの先頭をcurl.exeにできます。実行中はログも確認してください。リクエストがコアに届く一方でブラウザーのリクエストが届かない場合は、ブラウザーのプロキシ設定、拡張機能、接続の再利用を確認します。すぐに127.0.0.1:7890へ接続できないと表示される場合は、コアが起動しているか、ポート番号が正しいか、待ち受けが成功しているかを確認してください。

  • address already in use：待ち受けアドレスまたはポートが使用中です。プロキシクライアントが2つ同時に起動していないか確認し、競合するサービスを停止するか待ち受けポートを変更して、入口側の設定も更新してください。
  • permission denied / operation not permitted：ログの前後関係を確認し、TUN、ルート操作、ファイルアクセスに必要な権限を調べます。クライアントの案内に従って必要な許可を与えてください。
  • authentication failed：エラーがローカルの入口認証、プロキシノードの認証、サブスクリプションのダウンロード認証のどれに関するものか確認してください。各箇所の認証情報を混同しないようにします。
  • TUNの起動に失敗する場合は、仮想ネットワークアダプターの作成、ルートの追加、権限確認で最初に出たエラーを確認します。ほかのVPNと同時にルートを変更した状態でテストを続けないでください。

このcurlテストで確認できるのは、明示的なHTTPプロキシの入口と、そのリクエスト経路が中心です。TUN、UDP、すべてのアプリが正常だと証明するものではありません。クライアントにTUNの自動ルーティングなどの設定がある場合は、実際のルートもあわせて確認してください。

再現手順を固定して調査内容を記録

役に立つ障害記録とは、赤字が何十行も並んだスクリーンショットだけでなく、別の担当者が同じ操作を再現できるものです。以下の順で調査を進め、各段階を確認してから次へ進みましょう。

  1. コアの起動：設定の読み込みと必要なポートの待ち受けが成功し、再起動を繰り返していないことを確認します。
  2. リクエストの到達：プロキシを明示したテスト、またはアプリの接続記録を使い、コアが対象リクエストを認識していることを確認します。
  3. 名前解決の完了：ノードのドメインと接続先のドメインを区別し、DNSの前段階で失敗していないか確認します。
  4. ルーティングの確認：適用されたルール、ポリシーグループ、最終ノードを記録します。必要に応じて既存接続を終了して再テストしてください。
  5. 出先の比較：同じ接続先でノードを変える、または同じノードで接続先を変えるなど、1回のテストで変更する条件は1つだけにします。
  6. 設定の復元：debugをinfoに戻し、診断用の一時ルールを取り消して、普段使うアプリの接続状態を確認します。

問い合わせ時に添える情報

OSのバージョン、クライアントとコアの完全なバージョン、使用したプロキシ入口とポート、出先モード、TUNの状態、エラー発生時刻、該当部分を伏せ字処理したログを記録してください。「ブラウザーから特定ドメインに接続できないが、プロキシを明示したcurlは成功する」のように説明すると、「急にネットワークがおかしくなった」より原因を特定しやすくなります。「1つのノードだけ失敗し、同じグループの別ノードでは成功する」とあれば、ノード設定やノードからの通信経路に絞り込めます。

接続の確立がログに記録されているのに、アプリが証明書、ログイン、HTTPステータスのエラーを表示する場合は、アプリケーション層を調べてください。システム時刻のずれ、サーバーから返された403、アカウントの状態、証明書の信頼性は、ルールの順番を変えても解決しません。調査のゴールは、障害が発生している層を特定し、同じ操作で修復を確認することです。ログ画面から警告をなくすことではありません。