Clashのログの見方｜dial tcp・i/o timeoutなど代表的なエラーを解説

1. まず問題を再現し、その時刻のログを確認する

Webページが開かないとき、DNSやノード、TUN、ルールを一度に変更するのは避けましょう。クライアントの「ログ」画面を開いて現在時刻を控え、問題のページを一度だけ再読み込みします。画面いっぱいのエラーから深刻そうなものを選ぶのではなく、その前後数秒の記録を優先して確認してください。

ログの色が示すのは記録のレベルであり、障害の範囲ではありません。バックグラウンドの速度測定に失敗して警告が出ても、ブラウザーの接続は正常な場合があります。逆に、誤ったルールで直接接続されても、目立つエラーがなく通常の接続ログだけが残ることがあります。

1. クライアント名、バージョン、コア名に加え、現在のモードが「ルール」「グローバル」「直接接続」のどれかを記録します。
2. 失敗したドメイン、操作した時刻、症状を記録します。たとえば、トップページは開くが画像を読み込めない、といった内容です。
3. ログ表示をクリアするか時刻で絞り込み、同じ操作をもう一度行います。表示をクリアしても、ディスク上のログファイルが削除されるとは限りません。
4. 失敗したリクエストの前後の記録を残します。特に、接続先、適用されたルール、出力先のポリシー、エラーの原因を確認してください。

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

Clash系クライアントでは、通常サイドバーの「ログ」から実行ログを確認できます。ログレベルの絞り込み機能がある場合は、表示済みの記録をフィルターしているだけなのか、コアのログレベル自体を変更するのかを確認しましょう。フィルターをDebugに切り替えただけでは、コアがデバッグ情報を出力するとは限りません。

コア設定でログの詳細度を制御する項目はlog-levelです。オリジナル版Clashとmihomoでは、どちらもこの項目を使用します。クライアントに「ログレベル」の設定がある場合は、まず画面から変更してください。設定画面に項目がなければ、クライアントが対応する設定の上書き機能やマージ機能を使います。サブスクリプションから生成されたファイルを直接編集しても、設定が保持されるとは限りません。サブスクリプションの更新で上書きされる可能性があります。

# 設定の最上位に記述し、dnsやrulesの下にはインデントしない
log-level: info

デバッグが必要な場合は、この項目を一時的にdebugへ変更し、クライアントの指示に従って設定を再読み込みするか、コアを再起動します。問題を一度再現したらinfoに戻してください。設定項目ではwarningを使用しますが、ログ行のレベル表示はWARNまたはwarningとなる場合があります。混同しないようにしましょう。

ログを共有する前に、サブスクリプションURL、アクセストークン、ノードのパスワード、サーバーアドレス、ローカルパスが含まれていないか確認してください。エラーの原文とポートの構成を残せば十分です。公開の場で相談する際に、サブスクリプション設定全体を共有する必要はありません。

3. 接続ログは4点を確認：接続先・ルール・出力先・エラー

[info] [TCP] 127.0.0.1:53142 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[ノード-A]

この簡略化したログは、ローカルのプログラムが一時ポート53142からTCPリクエストを送信し、接続先がwww.example.com:443であることを示しています。ドメインサフィックスルールに一致し、最終的にProxyグループで選択されたノード-A経由で接続しています。左側の一時ポートはクライアントのプロキシ待ち受けポートではないため、これに合わせて設定を変更する必要はありません。

• 接続先：問題のページのドメインなのか、更新確認・速度測定先・広告リソースなどのバックグラウンド通信なのかを確認します。
• ルール：実際に適用されたルールを確認します。ルールモードでは通常、上から順に照合され、一致した時点で対応するポリシーが使われます。
• 出力先：DIRECTは直接接続、REJECTは拒否を意味します。ポリシーグループ名の後に、最終的に選択されたノードが表示される場合もあります。
• エラー：同じ時刻・同じ接続先に関する失敗理由を続けて確認します。using Proxyと表示されただけで、プロキシ経由の接続が成功したと判断しないでください。

