まず何のログを見ているか確認する

Clashクライアントには通常、グラフィカルな画面とプロキシコアが含まれています。画面側は設定のインポートやノードの切り替え、各種設定を担当し、Clash Meta（mihomo）などのコアはポートの待ち受け、DNSの解決、ルールの照合、接続の確立を担います。ネットワークの問題を調べる際に役立つのは、インストール履歴や画面のクラッシュレポートではなく、基本的にコアの実行ログです。

典型的なログには、時刻、レベル、接続元、接続先アドレス、適用されたルール、最終的な出口が記録されます。クライアントによって表示形式は多少異なりますが、情報の意味はほぼ同じです。例えば次のような記録です。

2026-06-02 14:32:18 INFO [TCP] 127.0.0.1:51842
--> api.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

この記録は、ローカルのポート51842からTCP接続が開始され、接続先が api.example.com:443 であり、設定内の DOMAIN-SUFFIX,example.com ルールに一致したことを示します。接続は最終的に Proxy というポリシーグループへ渡され、グループ内では実際に Node-A が使われています。Clashにトラフィックが入ったことや、ルールと出口の選択結果は確認できますが、接続先サイトが正常な内容を返したことまでは、この記録だけでは証明できません。

画面ログとコアログの違い

  • コアログ：TCP、UDP、DNS、ルール照合、プロキシのハンドシェイク、TUNのインバウンド情報を含み、接続を調べる際の主な手がかりになります。
  • 画面ログ：設定の保存、トレイ操作、ウィンドウの読み込み、更新確認などを記録します。クライアントが起動しない、ボタンが反応しないといった問題の調査に適しています。
  • サービスログ：Windowsの一部クライアントでは、TUNの制御や権限昇格のためにシステムサービスをインストールします。サービスの起動に失敗した場合は、サービスログも確認してください。
  • サブスクリプション更新履歴：リモート設定へのリクエストが200、401、403、404を返したか、またはタイムアウトしたかを確認するためのもので、通常のプロキシ接続ログとは異なります。

ログレベルの選び方

Clash設定の log-level は、コアが出力するログ量を制御します。mihomo 1.19.xでよく使われるレベルは silent、error、warning、info、debug です。グラフィカルクライアントによっては warning をWarnと略したり、「カーネル設定」内に配置したりします。

レベル 主な内容 適した用途
silent 通常の出力を停止 長時間稼働させ、監視が不要な場合に使用。トラブル対応には不向き
error 明確に失敗した操作 コアで重大なエラーが継続して発生していないか確認
warning 警告とエラー 設定の互換性、DNS異常、リソース読み込みの問題を確認
info 接続、ルールの一致、通常の状態 接続失敗やルール未適用の初回調査で優先して使用
debug 詳細な名前解決、ダイヤル、内部処理の情報 Infoで原因を特定できない場合に短時間だけ有効化

ほとんどの問題は、まずInfoで十分です。Debugでは数分で数千行に達することがあり、ブラウザーのバックグラウンド接続が本当の失敗リクエストを埋もれさせます。再現の直前だけ有効にし、テストが終わったらすぐInfoへ戻してください。

YAMLを直接編集する場合は、トップレベルに次のように設定します。

log-level: info

Clash Verge Rev 2.3.xの場合は、「設定」→「Clash設定」→「ログレベル」を開き、Infoを選択します。記録を確認するには「ログ」を開いてください。小さなバージョン違いにより、入口が「コアログ」や「実行ログ」と表示される場合もあります。画面で変更しても反映されない場合は、現在の設定がサブスクリプション管理下にないか、設定切り替え後にクライアントがローカルの値を上書きしていないか確認します。

1行の記録から接続経路を読み解く

ログを読むときは、赤色のErrorだけを検索しないでください。Webページが開けない場合でも、コアがリクエストを正常に受け取った後、ダイヤル段階でタイムアウトしているため、通常のInfoとして記録されることがあります。より効果的なのは、「インバウンド、接続先、ルール、ポリシー、結果」の5項目を順番に確認する方法です。

  1. インバウンドの送信元：リクエストがHTTP、SOCKS、Mixed、TUNのどれから来たか確認します。よくあるローカルの待ち受けアドレスは 127.0.0.1 で、Mixedポートには 7890 がよく使われます。
  2. 接続先アドレス：接続先がドメインかIPか、またポートが80、443、53、またはアプリ固有のポートかを確認します。
  3. 適用ルール：Domain、DomainSuffix、GeoIP、IPCIDR、RuleSet、または最後の Match を確認します。
  4. ポリシーの出口：トラフィックがDIRECT、REJECTのどちらへ進んだか、またはどのプロキシグループと具体的なノードを通ったか確認します。
  5. 接続結果：同じ時刻の前後にtimeout、refused、TLS、DNS、EOFが出ていないか続けて確認します。

