Clash ログの見方:エラーの意味と原因の特定手順

クライアントが繋がらないとき、システムプロキシのスイッチをオンオフしたり、ノードを片っ端から切り替えたりするのが一番よくある対処法です。しかし実際には、内核のログにはすでに失敗の原因がかなり具体的に記録されています。ただフォーマットが詰まっていて英語のエラーが多いため、多くの人はざっと見て閉じてしまいます。この記事ではエラーキーワードごとによく出るログを5つのカテゴリに分け、それぞれがどの段階で起きるものか、通常の原因、次に確認すべきポイントを順番に説明します。

まずログ1行の構造を理解する

Clashの内核(Clash Meta / mihomo含む)の接続ログの書式はほぼ固定されています。典型的なTCPログを例に見てみましょう。

[TCP] 127.0.0.1:52310 --> www.google.com:443 match DomainSuffix(google.com) using ノード選択[香港01]

5つの要素に分けられます。

[TCP] / [UDP]:この接続が使う転送プロトコル。Web閲覧はほぼTCP、QUICや一部のゲーム・音声通話はUDPを使います。
127.0.0.1:52310:ローカルのどこから来た接続か。システムプロキシモードでは通常127.0.0.1、TUNモードではより具体的なローカルネットワークの送信元アドレスが表示されます。
--> www.google.com:443:接続先アドレスとポート。ここにドメイン名でなくIPが表示される場合、アプリがIPで直接接続しているということで、ルールのドメインマッチングは効きません。
match DomainSuffix(google.com):マッチしたルール。match Match()と表示される場合は最後のフォールバックルールまで流れ着いており、それより前のルールセットには一つも当たっていないということです。
using ノード選択[香港01]:実際の出口。DIRECTと表示される場合、その通信はプロキシを経由していません。本来プロキシ経由になるべき宛先がDIRECTになっている場合、問題はルール側にあり、ノード側の問題ではありません。

ログの詳細度は設定ファイルのlog-levelで決まり、silent、error、warning、info、debugから選べます。多くのクライアントの初期値はinfoです。問題を調べる際はまずdebugに切り替えることで、DNSクエリ、ルールマッチングの詳細、ハンドシェイクの過程まで確認できます。

log-level: debug

GUIクライアント(Clash Verge Rev、Clash for Windowsなど)にはログ画面が用意されており、レベルを直接切り替えられます。内核単体で動かしている場合はログは標準出力に流れますが、external-controllerを設定すればコントローラーの/logsエンドポイントからリアルタイムに取得できます。

注意

debugレベルのログは量が非常に多く、アクセスの詳細まで記録されます。調査が終わったらinfoに戻しましょう。そのままにしておくと大量のdebug出力に肝心な情報が埋もれてしまいます。

ノード接続段階のエラー

ログにdialという文字が出ている場合、Clashがノードのサーバーへ接続を試みている最中で、問題は端末からノードまでの経路上で起きています。

[TCP] dial 香港01 --> www.google.com:443 error: dial tcp 198.51.100.7:443: connect: connection refused

connect: connection refused:サーバーが接続を拒否している状態で、ノードのポートで待ち受けるサービスが存在しません。ノードがオフライン、ポート変更、サブスクリプション情報の期限切れが典型的な原因です。まず同じサブスクリプション内の別ノードに切り替え、すべて失敗する場合はサブスクリプションを更新してください。
i/o timeout / context deadline exceeded:接続がタイムアウトし、送信したリクエストに応答が一切返ってきません。connection refusedより経路の遮断やサーバーダウンに近い状況です。Wi-Fiからスマホのテザリングに切り替えて再テストすれば、ローカルの通信環境の問題かノード側の問題かを素早く区別できます。
connection reset by peer:接続確立後に相手側から途中で切断されています。一度だけなら無視して構いませんが、頻発する場合はノードの負荷が高い、または通信経路に干渉が入っていることが考えられます。

