Clashの実行ログの読み方：DNSエラーから接続タイムアウトまでの切り分け

まずログが画面、カーネル、OSのどこから出ているか確認する

Clashクライアントで「接続に失敗しました」と表示されても、画面の通知は結果しか示さないことが多く、切り分けに役立つのはカーネルの実行ログです。Clash Meta（現在の名称はMihomo）はDNS、ルール判定、ノード接続、TUNによる通信転送を担当し、デスクトップクライアントはカーネルの起動、システムプロキシの変更、ログの表示を担います。2つの層で別々にエラーが発生することがあるため、最初に確認すべきなのは英文の一行を検索することではなく、どの層でエラーが起きたかです。

ログの発生元	よくある内容	優先して確認する対象
クライアントの画面ログ	カーネルの起動失敗、設定の保存失敗、サービスモードのインストール結果	クライアントの権限、カーネルのパス、設定ファイル
Mihomoカーネルの実行ログ	DNSクエリ、ルールの適用、プロキシへの接続、接続タイムアウト	サブスクリプション設定、ノード、DNS、ネットワーク出口
OSのログ	TUNネットワークアダプターの作成失敗、ポートの競合、権限拒否	管理者権限、ファイアウォール、既存のプロセス

多くのデスクトップクライアントでは、サイドバーの「ログ」ページからカーネルの出力を直接確認できます。一般的なMihomoデスクトップクライアントを例にすると、「設定」→「Clash設定」→「ログレベル」を開き、レベルをinfoから一時的にdebugへ変更してから、「ログ」ページに戻って問題を再現します。クライアントによってメニュー名は多少異なりますが、設定ファイルで使われる標準フィールドは通常log-levelです。

log-level: debug

問題を再現するときは時系列全体を残す

最後の赤いエラーだけを切り取らないでください。1回の接続は通常、名前解決、ルール判定、ポリシーグループの選択、ノードへの接続、TLSハンドシェイクの順に進みます。最後の行は、処理が止まった位置を示しているにすぎません。まず現在のログを消去し、システム時刻を記録してから失敗する操作を1回実行し、エラーの前後少なくとも10秒間の内容を保存しましょう。

動画再生、同期、ダウンロードなど、継続的に通信するプログラムを終了して、無関係なログを減らします。
クライアントのログを消去し、現在の設定が正常に読み込まれていることを確認します。
テスト用のアドレスを1つだけ開きます。例：https://example.com。
アクセス時刻、選択したポリシーグループ、ノード名を記録します。
DNSクエリの開始から接続終了までの全ログをエクスポートまたはコピーします。

Clashのログ1行をどのフィールドに分けて読むか

Mihomoはバージョンやクライアントによって表示形式に違いがありますが、基本的な情報は共通しています。時刻、レベル、ネットワーク種別、送信元アドレス、宛先アドレス、適用されたルール、最終的に使用された出力ポリシーです。以下は典型的なTCP接続の記録です。

time="2026-07-27T14:32:18.412+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[HK-01]"

[TCP]は、このセッションがTCPを使用していることを示します。DNS、QUIC、一部のゲーム通信ではUDPと表示されることもあります。
127.0.0.1:53124はClashに入ってきたローカル接続の送信元です。末尾のポートは通常、システムが一時的に割り当てます。
example.com:443は宛先のドメインとポートです。443は通常HTTPSに対応します。
match DomainSuffix(example.com)は、ドメインサフィックスのルールに一致したことを示します。最終ルールへ直接進んだという意味ではありません。
using PROXY[HK-01]は、まずPROXYというポリシーグループに入り、実際にはノードHK-01が選択されたことを示します。

ログにusing DIRECTと表示される場合、その接続はルールによって直接接続と判定されています。using REJECTなら、設定によってリクエストが明示的に拒否されています。この場合、ノードを切り替えても結果は通常変わらないため、まずルールの順序、ルールセットの内容、現在の動作モードを確認します。ルールは上から順に判定され、一度一致した接続は後続のルールを調べません。

info、warning、error、debugの見分け方

