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

まず、ログがどの接続区間を記録しているか確認する

Clash、Clash Meta（mihomo）とそのGUIクライアントは通常、システムプロキシ、DNS、ルールマッチング、ノード接続、TUN転送、サブスクリプション更新を同時に処理します。ログにerrorが出ても、クライアント全体が停止したとは限りません。1件の接続失敗だけで、現在のノード全体が使えないとも限りません。切り分けでは、まずエラーがどの層で発生したかを確認し、該当する設定を調べます。

一般的な接続ログには、時刻、ログレベル、受信方式、宛先アドレス、マッチしたルール、プロキシグループ、実際に使用したノード、エラー内容が含まれます。クライアントによって並び方は少し異なりますが、核心となる情報は同じです。例えば：

20:14:08 INF [TCP] 127.0.0.1:53142
--> api.example.com:443
match DomainSuffix(example.com)
using Proxy[HK-01]

20:14:13 ERR dial HK-01
198.51.100.20:443
dial tcp 198.51.100.20:443: i/o timeout

この記録から、本体のアプリが127.0.0.1からTCPリクエストを開始し、宛先がapi.example.com:443であることが分かります。ドメインはサフィックスルールに一致し、プロキシグループではHK-01が選択されています。その後、Clashがノードサーバー198.51.100.20:443への接続でタイムアウトしました。問題は「本体からノードサーバーまで」の区間にあり、対象サイトがアクセスを拒否したわけではありません。

ログから必ず確認する5項目

1. 時刻：エラーが直前の操作と一致しているか確認します。まず一度再現し、同じ1分間の記録を確認してください。
2. プロトコルと受信方式：TCP、UDP、HTTP、SOCKS、TUNのどれかを確認します。UDPだけに影響し、Webページは正常に開ける場合もあります。
3. 宛先アドレス：ログのドメインまたはIPが、ノードサーバー、サブスクリプションURL、DNSサーバー、最終的なWebサイトのどれなのかを確認します。
4. ルールとポリシー：どのルールに一致し、プロキシグループが最終的にDIRECT、REJECT、具体的なノードのどれを選んだか確認します。
5. エラー末尾：Goのネットワークエラーでは、最も具体的な原因が末尾に示されることが多く、i/o timeout、connection refused、no such hostなどが該当します。

info・warning・errorの違い

ログレベルはイベントの深刻度を示すもので、対応の優先度と直接一致するわけではありません。バックグラウンドのヘルスチェックで出たerrorが、予備ノード1つだけに影響することもあります。一方、infoレベルのルール記録が、現在のサイトがREJECTルールでブロックされたことを示す場合もあります。レベルだけでなく、宛先アドレスとポリシー結果も合わせて読み取りましょう。

正常なログにも失敗の記録は含まれる

ブラウザーはIPv4、IPv6、HTTP/3、通常のHTTPSを同時に試すことがあります。いずれかの接続に失敗しても、すぐ別の経路へ切り替わるため、ページが開ける場合があります。ノードのヘルスチェックもテスト先へ定期的にアクセスします。あるノードがタイムアウトしても、そのチェックが完了しなかっただけで、現在使用中のノードが切断されたとは限りません。

対応が必要かどうかは、3つの点で判断できます。同じエラーが連続しているか、エラーの宛先が実際にアクセスできないサービスか、ノードの切り替えや機能の無効化でエラーがすぐ消えるかを確認してください。一度だけ発生し、目に見える影響がないバックグラウンドエラーは、まず記録するだけで構いません。複数の設定を同時に変更する必要はありません。

dial tcp timeout：制限時間内に接続が完了しない

dial tcp ...: i/o timeoutは、制限時間内にTCP接続を確立できなかったことを示します。エラー内のアドレスがノードサーバーのIPなら、本体からノードまでのネットワークを優先して確認します。アドレスが最終的なWebサイトなら、プロキシノードから対象サイトまでの経路を確認します。timeoutは「ポートが明確に拒否された」状態とは異なり、リモート側から制限時間内に利用可能な応答が返っていません。

