Clash初心者のよくある疑問：サブスク、モード、接続状態の10問

開始前に：4つの状態を区別する

Clashクライアントは通常、グラフィカルインターフェース、Clashまたはmihomoカーネル、設定ファイル、システムネットワーク設定の4要素が連携して動作します。ウィンドウが開くのは、グラフィカルインターフェースが起動したことを示すだけです。設定の取り込みに成功しても、通信がすでにプロキシを通っているとは限りません。初期化が完了したかどうかは、設定、ノード、プロキシの入口、実際のリクエストの順に確認しましょう。

1. 設定状態：現在の設定ファイルをカーネルが読み込めており、画面にYAMLの解析エラーや非対応フィールドのエラーが表示されていない。
2. ポリシー状態：プロキシのポリシーグループに利用可能なノードがあり、手動選択が必要なポリシーグループが空になっていない。
3. 通信の取り込み状態：システムプロキシまたはTUNモードの少なくとも一方が有効で、アプリの通信がClashの待受ポートに入っている。
4. 接続状態：接続一覧に新しい記録が追加され、ログにルールのマッチ結果が表示され、対象リクエストが正常な応答を受け取っている。

「起動済み」やトレイアイコンだけを見ていると、設定、ノード、システムプロキシの問題を混同しがちです。以下の10問は実際の操作順に沿って説明しているため、トラブル時は該当する章へ直接移動できます。

サブスクリプションと設定：取り込み＝接続ではない

質問1：サブスクリプションURLを取り込んだのに、なぜノードが表示されない？

サブスクリプションURLは、本質的にはリモート設定への入口です。クライアントはそのURLへアクセスしてレスポンスを取得し、内容をプロキシノード、ポリシーグループ、ルールとして解析します。取り込みが完了したのに一覧が空になる場合、URLのコピー漏れ、サブスクリプションの期限切れ、現在のネットワークからサーバーへ接続できない、サーバーが設定ではなくWebページを返している、クライアントが返却形式に対応していない、といった原因が考えられます。

まず設定またはサブスクリプション管理画面で手動更新を実行し、更新時刻とエラーメッセージを確認します。タイムアウトが表示されたら、現在のネットワークとサブスクリプションサーバー間の疎通を確認してください。解析エラーの場合は、ログインページ、管理画面のURL、QRコード画像のリンクではなく、サブスクリプションURLを取り込んでいるか確認します。サービスによっては汎用サブスクリプション、Clash設定、単一ノード用リンクを別々に提供しています。デスクトップ版Clashクライアントでは通常、「Clash」または「Clash互換」と明記された設定用の入口を選びます。

「ノードが空」と「ポリシーグループが未選択」は分けて考えましょう。ノードは設定内に存在していても、ホーム画面にはポリシーグループだけが表示される場合があります。プロキシまたはProxiesページで具体的なポリシーグループを展開し、メンバーを確認してください。ルール提供元がポリシーグループを動的に生成する場合は、設定のダウンロードと解析が終わるまで待ってから操作します。

質問2：サブスクリプションを更新すると、手動で変更した内容は上書きされる？

通常は上書きされます。リモートサブスクリプションの更新は、設定を新たにダウンロードし直す処理に相当します。サブスクリプションから生成されたノード名、ルール、DNS項目を直接変更すると、次回更新時にリモート側の内容で置き換えられる可能性があります。クライアントによってオーバーライド、設定のマージ、スクリプト処理、設定パッチの実装は異なりますが、基本原則は共通です。更新される内容はリモート設定に任せ、ローカルのカスタマイズはクライアントが提供するオーバーライド層に記述しましょう。

初心者が最初からYAMLを大幅に編集するのはおすすめしません。まず元の設定を残し、基本的な接続が使えることを確認してから、クライアントの機能に応じてローカルルールを追加します。編集後に起動できなくなった場合は、インデント、コロンの後のスペース、リスト記号、フィールドの階層を優先的に確認してください。YAMLはスペースで階層を表現するため、タブ、全角記号、誤ったインデントによってファイル全体を読み込めなくなることがあります。