MATCHは通常、最後のフォールバックルールに一致したことを示し、ルールエンジンの故障を意味するものではありません。特定のポリシーで接続するはずのサイトがフォールバックに一致する場合は、それより前のルールがドメインをカバーしているか、ルールセットが読み込まれているか、意図した設定が実際に使われているかを確認してください。

4. dial tcp：TCP接続の開始を示す。原因は後続のエラーで判断

dial tcpは接続処理を示す表現であり、それだけで障害の原因が分かるわけではありません。通常は後ろにアドレスと低レベルのエラーが続きます。次の2つの例はどちらもこの語句を含みますが、対処する箇所は異なります。

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

接続先アドレスへの失敗：まず何のアドレスかを確認

1つ目の接続先アドレスは、プロキシサーバーの場合も、直接接続しているWebサイトの場合もあります。出力先の項目と設定を合わせて判断してください。現在のノードのサーバーアドレスと一致する場合は、まずローカル端末からノードまでの接続を確認します。DIRECTでアクセスしているサイトのアドレスなら、ローカルネットワーク、ルーティング、サイト自体を確認してください。

ローカルアドレスへの接続失敗：まず待ち受けポートを確認

2つ目はローカルの127.0.0.1:7897を示しています。ブラウザーやコマンドラインで使うプロキシの入口であれば、接続拒否は、そのアドレスでサービスが待ち受けていないか、サービスの起動に失敗したことを意味する場合があります。7897はあくまで例であり、すべてのクライアントの標準値ではありません。

クライアント画面で実際の「混合ポート」またはHTTP/SOCKSポートを確認してください。混合ポートを有効にしている場合、対応する設定項目はmixed-portです。Windowsでは、次のコマンドで例示したポートが待ち受け中か確認できます。

netstat -ano | findstr :7897

出力に表示されるローカルアドレスとLISTENINGの状態を確認し、プロセスのPIDも照合します。この番号を含むリモート接続行があるだけでは、ローカルで待ち受けている証拠にはなりません。クライアント自体が正常に起動していない場合は、ノードを変更する前に起動エラーを解消してください。

5. i/o timeout：応答待ちのタイムアウト。ノード障害とは限らない

i/o timeoutは、ネットワークの読み書きが制限時間内に完了しなかったことを示します。TCP接続の確立、DNS問い合わせ、プロキシのハンドシェイク、接続確立後の読み込みなど、さまざまな段階で発生します。この語句だけでは、回線事業者までの経路、接続先サービス、UDPパケットの損失、ローカルファイアウォールのどれが原因かを区別できません。

1. まず失敗した対象を確認。ノードサーバーのタイムアウトとDNSサーバーのタイムアウトでは、問題の箇所が異なります。read udpやdial tcpなどの先頭部分は省略せずに残してください。
2. 同じネットワークで別のノードを試す。ルール、DNS、TUNの設定は変えず、ポリシーグループで選択するノードだけを切り替えて、同じ接続先にアクセスします。
3. 同じノードで別のネットワークを試す。たとえばWi-Fiからスマートフォンのテザリングに切り替え、同じ種類のタイムアウトが解消するか確認します。
4. すべてのサイトで発生するか、特定のサイトだけかを確認。1つのドメインだけが失敗する場合は、接続先サイトの状態や適用されるルールも確認してください。

複数の接続先で同じノードを使ったときだけ失敗するなら、ノードまたはノードまでの経路を優先して確認します。バックグラウンドの速度測定が一度タイムアウトしただけで、Webページが正常に開くなら、設定全体をリセットする必要はありません。速度測定と実際の通信では、確認用URLやプロトコルが異なる場合があります。

6. connection refused：接続拒否はタイムアウトと分けて対処

connection refusedは通常、応答がないまま待ち続けるのではなく、接続要求に対して明確な拒否応答が返ったことを示します。接続先のポートでサービスが待ち受けていない、またはデバイス上のポリシーが接続を拒否している場合によく発生します。パスワードの誤りとは異なります。パスワードやプロトコルの不一致は、通常、接続確立後の認証・ハンドシェイク段階で発生します。