よくある原因

• ノードサーバーが一時的にオフライン、またはノードのポートが変更されている。
• 現在のWi-Fi、モバイル回線、上流ルーターからそのサーバーへ到達できない。
• ファイアウォールが特定ポートの通信を破棄している。
• IPv6の経路が利用できないのに、ノードのドメインがAAAAレコードを優先して解決されている。
• TUNインターフェースのルーティングでループが発生し、ノード接続が再びClashへ送られている。
• ノードには接続できるが、TLSハンドシェイクまたは後続の転送が継続的にタイムアウトしている。

順番に4つの比較テストを行う

1. クライアントのノード一覧で別のノードに切り替え、同じリクエストを再実行します。新しいノードで正常なら、問題は元のノードまたはその回線に絞れます。
2. ネットワークを切り替えます。例えば、自宅のWi-Fiからスマートフォンのテザリングへ変更します。同じノードで復旧するなら、ルーター、ファイアウォール、現在の通信事業者の回線を確認します。
3. 一時的にTUNを無効にし、システムプロキシだけを残して同じアドレスへアクセスします。システムプロキシでは正常でTUNだけタイムアウトする場合は、ルーティング、DNSハイジャック、インターフェース選択を重点的に確認します。
4. タイムアウトしたアドレスを確認します。ノードIPのタイムアウトと対象ドメインのタイムアウトは異なる経路の問題です。Webサイト名だけで判断しないでください。

Clashでよく使われるローカルプロキシポートには、HTTPポート7890、SOCKSポート7891があります。また、mixed-port: 7890で統一することもできます。これらの番号は設定で変更可能です。切り分ける前に、クライアントの「設定」→「ポート設定」または「設定」→「パラメータ設定」で実際の値を確認し、システムプロキシが同じポートを参照しているか照合してください。

connection refused：アドレスには到達できるが、ポートが接続を拒否する

connect: connection refusedまたはdial tcp ...: connect: connection refusedは、通常、データが対象ホストに到達したものの、指定ポートでサービスが待ち受けていないか、ファイアウォールが明示的に拒否を返したことを示します。timeoutより早く発生することが多いエラーです。

ERR dial tcp 127.0.0.1:7890:
connect: connection refused

ERR dial tcp 203.0.113.8:443:
connect: connection refused

1つ目が127.0.0.1:7890を指している場合、本体のアプリがローカルプロキシポートへ接続しようとしたものの、そのポートで利用可能な待ち受けがないことを示します。Clashのコアが起動していない、ポートが別の値に変更された、クライアントでSOCKSポートだけが有効になっている可能性があります。2つ目がリモートIPを指している場合は、ノードのポート設定が誤っている、ノードサービスが停止している、サーバーのファイアウォールが明示的に拒否している可能性があります。

ローカルポートが拒否されたときの確認箇所

• クライアントのステータス画面で、コアが起動中と表示されているか確認します。起動失敗の状態で止まっていないことが重要です。
• 「設定」→「ポート設定」を開き、HTTP、SOCKS、Mixed Portの実際の番号を確認します。
• ブラウザーまたはアプリの手動プロキシ設定で、アドレスを127.0.0.1にし、ポートをClashの現在の待ち受けポートと一致させます。
• 設定がmixed-port: 7890の場合、HTTPクライアントとSOCKSクライアントのどちらもそのポートへ接続できます。7891が必ず有効だと決めつけないでください。
• ログの先頭付近にbind: address already in useがないか確認します。これはポートが別のプロセスに使用され、コアが待ち受けできないことを示します。

リモートポートが拒否されたときの対応

まずサブスクリプションを更新し、ノードサーバーのアドレスとポートが変更されていないか確認します。1つのノードだけでエラーが出るなら、別のノードへ切り替えて問題の項目を記録します。同じサブスクリプション内のすべてのノードが拒否される場合は、サブスクリプションの有効期限、設定が古いサーバーを参照していないか、ネットワークが透過ゲートウェイによって接続を書き換えていないかを確認します。