システムプロキシがトラフィックを取得していないか確認する方法

ログを消去して、これまで開いていないサイトへアクセスします。TCPまたはUDP接続がまったく追加されない場合、問題は通常、リクエストがコアに入る前に発生しています。まずシステムプロキシが有効か確認し、次にアプリがシステムプロキシを迂回していないか確認します。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの状態を確認できます。一般的なHTTPプロキシのアドレスは 127.0.0.1:7890 ですが、実際のポートはクライアントの表示に従ってください。

ブラウザーに独立したプロキシ拡張機能がある場合、拡張機能のポートもClashが現在待ち受けているポートと一致させる必要があります。ログが空のままなら、ノードを何度も切り替えても意味がありません。そもそもノードにリクエストが届いていないためです。TUNモードでは、ログにTUNインバウンドの起動記録があること、仮想ネットワークアダプターが作成されていることも確認してください。

ルールの誤適用を判断する方法

接続先がログに現れているのに、出口が想定と異なる場合は、match の後に表示されるルールを確認します。プロキシを通すはずの接続が、例えば次のように表示される場合です。

INFO [TCP] 198.18.0.1:42116 --> service.example.com:443
match GeoIP(CN) using DIRECT

198.18.0.1 はFake-IPのマッピングアドレスである可能性があり、実際のサーバーがそのアドレスにあることを意味しません。重要なのは、最終的にGeoIPに一致してDIRECTへ進んでいる点です。ドメインルールを先に適用したい場合は、ルールの順序、ルールセットの読み込み状態、ドメインが早い段階でIPに解決されていないかを確認します。Clashのルールは上から順に照合され、最初に一致した時点で後続のルールは確認されません。

頻出エラーの意味

i/o timeout と context deadline exceeded

どちらもタイムアウトを示しますが、発生箇所は異なる場合があります。ノードのアドレスへの接続がタイムアウトする場合は、ノードの停止、ポートへの到達不能、ネットワーク遮断、UDPの不通などが考えられます。接続先サイトへの接続がタイムアウトする場合は、ノードから接続先までの経路に問題がある可能性があります。まずエラーに表示されたアドレスを確認してください。ノードサーバーのIPとノードポートなら、遅延テストに成功した別のノードへ切り替えます。接続先ドメインの443ポートなら、DIRECTとプロキシ出口を比較します。

遅延テストで80msと表示されても、ノードが必ず使えるとは限りません。テストによっては固定URLにアクセスするだけで、実際のWebサイトではDNS、TLS、接続先サーバーのポリシーも関係します。3回続けてテストし、80ms、450ms、タイムアウトの間で結果が大きく変動するなら、ノードの経路自体が不安定です。

connection refused

connect: connection refused は、接続先ホストが接続を明確に拒否したことを示し、通常はタイムアウトより早く返ります。拒否されたアドレスが 127.0.0.1:7890 なら、アプリがローカルのプロキシポートへ接続しようとしているものの、そのポートを待ち受けるプロセスがありません。コアが起動していないか、ポートが変更された可能性があります。リモートノードのポートが拒否された場合は、サーバー側プロセスの停止、ポート変更、サブスクリプション内のノード情報の期限切れなどがよくある原因です。

Windowsでは netstat -ano | findstr 7890 を実行してポートを確認できます。macOSまたはLinuxでは lsof -i :7890 を実行します。LISTENの記録がなければ、まずコアの動作を復旧し、ルールの確認は後回しにしてください。

no such host、server misbehaving とDNSタイムアウト

no such host は通常、ドメインから利用可能な名前解決結果を取得できなかったことを示します。ドメインの入力ミス、上流DNSからのNXDOMAIN、Clashが設定済みのnameserverへアクセスできないことなどが原因です。server misbehaving は、DNS上流から異常な応答が返った場合や、リクエスト処理が中断された場合によく見られます。ログに lookup、exchange failed、deadline exceeded も出ているなら、ノードやルールより先にDNSを確認してください。