レベル	用途	必ず障害を示すか
info	設定の読み込み、接続の確立、ルールの適用	いいえ。主に処理の流れを確認するための情報です
warning	再試行、互換性のためのフォールバック、ルールセット更新の異常	必ずしもそうとは限りません。機能に影響があるか確認します
error	接続失敗、名前解決失敗、設定の読み込み不能	通常は対処が必要です
debug	DNS、接続、プロトコル状態の詳細情報	いいえ。情報量が多いだけの場合があります

DNSエラー：上流DNSの失敗とローカル待受の失敗を分ける

dns resolve failed、lookup failed、exchange failedはいずれも、名前解決の経路から正常な応答が返っていないことを示します。ただし原因はそれぞれ異なる可能性があります。一般的には、アプリがシステムまたはMihomoへ問い合わせを渡し、Mihomoが設定されたnameserverへアクセスし、結果を受け取った後にfake-ipまたはredir-hostモードで処理します。どこか一箇所でも途切れると、画面には「DNS失敗」としか表示されないことがあります。

timeoutが出たら上流DNSを確認する

level=error msg="dns resolve failed: lookup example.com: i/o timeout"
level=warning msg="[DNS] exchange failed: context deadline exceeded"

i/o timeoutまたはcontext deadline exceededは、制限時間内に有効な応答を受け取れなかったことを示します。まず、設定されたDNSアドレスへ現在のネットワークからアクセスできるか確認します。DoHを使う場合は、そのドメイン自体をdefault-nameserverで解決できることも確認してください。そうしないと「DoHのドメインを解決するために、利用可能なリゾルバー自体がそのDoHを必要とする」という循環依存が起こります。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

この例ではローカルDNSを127.0.0.1:1053で待ち受け、DoHドメイン用の基本リゾルバーを用意しています。実際には利用するネットワークに合わせて上流アドレスを調整してください。別のネットワークで到達できる上流DNSが、現在のWi-Fi、社内ネットワーク、モバイルホットスポットでも安定して使えるとは限りません。

ローカルDNSポートが実際に待ち受けているか確認する

ログにbind: address already in useと表示される場合、設定された待受ポートは別のプロセスに使用されています。ポート53はシステムのDNSサービスが使っていることが多く、環境によっては一般ユーザーのプロセスに低い番号のポートをバインドする権限がありません。デスクトップ環境では1053などに変更し、クライアントまたはTUNのDNSハイジャック機能でクエリを引き継がせます。

dig @127.0.0.1 -p 1053 example.com

nslookup example.com 127.0.0.1

digコマンドで1053番ポートを明示的に指定しています。対応ツールをインストールしたmacOSまたはLinuxで利用できます。Windows標準のnslookupは53以外のポートを直接指定しにくいため、まず標準の待受を確認するのが適しています。1053を使う設定なら、クライアントログで待受の成功を確認するか、ポート検査ツールで検証してください。

dial tcp timeout：ノード、ネットワーク、それとも接続先か

dial tcp timeoutは、TCP接続の開始処理が制限時間内に完了しなかったことを示します。重要なのは、どこへ接続しようとしているかです。宛先がプロキシサーバーのIPアドレスとポートなら、問題は主に本機からノードまでの間にあります。すでにプロキシを経由して接続先サイトへ接続している場合は、ノードの出口、接続先サイト、ルール選択が原因の可能性があります。

level=error msg="dial tcp 203.0.113.20:443: i/o timeout"
level=error msg="connect failed: dial tcp: lookup node.example.net: i/o timeout"
level=error msg="dial tcp 127.0.0.1:7890: connect: connection refused"

最初の行でノードIPまで取得できているのにTCP接続がタイムアウトする場合は、ノードのポート、現在のネットワーク出口、ファイアウォールを確認します。
2行目のようにノードのドメインさえ解決できていない場合は、DNS経路に戻って対処します。ノードの速度測定を繰り返しても解決しません。
3行目のようにローカルの7890ポートが接続を拒否する場合は、通常、カーネルが起動していない、ポート設定が異なる、またはプロセスが直前に終了したことを示します。

ローカルプロキシポートで再現可能なテストを行う