DNS解決失敗：まずドメインの問題と接続の問題を分ける

よくあるDNSエラーにはno such host、DNS request failed、server misbehaving、context deadline exceededがあります。DNSの失敗は、ドメインをIPへ変換する段階で発生します。ログに198.51.100.20:443のような明確なIPへの接続がすでに表示されているなら、その後のtimeoutは通常、その接続におけるドメイン解決失敗ではありません。

3種類のDNS障害を分けて対応する

mihomoのDNS設定では、ノードのドメイン解決に使うデフォルトサーバーと、通常の問い合わせを処理するnameserverを分けられます。以下は構造を理解するために簡略化した例です。実際のアドレスは現在のネットワーク環境に合わせて調整してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

default-nameserverにはIPアドレスを指定し、主にDoHサーバーやプロキシノード自体のドメインを解決します。これにより、「DNSサーバーを解決する前に、まずDNSサーバーを解決しなければならない」という依存ループを避けられます。listen: 0.0.0.0:1053はClashのDNS待ち受けアドレスであり、システムがすべての問い合わせを自動的にそのポートへ送ることを意味しません。TUNモードでは通常、DNSハイジャックの設定も必要です。

Fake-IPモードで起きる特殊な現象

Fake-IPはアプリへマッピングアドレスを返し、ルールマッチングのためにClash内部で元のドメインを保持します。ログに198.18.0.0/16範囲のアドレスが表示されても、通常はマッピング結果であり、実際のWebサイトサーバーではありません。LAN機器、ゲーム、企業向けアプリがFake-IPに対応しない場合は、ドメイン単位で除外を設定するか、redir-hostモードで比較テストを行います。マッピングアドレスが表示されたというだけでDNSの故障と判断しないでください。

TLS、EOF、context deadline exceededの見方

TLS handshake timeout

TLS handshake timeoutは、TCP接続自体は確立している可能性があるものの、TLSハンドシェイクが制限時間内に完了しなかったことを示します。回線のパケットロス、ノードの過負荷、中間機器の干渉、MTUの不適合などが原因です。まずノードとネットワークを切り替えます。TUNでだけ発生する場合は、MTUを一般的な1500から1400または1280へ変更して比較し、1回ずつテストします。MTU、DNS、プロキシプロトコルを一度に変更しないでください。どの変更が効果を生んだのか分からなくなります。

x509 certificateエラー

x509: certificate has expiredは証明書の有効期限切れを示します。x509: certificate is valid for ...は証明書のドメインと接続先が一致していないことを示します。certificate signed by unknown authorityは、証明書チェーンが現在の環境で信頼されていないことを示します。まずシステムの日付、時刻、タイムゾーンが正確か確認し、次にノードのドメイン、SNI、server name設定を確認します。証明書検証を無効にして隠す方法は、設定ミスを見逃すため、長期的な対応には適しません。

EOFとunexpected EOF

EOFは、接続相手がデータストリームを終了したことを示します。1回だけのEOFなら、サービスが正常に切断した可能性があります。同じ段階で毎回発生するなら、プロトコルパラメータ、ノードサービスの状態、中間ネットワーク機器を確認します。unexpected EOFは、予定していたデータの読み取りが完了する前に接続が中断されたことをより強く示します。ノードを切り替えるのが最も手早い比較方法です。

context deadline exceeded

これは一般的な操作タイムアウトの通知であり、これだけではDNS、ノードへのダイヤル、ヘルスチェック、サブスクリプションのダウンロードのどこで発生したか判断できません。同じ行の前にある操作名と、前後5〜10行のログを確認してください。proxy providerの直後なら、サブスクリプションまたはproviderの更新タイムアウトである可能性が高く、DNSリクエストの直後なら上流DNSを確認します。ノードアドレスの後なら、接続タイムアウトとして対応します。

ポート競合、設定エラー、コアの起動失敗

ログ画面が数行しかなく、その後クライアントが停止する場合、問題は通常ノードの品質ではなく、コアが起動を完了できていないことにあります。設定の構文エラーとリスニングポートの競合が、最もよくある2つの原因です。