まず設定内のDNS機能と待ち受けアドレスを確認します。例えば次のような設定です。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

ここでの 1053 はClash DNSの待ち受けポートであり、ブラウザーのプロキシポートではありません。システムや他のプログラムからこのポートへDNSリクエストを送る場合は、ポートが使用中でないことも確認してください。DoHを使う場合は、DoHドメイン自体を最初に名前解決する必要がある点にも注意が必要です。必要に応じて default-nameserver で、直接アクセスできるIP形式のDNSを指定します。

TLS handshake timeout と証明書関連のエラー

TLS handshake timeout は、TCP接続は確立している可能性があるものの、制限時間内にTLSハンドシェイクが完了しなかったことを示します。ノードの品質、接続先サイトの応答遅延、途中経路でのパケットロス、システム時刻の異常などが原因になります。まずシステムの日付、タイムゾーン、自動時刻合わせを確認し、別のノードで再テストしてください。1つのドメインだけ失敗する場合は、接続先サイトまたはそのドメインへの経路に問題がある可能性が高いです。

x509、certificate signed by unknown authority、ドメイン不一致は、証明書の検証に失敗したことを示します。長期的な対策として証明書検証を無効にしないでください。システム時刻、ローカルのパケットキャプチャーソフト、企業ネットワークの証明書、ノードから返された内容を確認し、接続が誤ったサーバーへリダイレクトされていないか調べます。

EOF、connection reset by peer、broken pipe

EOF はデータストリームが途中で終了したことを示しますが、1回だけなら必ずしも障害ではありません。ブラウザーがリクエストをキャンセルした場合にもEOFが発生します。connection reset by peer はリモート側が接続をリセットしたこと、broken pipe はローカルが書き込みを続けた時点で相手側の接続が閉じていたことを示します。ページを閉じるときだけ出るなら無視できますが、アクセスのたびに1～2秒以内で繰り返す場合は、ノードを切り替え、QUICを無効にして再試行し、接続先が現在の出口IPを制限していないか確認してください。

現象からノード・ルール・DNSを切り分ける

ノードの遅延は正常なのにWebページが開けない

  1. ログレベルをInfoに設定し、既存の記録を消去します。
  2. HTTPSサイトを1つだけ開き、接続先ドメインと操作時刻を記録します。
  3. ログに接続先ドメインが現れていることを確認し、実際に使われたポリシーグループとノードを確認します。
  4. 同じ1分間に発生したtimeout、TLS、reset、EOFを検索します。
  5. 同じルールを固定したまま別のノードで再テストし、複数の変数を同時に変更しないようにします。
  6. すべてのノードで失敗する場合は、DIRECTへ切り替えて比較し、DNSの解決結果も確認します。

ノードを切り替えてすぐ復旧した場合は、元のノードまたはその上流経路に問題があります。すべてのノードが名前解決の段階で失敗するなら、まずDNSを確認します。ログがDIRECTを示しているのにプロキシを想定していた場合は、ルールの順序またはポリシーグループの選択を見直します。

特定のアプリだけ接続できない

ブラウザーは正常なのに、特定のアプリでログがまったく生成されない場合、そのアプリがシステムプロキシを使っていない可能性が高いです。ゲーム、コマンドラインツール、ストアアプリの一部は直接接続するため、より多くのトラフィックを取り込むにはTUNモードを有効にします。有効化後は、TUNデバイスの起動、ルートの追加、権限エラーの有無を確認してください。

アプリがログを生成するもののUDPだけが継続的に失敗する場合は、選択したノードがUDPに対応しているか、ポリシーグループがUDPを許可しているか確認します。TUNのMTUが特定のネットワークに影響することもあります。デフォルト値でフラグメントの問題が出る場合は、クライアントの対応範囲内で1500から1400へ変更して比較テストできますが、症状の根拠がないまま頻繁に変更するのは避けてください。

ルールモードでは動かないが、グローバルモードなら正常