設定のmixed-portが7890だと仮定し、まずポートを確認してから、コマンドラインのリクエストを明示的にClash経由で送ります。以下のリクエストでは接続タイムアウトを5秒、全体の制限時間を15秒に設定し、「すぐ拒否された」のか「待機後にタイムアウトした」のかを区別しやすくしています。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  -I https://example.com

コマンドが1秒未満でConnection refusedを返す場合は、まずカーネルプロセスとローカルポートを確認します。約5秒待った後に接続タイムアウトが出るなら、ローカルポートはリクエストを受け付けている可能性が高く、障害はノードへの接続開始段階にあると考えられます。HTTP/2 200またはHTTP/1.1 200 OKが返る場合は、テスト先へ現在のプロキシ経由で接続できています。元のアプリの問題は、プロキシ設定の上書き、QUIC、証明書、独自DNSなどにある可能性があります。

Windows PowerShellでは、まず次のコマンドでローカルポートへ接続できるか確認します。

Test-NetConnection 127.0.0.1 -Port 7890

TcpTestSucceeded : Trueと表示されても、本機からClashの待受ポートへ接続できることしか意味しません。リモートのノードが利用可能だとは限らないため、続けてカーネルログのポリシーグループ、ノード名、リモート側のエラーを確認します。

connection refusedとnetwork unreachableの違い

エラー	直接的な意味	優先する対応
connection refused	接続先ホストが明示的に接続を拒否した、またはローカルで待ち受けているプロセスがない	IPアドレス、ポート、カーネルプロセス、ノードサービスの状態を確認する
i/o timeout	制限時間内に読み書きが完了しなかった	ネットワーク出口をテストし、ノードを変更して所要時間を比較する
network is unreachable	システムに接続先ネットワークへ到達するための有効なルートがない	ネットワークアダプター、IPv4/IPv6ルート、TUNの状態を確認する
TLS handshake timeout	TCP接続後のTLSハンドシェイクが時間内に完了しなかった	回線品質、時刻、プロトコルパラメーター、中継ネットワークを確認する
EOF	接続先が先に接続を閉じた	継続的に発生しているか確認し、他のノードと比較する

TUNモード関連のログを判断する方法

システムプロキシは、プロキシ設定を読み取るアプリにだけ影響します。一方、TUNモードは仮想ネットワークアダプターを通じて、より広範囲の通信を引き継ぎます。ブラウザーは正常なのにゲームやターミナルが失敗する場合、ログに該当プロセスの接続記録があるかが重要です。記録がまったくなければ、通信がまだMihomoに入っていない可能性が高く、ルール適用後に接続開始が失敗しているなら、プロキシ経路内部の問題です。

TUNの起動時には、operation not permitted、failed to create tun device、ルート書き込み失敗などがよく発生します。これらは通常、権限、サービスモード、仮想ネットワークアダプターの状態を示します。Windowsクライアントでは「設定」→「サービスモード」が正常か確認してから、TUNを再度有効にします。macOSとLinuxでは、クライアントまたはカーネルに仮想インターフェースの作成とルート変更を行う権限があることを確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interfaceを使うと、Mihomoは現在のデフォルトの出口インターフェースを認識します。Wi-Fi、有線ネットワーク、VPN、モバイルホットスポットを頻繁に切り替えた後もログに古いインターフェースが表示される場合は、いったんTUNを無効にし、システムのルートが安定してから再び有効にします。2つのネットワークツールに同時にデフォルトルートやDNSハイジャックのルールを書き込ませないでください。インターフェース到達不能とDNSタイムアウトが交互に記録されることがあります。

ログに接続先の記録がない場合の意味

アプリが独自のプロキシ設定を有効にし、別のポートを指定している。
ターミナルにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYが設定されておらず、TUNも有効になっていない。
ブラウザーがQUICを使用している一方、現在の引き継ぎ方式が対応するUDP通信を正しく処理できていない。
LAN上のデバイスが本機のプロキシへ接続しているが、allow-lan、待受アドレス、ファイアウォールのいずれかが接続を許可していない。
TUN仮想ネットワークアダプターの作成には成功したが、デフォルトルートが設定されていない、または別のネットワークツールに上書きされた。

設定とサブスクリプションのエラーは起動時に対処する