ノードと遅延：テスト値が実速度を示すとは限らない

質問3：遅延が最も小さいノードは、必ず最速？

必ずしもそうではありません。遅延テストは主に、クライアントからテスト先への接続またはリクエストが完了するまでの時間を示すもので、ノードがオンラインか、インタラクティブな応答が速いかを判断するのに適しています。ダウンロード速度は、ノードの出口帯域幅、回線の混雑、ネットワーク間の経路、接続先サイトの速度制限、プロトコルのオーバーヘッド、ローカルネットワークの品質にも左右されます。遅延が数十ミリ秒でも混雑したノードは、遅延がやや大きくても回線が安定したノードより実効速度が遅い場合があります。

ノードを選ぶときは、3段階で確認するとよいでしょう。まずタイムアウトするノードを除外し、次に低遅延のノードで実際にWebページやファイルへリクエストを送ります。最後に、しばらく使って通信が頻繁に途切れないかを確認します。ゲーム、リモートターミナル、リアルタイム通話では遅延とジッターが重視されます。動画や大容量ファイルのダウンロードでは持続的なスループット、通常のWeb閲覧ではDNS、ハンドシェイク速度、安定性のバランスが重要です。

クライアントのURL Testポリシーグループは、固定URLを定期的にテストし、結果のよいノードを選べます。ただし、テスト結果が示すのは、そのテスト先とテストした時点の状態だけです。Fallbackポリシーは障害時の切り替えに向き、ロードバランスポリシーは設定に応じて複数のノードへ接続を振り分けます。具体的な動作は設定されたポリシーグループの種類によって異なるため、「自動選択」をすべて単純な最低遅延の選択だと考えないでください。

質問4：ノードは利用可能なのに、なぜWebページが開けない？

ノードテストに成功しても、ブラウザーのリクエストが同じ経路を通るとは限りません。まず接続一覧にブラウザーがアクセスしたドメインが表示されているか確認します。記録がまったくなければ、問題は通常、システムプロキシ、ブラウザー独自のプロキシ設定、またはTUNの取り込み層にあります。記録があれば、適用されたルール、最終ポリシー、エラー情報を続けて確認します。

テスト先にはアクセスできても、目的のWebサイトにはアクセスできない場合があります。対象ドメインがルールによってDIRECTに振り分けられている、ポリシーグループで別のノードが選択されている、DNSの解決結果と接続経路が一致していない、といった可能性があります。グローバルモードへの切り替えは、短時間の切り分けに使えます。グローバルモードで使えてルールモードで使えないなら、ルールのマッチングとポリシーグループを確認します。どちらも使えないなら、まずノード、DNS、システム時刻、ローカルネットワークを確認してください。

ルールモードとシステムプロキシ：通信の入口を確認する

質問5：Rule、Global、Directの3モードにはどんな違いがある？

Rule（ルール）モードでは、設定されたルールに従ってリクエストを1件ずつ判定します。ドメイン、IP、プロセス、ルールセットなどを基準に、直接接続するか、拒否するか、特定のポリシーグループへ渡すかを決定します。日常利用で最も一般的なモードですが、設定内のルールとポリシーグループが正常に使えることが前提です。

Global（グローバル）モードでは通常、Clashに入ってきたリクエストをすべてグローバルポリシーグループへ渡します。ノードが機能するかを一時的に確認するのに適しています。ただし、端末上のすべての通信が自動的にClashへ入るわけではありません。通信は先にシステムプロキシ、アプリのプロキシ、またはTUNインターフェースを通る必要があります。

Direct（ダイレクト）モードでは、Clashに入ったリクエストをプロキシノードを経由せず、接続先へ直接接続します。プロキシノードが異常の原因かを確認したり、Clashの取り込み状態を保ったままノード転送だけを停止したりする場合に便利です。Directはクライアントを完全に終了することとは異なり、DNS、待受ポート、接続記録は引き続きカーネルが処理する場合があります。

