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

まずリクエストを再現し、該当ログを絞り込む

Clashでページが開けなくても、ノードの障害とは限りません。リクエストがカーネルに届いていない場合もあれば、DNS解決、ルール選択、プロキシのハンドシェイク、接続先サーバーの応答のいずれかで止まっている可能性もあります。重要なのは、エラー表示を見て設定全体を入れ替えることではなく、最後に正常に完了した処理を特定することです。

この記事は、オリジナル版ClashとClash Meta（現mihomo）の一般的なログを対象としています。カーネルやバージョン、クライアントによって項目や表示方法が異なるため、例はログの構造を説明するもので、すべてのバージョンで同じ文言が出力されるとは限りません。まずクライアントの「バージョン情報」またはカーネル情報画面で、クライアントのバージョン、カーネル名、カーネルのバージョンを控えてから比較してください。クライアントのバージョン番号は、カーネルのバージョン番号の代わりにはなりません。

1. 現在の設定のコピーを保存し、システムプロキシ、TUN、動作モード、選択中のプロキシグループを記録します。
2. クライアントの「ログ」画面を開きます。メニュー名はクライアントによって異なります。見つからない場合は、そのクライアントのマニュアルを確認してください。
3. ほかのダウンロードを一時停止して現在時刻を控え、問題を安定して再現できるURLを1つだけ開きます。
4. リクエストの前後約10秒分のログを保存し、対象ドメイン、対象ポート、または送信元ポートで絞り込みます。

ログレベルと各項目：まず適用ルール、次に失敗箇所を確認

設定の log-level でログの詳細度を指定します。通常は info のままにし、原因を特定しにくい問題を再現するときだけ一時的に debug に変更します。変更を適用して調査し、終わったら元に戻してください。デバッグ情報が増えすぎると、重要なエラーが埋もれることがあります。

log-level: info

設定値は warning でも、画面上では WARN と表示される場合があります。表示上の略称を設定値と混同しないでください。また、ログレベルだけでは障害の影響範囲は判断できません。警告がページ内の統計リクエストに関するものでも、誤ったプロキシグループが選ばれた接続は通常の情報ログとして表示されることがあります。

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

• time：イベントの発生時刻です。別の端末のログと照合する前に、タイムゾーンとシステム時刻を確認してください。
• [TCP]：接続プロトコルです。UDP通信は別途確認が必要で、TCPのテストだけでは判断できません。
• 127.0.0.1:53124：送信元アドレスと一時ポートです。プロキシの待ち受けポートではありません。
• www.example.com:443：接続先ホストとポートです。HTTPSでは443が一般的ですが、すべてのアプリが既定のポートを使うわけではありません。
• match：今回適用されたルールです。通常、using の後にプロキシグループと実際に選ばれた接続先が表示されます。

ログの using は接続先が選択されたことを示すだけで、接続の成功やページの完全な読み込みを意味しません。同じ宛先の同じ時刻付近に、接続開始の失敗、ハンドシェイクエラー、接続切断がないか続けて確認してください。

接続タイムアウト：プロキシサーバーと接続先サーバーを切り分ける

i/o timeout、context deadline exceeded、または timeout を含む接続エラーは、いずれかの処理が制限時間を超えたことを示します。「タイムアウト」という表示だけでは、ローカルネットワーク、ノードの回線、接続先サイトのどこに問題があるか判断できません。

エラーに表示されたアドレスから、止まっている箇所を特定する

1. プロキシサーバーへの接続がタイムアウト：エラーの宛先がノード設定のサーバーアドレスとポートか確認します。該当する場合は、ノードへの接続、本機のネットワーク、サーバーのポートを優先して確認してください。
2. 接続先への直接接続がタイムアウト：ログに DIRECT と表示され、接続先IPの443番ポートでエラーが出る場合は、まずその通信が本来直接接続されるべきかルールを確認します。
3. ハンドシェイクまたはリモートからの読み取りがタイムアウト：TCP接続は確立していても、その後のプロトコル通信が完了していない可能性があります。ノードのプロトコル、TLSパラメーター、サーバーの状態を確認してください。

複数の異なるサイトを開くより、同じURLで比較するほうが有効です。以下のコマンドはHTTP混合ポート 7890 が設定されている場合に使えます。Windows PowerShellでは curl.exe を明示的に実行し、macOSとLinuxでは curl を使ってください。

curl -I --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 5 --max-time 15 --noproxy "*" https://example.com/

