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

1. コアのログを開き、失敗時の記録をひと通り残す

クライアントには「アプリログ」「コアログ」「接続」の各画面がある場合があります。アプリログには主に画面の起動、設定ファイルのダウンロード、サービス管理が記録されます。ルール判定、DNSクエリ、プロキシ接続を確認するにはコアログを見ます。接続画面では、現在アクティブな接続とプロキシチェーンを確認できます。これらは相互に補完する情報で、同じ記録ではありません。

最小限の操作で一度だけ再現する

1. クライアントの「ログ」または「コアログ」を開き、現在時刻、有効な設定ファイル、プロキシモードを記録します。メニュー名は使用中のクライアントに合わせてください。
2. コアのログレベルが info になっていることを確認します。必要な情報が足りない場合は、一時的に debug に変更して設定を適用し、もう一度再現します。
3. ほかの通信中アプリを終了し、失敗するページを1つだけ開きます。クリックした時刻（例：14:32:08）を記録し、その後約10秒間のログを確認します。
4. エラー行とその前後5～10行を保存します。調査が終わったら info に戻し、デバッグ情報が長期間大量に蓄積しないようにします。

# 現在の設定のトップレベルに統合し、同名のフィールドを重複して追加しないでください
log-level: info

サブスクリプションで設定を管理している場合、ダウンロード後のファイルを直接編集すると、次回の更新で上書きされることがあります。クライアントのオーバーライドまたはマージ機能を優先してください。ファイルを編集するしかない場合は、先にバックアップし、再読み込みが成功したことを確認します。設定の解析に失敗すると、新しい設定が反映されていない可能性があります。

2. ログレベルと各行のフィールドを読む

ログレベルは記録の重要度を示すもので、ネットワーク品質の評価ではありません。バックグラウンドアプリの再試行で出た warning が、現在開いているページの障害とは限りません。反対に、info しか出ていなくても、ページの内容が正常に読み込まれた証拠にはなりません。

ログ1行を5つの要素に分けて読む

time="2026-09-15T14:32:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using Webプロキシ[ノードA]"

• 時刻：14:32:08+08:00 を直前の操作時刻と照合します。複数のデバイス間で確認する場合は、タイムゾーンにも注意してください。
• プロトコル：[TCP] は、この接続がTCPを使用していることを示します。これだけでUDPも正常だとは判断できません。
• 送信元：127.0.0.1:53124 は、ローカル端末のアドレスと一時ポートです。53124 はプロキシ設定に入力する待ち受けポートではありません。
• 接続先：www.example.com:443 はアクセス先とそのポートです。エラー発生時に最終的に接続しようとしたノードのアドレスとは限りません。
• マッチしたルールと出口：DomainSuffix(example.com) はマッチしたルール、Webプロキシ[ノードA] はポリシーグループと選択中のノードを示します。

この種の情報行が示すのは、コアが接続をどう処理したかです。TLSハンドシェイク、ログイン、ページ内リソースの読み込みまで完了したことを意味しません。後続にタイムアウトやハンドシェイクエラーがあれば、ログを続けて確認してください。「プロキシにマッチした」という行だけで判断を終えないようにしましょう。

3. dial tcp timeout：どの区間でタイムアウトしたかを確認

level=warning msg="[TCP] dial Webプロキシ (match DomainSuffix/example.com) 127.0.0.1:53124 --> www.example.com:443 error: dial tcp 203.0.113.20:443: i/o timeout"

dial tcp はTCP接続の確立を示し、i/o timeout は、処理のどこかで待ち時間が上限を超えたことを示します。ログによっては connect: connection timed out や、上位のエラーとして context deadline exceeded と表示されます。待機が失敗したことは分かりますが、原因がDNS、接続先サーバー、ローカルのファイアウォールのどれかまでは特定できません。

最後に表示されたIPアドレスとポートを確認

例では接続先が www.example.com:443 である一方、実際の接続先アドレスは 203.0.113.20:443 です。後者がノードの server と port に該当するなら、まずPCからノードまでの経路を調べます。現在の接続先が DIRECT なら、Webサイトまでの直接接続経路を確認してください。プロキシをチェーン接続している場合は、実際のチェーンに沿って中継区間も調べます。

1. ノード設定を確認：サブスクリプションの有効期限、ノードのドメイン名、ポート、プロトコルがサーバー側の設定と一致しているか確認します。Webサイトの 443 をそのままノードのポートとして扱わないでください。
2. 変更する要素は1つだけ：ルールとDNSはそのままにし、正常に使えることが分かっている別のノードに切り替えて、同じ接続先にアクセスします。
3. ネットワークを比較：問題がなければ、スマートフォンのテザリングに切り替えてみます。同じノードが特定のWi-Fiでのみタイムアウトする場合は、そのネットワークの外向き通信制限を優先して調べます。
4. ローカルの通信経路を確認：ファイアウォール、ほかのVPN、仮想ネットワークアダプター、TUNのルーティング競合を確認します。最初からすべてのセキュリティ対策を無効にしないでください。