この段階の問題はローカルのプロキシ設定とは無関係です。ログにすでにdialでノードへ接続している記録がある時点で、通信はすでにClashに正しく渡っています。システムプロキシのオンオフを何度も試す必要はありません。

TLS・プロトコルハンドシェイク段階のエラー

サーバーへの接続は成立したがハンドシェイクに失敗する場合、エラーキーワードはtls、x509、EOFといったものに変わります。

x509: certificate has expired or is not yet valid:証明書の期限検証に失敗しています。まず端末のシステム時刻が正確かどうかを確認してください。時刻のズレが大きいとほぼすべてのTLS系プロトコルが失敗します。システム時刻が正常であれば、次にノード側の証明書設定を疑いましょう。
tls: first record does not look like a TLS handshake:接続先のポートで動いているのがTLSサービスではありません。サブスクリプション内のポートやプロトコル種別の設定ミスが多く、例えばTrojanノードが非TLSのポートを指している場合などに起こります。
EOF / tls: handshake failure:ハンドシェイクの途中で接続が切断されています。SNIやALPNがサーバー側と一致していない場合によく見られます。ノード設定内のservername / sniの項目が変更されていないか確認してください。
Shadowsocksでcipher: message authentication failedが出る場合:AEAD検証に失敗しており、パスワードまたは暗号化方式がサーバー側と一致していません。サブスクリプションの提供元に戻ってこの2項目を照合してください。
VMessノードの設定に問題が見当たらないのに認証に失敗する場合:システム時刻を確認してください。VMessはタイムスタンプによる検証を行うため、端末とサーバーの時刻差が許容範囲を超えると拒否されます。
WebSocket系ノードでwebsocket: bad handshakeが出る場合:パス(path)またはHostがサーバー側と一致していません。CDNのオリジン設定が変更された後に特によく見られます。

ハンドシェイク段階のエラーはローカルのネットワーク品質とはほぼ無関係で、大半は次の2点に集約されます。ノードのパラメータが変更されていないか、サブスクリプション情報が期限切れになっていないかです。

設定・サブスクリプション読み込み段階のエラー

このカテゴリのエラーは内核起動時やサブスクリプション更新時に発生し、ログにはyaml、unmarshal、proxy providerといった語句が含まれます。

yaml: line X: ... / unmarshal errors:設定ファイルのX行目付近に構文エラーがあります。YAMLはタブによる字下げが許されず、コロンの後には必ずスペースが必要で、特殊文字を含む値は引用符で囲む必要があります。行番号に沿って確認すればすぐに直せます。
proxy [xxx] not found:ポリシーグループが存在しないノードを参照しています。ノードの名前変更や削除後にポリシーグループの参照名を更新し忘れているケースが多く、参照名を揃えれば解決します。
rules[X] ... error:X番目のルールの解析に失敗しています。ルールの種類の記述ミスや、パラメータの数が合っていない(末尾の振り先ポリシーが抜けているなど)ことが多い原因です。
proxy provider ... error、サブスクリプション更新時に404やタイムアウトが返る場合:サブスクリプションのリンクが失効している、またはそのリンク自体が現在のネットワークからアクセスできない状態です。多くのクライアントには「プロキシ経由でサブスクリプションを更新」というオプションがあります。サブスクリプションのアドレスにプロキシ経由でしかアクセスできない場合は、これをオンにして更新してください。

設定の読み込みに失敗すると内核はそのまま終了するか起動を拒否することが多いため、実はこのカテゴリのエラーは最も特定しやすいものです。エラーメッセージに行番号やフィールド名まで具体的に示されているので、その通りに直せば済みます。

DNS・ポート競合・TUN関連のエラー

dns resolve failed、DNSクエリのタイムアウト:Clash内蔵DNSの設定が不適切か、上流サーバーに到達できていません。設定内のdns.enable: trueを確認し、nameserverリストに到達可能な上流サーバーがあるか確認してください。fake-ipモードで異常が出る場合は、まずredir-hostに切り替えてfake-ipのキャッシュが原因かどうかを検証しましょう。

dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

bind: address already in use、7890番ポートでのリスニング失敗:ミックスドポートが既に使用されています。多くの場合は別の内核プロセスや同種のソフトが既に起動しているためで、古いプロセスを終了させれば解決します。mixed-portを変更してポートを切り替えることもできますが、その場合はシステムプロキシ設定側のポートも合わせて変更する必要があります。
TUNモードの起動失敗(permission denied、utun / wintunデバイスが見つからない):TUNには管理者権限が必要で、Windowsではwintunドライバーにも依存します。クライアントを管理者権限で実行してください。それでもエラーが出る場合はtun.stackをsystemとgVisorの間で切り替えて試してみてください。特定のプロトコルスタックが特定のOSバージョンと相性が悪いケースがあります。
システムプロキシの設定に失敗する場合:macOSではネットワーク設定の変更に許可が必要です。Windowsではセキュリティソフトがプロキシスイッチの書き込みをブロックしていないか確認してください。

決まった順序で調べる

ログレベルをdebugに切り替え、問題を一度完全に再現させ、エラーがログの末尾に新しく現れるようにします。
下から上に向かって最初のerrorまたはwarningを探します。最後の1行だけを見てはいけません。それ以降に続く大量の出力は、最初のエラーが引き起こした連鎖反応であることが多いです。
キーワードから最初のエラーを次の5段階のいずれかに分類します。設定読み込み、サブスクリプション更新、DNS解析、ノード接続、プロトコルハンドシェイク。分類したら前述の各節に沿って対処してください。
クロス検証を行います。システムプロキシを経由せず、直接Clashのポートを叩いて一度テストします。

curl -x http://127.0.0.1:7890 https://www.google.com -I

通れば内核とノードは正常で、問題はシステムプロキシまたはブラウザ側にあります。通らなければ、問題は内核からノードまでの間にあります。1回のテストでは1箇所だけを変更してください。3箇所を同時に変えると、どれが効いたのか永久に分からなくなります。

ヒント

ログにはノードのアドレスやアクセス先のドメインなど個人情報に近い内容が含まれます。グループチャットやフォーラムでログを貼って質問する前に、ノードのIP、ドメイン、サブスクリプションのリンクは必ずマスキングしましょう。

エラーキーワード早見表

エラーキーワード	発生段階	疑うべき原因	次に行うこと
`connection refused`	ノード接続	ノードのオフライン、ポート設定ミス	ノードを切り替え、サブスクリプションを更新
`i/o timeout`	ノード接続	経路の遮断、サーバーダウン	ネットワーク環境を変えてクロス検証
`connection reset by peer`	ノード接続	ノードの過負荷、通信への干渉	ノードを切り替えて再現するか確認
`x509: certificate has expired`	TLSハンドシェイク	システム時刻のズレ	時刻を修正して再テスト
`not look like a TLS handshake`	TLSハンドシェイク	ポートまたはプロトコル種別の設定ミス	サブスクリプションのノードパラメータを照合
`message authentication failed`	プロトコル認証	パスワードまたは暗号化方式の不一致	サブスクリプションの提供元で照合
`yaml unmarshal errors`	設定読み込み	構文エラー	行番号から字下げと引用符を確認
`proxy provider error`	サブスクリプション更新	リンクの失効、プロキシ経由での更新が必要	プロキシ経由で更新するかリンクを変更
`dns resolve failed`	DNS解析	上流サーバーが利用不可	dns設定を確認
`address already in use`	ローカルポート	ポートの競合	古いプロセスを終了するかポートを変更
`permission denied`(TUN)	TUN起動	権限不足、ドライバー未導入	管理者権限で実行

ログはClashが残した一次証言です。まずログを読んでから対処に動く、この順序を固定してしまえば、ほとんどの接続問題は数分で該当箇所を特定できます。