1つ目のコマンドはローカルプロキシポートを明示して接続し、2つ目はcurlのプロキシ設定を迂回します。ただし、TUNが引き続きルーティングを制御している場合、2つ目の通信もカーネルに取り込まれる可能性があります。本当に直接接続した状態で比較するには、条件を管理したうえでTUNを一時的に無効にしてください。403や405もHTTPレスポンスであり、ネットワーク接続の失敗と単純にみなすことはできません。

DNS解決失敗：どこで名前解決しているかを確認

no such host は名前解決で有効な結果を取得できなかったことを示しますが、DNSサーバーの停止とは限りません。ドメインが存在しない、上流から否定応答が返された、本機の名前解決経路に問題があるなど、原因はさまざまです。特に lookup の後に表示されるドメインを確認してください。プロキシサーバーのドメインならノードへの接続前に失敗しています。接続先サイトのドメインなら、接続先とDNSの設定を合わせて確認します。

ポートを指定してカーネルのDNSをテストする

現在有効な設定に以下のDNS設定が含まれている場合、カーネルが待ち受ける 1053 ポートへ直接問い合わせできます。ここで示す上流DNSアドレスは診断用の例です。実際のネットワークから到達できるものを選び、サブスクリプション内のDNS設定全体を置き換えないでください。

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

# macOS / Linux（digのインストールが必要）
dig @127.0.0.1 -p 1053 example.com A

# Windows：nslookupの対話モードに入り、順に入力
nslookup
server 127.0.0.1
set port=1053
example.com
exit

• 問い合わせがタイムアウト：カーネルにこの設定が読み込まれていることと、1053番ポートが待ち受け状態であることを確認してから、上流DNSに到達できるか調べます。
• NXDOMAINが返る：ドメインの綴りを確認し、存在が分かっているドメインでも試してください。存在しないドメインへの応答をネットワーク障害と混同しないでください。
• Fake-IPが返る：たとえば既定のアドレス範囲を使う設定では、198.18.0.0/16 内のアドレスにマッピングされることがあります。これはDNS解決の失敗ではありません。
• システムからの問い合わせは正常で、カーネルからの問い合わせに問題がある：カーネルDNSの上流設定とルーティングを確認します。逆の場合は、システムDNSが意図した経路を参照しているか確認してください。

通常の nslookup example.com は一般にシステムで設定されたDNSを参照するため、カーネルDNSの正常性を直接証明するものではありません。DoHまたはDoTを使う場合は、上流サーバーのドメインを解決するためのDNS、TLS検証、接続経路も確認してください。mihomoのDNS拡張項目は、オリジナル版Clashではすべて使えるとは限りません。追加する前に、使用中のカーネルが対応しているか確認してください。項目の説明はDNS設定リファレンスをご覧ください。

ポート競合と接続拒否：カーネルが実際に待ち受けているか確認

bind: address already in use は通常、起動時または再読み込み時に発生し、ローカルアドレスとポートを再度バインドできないことを示します。よくある原因は、クライアントを2つ同時に起動していること、または古いカーネルプロセスが終了していないことです。まずエラーに記載されたポートがプロキシ用、DNS用、コントロール用のどれかを確認し、すべてのポートを一度に変更しないでください。

mixed-port: 7890
external-controller: 127.0.0.1:9090

上記の設定では、7890 が混合プロキシの受け入れポート、9090 がコントロールインターフェースです。コントロールインターフェースはHTTPプロキシの入口ではないため、ブラウザーのプロキシ先に9090を指定しても期待どおりには動作しません。以下のコマンドはプロセスを確認するだけで、終了はさせません。

# Windows
netstat -ano | findstr :7890

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

# Linux
ss -lntp 'sport = :7890'

1. ポートに対応するPIDとプログラム名を確認し、重複起動しているクライアントを正常に終了します。
2. 7891 に変更する場合は、システムプロキシ、ブラウザー拡張機能、コマンドラインのプロキシ設定も合わせて変更してください。
3. カーネルを再起動し、バインドエラーがないことを確認してから、指定したプロキシポートでcurlを再実行します。

connection refused はポート競合とは異なり、接続先で接続が拒否されたことを示します。接続先ポートでサービスが待ち受けていない場合によく発生します。拒否されたアドレスが 127.0.0.1:7890 ならローカルのカーネルを優先して確認し、ノードサーバーのアドレスならサーバーのポートとサービスの状態を確認してください。ローカル接続の問題を解消するために、待ち受けアドレスを安易にすべてのネットワークインターフェースへ広げないでください。

ルールに一致しない：モード、順序、最終的な接続先を確認

Clashのルールモードでは rules を上から順に評価し、最初に一致したルールで接続先が決まります。リストに正しいルールがあっても、そのルールが評価されるとは限りません。グローバルモードでは同じルール一覧を順に使って接続先を選ぶわけではないため、調査前に現在の動作モードを確認してください。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手動選択