address already in use

listen tcp 127.0.0.1:7890:
bind: address already in use

これは7890を別のプロセスが使用していることを示します。別のプロキシクライアント、終了しきれていない前回のコアプロセス、本体の開発用サービスなどが原因です。まず他のプロキシプログラムを完全に終了してからクライアントを再起動します。それでも競合する場合は、「設定」→「ポート設定」でMixed Portを一時的に7892へ変更し、システムプロキシのポートも同じ番号にします。Clashのポートだけを変更してシステムプロキシを更新しないと、ブラウザーが旧ポートへ接続し続け、connection refusedが発生します。

設定の解析エラー

YAMLはインデントとデータ型に厳格です。ログにはyaml: line 42: did not find expected keyのように具体的な行番号が表示されることがあります。まず該当行とその1つ前の行を確認し、インデントにスペースを使っているか、コロンの後にスペースがあるか、リスト項目が-で始まっているかを確認します。プロキシグループが参照するノード名も、実際の名称と一致している必要があります。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,Proxy

サブスクリプション更新後すぐに起動に失敗した場合は、まずクライアントの「設定」→「設定ファイル」で、前回正常に使えた設定へ戻します。その後、新しい設定の構文を確認します。原因が分からない設定を一度に十数か所変更しないでください。毎回1項目だけ変更し、保存、再読み込みを行って、最初のerrorを確認します。

TUNモードのログで重点的に見る箇所

TUNモードはシステムプロキシより広い範囲の通信を引き受けるため、UDP、LAN、システムサービス、プロキシ設定に従わないアプリの接続も現れます。TUNを有効にしてログ量が大幅に増えるのは正常です。継続的な再試行、ルーティングループ、インターフェース作成失敗、DNSハイジャックの異常に注目してください。

よくあるTUNの問題

• operation not permitted：インターフェースの作成やルート変更に必要な権限が不足しています。クライアントの権限とTUNサービスのインストール状態を確認します。
• network is unreachable：現在のルーティングテーブルに対象への利用可能な経路がありません。無効なIPv6や誤ったインターフェース選択でよく発生します。
• device or resource busy：TUNデバイスが別のインスタンスまたは他のVPNによって使用されています。
• 接続ループ：ノードサーバーへの通信が再びTUNへ入り、ログで同じ宛先が高速に繰り返されます。自動ルート、インターフェース検出、ノードアドレスの除外ロジックを確認します。
• UDP timeout：ゲーム、音声通話、QUICだけに影響し、通常のTCPによるWebページには影響しない場合があります。

システムプロキシとTUNの二分テスト

1. 現在の設定を記録し、ルールモード、ノード、DNS設定が変わっていないことを確認します。
2. TUNを無効にしてシステムプロキシだけを有効にし、ブラウザーとサブスクリプション更新をテストします。
3. TUNを再度有効にし、システムプロキシを無効にして、同じ宛先をテストします。
4. TUNだけが失敗する場合は、インターフェース権限、自動ルート、MTU、DNSハイジャック、他のVPNを確認します。
5. 両方のモードで失敗する場合は、ノード、DNS、ルール、ローカルポートに戻って切り分けます。

Androidでは、システムVPNの権限が別のVPNアプリに占有されていないか確認し、システムの「設定」→「アプリ」→「Clashクライアント」→「バッテリー」で、用途に合ったバックグラウンド実行を許可します。WindowsでTUNインターフェースの作成に失敗する場合は、クライアントのサービスモードまたは管理者権限を確認します。macOSでは、システム設定のネットワーク拡張機能の許可状態を確認してください。

ルールには正しく一致するのに、Webサイトへアクセスできない

ログにmatch、using、ルール名が表示されても、Clashがポリシーを選択したことを示すだけで、後続の接続成功を意味しません。同じ接続の後にdial、TLS、DNSエラーが出ていないか、続けて確認する必要があります。

まずポリシーの結果を確認する