Windowsでは、PowerShellの Test-NetConnection を使ってTCP接続の可否を確認できます。以下のアドレスはドキュメント用の例です。実際にテストする場合は、ノード設定にある実際のホスト名とポートに置き換えてください。例示用アドレス自体はテストしないでください。

Test-NetConnection -ComputerName 203.0.113.20 -Port 443

TcpTestSucceeded がTrueでも分かるのは、そのときTCP接続が確立できたことだけです。プロキシのプロトコル、認証情報、UDP転送は検証できません。ノードの遅延テストも同様で、テスト用URLに接続できても、すべてのドメインにアクセスできるとは限りません。

4. connection refused：拒否されたポートがローカルかリモートか確認

dial tcp 127.0.0.1:7890: connect: connection refused

connection refused は通常、接続が明示的に拒否されたことを示します。接続先ポートでサービスが待ち受けていない場合のほか、ファイアウォールが明示的に拒否している可能性もあります。タイムアウトとは異なり、タイムアウトは応答がないまま時間切れになる一方、拒否はより早く返る傾向があります。

アドレスが127.0.0.1の場合：プロキシの待ち受けを確認

ブラウザー、コマンドライン、ほかのアプリからのエラーで、アドレスが 127.0.0.1:7890 の場合は、まずコアが実行中で、実際の待ち受けポートが 7890 か確認します。クライアント側のポートが 7897 に変更されているのに、システムプロキシには古い値が残っている場合があります。送信元の一時ポートを、ここで確認するポートと取り違えないでください。

# 現在の設定にある関連フィールドの例。ポートはアプリの設定と一致させてください
mixed-port: 7890
allow-lan: false

mixed-port はHTTPとSOCKS5のプロキシ接続を受け付けます。アプリにプロキシを入力するときは、ポートを混在して使える場合でも、適切なプロトコルを選択してください。Windowsでは待ち受け状態を確認できます。macOSとLinuxでは、それぞれのポート確認コマンドを使います。

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'

アドレスがリモートノードの場合：サーバーの待ち受けとサブスクリプションを確認

拒否された接続先がノードのIPアドレスとポートであれば、サーバーが待ち受け中か、ポートが変更されていないか、サブスクリプションが更新されているかを重点的に確認します。ローカルの mixed-port を何度変更しても、リモートポートの拒否は解決しません。起動ログに address already in use が表示される場合は、ローカルのポートが使用中です。まず使用中のプロセスを特定し、競合するサービスを停止するか、ポートを統一して変更するかを判断します。

5. DNS解決失敗：アクセス先とノードのドメインを分けて確認

lookup www.example.com: no such host
dns resolve failed: all DNS requests failed
read udp 192.168.1.8:53012->192.168.1.1:53: i/o timeout

no such host は、システムのリゾルバーがホスト名を解決できない場合によく表示されますが、ドメイン名の入力ミス、DNSの上流サーバー、応答内容も確認が必要です。all DNS requests failed は集約されたエラーです。前後のログを調べ、具体的な失敗原因を確認してください。UDPの 53 番ポートでタイムアウトしている場合は、該当するDNSサーバーへのクエリに応答が間に合っていません。

3つの観点から名前解決の経路を確認

1. 解決に失敗したドメイン：Webサイトのドメインであれば、そのサイトへのアクセスに影響します。ノードの server ドメインであれば、プロキシトンネル自体を確立できない可能性があります。対処の順番は異なります。
2. どのリゾルバーが処理しているか：コアの dns が有効か、アプリが独自のセキュアDNSを使っているか、システムのDNSリクエストがTUNに取り込まれているかを確認します。
3. 上流サーバーに到達できるか：通常のDNS、DoH、DoTではネットワーク経路が異なります。DoHがHTTPSを使っていても、現在のネットワークから必ず到達できるとは限りません。

システムコマンド nslookup www.example.com は通常、システムに指定されたDNSサーバーに問い合わせます。成功しても、その名前解決経路が使えることしか分かりません。ClashコアのDNSやブラウザー内蔵のDoHが正常だとは証明できません。比較する際は、IPアドレスが返されたかだけでなく、どのサーバーに問い合わせたかも記録してください。

Fake-IPモードで、アプリに 198.18.0.0/16 の範囲にあるマッピングアドレスが渡されるのは正常な場合があります。範囲は fake-ip-range の設定によって異なります。アドレスが一般的なパブリックIPに見えないというだけで、名前解決エラーと判断しないでください。また、このマッピングアドレスを使ってインターネット接続の可否を直接判断しないでください。

