Clashのログの見方｜mihomoのよくあるエラーと原因の特定方法

まず再現可能なリクエストを用意する

Clashの接続に失敗したら、まずどの段階で問題が起きているかを切り分けます。アプリからクライアントへリクエストが渡っているか、コアがルールを判定できているか、ノードのホスト名を解決できるか、外向きの接続が確立しているかを確認しましょう。FlClashはクライアント、mihomoはそのプロキシコアです。画面上のエラー、サブスクリプションの取得エラー、コアの転送ログは、同じ場所に表示されるとは限りません。

クライアントの「ログ」画面を開き、現在時刻、動作モード、選択中のプロキシグループ、接続先を記録します。メニュー名はバージョンによって異なるため、「コアログ」や「実行ログ」を探してください。更新チェックの記録だけを見ても原因は分かりません。続けてページを1つだけ再読み込みするか、テストリクエストを1回送信し、バックグラウンドアプリの通信にログが埋もれないようにします。

1. 現在のモードが rule、global、direct のどれかを確認します。カスタムの振り分けルールを調べるには、ルールモードを使います。
2. 現在のmixed-portを記録します。以下では例として 127.0.0.1:7890 を使いますが、すべてのクライアントで共通の初期値ではありません。
3. 失敗した時刻の前後約10秒分のログを保存し、ブラウザーに表示されたエラーも記録します。
4. 一度に変更する設定は1つだけにし、同じ接続先へ再度リクエストを送ります。ノード、DNS、TUNを同時に切り替えないでください。

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

このコマンドはローカルのHTTPプロキシを明示的に使い、接続タイムアウトを10秒、全体の制限時間を20秒に設定します。Windows PowerShellではコマンド名を curl.exe とすると、古い環境で同名のエイリアスが使われるのを避けられます。接続先から403や405が返った場合も、「HTTP応答を受け取った」状態と「接続自体が確立しなかった」状態をまず区別してください。このテストで確認できるのはプロキシの入口であり、TUNによる通信の取り込みが正常かどうかは分かりません。

ログレベルと各行の読み方

mihomoの log-level では silent、error、warning、info、debug を指定できます。通常はまず info を使い、解析や接続の詳細を確認したいときだけ一時的に debug に変更します。クライアントがサブスクリプション内の設定を上書きする場合もあるため、ダウンロードしたYAMLだけでなく、最終的に適用されている設定を確認してください。

log-level: info

以下は読み方を示すための例で、すべてのmihomoバージョンで表示が完全に一致するとは限りません。GUIクライアントでは、時刻、レベル、メッセージが別々の列に表示されることがあります。

time="2026-09-15T10:24:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using 手動選択[ノードA]"

• time：同じ操作のログを結び付けるために使います。まずシステムのタイムゾーンを確認し、異なる端末の時刻をそのまま比較しないでください。
• [TCP] または [UDP]：通信プロトコルを示します。Webサイトに接続できても、UDPを使うゲームやQUICが正常とは限りません。
• 127.0.0.1:53124：接続元と一時的な送信元ポートです。ここにある 53124 はプロキシの待ち受けポートではありません。
• example.com:443：接続先のドメイン名とポートです。TUNでは、先に接続先IPアドレスが表示される場合もあります。
• match：一致したルールの種類と内容、using：使用するポリシーとノードを示します。

「ルールに一致し、特定のノードを使用した」というログは、ルーティング先が選択されたことを示します。接続先サイトから正常な応答が返ったことを意味するわけではありません。前後の接続エラーと実際のリクエスト結果も確認してください。

dialのタイムアウト：まず接続先を確認する

i/o timeout と context deadline exceeded

どちらも、処理が制限時間内に完了しなかったことを示します。ただし、この文言だけで「ノードが使えない」とは断定できません。直前の処理対象を見て、DNS問い合わせなのか、プロキシサーバーへのTCP接続なのか、プロキシ経由での接続先アクセスなのかを確認します。エラーに含まれるIPアドレスは、プロキシサーバー、DNSサーバー、接続先サイトのいずれかで、対象によって調査方法が異なります。

dial tcp 203.0.113.10:443: i/o timeout

上記のアドレスは、説明用に予約されたIPアドレス範囲を使っています。実際の調査では、ログにあるアドレスを現在のノードの server と port に照らし合わせてください。プロキシサーバーのアドレスなら、まずローカルネットワークからそのサーバーへ接続できるか確認します。接続先への直接接続なら、ルールが DIRECT を選んだ理由と、ローカルネットワークからその接続先へ到達できるかを確認してください。

1. 同じノードで異なる接続先を2つ試します。すべて失敗する場合と、特定のサイトだけ失敗する場合は分けて対処します。
2. ルールとDNSは変えず、ノードだけを切り替えます。切り替え後に復旧した場合、原因は元のノードか、その経路にある可能性が高いです。
3. ノードを変えずに、Wi-Fiとモバイル回線を切り替えて試します。一方の回線だけで失敗する場合は、ネットワークの制限、ルーティング、IPv6の到達性を確認してください。
4. UDPリクエストだけ失敗する場合は、ノードのプロトコルとサーバー側のUDP転送対応を確認してください。TCPの遅延結果でUDPの正常性を判断しないでください。