• DIRECTに一致：プロキシを経由せず接続しています。対象へのアクセスにノードが必要なら、ルールの順序とドメインのマッチング方法を確認します。
• REJECTに一致：Clashがルールに従って接続を能動的にブロックしています。広告フィルターやカスタムルールの誤マッチを確認します。
• プロキシグループに一致：グループ名だけでなく、グループ内で実際に選択されたノードを確認します。
• MATCHに一致：前にある具体的なルールには一致せず、最終的なフォールバックポリシーへ進んでいます。

Clashのルールは上から順に評価され、通常は最初に一致した時点で処理が止まります。具体的なドメインルールは広範なルールより前に置き、MATCHは末尾のフォールバックにします。例えば：

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

MATCH,DIRECTがリストの前方にあると、後続のドメインルールは意図どおりに実行されません。変更後は設定を再読み込みし、新しい接続が対象ルールに一致したことをログで確認します。すでに確立された接続は元のポリシーを使い続ける場合があるため、テスト時は該当アプリを終了するか、既存接続が終了するまで待ちます。

再現可能なログ切り分け手順

有効な切り分けには、設定、ノード、DNS、ネットワークを同時に変更するのではなく、比較テストが必要です。以下の手順は、Webページが開けない、サブスクリプション更新に失敗する、ノードの速度テストがタイムアウトする、TUNで通信できないといった一般的な問題に使えます。

1. 環境を記録：クライアントのバージョン、コアの種類、現在のネットワーク、プロキシモード、TUNの有効状態、実際の待ち受けポートを記録します。
2. ログを消去：「ログ」または「設定」→「ログ」を開き、レベルをinfoに設定します。より詳しい情報が必要な場合だけ、一時的にdebugへ切り替えます。
3. 一度だけ再現：明確な操作を1つ実行し、正確な時刻を記録します。
4. 対象を見つける：ドメイン、IP、ポート、プロキシグループ名で記録を絞り込みます。
5. 層を特定：ローカルポート、DNS、ルール、ノードへのダイヤル、TLS、対象サービス、TUNルートのどこで失敗したか判断します。
6. 1回比較する：ノード、ネットワーク、TUNの状態、DNSの上流など、変更する変数を1つだけにします。
7. 結果を確認：再びログを消去して再現し、元のエラーが消え、新しいエラーに変わっていないことを確認します。

ログを共有する前に整理すべき情報

クライアントの開発者、サブスクリプション提供者、ネットワーク管理者へ報告する際は、「接続失敗」とだけ表示されたスクリーンショットより、環境情報をそろえた方が役立ちます。クライアント名とバージョン、mihomoコアのバージョン、OSのバージョン、プロキシモード、TUNの状態、障害発生時刻、再現手順、関連するログ断片を添えることをおすすめします。

ログには、アクセスしたドメイン、ノード名、サーバーIP、本体のLANアドレス、設定ファイルのパスが含まれることがあります。共有前にサブスクリプションURL、認証情報、ユーザー名、パスワード、アクセストークンを隠してください。エラー前後のコンテキストをすべて削除しないでください。対象接続の前後10〜20行を残せば、通常はルール選択と失敗段階を判断できます。

報告に使える簡潔な形式

クライアント：名前とバージョン
コア：mihomoのバージョン
システム：OS名とバージョン
モード：Rule / TUN は有効
ポート：mixed-port 7890
現象：ブラウザーで指定ドメインへのアクセスがタイムアウト
時刻：20:14:08
比較：ノードを切り替えると復旧
エラー：dial tcp ...: i/o timeout

ログの切り分けでは、まず接続段階を特定し、次に変数を1つだけ変えて比較します。timeoutは完了が遅れていること、refusedはポートが明確に拒否したこと、DNSエラーはドメイン解決中に発生したことを示します。ルールログはポリシーの選択だけを示し、TUNエラーでは権限とルートを追加で確認する必要があります。「ローカルアプリ → Clashの受信 → DNSとルール → ノード → 対象サービス」の経路に沿って順番に検証すれば、通常は問題を操作可能な設定項目またはネットワーク区間まで絞り込めます。