なぜまずログを見るべきか、ノードを変える前に
ページが開かない、接続が不安定といった問題に遭遇したとき、多くの人はまずサブスクリプションやノードの切り替えを試し、何度か失敗するとクライアント自体を疑い始めます。しかしこのやり方は効率が悪く、プロキシ経路にはローカル設定・ノードの可用性・国際回線の品質・接続先サイトの応答など複数の要素が絡んでいるため、闇雲にノードを変えても可能性の一部しか排除できません。より速い方法は、ログ画面を開いてクライアントが今回の接続リクエストをどう処理したかを確認することです。エラーメッセージは通常、問題がどの層で起きているかを直接示してくれます。
Clash 系クライアントのログは、本質的にはコア(Clash Meta / mihomo)の実行過程のリアルタイム出力であり、クライアント画面はそのテキストを表示し、色分けとフィルタリングを施しているだけです。ログの構造とよく出るフィールドの意味を理解することは、接続問題を切り分けるうえで最も基本的かつ効果的なスキルです。
ログレベルとフィールド構造
クライアントのログ画面(サイドバーで通常 Logs や「ログ」と表記)を開くと、次のような一行のレコードが見つかります。
[Info] [TCP] 192.168.1.5:51234 --> example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using Proxy-HKこの一行には次の 4 つの重要な要素が含まれています。
- ログレベル:角括弧内の Info、Warning、Error などで、記録の重大度を示します。
- プロトコルと接続方向:TCP または UDP、およびローカルポートから接続先ドメイン/ポートへの方向。
- マッチしたルール:この接続が設定ファイル内のどの振り分けルールにヒットしたかを示します。
- 使用されたプロキシノード:実際にこの接続を転送しているノードまたはプロキシグループ名。
ログレベルは通常 4 段階に分かれており、クライアントの設定で表示する最低レベルを調整できます。
- Debug:最も詳細で、ルールマッチの全過程を含みます。通常はオンにせず、原因が分かりにくい問題を調べるときだけ使います。
- Info:デフォルトレベル。正常な接続確立、ルールマッチ、ノード切り替えなどの情報を記録します。
- Warning:致命的でない異常。たとえば、ある DNS クエリが予備のリゾルバーを使った、あるノードの検査がタイムアウトしたが代替がある、といったケースです。
- Error:接続失敗や設定読み込みエラーなど、注意が必要な問題で、通常は具体的なエラー文言を伴います。
問題を切り分ける際は、まずレベルを Info または Debug に設定し、問題が起きた操作(たとえば開けないページを開く)を一度再現してから、ログの中の Error と Warning レベルの記録を確認し、問題が起きたリクエストに正確に対応付けることをおすすめします。
connection refused 系のエラー
これは最もよく見られるエラーの一つで、完全な内容は次のようになります。
[Error] [TCP] dial tcp 203.0.113.10:443: connect: connection refusedこれは、ローカルは既に接続リクエストを送信したが、相手側(ノードのサーバーの場合もあれば接続先サイトの場合もある)がこの TCP 接続を能動的に拒否した、という意味です。よくある原因は次の 3 種類に分けられます。
- ノードサーバーが利用不可:ノードがオフラインになった、サービス提供者が一時的にポートを閉じた、あるいはノード自体の設定に誤りがある(ポート番号や暗号化方式がサーバー側と一致しない)場合です。この場合、同じサブスクリプション内の別のノードに切り替えるとすぐに確認できることが多いです。
- ローカルのファイアウォールやセキュリティソフトによるブロック:一部のセキュリティソフトはクライアントが確立するアウトバウンド接続をブロックすることがあり、特に TUN モードを有効にすると発生しやすくなります。セキュリティソフトのリアルタイム保護を一時的に無効にして比較テストできます。
- 接続先サイトが現在のノードの IP を拒否している:一部のサイトは特定の IP 帯域にアクセス制限をかけており、この場合ノード自体は正常でも、そのサイトへのアクセスは継続してエラーになります。ノードを変えるしか対処法がありません。
この 3 つを区別する簡単な方法は、同じノードで複数の異なるサイトにアクセスしてみることです。すべてで connection refused が出るなら、ノードまたはローカル環境の問題である可能性が高く、一部のサイトだけでエラーが出て他は正常なら、そのサイトが当該ノードの IP を制限している可能性が高いです。
DNS タイムアウトと解析失敗
DNS 関連のエラーには通常、明確なキーワードが含まれます。例えば以下の通りです。
[Warning] [DNS] resolve example.com failed: context deadline exceeded
[Error] [DNS] all DNS servers failed to resolve example.com一つ目は、あるドメイン解決リクエストがタイムアウトした(設定されたタイムアウト時間を超えた)ことを示します。一時的なものであれば通常使用に影響はなく、コアが自動的に再試行するか次の DNS サーバーに切り替えます。二つ目は、設定ファイルに列挙されたすべての DNS サーバーで解決が失敗したことを示し、この場合ページは開けなくなります。
DNS 解決失敗のよくある切り分け方向は次の通りです。
- 設定ファイルの DNS セクションを確認する:
nameserverリストのアドレスが利用可能か確認します。海外の DNS(8.8.8.8、1.1.1.1など)を使っている場合、これらのアドレスへのクエリ自体もプロキシ経由になっているか確認してください。そうでなければ、直接接続が許可されていない環境ではやはりタイムアウトします。 - Fake-IP モードが有効かどうか確認する:Fake-IP はドメインに仮想 IP を割り当て、接続確立時にコアが実際の解決を行う仕組みです。この層の設定に誤りがある(fake-ip-range がローカルネットワークセグメントと衝突しているなど)場合、ドメインは「解決」できているのに実際には接続できない、という状態になります。
- ローカルの Hosts ファイルや他のプロキシソフトの干渉を調べる:同一マシンで別のネットワークツールが動作していたり、Hosts ファイルに古いドメインマッピングが残っていたりすると、DNS 層で異常な結果が出ることがあります。
ログに DNS 関連の Warning が頻繁に出ていてもページが問題なく開けている場合、通常はリゾルバーが自動的に再試行しているだけなので追加対応は不要です。Error レベルの解決失敗が継続して出ており、実際にページにアクセスできない場合にのみ、DNS 設定の調整に取り掛かる必要があります。
サブスクリプション解析失敗
サブスクリプション更新時に次のようなエラーが出た場合、問題は設定ファイルの取得または解析の段階で発生しており、プロキシノード自体とは関係ありません。
[Error] update subscription failed: Get "https://sub.example.com/link": context deadline exceeded
[Error] parse config failed: yaml: line 42: did not find expected key一つ目はネットワークレベルの失敗です。クライアントがタイムアウト時間内にサブスクリプション提供元のサーバーからコンテンツを取得できなかったことを示し、よくある原因としては、この時点でローカルに利用可能なプロキシがなくサブスクリプションリンクにアクセスできない、サブスクリプション提供元のサーバーが一時的に到達不能、あるいはサブスクリプションリンク自体が失効している、といったことが挙げられます。二つ目はコンテンツレベルの失敗です。サブスクリプションの内容は正常にダウンロードできたものの、YAML 形式の解析でエラーが発生しており、多くの場合サブスクリプション提供元がメンテナンス告知の HTML など正常な設定内容ではないページを一時的に返しています。
サブスクリプション解析失敗は、次の順序で切り分けられます。
- まずサブスクリプションリンクがブラウザで正常に開き、テキスト内容が表示されるか確認します。エラーページや空白のページが表示される場合、問題はサービス提供者側にあり、提供元に連絡するか復旧を待つ必要があります。
- サブスクリプション更新時に使われているネットワーク環境を確認します。一部のクライアントはサブスクリプション更新時に現在有効なプロキシではなく「直接接続」を使うことがあり、直接接続環境からサブスクリプションのドメインにアクセスできなければ、更新は当然タイムアウトします。
- サブスクリプションリンクに特殊文字が含まれていないか、途中で切れていないか確認します。コピー&ペースト時に余分なスペースが入ったり文字が欠けたりすると、リンクが無効になります。
プロキシグループの速度測定とノード切り替え関連のログ
設定ファイルに自動速度測定を行うプロキシグループ(url-test や fallback タイプなど)が使われている場合、ログには継続して次のような記録が現れます。
[Info] Proxy-HK check health: 156ms
[Warning] Proxy-SG check health failed: dial tcp: i/o timeoutこれらのログはコアのヘルスチェック機構によるもので、一定間隔でプロキシグループ内のノードに対して速度測定リクエストを送り、遅延を記録するか利用不可としてマークします。あるノードで check health failed が続けて出ている場合、そのノードに実際に問題があることを示し、プロキシグループは自動的にそのノードをスキップして遅延の低い代替ノードを選択します。これが、設定を変えていないのに接続速度が速くなったり遅くなったりする理由で、裏ではプロキシグループがノード間で動的に切り替えを行っているのです。
グループ内の全ノードで速度測定が失敗している場合、通常は 2 つのケースが考えられます。一つはサブスクリプション自体の品質が悪く、ノードが大量に利用不可になっている場合。もう一つはローカルのネットワーク環境自体に異常があり、すべてのアウトバウンド接続が確立できない場合です。この場合はまずローカルのネットワーク問題を排除すべきで、慌ててサブスクリプションを変える必要はありません。
TUN モード関連のエラー
TUN モード(システムレベルのプロキシで、すべてのトラフィックを引き受ける)を有効にして起動に失敗した場合、ログには比較的直接的なヒントが出ます。
[Error] start TUN device failed: operation not permitted
[Error] start TUN device failed: address already in use一つ目は基本的に権限の問題です。TUN モードは仮想ネットワークカードを作成する必要があり、この操作にはクライアントを管理者権限で実行することが求められます。以前は一般権限で起動していた場合、クライアントを管理者として開き直すことで通常は解決します。二つ目は、仮想ネットワークカードが使用するアドレス帯域が既存のローカルネットワーク設定と衝突していることを示し、他の仮想ネットワークカードを使うツール(一部の VPN クライアントなど)が同時に動作している場合によく見られます。競合するソフトを先に終了するか、設定で TUN が使うアドレス帯域を調整する必要があります。
エラー種別ごとに原因を特定する実用的な手順
上記のエラー種別をまとめると、比較的汎用的な切り分け手順が導き出せます。
- まず問題が発生している層を確認する:完全にネットにつながらないのか(TUN やシステムプロキシ設定の問題の可能性)、特定のサイトだけ開けないのか(ノードやルールの問題の可能性が高い)、すべてのサイトが遅いのか(ノード品質や国際回線の問題の可能性が高い)を切り分けます。
- ログ画面を開き、操作を一度再現する:ログレベルを Info に設定し、失敗するアクセスをもう一度実行して、その時に発生したエラー文言を記録します。
- キーワードで分類する:
dial tcp/connection refusedはノードまたは接続先サイトとの接続問題を、DNS関連はドメイン解決層の問題を、update subscription/parse configはサブスクリプション取得とフォーマットの問題を、TUN関連はシステムレベルのプロキシ権限またはネットワークデバイスの衝突を示します。 - 層ごとに排除していく:まずローカル環境(権限、ファイアウォール、他のプロキシソフトとの衝突)を排除し、次にサブスクリプションとノード自体を排除し、最後に接続先サイト個別の制限を検討します。
この順序を守れば、ほとんどのエラーは数分でおおよその方向性を特定でき、当てずっぽうに設定やノードを変え続ける必要はなくなります。
まとめ
ログは開発者向けのブラックボックス出力ではなく、クライアントが「今回の接続がどの段階でつまずいているか」を積極的に教えてくれる説明文です。よくあるエラーのキーワードとその意味を数分かけて把握し、問題に遭遇したらまずログを見てから設定を調整する習慣をつければ、クライアントを何度も再起動したり闇雲にノードを変えたりするより時間の節約になり、本当の問題の根本原因も見つけやすくなります。