この例では、設定内に「手動選択」という名前のプロキシグループが定義済みであることを前提としています。www.example.com にアクセスすると最初のルールに一致し、それ以外の未一致リクエストは最後の MATCH に渡されます。MATCH を先頭に置くと、後続のルールは評価されません。

4つのポイントを確認して原因を絞る

• 実際に読み込まれている設定を確認：サブスクリプションの元ファイル、編集したローカルファイル、クライアントで実行中の設定は異なる場合があります。エディターに保存しただけでなく、変更が適用されていることを確認してください。
• ドメインが取得できているか確認：アプリがIPアドレスへ直接接続し、カーネルがドメイン情報を復元できない場合、DOMAIN-SUFFIX に一致しないことがあります。スニッフィングが役立つ場合もありますが、すべての接続でドメインを復元できるわけではありません。
• ルールセットの状態を確認：RULE-SET を使っている場合は、まずルールプロバイダーがダウンロードされ、正常に解析されているかを確認します。その後、参照名とルールの順序を照合してください。
• プロキシグループで実際に選ばれている項目を確認：ログに正しいグループ名が表示されても、グループ内で DIRECT や別のノードが選択されていれば、想定とは異なる結果になります。

ルール変更をテストするときは、新しい接続を作成してください。既存の長時間接続は以前の接続先を使い続けることがあり、ページを再読み込みするだけではすべての接続が作り直されない場合があります。テストするアプリを一度終了して再起動するか、影響範囲を確認したうえで該当する接続を閉じてください。各項目の詳細は設定ガイド、サブスクリプションの更新手順はサブスクリプションの使い方をご覧ください。

TLS・認証・TUNのエラーを、ひとまとめにネットワーク障害として扱わない

TLSエラーでは、まずノードとのハンドシェイクか、接続先サイトとのハンドシェイクかを切り分けます。ノードでTLSを使う場合、サーバーアドレス、SNI、証明書の名前がサーバー側の設定と一致している必要があります。システム時刻が大きくずれている場合も、検証に失敗することがあります。証明書の検証を無効にするとセキュリティ上の前提が変わるため、一般的な解決策として使わないでください。

TUN関連のエラーは、仮想インターフェースの作成、ルート設定、DNSの取り込み時に発生することがあります。Windowsではクライアントのサービスモードと必要な権限を確認してください。Linuxでは /dev/net/tun の有無とプロセスの権限を確認し、macOSではクライアントが求めるシステム権限を確認します。設定項目の名称はクライアントによって異なるため、別のクライアントのメニュー手順をそのまま使わないでください。

プロキシポートを明示したcurlが成功する一方、TUNを有効にするとアプリが失敗する場合は、ノードを切り替え続けるのではなく、ルーティング、DNSの取り込み、ほかのVPNやセキュリティソフトとの競合を確認します。詳しい設定はTUN設定リファレンスをご覧ください。TUNが通信を取り込んでも、すべての通信がプロキシを経由するとは限りません。最終的な経路は動作モードとルールによって決まります。

最後の確認：同じリクエストで修正結果を検証

変更後、最初に記録したURLでもう一度テストします。復旧したかどうかはアプリの動作とログの経路の両方で判断してください。ページが最後まで読み込まれるか、想定したルールに一致するか、想定したノードが選ばれるか、同じ種類のエラーが繰り返し出ていないかを確認します。ノードの遅延テストにミリ秒の数値が表示されても、DNS、接続先サイト、アプリのプロトコルが正常とは限りません。

1. カーネルが起動しない：設定の構文、ポート、権限を先に確認します。
2. リクエストがログに出ない：info レベルで問題を再現し、システムプロキシ、アプリ独自のプロキシ設定、TUNの取り込み範囲を確認します。
3. 名前解決エラーが出る：ノードのドメインと接続先のドメインを区別し、システムDNSとカーネルDNSをそれぞれテストします。
4. 接続エラーが出る：エラーのアドレスから、ローカルの入口、プロキシサーバー、接続先サーバーのどこで失敗したかを判断します。
5. 接続できるが経路が想定と異なる：動作モード、ルールの順序、プロキシグループの選択、既存の接続を確認します。
6. 問題が解消した：通常のログレベルに戻し、効果があった変更と再現手順を記録しておきます。

有効な調査記録には、「どのリクエストが、どのルールを通り、どの段階で失敗したか」が分かる情報が必要です。この順序で原因を絞れば、設定をまとめて置き換えるより見つけやすく、サブスクリプション更新後やクライアントのアップグレード後にも再確認しやすくなります。