この現象は通常、ルールの適用に関係します。グローバルモードでは大半のルール判定を迂回し、選択したプロキシグループを直接使うため、ノードに最低限の接続能力があることを確認できます。ルールモードへ戻したら、接続先ドメインを検索して適用項目を確認します。MATCH,DIRECT に落ちている場合は末尾のルールを確認し、期限切れのルールセットに一致している場合は、ルールプロバイダーのダウンロードに失敗していないか確認してください。

ルールセットの読み込み問題には、HTTP 404、403、タイムアウト、YAML解析エラーが伴うことがあります。リモートアドレスを修正したら、クライアントで「設定」→「更新」または該当するルールセット更新操作を実行し、ログに読み込み成功の記録が出ることを確認します。ポリシーグループ名だけを変更してルールの参照先を更新しないと、存在しないポリシーを指すことになります。

TUNモードのログで追加確認する項目

TUNモードはシステムのネットワーク層でトラフィックを受け取るため、ログに仮想ネットワークアダプター、ルート、DNSハイジャック、インターフェース選択に関する情報が現れることがあります。コア起動後もTUNデバイスが作成されない場合、権限不足、システムサービスの停止、仮想アダプターの競合、別のVPNによるルート占有などがよくある原因です。

  • 起動直後に権限エラーが出る：クライアントのサービス状態を確認し、OSの要件に従って管理者権限を付与します。
  • 起動は成功するがネットワーク全体が切断される：デフォルトインターフェースの認識、DNSハイジャック先、ルートの追加が正常か確認します。
  • LAN内のデバイスにアクセスできない：プライベートネットワークが誤ってプロキシへ送られていないか確認します。よくあるネットワークには 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 があります。
  • 一部のUDPアプリで問題が起きる：ノードのプロトコルがUDPに対応しているか確認し、タイムアウトやネットワーク到達不能が出ていないか確認します。
  • 終了後もネットワークが復旧しない：まずコアを完全に終了し、システムプロキシ、DNS、デフォルトルートに古い値が残っていないか確認します。

使えるトラブル記録をまとめる

設定提供元やクライアントプロジェクトへ報告する際は、画面全体のスクリーンショットより、整理したテキストのほうが有効なことが多いです。コアのバージョン、クライアントのバージョン、OS、発生時刻、プロキシモード、接続先ドメイン、適用ポリシー、連続して発生したエラー行を残すことをおすすめします。mihomoコアのバージョンは、クライアントの「情報」または「コア」画面で確認できます。例えば mihomo v1.19.x のように表示されます。クライアントのバージョンも正確な小数点以下まで記載してください。

送信前に、サブスクリプションURL、認証パラメーター、ノードサーバーの認証情報、LAN内デバイス名を削除してください。公開サイトのドメイン、エラーの種類、ルール名は通常残す必要があります。削除すると、リクエストがどの段階で失敗したか判断できません。次の形式で整理できます。

システム：Windows 11 24H2
クライアント：Clash Verge Rev 2.3.x
コア：mihomo 1.19.x
モード：Rule + TUN
発生時刻：2026-06-02 14:32
現象：ブラウザーで接続先ドメインへのアクセスが継続的にタイムアウト
適用：DomainSuffix → Proxy → Node-A
エラー：dial tcp 203.0.113.10:443: i/o timeout
比較：Node-Bへ切り替えると接続が復旧

この記録があれば、問題をNode-Aまたはその経路まで絞り込めます。数分間にわたるすべてのバックグラウンド接続を添付する必要はありません。DNSが関係する場合は、nameserverの種類、Fake-IPまたはRedir-Hostモード、名前解決に失敗したメッセージを追加すれば十分です。

ログを調べる順番のまとめ

安定した調査手順は、まずトラフィックがClashに入っているか確認し、次に接続先とポート、適用されたルール、ポリシーグループ、実際のノード、直後に出たエラーの順に確認することです。ログが空ならシステムプロキシまたはTUNの取り込みを確認し、出口が誤っていればルールを確認します。lookupやno such hostが出たらDNSを確認し、timeout、refused、TLS、resetが出たらノードまたはリモート経路を判断します。

Infoレベルはほとんどの場面に適しており、Debugは重要な情報が足りない場合だけ短時間有効にします。再現テストが終わったら元の設定へ戻し、時刻とバージョン情報を含む簡潔なログを保存してください。感覚だけで設定を何度も変えるのを防ぎ、問題がクライアント、ルール、DNS、ノード、接続先サイトのどこにあるかをより早く判断できます。