DNSを変更したあとも、アプリ、システム、コアがそれぞれキャッシュを保持している場合があります。クライアントで対応している方法でキャッシュを消去し、既存の接続を閉じてから再テストしてください。古いキャッシュで一度解決できた結果を、新しい設定が反映された証拠とみなさないようにしましょう。

6. ルールのマッチ状況から原因を探る：リクエストの出口が想定と違う理由

ルールモードでは通常、rules を上から順に評価し、マッチしたルールのポリシーを適用します。グローバルモードでは、主に選択中のグローバルポリシーを確認します。ダイレクトモードでは、ルールモードと同じように通常のプロキシルールが通信を処理するとは限りません。調査を始める前に現在のモードを確認し、判定に使われていない設定を何度も変更しないようにしましょう。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Webプロキシ
  - GEOIP,LAN,DIRECT
  - MATCH,Webプロキシ

この例を使うには、既存の proxy-groups に「Webプロキシ」という名前のポリシーグループがあり、コアが使用するルールに対応している必要があります。これはルールの一部であり、完全な設定ではありません。MATCH はフォールバック用のルールなので、優先して判定するルールの後ろに置きます。

ルール、ポリシーグループ、最終的なノードを順に確認

• ルールにマッチしているか：example.com にアクセスする想定なのに MATCH と表示される場合は、実際のドメイン名、サブドメイン、ルールの順序、設定の再読み込み結果を確認します。
• マッチ結果は妥当か：DIRECT と表示される場合は、ノードの障害と決めつけず、より上位のダイレクトルールに先にマッチしていないか確認します。
• ポリシーグループの選択は正しいか：同じグループでも、DIRECT、別のグループ、特定のノードが選ばれる場合があります。自動速度測定やフェイルオーバーのグループでは、出口が動的に変わることもあります。
• 一部のリソースだけが失敗していないか：メインページ、画像、ログインAPIでは異なるドメインが使われることがあります。アドレスバーに表示されるドメインだけを調べると、本当にエラーが起きているリソースを見落とす可能性があります。

たとえば、メインページは「Webプロキシ」を通る一方で、ログインAPIがダイレクトルールにマッチすると、「ページは開くがログインが終わらない」という状態になることがあります。ログイン操作をした時刻をもとに該当する接続先ドメインを探し、必要に応じてブラウザーの開発者ツールにある「ネットワーク」パネルで失敗したリクエストを特定してから、ログを確認してください。

一時的にグローバルモードへ切り替えて比較することはできますが、それ自体が最終的な解決策ではありません。グローバルモードでは接続でき、ルールモードでは失敗する場合は、ルールとDNSの経路に戻って原因を調べます。設定を変更した後は、既存の接続を閉じてから再試行してください。既存の接続は元の出口を使い続けることがあり、ルールの変更だけで自動的に再接続されるとは限りません。

7. TLS、UDP、設定エラーについて確認すること

設定の udp: true を有効にしても、UDPに対応していないサーバーが対応するようになるわけではありません。ゲームや音声通話に問題がある場合は、クライアントの入口からノードのプロトコル、サーバー、外向きネットワークまで、経路全体を確認してください。同様に、ブラウザーがQUICを使うとUDP関連のログが出ることがあります。TCP接続の成功だけですべての状況を説明しないようにしましょう。

証明書エラーがノードとのハンドシェイク中に発生する場合は、ノードのサーバー名とプロトコルのパラメーターを確認します。サブスクリプションの更新中に発生する場合は、サブスクリプションのサイトとシステムの信頼チェーンを確認してください。どちらも x509 を含むエラーですが、接続の段階は異なります。

8. トラブル調査の情報を共有する：前後関係を残し、機密情報を隠す

役に立つ調査記録は長文である必要はありませんが、操作と接続を対応づけられる情報が必要です。「タイムアウトしました」とだけ伝えるより、次の情報を添えると原因を正確に判断しやすくなります。

1. 環境：OSとクライアントのバージョン、コアの名称と完全なバージョン番号を記載します。「バージョン情報」または起動ログからコピーし、「最新版」とだけ書かないでください。
2. 通信の入口：システムプロキシかTUNか、現在のモード、ローカルの待ち受けポート、失敗するのが1つのアプリだけかすべてのアプリかを記載します。
3. 再現手順：操作した時刻、失敗した機能、そのときのポリシーグループとノードの選択状況を記載し、直前にサブスクリプションや設定を更新したかどうかも伝えます。
4. 根拠となる情報：関連ログの前後、マッチしたルール、ノードやネットワークを変更した場合の比較結果を記載します。

最終確認も同じ順序で行います。リクエストがコアに届いたこと、ルールと出口が想定どおりであること、DNS、接続の確立、アプリケーション層のリクエストが完了したことを確認します。変更するのは毎回1項目だけにし、結果を記録してください。そうすれば、本当に解決したのか、一時的に復旧しただけなのかを区別でき、サブスクリプション更新後も有効な設定をすばやく特定できます。