Clashのログの見方｜よくあるエラーの意味と原因の調べ方

まず、どの段階で失敗したのかを確認してから設定を変更しましょう。赤いログが出たからといってノードを切り替えると、かえって遠回りになることがあります。ローカルポートが起動していない、ドメインを名前解決できない、ルールで誤った接続先が選ばれた、リモートとのハンドシェイクに失敗したなど、どれも「ウェブページが開かない」ように見えますが、対処法はそれぞれ異なります。

この記事はClashおよびClash Meta（現名称：mihomo）カーネルを対象としています。ログの表示形式はクライアントによって異なり、同じエラーでも先頭部分が違う場合があります。以下のログは構造を示す例であり、特定の端末で取得した実測ログではありません。調査の際は、ご自身のログに記録された時刻、接続先アドレス、実際の出口を確認してください。

1. 失敗時のログを一式取得する

クライアントの「ログ」または「Logs」画面を開き、まず画面内の検索語を消します。レベルの表示フィルターとカーネルのログレベル設定が両方ある場合は、違いに注意してください。フィルターは既存のログを非表示にするだけで、出力されなかったデバッグ情報を後から補うことはできません。通常はinfoを使い、問題を再現しにくい場合に限って一時的にdebugへ切り替えます。

クライアント名とバージョン、カーネル名とバージョンを記録します。クライアントのバージョンとカーネルのバージョンは別です。
現在の設定名、動作モード、システムプロキシとTUNの有効・無効を確認し、端末の時刻も記録します。
既存のログは残したまま、画面表示をクリアするか開始位置を控えてから、問題のあるURLに一度だけアクセスします。
失敗した行と、その前後およそ10行をコピーします。複数の接続がある場合は、接続先ドメインやポート、送信元ポートで区別してください。表示位置が近いだけで関連があると判断しないようにします。

2. ログレベルと接続情報の読み方

レベル	主な内容	調査での使い方
`debug`	名前解決や接続など、詳細な処理情報	問題の短時間の再現に使用し、終わったら元に戻す
`info`	起動状態、ルールの一致、出口の選択	リクエストがカーネルに届いたか、どのポリシーを通ったかを確認
`warning`	接続失敗または復旧可能な異常	接続先アドレスから、利用中のサービスに影響があるか判断
`error`	比較的深刻な動作・読み込み上の問題	設定の読み込み、待ち受け、リソースの初期化を優先して確認
`silent`	通常のログ出力を抑制	障害の再現時には不向き

これらは、カーネルログでよく使われるレベル名です。クライアントによってはwarningをWARNや日本語のラベルで表示します。レベルが示すのはログの重要度であり、障害が必ずローカルで発生したという意味ではありません。ウェブサイト側のリクエストタイムアウトも、警告として記録されることがあります。

time="2026-09-11T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[ノードA]"

time：記録された時刻です。システムのタイムゾーンと照らし合わせ、過去のエラーを今回のリクエストと取り違えないようにします。
[TCP]：接続に使用したトランスポートプロトコルです。UDPリクエストには対応する識別子が表示されます。
127.0.0.1:53124：今回の接続元です。カーネルのプロキシ待ち受けポートではありません。
example.com:443：リクエストの接続先です。443は通常HTTPSに使われますが、ポート番号だけではアプリケーションプロトコルを特定できません。
match：実際に一致したルールです。設定上、適用されるはずのルールとは限りません。
using：ポリシーグループと選択された出口です。グループ名がPROXYでも、現在選択されている項目がプロキシノードとは限りません。

このログ行から分かるのは、カーネルが接続にルールを適用し、出口を選択したことです。ウェブページのダウンロードに成功したという意味ではありません。その後の接続、TLSハンドシェイク、アプリケーションからの応答で失敗することもあります。同じアクセスで出力された失敗ログもあわせて確認してください。

3. dial tcpのタイムアウト：接続先を確認する

dial tcp 203.0.113.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

最初の行は、TCP接続の開始が制限時間内に完了しなかったことを示します。例にある203.0.113.10は文書用のアドレスで、テストには使えません。実際のログでは、ここにウェブサイトのIPアドレスが表示されることも、プロキシサーバーのIPアドレスが表示されることもあります。エラーの前後の記録と出口を確認して判断してください。プロキシ経由の場合、「接続開始に失敗」とあっても、ウェブサイトのサーバーに問題があるとは限りません。

アドレスの種類ごとに確認する