切り分けには次のような簡単な比較が使えます。ルールモードで失敗し、グローバルモードで成功するなら、主にルールを確認します。グローバルモードでも失敗するなら、ノードと通信の取り込み口を確認します。Directモードでも失敗するなら、ローカルネットワーク、DNS、接続先サービス自体に問題がある可能性もあります。テストが終わったら元のルールモードに戻し、想定していた振り分け結果を長期間変えないようにしましょう。

質問6：システムプロキシを有効にしても、一部のアプリが直接接続するのはなぜ？

システムプロキシは、OSがアプリに提供するプロキシ設定です。ブラウザーや多くのデスクトップアプリはこの設定を読み取り、HTTPまたはHTTPSのリクエストをClashの混合ポート、または対応するプロキシポートへ送ります。ただし、すべてのアプリがシステムプロキシに従うわけではありません。一部のゲーム、コマンドラインツール、仮想マシン、コンテナ、独自のネットワークスタックを実装したソフトウェアは、直接接続することがあります。

まず、システムプロキシを有効にした後、OSのプロキシアドレスがローカルの待受アドレスを指し、ポートがクライアントの現在のポートと一致しているか確認します。他のアプリがポートを使用している、カーネルが動作していない、設定の切り替え後にクライアントの待受に失敗している、といった場合は、システムプロキシが有効でも通信が入ってきません。ブラウザーに独自のプロキシ拡張機能を入れている場合は、拡張機能を一時的に無効にしてからテストしてください。

より多くのTCP、UDP、またはシステムプロキシを読み取らないアプリを対象にするなら、TUNモードを検討できます。TUNは仮想ネットワークインターフェースを作成し、システムのルーティングによってより多くの通信をカーネルへ送ります。通常は管理者権限が必要です。対象範囲が広い一方、他のVPN、仮想NIC、セキュリティソフト、カスタムルートと競合しやすくなります。初心者はまずシステムプロキシを正常に動かし、必要に応じてTUNを有効にしてください。複数のネットワーク設定を同時に変更するのは避けましょう。

接続失敗：入口、ルール、ノード、接続先の順に確認する

質問7：ログのtimeout、connection refused、DNS errorはそれぞれ何を示す？

timeoutは、ネットワーク処理のいずれかの段階が制限時間内に完了しなかったことを示します。サブスクリプションへのアクセス、ノードへの接続、接続先との接続確立、応答待ちなどで発生する可能性があります。回線障害、深刻なパケットロス、接続先の応答遅延、ファイアウォールによる遮断などが考えられますが、timeoutだけで障害箇所を断定することはできません。ログの対象アドレス、ポリシー名、接続経路を合わせて判断してください。

connection refusedは、対象アドレスが接続を明確に拒否したことを示します。ローカルポートで拒否された場合は、Clashカーネルが該当ポートを待ち受けていない可能性があります。プロキシサーバーで拒否された場合は、ノードのサービス停止やポート設定の不一致が考えられます。最終的な接続先で拒否された場合は、そのサービスが該当ポートを開放していない可能性があります。

DNS関連のエラーは、ドメイン名の解決段階で有効な結果を取得できなかったことを示します。よくある原因は、DNSサーバーに到達できない、拡張モードの設定が合っていない、ネットワークがDNSリクエストを遮断している、ドメイン自体が存在しない、といったものです。このような場合、ノードを何度も切り替えるだけでは解決しません。まず通常のネットワークでドメインを解決できるか確認し、次に設定のDNSスイッチ、待受設定、nameserver、fallbackなどの項目を確認してください。DNSを変更した後は設定を再読み込みして接続をやり直します。既存の接続に新しい結果が自動適用されることはありません。

質問8：システムプロキシは有効なのに、なぜ接続一覧が空のまま？

接続一覧が空ということは、現在確認しているリクエストがClashに入っていないという意味です。まず、ブラウザーがキャッシュを直接使わないよう、まだ開いていないWebページを更新します。その後、クライアントのカーネルが動作中か、システムプロキシが正しいポートを指しているか、OSの設定に以前のクライアントのプロキシアドレスが残っていないかを確認します。