• ローカルポートで拒否される：システムプロキシ、ブラウザーのプロキシ拡張機能、ターミナルの環境変数が古いポートを参照していないか確認し、コアが動作中か確認します。
• ノードのポートで拒否される：サブスクリプションに記載されたサーバーとポートを確認し、サブスクリプションを更新してから再試行します。すべてのノードのポートを443に変更するのは避けてください。
• LANアドレスで拒否される：サービスがループバックアドレスのみにバインドされていないか、LANからのアクセス許可とファイアウォールの設定を確認します。

ログにaddress already in useと表示される場合は別の問題です。クライアントがポートを待ち受けようとした際に、そのポートがすでに使用中であることを示します。まず使用中のプロセスを確認し、既存のプロセスを終了するかポートを変更するか判断してください。ポートを変更したら、プロキシを手動設定しているアプリ側も合わせて変更する必要があります。

7. DNSエラー：ノードのドメインとWebサイトのドメインを区別

no such hostは、ドメイン名の問い合わせで有効な結果が得られなかったことを示す場合があります。ドメインが存在しない、入力に誤りがある、名前解決経路に問題がある、といった原因が考えられます。server misbehavingは通常、リゾルバーが異常な状態を返したことを示します。こうしたエラーが出たら、DNS設定全体をすぐに置き換えるのではなく、まず実際に名前解決しようとしているドメインを特定してください。

lookup www.example.com: no such host
read udp 192.168.1.20:53000->192.168.1.1:53: i/o timeout

2行目は、192.168.1.1:53へのUDP読み取りがタイムアウトしたことを示しています。DNSクエリの経路を確認しましょう。DoHを使用している場合は、名前解決サービスの443ポートへの接続エラーやTLSエラーが記録されることもあります。従来のUDP 53番ポートだけを調べても原因は特定できません。

ノードサーバーのドメインを名前解決できない

ノード自体のドメインを名前解決できない場合、その後のプロキシハンドシェイクを開始できません。mihomoのproxy-server-nameserverは、プロキシサーバーのドメイン名を解決するリゾルバーの指定に使えます。ただし、バージョンや設定上の要件があるため、対応していない旧バージョンのコアにそのままコピーしないでください。まず使用中のコアを確認し、プロキシ接続が確立する前に現在のリゾルバーへアクセスできるか調べます。

接続先サイトのドメインだけが名前解決できない

そのドメインがnameserver-policyなどの設定の影響を受けているか、クライアントがアプリのDNS通信を実際に処理しているか確認してください。ブラウザー内蔵のセキュアDNS、アプリ独自の名前解決、システムキャッシュ、TUNのDNSリダイレクト設定によって、問い合わせ経路が異なる場合があります。

Fake-IPを使用している場合、ログに198.18.0.0/16など設定範囲内のマッピングアドレスが表示されても、それだけでDNSの改ざんを意味するわけではありません。ドメインのマッピングと出力先を続けて確認してください。システムのnslookupで分かるのは、その問い合わせが通った名前解決経路です。ブラウザーやコアも同じリゾルバーを使っている証拠にはなりません。

8. その他の代表的なエラー：TLS・EOF・起動失敗

オリジナル版Clash、Clash Meta、後継のmihomoでは、対応する設定機能が完全には一致しません。サブスクリプションに現在のコアが対応していないプロトコルや項目が含まれていると、設定の読み込み段階で問題が発生します。通常、ノードを切り替えても解決しません。設定が正常に読み込まれているか、プロキシグループが生成されているかを確認してから、接続タイムアウトを調べてください。

TUNの起動失敗には、権限、仮想ネットワークアダプター、ルート作成が関係する場合もあります。このとき、システムプロキシ経由とTUN経由では動作が異なることがあります。ブラウザーからシステムプロキシでアクセスできても、TUNが動作しているとは限りません。また、TUNエラーが出たからといって、すぐにシステムのネットワークコンポーネントを削除しないでください。