アドレスがプロキシサーバーの場合：テストするURLは変えず、ノードを1つだけ切り替えます。特定のノードだけでタイムアウトが続く場合は、まずノードのアドレス、ポート、サービスの稼働状況を確認してください。DNS設定全体を先に変更する必要はありません。
アドレスが接続先ウェブサイトの場合：実際にDIRECTで接続していないか確認します。中国本土向けと海外向けのルール設定が逆だと、本来プロキシ経由にする接続が直接接続されることがあります。
アドレスがローカルのループバックアドレスの場合：ローカルプロキシがそのポートで待ち受けているか確認します。7890はよく使われる設定値ですが、実際の値は現在の設定とクライアント画面で確認してください。

connection refusedは通常、接続が明示的に拒否されたことを示します。待ち受けプロセスがない場合や、ファイアウォールが拒否した場合によく発生します。一方、i/o timeoutは応答を待っているうちにタイムアウトした状態です。両者を混同せず、一度のタイムアウトだけでノードが恒久的に使えないと決めつけないでください。

プロキシを明示したリクエストで原因を絞り込む

混合プロキシポートが実際に7890であることを確認してから、次のコマンドを実行します。Windowsでは、PowerShellの旧バージョンでcurlのエイリアスが影響するのを避けるため、curl.exeを使ってください。

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

ここで10秒は接続確立までの上限、20秒はリクエスト全体の上限です。ネットワーク速度を測る値ではありません。コマンドでローカルプロキシを明示しているため、ブラウザーでの結果と比較できます。コマンドでは成功してブラウザーでは失敗する場合は、ブラウザーのプロキシ拡張機能、システムプロキシ、アプリ独自のネットワーク設定を確認してください。ログに該当する接続がまったくない場合は、コマンドで指定したポートとログのフィルターを確認します。

4. DNS名前解決の失敗：3種類のドメインを区別する

DNSエラーが出たら、まず何の名前解決に失敗したのかを確認します。接続先ウェブサイトのドメイン、プロキシサーバーのドメイン、それともDNS上流サーバー自体のドメインでしょうか。この3種類の失敗は、それぞれ異なる段階で発生します。プロキシサーバーのドメインを解決できない場合、接続の出口がまだ用意できていないため、ウェブサイトを変えても解決しません。

lookup example.com: no such host
lookup example.com: i/o timeout

no such hostは、ドメインが存在しない場合や、リゾルバーから否定応答が返された場合によく発生します。i/o timeoutは、問い合わせに時間内に応答がなかった可能性を示します。具体的な原因は、エラーに記載されたDNSサーバーと前後の状況も確認してください。all DNS requests failedと表示された場合は、今回問い合わせた上流サーバーがすべて失敗したという意味です。「すべてのノードが使えない」とは判断できません。

まずドメインのつづりを確認し、次に現在の設定にあるdns.enableやnameserverなどのフィールドを確認します。
DNS上流サーバーに到達できるか確認します。暗号化DNSを使う場合は、上流サーバーのアドレス解決、接続、証明書の検証も関係するため、UDPの53番ポートだけを確認しても不十分です。
mihomoの設定でproxy-server-nameserverを使っている場合は、プロキシノードのドメイン名を解決する役割を果たしていることも確認してください。まだ確立していないプロキシ出口に依存しないようにします。
上流サーバーを1つだけ置き換え、同じドメインで変更前後の結果を記録します。DNS、ノード、ルールを一度に変更しないでください。

fake-ipモードで198.18.0.0/16の範囲にある合成アドレスが表示されても、すぐにDNS汚染と判断しないでください。fake-ipのマッピング、通信がカーネルに戻っているか、ドメイン情報をルールの判定に使えるかを続けて確認します。

5. ルールが一致しない：実際の出口から順に確認する

「ルールが一致しない」は、明確なエラーメッセージではなく、接続ログに想定外のルールが表示されている状態を指すことがよくあります。まず現在のモードがRule／ルールモードか確認してください。Global／全体モードやDirect／直結モードでは、分割ルールが同じように適用されません。ルールファイルを変更しても期待した変化が見られないことがあります。

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

この例はルールの順序を説明するもので、設定にPROXYという名前のポリシーグループが定義されている前提です。ルールは通常、上から順に評価され、最初に一致したルールのポリシーが使われます。MATCHは末尾にフォールバックとして置きます。ドメインルールより前にMATCHを書くと、後続のルールは接続に適用されません。

MATCHに一致しても、必ずしもエラーではない

より具体的なルールが一致しない場合、フォールバックが使われるのは正常です。特定のドメインに専用ルールを適用する想定なら、実際に読み込まれた設定、ルールのつづり、リモートルールセットの読み込み状態、ログにドメイン名が記録されているかを確認します。接続先がIPアドレスしか分からない場合、ドメインルールが想定どおりに適用されないことがあります。スニッフィングでも、すべての接続から確実にドメイン名を復元できるわけではありません。