ブラウザーがプライバシープロキシ、拡張機能のプロキシ、企業の管理ポリシーを使用している場合、システムプロキシを迂回することがあります。コマンドラインツールにも、HTTPプロキシやHTTPSプロキシなどの独自の環境変数が設定されている場合があり、別のポートを指している可能性があります。TUNモードで接続一覧が空なら、仮想NICが正常に作成されたか、ルートが反映されているか、管理者権限が付与されているかを確認してください。

LAN上の端末からのテスト方法が適切かどうかも確認しましょう。Clashが初期状態でローカルアドレスだけを待ち受けている場合、他の端末から直接接続することはできません。クライアントでLANアクセスを許可し、待受アドレスがLANインターフェースを含み、OSのファイアウォールが該当ポートを許可して初めて、スマートフォンや別のPCからその端末をプロキシサーバーとして利用できます。LAN待受を公開する前に、ネットワークが信頼できるか確認し、アクセス範囲を制限してください。

更新とメンテナンス：設定状態のずれを防ぐ

質問9：クライアントの更新後に設定を読み込めない場合は？

グラフィカルクライアント、カーネル、設定仕様は、同じバージョン概念で管理されているわけではありません。クライアントの更新でカーネルも同時に変わることがあれば、旧カーネルを使い続けることもあります。一方、サブスクリプション設定には特定のカーネルでしか対応していないフィールドが含まれる場合があります。更新後に読み込めなくなったら、まずエラー行全体を記録し、複数の項目を続けて変更しないでください。

不明なフィールドやポリシー種別が原因なら、現在のクライアントがClash、Clash Meta、mihomoのどのカーネルを使っているか、設定がそのカーネル向けに生成されたものかを確認します。mihomoはClash Metaの機能を引き継ぎ、さらに拡張していますが、旧版クライアントに内蔵されたカーネルが新しい設定項目に対応しているとは限りません。YAMLの行番号が示されている場合は、その行付近のインデント、引用符、リスト構造を確認してください。実際の構造エラーが、表示された行より前にあることもあります。

推奨する処理手順は固定しておきましょう。現在のファイルをバックアップし、正常に動作することが分かっている基本設定へ切り替え、カーネルが起動できることを確認してから、サブスクリプションを再更新します。基本設定は使えるのにサブスクリプション設定だけ失敗するなら、問題はサブスクリプションの内容または互換性に絞れます。すべての設定で失敗するなら、クライアントの権限、カーネルファイル、待受ポート、アップグレード手順を確認します。こうすれば設定エラーをインストールエラーと誤認せずに済みます。

質問10：Clashが正常に動作しているかどうかを判断するには？

1つのWebページだけで判断しないでください。完全な確認には、ローカル状態、プロキシ経路、振り分け結果の3つの観点が必要です。まずカーネルが動作し、設定にエラーがなく、ポリシーグループでノードが選択されていることを確認します。次にシステムプロキシまたはTUNが有効で、Webページを開いたときに接続一覧へ新しい記録が追加されることを確認します。最後に、各リクエストが想定したルールに一致しているか確認します。たとえばローカルサービスはDIRECT、プロキシが必要な接続先は指定したポリシーグループに入る状態です。

次のチェックリストを上から順に確認しましょう。

• 設定ページに最新の更新時刻が表示され、手動更新でダウンロードまたは解析エラーが返されない。
• プロキシページに少なくとも1つ利用可能なノードがあり、現在のポリシーグループが空または無効なノードになっていない。
• ルールモードが有効で、ログにドメイン、ルール、最終ポリシーが表示される。
• 新しいWebページを開くと接続数が変化し、アップロードとダウンロードの通信量が継続的にゼロではない。
• システムプロキシを無効にするとリクエスト経路が想定どおり変化し、再度有効にすると元に戻る。
• クライアントを再起動しても設定が自動的に読み込まれ、システムプロキシの状態がクライアントの設定と一致する。

以上がすべて正常なら、インストール、設定、ノード、通信の入口が一連の経路として機能しています。その後に遅延、ルールの詳細化、DNSの最適化、TUNの互換性を調整するほうが、クライアントを何度も再インストールするより効果的です。