connection refused と network is unreachable

connection refused は通常、接続を明示的に拒否されたことを示します。ポートでサービスが待ち受けていない場合のほか、ファイアウォールが拒否した場合もあります。接続先が 127.0.0.1:7890 なら、コアが起動しているか、ポート番号が変更されていないかを確認します。リモートノードなら、アドレスとポートを確認してください。「タイムアウトまで応答を待った」状態とは異なります。

network is unreachable は、ローカルのルーティングやアドレスファミリーの問題を示すことが多いエラーです。たとえば、ログがIPv6アドレスへの接続を試みている一方、現在のネットワークに利用可能なIPv6ルートがない場合です。まずルートとネットワーク環境を確認し、そのうえでIPv6関連の設定を検討してください。一度エラーが出ただけで、IPv6を全面的に無効化しないでください。

DNS名前解決の失敗：ノードのドメイン名と接続先のドメイン名を区別する

no such host、DNS resolve failed、またはDNS問い合わせ中のタイムアウトが表示されたら、まずどのドメイン名を問い合わせているか確認します。プロキシサーバーをドメイン名で指定している場合、プロキシへの接続を確立する前にその名前を解決する必要があります。アクセス先サイトのドメイン名は、接続の入口や設定に応じて、ローカルDNS、mihomoのDNS、またはプロキシ経由で解決されます。

no such host は、名前が存在しない場合などの名前解決失敗でよく見られますが、上流からの応答も確認してください。タイムアウトは結果を時間内に取得できなかったことを示し、ドメイン名が存在しない証拠にはなりません。nslookup example.com は通常、システムに設定されたDNSをテストするコマンドで、mihomoのDNSを自動的に検証するものではありません。コアの名前解決経路を確認するには、実際のDNS待ち受けアドレスとポートを指定できるツールか、コア自身のログを使ってください。

Fake-IPモードでは、アプリに 198.18.0.0/16 の範囲内の合成アドレスが返されることがあります。この範囲はよく使われますが、実際には fake-ip-range の設定に従います。このアドレスが表示されても、すぐにDNS汚染と判断しないでください。ドメインとの対応付け、通信の取り込み、fake-ip-filter がアプリの要件に合っているかを確認します。

ログに合成アドレスが表示されないようにするためだけに、すべてのドメイン名を fake-ip-filter に追加しないでください。名前解決経路が変わるだけで、ノードへの接続不可、上流のタイムアウト、TUNの通信取り込みの異常は直接解決しません。

ルール不一致：必ずしもエラーとは限らない

「ルールに一致しない」は、振り分け結果を表すユーザー側の説明で、必ずしも対応するエラーログがあるわけではありません。mihomoのルールは上から順に評価され、先に一致したルールが適用されると、その後のルールは実行されません。末尾の MATCH はフォールバックルールです。ここに一致するのは正常なルーティング動作で、コアがルールの解析に失敗したことを示すものではありません。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

これはルールの並び順を示す断片であり、そのまま実行できる完全な設定ではありません。PROXY は、すでに存在するポリシーグループ名または出力先名である必要があります。この例では、example.com とそのサブドメインを直接接続し、それ以外のリクエストを PROXY に渡します。ログでリクエストがより上位の別ルールに一致している場合は、DNSを何度も切り替えるのではなく、ルールの順序を見直してください。

• まずモードを確認：global と direct では、通常のルール一覧に基づく振り分けは行われません。
• 次に接続先情報を確認：接続先IPしかなくドメイン名が分からないと、ドメイン名ルールが想定どおりに一致しないことがあります。アプリが事前に名前解決していないか、Fake-IPの対応情報があるか、必要な場合は適切なスニッフィング設定が有効かを確認します。
• ルールの読み込み元を確認：RULE-SET を使っている場合、対応する rule-providers が正常に読み込まれているか、形式、パス、更新にエラーがないか確認します。
• 実際に適用された設定を確認：サブスクリプションの更新、オーバーライド、クライアント側の設定統合によってルールの順序が変わる場合があります。実行中の設定を基準にしてください。
• 最後にポリシーグループを確認：プロキシ用ポリシーグループに一致しても、グループ内で DIRECT が選択されることがあります。グループ名に「プロキシ」とあっても、最終的にリモートノードを経由するとは限りません。

接続ログにリクエストがまったく表示されない場合は、まず通信の入口を確認します。システムプロキシに従わないアプリもあり、個別にプロキシを設定するかTUNを使う必要があります。既存の接続が再利用されている可能性もあります。古い接続で何度も再読み込みするより、アプリを終了してからリクエストをやり直すほうが切り分けに有効です。

ポート競合とTUNの起動失敗

address already in use：ポートの使用状況を確認

典型的なメッセージは listen tcp 127.0.0.1:7890: bind: address already in use です。これは待ち受けアドレスとポートが競合していることを示し、リモートノードのエラーではありません。別のプロキシクライアントがバックグラウンドで動いている、または同じコアを2つ起動している場合などに発生します。競合しているのがmixed-port、DNSの待ち受けポート、コントロール用インターフェースのポートのどれかも確認してください。