DOMAINはドメイン名の完全一致に使います。DOMAIN-SUFFIXはドメイン名とそのサブドメインに使います。完全なURLやパスは指定しないでください。
RULE-SETには対応するrule-providers名が必要です。ルールセットの種類と内容の形式も適合していることを確認してください。
GEOSITEなどの機能は、カーネルが対応しているか確認してください。mihomoの設定が旧バージョンのClashカーネルでもすべて使えるとは限りません。
サブスクリプションから生成された設定を変更する前に、クライアントの上書き機能を確認してください。一時ファイルを直接編集しても、次回のサブスクリプション更新で変更が消えることがあります。

最後にポリシーグループを開き、グループ内で実際に選択されている項目を確認します。ログでPROXYに一致していても、グループの現在の選択先がDIRECTなら、最終的には直接接続されます。ルール名、ポリシーグループ名、実際の出口を分けて確認してください。

6. 待ち受け、TLS、TUNでよくある見落とし

ログや症状	まず確認すること
`address already in use`	競合している具体的な待ち受けアドレスとポート、2つ目のカーネルが動作していないか
`certificate has expired or is not yet valid`	システムの日付とタイムゾーン、検証対象サービスの証明書の有効期間
`TLS handshake timeout`	TCP接続後のハンドシェイク、ノードの設定、ネットワーク上の中間機器
`permission denied`	エラーに関連するファイル、待ち受け処理、仮想ネットワークアダプターの権限
TUNを有効にしても該当する接続ログがない	TUNが正常に作成されたか、ルートが有効か、アプリがトラフィック制御を回避していないか

ポートの競合が疑われる場合、Windowsではnetstat -ano | findstr :7890を実行して、関連する待ち受けとPIDを確認できます。macOSまたはLinuxではlsof -nP -iTCP:7890 -sTCP:LISTENを使います。プロセスを確認してから重複したインスタンスを終了してください。正体の分からないシステムプロセスをそのまま終了してはいけません。ポートを変更する場合は、システムプロキシとテストコマンドの設定も合わせて変更します。

証明書エラーが出ても、証明書検証を無効にすることを一般的な解決策にしないでください。まずシステム時刻を合わせ、エラーがサブスクリプションのダウンロード、DNS上流、プロキシサーバー、接続先ウェブサイトのどこで発生したかを確認します。それぞれの段階で使われる証明書は別物です。誤った箇所を変更しても解決せず、接続の検証が弱まるおそれがあります。

TUNは通信を取り込む方式であり、到達できないノードや期限切れの証明書を自動で修復するものではありません。まずTUNを無効にし、HTTPプロキシを明示したコマンドでカーネル経由の接続を確認します。明示的なプロキシ接続は成功し、TUNでは失敗する場合は、サービスの権限、仮想ネットワークアダプター、ルーティング、DNSの取り込みに絞って調べます。クライアントを再インストールしたり、すべてのルールを変更したりするより、問題の切り分けに役立ちます。

7. ログから設定をたどる手順

カーネルが動作しているか確認します。設定の読み込みが成功したか、プロキシポートが待ち受けているかを確認します。起動エラーが解決するまでは、ウェブサイトのルールを調べる必要はありません。
リクエストがカーネルに届いているか確認します。URLとアクセス回数を1つに絞り、該当する接続が記録されるか確認します。ログのフィルターによって表示されていない可能性も除外してください。
動作モードと一致したルールを確認します。Rule、Global、Directのどれかと、ログに記録された一致項目を控えます。
実際の出口を確認します。ポリシーグループを展開し、最終的に選択されているノードまたはDIRECTを確認します。グループ名だけで判断しないでください。
失敗した段階を確認します。ドメインの名前解決、TCP接続、TLSハンドシェイク、アプリケーションの応答を区別してから、関連する設定項目を調べます。
一度に変更するのは1か所だけにします。元の設定を保存し、再読み込みしてから新しい接続を行い、同じリクエストで結果を比較します。既存の接続は、以前の出口を使い続ける場合があります。
再テスト後、ログレベルを元に戻します。同じリクエストを数回続けて試し、安定して解決したことを確認します。その後、debugをinfoに戻し、アクセス記録が細かく残り続けないようにします。

設定項目を確認するには、設定項目の説明をご覧ください。コミュニティに質問する際は、カーネルのバージョン、機密情報を伏せた設定の抜粋、再現手順、該当する時刻のログを添えてください。「プロキシが使えない」とだけ伝えるより、ポートやルール、DNS上流のどこに問題があるかをすばやく絞り込めます。