カーネルが設定の読み込みを完了していない場合、その後のDNSやノードのテストには意味がありません。YAMLはインデントに敏感で、リスト項目、コロン、文字列の形式ミスによって起動に失敗することがあります。ログのparse config error、yaml: line 42、mapping values are not allowedは、エラーに近い位置を示すことが多いものの、実際の原因が直前の行にある場合もあります。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

同じ階層では空白の数をそろえ、タブを混在させないでください。名前にコロン、シャープ記号、その他のYAML特殊文字が含まれる場合は、引用符で囲みます。サブスクリプション更新後にprovider not found、存在しないポリシーグループの参照、ルールセットの読み込み失敗が発生したら、参照名がproxy-providersやrule-providersのキーと完全に一致しているか、大文字・小文字や空白も含めて確認します。

HTTPステータスコードでサブスクリプション更新の原因を絞り込む

401または403：リンクの認証が無効、アクセスが拒否された、またはサブスクリプションの認証情報が変更された。
404：サブスクリプションまたはルールセットのパスが存在しない。
429：短時間にリクエストを送りすぎています。頻繁な更新を止め、しばらく待ってから再試行します。
500、502、503：リモートサービスで一時的な障害が発生しています。時間を置いて再度リクエストします。
200が返るのに解析に失敗する場合：レスポンスが有効なYAMLではない可能性があります。Content-Type、リダイレクト、実際のレスポンス本文を確認してください。

現象から結論までのトラブルシューティング手順

ログの価値は、すべてのエラーを列挙することではなく、正常な処理から最初に外れた箇所を見つけることにあります。1回の失敗でDNSタイムアウト、ノードの速度測定失敗、ルールセット更新失敗が同時に起きることがあります。本機がすでにオフラインなら、3種類のエラーは同じ根本原因の異なる表れにすぎません。決まった順番で確認すれば、関係のない設定を何度も切り替えずに済みます。

基本ネットワークを確認：システムプロキシとTUNを無効にした状態で、現在のネットワークから直接接続を許可したサイトへアクセスできるかテストします。
設定の読み込みを確認：起動時にYAML解析、ポート競合、provider参照エラーが発生していないか確認します。
ローカル待受を確認：mixed-port: 7890などの実際のポートを確認し、本機から接続できるかテストします。
DNSを確認：ノードのドメインと接続先のドメインを解決できるか確認し、ローカル待受の失敗と上流のタイムアウトを区別します。
ルール適用を確認：接続先がDIRECT、REJECT、想定したポリシーグループのどれを経由しているか確認します。
ノードへの接続を確認：異なる地域の2つのノードでエラーと所要時間を比較し、単一ノードの障害か判断します。
アプリの通信が引き継がれているか確認：ログに接続先の記録がない場合は、システムプロキシ、環境変数、TUNルート、アプリ内プロキシを確認します。
通常設定に戻す：テスト終了後、ログレベルをinfoに戻し、一時的なプロキシ環境変数を削除します。

たとえば、ブラウザーが接続できないと表示し、ログにまずlookup node.example.net: i/o timeoutが出た後、複数のノードがすべて速度測定に失敗したとします。この場合、共通する障害点はノードのドメイン解決であり、ノードごとにプロトコルを変更するべきではありません。別の例として、ログにmatch MATCH using PROXY[US-02]と明確に表示され、その後US-02だけでconnection refusedが発生し、HK-01へ切り替えるとすぐ成功した場合、原因は単一ノードまたはそのポートに絞り込めます。

最終的な記録には少なくとも、クライアントのバージョン、Mihomoカーネルのバージョン、OS、ネットワーク種別、現在のモード、ログレベル、再現時刻、完全なエラー部分を含めます。バージョン情報は設定フィールドがサポートされているか判断する手がかりになり、ネットワーク種別はIPv6、社内ネットワークの制限、ホットスポット切り替えの問題を見極めるのに役立ちます。「通信がClashに入っているか」「DNSが完了しているか」「どのルールに一致したか」「どの出口へ接続しているか」の4点を明確にできれば、多くの実行障害を漠然とした「プロキシが動かない」状態から、検証可能な一つの段階まで絞り込めます。