# Windows：7890ポートを調べ、LISTENINGの行とPIDを確認
netstat -ano | findstr :7890

# macOS：TCP 7890を待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：TCP 7890を待ち受けているプロセスを確認
ss -ltnp 'sport = :7890'

プロセスを特定したら、該当アプリを正規の手順で終了するか、待ち受けポートを変更します。正体の分からないシステムプロセスを強制終了しないでください。mixed-port を 7890 から 7891 に変更する場合は、ブラウザー拡張機能、コマンドラインの環境変数、プロキシアドレスを手動入力したアプリも更新します。Linuxで他のユーザーのプロセス情報を確認するには、追加の権限が必要な場合があります。

TUNの権限とルーティングの問題：まず起動時の状態を確認

TUNには仮想ネットワークデバイスとシステム権限が必要です。operation not permitted、デバイスの作成失敗、ルートの追加失敗が発生した場合は、サブスクリプションのノードを変更する前に、クライアントのサービスモード、システムの認可、仮想ネットワークアダプターの状態を確認してください。Windowsでは管理者権限やインストール済みサービスが関係することが多く、macOSやLinuxで必要な認可方法はクライアントの実装によって異なります。

TUNの起動後も接続先へのリクエストがコアに届かない場合は、tun.auto-route、ルートの除外設定、他のVPNやセキュリティソフトの影響を確認してください。まずルーティングを変更する他のクライアントを終了してから再テストします。調査のためにシステムファイアウォールを長期間無効にしないでください。通信の遮断を確認する場合は、対象のプログラム、インターフェース、ポートに適用されるルールを調べます。

TLSと認証のエラー：接続確立後はパラメーターも確認

ログがTLSハンドシェイクまで進んでから x509: certificate has expired or is not yet valid が出た場合は、まずシステムの日付、時刻、タイムゾーンを確認し、次に証明書の有効期間を調べます。証明書名が一致しない場合は、ノードの servername、プロトコルに応じたSNI設定、サーバーのドメイン名、サーバー証明書を確認してください。

EOF、connection reset by peer、TLS handshake timeout だけでは原因を特定できません。リモート側からの切断、トランスポート設定の不一致、中間ネットワークの干渉、ハンドシェイクの未完了などが考えられます。プロトコル、ノードのポート、発生した段階を踏まえて判断し、すべての EOF をパスワードの誤りと決めつけないでください。

• プロトコル、ポート、パスワードまたはUUID、トランスポート層の設定がサーバー側と一致しているか確認します。
• WebSocketなどのトランスポートを使う場合は、パスとHostの設定を確認します。パラメーター名は使用中のプロトコル設定に従ってください。
• 認証失敗が明示されている場合は、まず認証情報とサブスクリプションの状態を再確認します。
• skip-cert-verify: true を万能な修正方法として使わないでください。証明書の検証を省略すると接続先の本人確認が弱まり、ポートやプロトコルの誤りも解決できません。

手順に沿って原因を絞り込み、再テストの結果を残す

1つのログには、複数のアプリ、複数のノード、複数回の再試行が含まれることがあります。結論は画面内で目立つ赤字ではなく、再現できる1件のリクエストに基づいて出してください。以下の順に確認すると、関係のない設定を何度も切り替えずに済みます。

1. 起動：設定の読み込み、待ち受けポート、TUNの起動を確認します。起動に失敗する場合は、構文、ポート、権限から対処します。
2. 入口：明示的なプロキシリクエストがコアに届くか確認します。明示的なプロキシでは成功し、元のアプリでは失敗する場合は、システムプロキシ、アプリのプロキシ設定、またはTUNを調べます。
3. ルーティング：接続先、一致したルール、ポリシーグループ、最終的なノードを確認し、想定した経路になっているか調べます。
4. 名前解決：失敗したのがノードのドメイン名、DNSサービスのドメイン名、アクセス先のドメイン名のどれかを特定し、対応する名前解決経路を確認します。
5. 接続：タイムアウト、拒否、ルートなし、TLSエラー、認証失敗を区別し、関連する設定は一度に1つだけ変更します。
6. アプリ：HTTP応答を受け取った後は、Webサイトの状態、ログイン状態、アプリのプロトコルを確認します。すべての失敗をプロキシ接続の問題と見なさないでください。

メンテナーに報告する際は、クライアントとコアのバージョン、OS、再現手順、動作モード、関連する設定の抜粋、同じリクエストのログを添えてください。公開前に、サブスクリプションURL、アクセストークン、パスワード、UUID、個人のドメイン名を削除します。エラーのキーワード、項目名、ポートの関係、時系列は残してください。アドレスを置き換える場合は、ログ内の同じ対象に一貫した別名を使います。

復旧後、同じ入口と接続先を使ってもう一度テストし、どの変更が有効だったか記録します。最後に、一時的に有効にした debug を通常のレベルに戻してください。設定項目の意味は設定項目リファレンスで確認できます。プロキシの入口やTUNを初めて設定する場合は、入門ガイドに沿って順に確認してください。