9. 実例：timeoutのログからノードまでの経路を特定

ブラウザーでwww.example.comにアクセスできず、同じ時刻に次の簡略化したログが記録されたとします。

[warning] [TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53142 --> www.example.com:443
error: dial tcp 203.0.113.10:443: i/o timeout

1. 今回のリクエストか確認。接続先ドメインと操作時刻が一致するため、バックグラウンドの速度測定ログではありません。
2. ルールが意図どおりか確認。ログにはProxy経由と表示されています。プロキシ経由でアクセスする想定なら、まずルールは変更しません。
3. 失敗した接続先を確認。現在のノードのサーバーアドレスが203.0.113.10:443である場合、現時点の情報が示すのはノードへの接続タイムアウトであり、WebページからHTTPエラーが返されたわけではありません。
4. ノードだけを切り替える。ノード-Bを選び、モードと接続先は変えずに試します。接続が回復した場合は、まずノード-Aまたはノード-Aまでの経路を確認してください。
5. 必要ならネットワークを変えて再確認。ノード-Aがテザリングでは使えて、元のネットワークではタイムアウトが続く場合、元のネットワーク経路に関係する可能性が高まります。ただし、どの機器が通信を遮断しているかまでは特定できません。

反対に、元のログにusing DIRECTと表示されている場合は、上記のノードに関する結論を当てはめられません。まず直接接続になった理由を確認し、クライアントの「接続」画面で現在のリクエストに適用されたルールと出力先を調べます。比較のために一時的にグローバルモードへ切り替える方法はありますが、確認後は元のモードに戻してルールを修正してください。グローバルモードをあらゆる問題の恒久的な解決策にしないでください。

10. ログがない場合は通信の入口を確認。相談時は必要な情報だけ共有

ページを再読み込みしても該当する記録がまったくない場合は、通信がこのコアに届いていないか、ログ表示で記録がフィルターされている可能性があります。アプリがシステムプロキシを使っているか、ブラウザー拡張機能がプロキシ設定を上書きしていないか、別のVPNに接続していないか、TUNが正常に起動しているかを確認してください。システムプロキシを有効にしただけでは、すべてのアプリやUDP通信がClashを経由するとは限りません。

ローカルの混合ポートを使って、通信の入口を明確にテストすることもできます。次のコマンドにある7897は、クライアントに表示された実際のポートに置き換えてください。Windows PowerShellではcurl.exeを使うと、古い環境で同名のエイリアスが使われる問題を避けられます。

curl.exe -I --proxy http://127.0.0.1:7897 https://example.com

コマンドを実行したら、すぐにログを確認します。ローカルポートへの接続失敗が表示された場合は、待ち受け状態とコアの動作を確認してください。接続先のログが記録されたら、ルール、出力先、エラーの順に調べます。コマンドが返すHTTPステータスはそのリクエストの結果を示すだけで、ほかのアプリの状態を確認する代わりにはなりません。

トラブルを相談するときに添える情報

• クライアントとコアのバージョン、OSのバージョン、システムプロキシまたはTUNの有効状態。
• 問題が発生した時刻、接続先ドメイン、現在のモードと最終的な出力先。すべてのサイトで失敗するのか、特定のサイトだけなのかも記載してください。
• 機密情報を伏せたエラー行全体と前後のログ。i/o timeoutの2語だけを切り取らないでください。
• 同じネットワークでノードを切り替えた結果、同じノードでネットワークを切り替えた結果、直近で変更した設定項目。

調査の順序を固定します。まず通信がコアに届いていることを確認し、次にルールと出力先、最後にDNS・接続・ハンドシェイクの段階を調べます。一度に変更する設定は1つだけにして結果を記録し、アクセスが回復したらデバッグレベルを元に戻してください。同じエラーが再発したとき、すべての設定を試し直すのではなく、記録した情報をもとに調査を続けられます。