Clash初心者のよくある疑問：サブスクリプションの追加、ノード選択、接続トラブル10問

Clash Verge Revを初めて開くと、画面に表示されるサブスクリプション、設定、プロキシグループ、システムプロキシ、ルールモード、TUNモードが、同じ「接続スイッチ」のように感じられることがあります。実際には、それぞれ役割の異なる階層にあります。サブスクリプションは設定の取得元、設定はノードとルール、プロキシグループは選択可能な出口を決め、システムプロキシまたはTUNモードがアプリの通信をコアへ取り込み、ルールが各接続を直接接続、プロキシ、拒否のいずれにするかを決定します。

ここでは、よくある10の疑問を通して一連の利用手順を整理します。トラブルシューティングでは、一度に変更する設定を1つだけにし、変更前後の結果を記録するのがおすすめです。これにより、問題がサブスクリプション、ノード、通信の取り込み、ルール判定、接続先サイトのどこで発生しているのかを切り分けられ、すべてのスイッチを何度も切り替えずに済みます。

Subscription

サブスクリプションと設定の追加

1. サブスクリプションURLをそのままノードとして使えないのはなぜ？

サブスクリプションURLはリモート設定を取得するための入口であり、特定のプロキシノードそのものではありません。クライアントがURLへアクセスすると、ノード一覧、プロキシグループ、ルール、ルールプロバイダー、DNSなどの設定内容を取得します。追加に成功したら、設定画面に該当する設定が表示され、プロキシ画面で選択可能なプロキシグループとノードを確認できるはずです。

一般的には、サービス提供元から発行されたClashまたはMihomoのサブスクリプションURLをコピーし、クライアントのサブスクリプションまたは設定画面に貼り付けてダウンロードします。通常のウェブページURL、アカウント管理画面のURL、他のクライアント専用のサブスクリプション形式は、現在のコアで解析できるとは限りません。追加後に形式エラーが表示された場合は、まずURLの種類を確認し、すぐにポートを変更したりTUNを有効にしたりしないでください。

2. サブスクリプション追加後にノードが表示されないのはなぜ？

まず、新しい設定がダウンロード済みで、現在の設定として選択されているか確認します。クライアントによっては複数の設定を同時に保存できるため、サブスクリプションの追加に成功しても、必ずしもその設定へ切り替わっているとは限りません。次に、プロキシ画面にプロキシグループ名だけが表示されていないか確認します。ノードは「ノード選択」「手動選択」、またはサービス提供元独自の名前のグループ内にあることが多く、トップ画面に直接並ぶとは限りません。

設定を有効にしてもノード数が0のままなら、クライアントのログや設定エラーを確認します。よくある原因は、サブスクリプションの期限切れ、リモートサーバーへの一時的な接続不能、空のレスポンス、サブスクリプション形式とコアの非互換、YAMLのインデントやフィールド構造の問題です。手動設定では、少なくともノード、プロキシグループ、ルールの間に有効な参照関係が必要です。たとえば、プロキシグループが参照するノード名は、ノード定義と完全に一致していなければなりません。

proxies:
  - name: "サンプルノード"
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "サンプルノード"
      - DIRECT

rules:
  - MATCH,ノード選択

この内容は参照関係を説明するためのもので、外部ネットワークへ接続できる完全な設定ではありません。実際のノードパラメーターは、信頼できる設定元から取得してください。

3. サブスクリプションを更新すると、設定済みの選択は上書きされる？

サブスクリプションを更新すると、通常はリモート設定が再取得されます。ノードの追加・削除、プロキシグループの構成、ルール、DNS設定が変わるかどうかは、サーバーから返される新しい内容によって決まります。プロキシグループの選択を記憶する方法はクライアントごとに異なります。グループ名とノード名が変わらなければ、以前の選択が引き続き有効な場合があります。一方、ノードが削除または改名された場合は、再選択が必要です。

サブスクリプションからダウンロードしたYAMLを直接編集する場合も注意が必要です。次回の更新でリモート版がローカル内容を置き換え、手動変更が失われる可能性があります。カスタムルールを長期的に管理するなら、クライアントが対応するオーバーライド、設定のマージ、スクリプト機能を利用し、別途バックアップを保管する方法が適しています。更新後は、現在の設定、主要なプロキシグループ、ルールモードを確認し、「更新成功」という表示だけで接続状態を判断しないでください。

Selection

ノード、プロキシグループ、プロキシモード

4. 遅延が最も低いノードなら、実際の速度も必ず最速？

遅延テストで分かるのは、クライアントからテスト先への短い接続にかかった時間だけであり、継続的なダウンロード、動画再生、地域をまたぐアクセスの性能を完全に示すものではありません。ノードの速度は、回線の混雑、出口帯域、パケットロス率、接続先サイトの位置、通信プロトコル、ローカルネットワークの品質にも左右されます。遅延がやや高くてもパケットロスの少ないノードのほうが、低遅延でも混雑したノードより実際の利用では安定することがあります。

ノードを選ぶときは、まず遅延を測定し、その後に実際の接続先で確認するとよいでしょう。ウェブ閲覧では初回応答と連続して安定表示できるか、動画では一定時間バッファリングを維持できるか、ダウンロードでは瞬間的なピーク値ではなく安定した速度を確認します。複数のノードがすべてタイムアウトする場合は、まずサブスクリプション、ネットワーク、コアの状態を確認します。1つのノードだけがタイムアウトするなら、そのノードが一時的に利用できない可能性が高いでしょう。

5. ルール、グローバル、直接接続モードはどれを選ぶ？

ルールモードでは、設定内のルールを上から順に照合します。ドメイン、IP、プロセス、ルールセットに一致すると、接続は指定されたプロキシグループ、DIRECT、REJECTへ渡されます。日常利用に向いており、ローカルサービスや日本国内でよく使うサイトを直接接続し、特定の接続先だけプロキシ経由にすることもできます。

グローバルモードでは通常、コアに入った接続をすべてグローバルプロキシグループへ渡します。プロキシノードが動作しているか短時間で確認したい場合や、ルールに含まれていない接続先を比較テストしたい場合に適しています。グローバルモードにしたからといって、すべてのデバイスやプロセスが自動的にClashへ入るわけではありません。取り込みの可否は、システムプロキシ、TUN、またはアプリ自身のプロキシ設定によって決まります。

直接接続モードでは、取り込まれた通信をプロキシノード経由にせず接続先へ直接つなぎます。異常がプロキシ経路に関係しているかを確認する際に利用できます。日常利用ではまずルールモードを使い、診断が必要なときだけグローバルまたは直接接続へ一時的に切り替えて比較するのがおすすめです。

モード	通信処理	主な用途
ルール	ルールの順序に従って出口を選択	日常の振り分け
グローバル	グローバルプロキシグループへ一括転送	ノード確認、一時的なテスト
直接接続	接続先へ直接アクセス	比較による切り分け

6. ノードを選択したのに、通信がプロキシを通らないのはなぜ？

ノードを選択すると、特定のプロキシグループの出口が決まるだけで、アプリの通信が自動的にClashへ入るわけではありません。少なくとも1つの通信取り込み方法が必要です。システムプロキシを有効にする、TUNモードを有効にする、または対象アプリにClashのHTTP／SOCKSリスニングアドレスを手動で入力してください。

さらに、ルールが実際に先ほど操作したプロキシグループを使っているか確認します。設定には「ノード選択」「自動選択」「メディアサービス」「その他」など、複数のグループが存在する場合があります。「ノード選択」でノードを変更しても、ルールによっては別のプロキシグループが指定されていることがあります。その場合は、接続履歴やログを開き、対象ドメインに一致したルール、プロキシグループ、最終ノードを確認します。

Traffic Capture

システムプロキシとTUNモード

7. システムプロキシを有効にしたのに、一部のアプリが直接接続するのはなぜ？

システムプロキシの影響を受けるのは、主にOSのプロキシ設定を読み取るアプリです。多くのブラウザーや一部のデスクトップソフトが該当します。一方、一部のゲーム、コマンドラインツール、独立したアップデーター、独自のネットワーク処理を行うプログラムはシステムプロキシを無視し、Clashを経由しないことがあります。アプリ側で「直接接続」や別のプロキシが指定され、システム設定が上書きされている場合もあります。

まずブラウザーで対象サイトへアクセスし、接続履歴を確認します。ブラウザーの通信だけが記録され、特定のアプリに記録がまったくない場合は、そのアプリがシステムプロキシに従うかどうかが問題である可能性が高いでしょう。アプリ独自のプロキシ設定を確認し、必要な場合にTUNモードを利用します。すべてのアプリで記録がないなら、クライアントのコアが起動しているか、システムプロキシが正常に書き込まれているか、リスニングポートを別のプログラムが使用していないかを確認してください。

8. TUNモードはどんなときに有効にする？

TUNモードは仮想ネットワークインターフェースを通じて、より広範囲のIP通信を取り込みます。システムプロキシを読み取らないプログラムに適しており、アプリごとにプロキシを設定する手間も減らせます。ただし、インストール直後から必ず有効にする必要はありません。ブラウザーや普段使うソフトがシステムプロキシで正常に動作しているなら、構成がシンプルで理解や切り分けもしやすいシステムプロキシ方式を維持するほうがよいでしょう。

TUNを有効にするにはシステム権限が必要になることが多く、ほかのVPN、仮想NIC、セキュリティソフト、企業ネットワーククライアントとルーティングが競合する可能性があります。インターネットに接続できなくなった場合は、TUNが正常に起動したか、デフォルトルートが正しいか、DNSが利用できるか、ほかの通信取り込みツールが同時に動作していないかを確認します。ほかのネットワーク制御ソフトを終了して再テストすると、競合元を特定しやすくなります。

TUNは通信をコアへ送る役割を担いますが、最終的にプロキシを通るかどうかは現在のモードとルールによって決まります。そのため、TUNを有効にした後、一部の接続がDIRECTになっていても、必ずしも故障とは限りません。直接接続ルールに一致している可能性があります。診断では、TUNスイッチの状態だけでなく、接続詳細に表示されるルール名と最終経路も確認してください。

Troubleshooting

接続トラブルの基本対処

9. ノードテストは正常なのにウェブページが開けない場合、何を確認する？

ノードの遅延を測定できたことは、特定のテストリクエストに応答があったことを示すだけで、対象ウェブページへの完全な接続経路が正常とは限りません。次の順番で確認してください。

通信がコアへ入っているか確認する。接続画面またはリアルタイムログを開き、対象サイトへアクセスします。新しい記録がなければ、まずシステムプロキシ、TUN、アプリのプロキシ設定を確認してください。
ルールの判定結果を確認する。対象ドメインが最終的にDIRECT、PROXY、REJECTのどれへ進んだかを確認し、対応するプロキシグループで利用可能なノードが選択されているか確認します。
ノードを切り替えて比較する。同じプロキシグループ内のノードだけを変更し、DNS、モード、設定は同時に変更しないでください。別のノードで正常になるなら、元のノードまたはその出口回線に問題がある可能性が高くなります。
ルールモードとグローバルモードを比較する。グローバルモードでは正常なのにルールモードで異常が出る場合は、ルールの判定、プロキシグループの参照、ルールセットの更新を確認する必要があります。
DNSを確認する。ドメイン名の解決失敗、異常なアドレスの返却、プロキシルールと合わない名前解決経路などが、ウェブページを開けない原因になることがあります。ドメインへのアクセスと既知のIPアドレスへの接続を比較することはできますが、一時的なIPアドレスを恒久的な解決策として使わないでください。
接続先サービスの状態を確認する。1つのサイトだけに問題がある場合は、接続先のメンテナンス、地域制限、アカウント状態、出口IPアドレスの拒否が原因の可能性もあります。

ログにタイムアウトが出ている場合は、プロキシサーバーへの接続がタイムアウトしたのか、DNSクエリがタイムアウトしたのか、プロキシサーバーから接続先への接続がタイムアウトしたのかを切り分ける必要があります。3つは異なる段階にあるため、対処方法も異なります。ブラウザーに最後に表示されたエラーページだけでは、原因を特定できないことがほとんどです。

10. 再起動後に接続できない場合、どうすればすぐに復旧できる？

まず、ウィンドウが開いていることだけでなく、クライアントのコアが起動しているか確認します。続いて、現在の設定が残っていて有効になっているか、サブスクリプションが空の設定になっていないか、主要なプロキシグループに利用可能なノードがあるかを確認します。OSの再起動後は、システムプロキシが自動的に有効になっていない場合があります。TUNを利用しているなら、権限要求、サービスコンポーネント、仮想NICの状態も確認してください。

「変更を最小限にする」方法で復旧できます。一時的にTUNを無効にしてシステムプロキシだけを有効にし、直近で利用できることを確認した設定を選び、ルールモードを使用します。主要なプロキシグループで利用可能なノードを手動選択し、最後にブラウザーでテストしながら接続履歴を確認します。この組み合わせで正常になったら、自動選択、TUN、カスタムDNS、オーバーライド設定を1つずつ戻してください。

クライアントがコアを起動できない場合は、エラーログにポート競合、設定の解析失敗、権限不足がないか確認します。ポートが使用中でも、複数のリスニングポートを無計画に変更し続けないでください。まずほかのプロキシソフトを終了して再起動します。設定の解析に失敗した場合は、利用可能な設定へ戻すか、直近のオーバーライド変更を取り消します。権限の問題は、OSの指示に従ってTUNサービスやネットワーク拡張の許可を処理してください。

Checklist

初回利用時のチェックリスト

インストールとサブスクリプションの追加が完了したら、次の順番で確認します。前の項目を確認できるまでは、DNSやルーティングの複雑な調整に進まないでください。

クライアントのコアが動作しており、設定の解析エラーがない。
サブスクリプションがダウンロードされ、対応する設定が現在の設定として選択されている。
プロキシ画面にプロキシグループが表示され、グループ内にノードが存在する。
遅延テストまたは実際の接続を完了できるノードを少なくとも1つ選択する。
日常利用ではまずルールモードを使い、主要なプロキシグループの選択を確認する。
システムプロキシを有効にし、ブラウザーで最初の接続テストを行う。
接続履歴で対象ドメイン、一致したルール、最終出口を確認する。
アプリがシステムプロキシを無視する場合に限り、TUNを有効にするか検討する。
サブスクリプション更新後にプロキシグループを再確認し、ノード名の変更で選択が無効になっていないか確認する。
異常が発生したら重要なログを保存し、通信の取り込み、ルール、ノード、DNS、接続先サービスの順に原因を切り分ける。

これらの階層を理解すれば、「ノードを選んだのに効果がない」「ブラウザーは正常なのにゲームだけつながらない」「グローバルでは使えるのにルールモードでは失敗する」といった問題も、検証可能な手順に分解できます。Clashの核心は単一のスイッチではなく、設定の取得元、通信の入口、ルール判定、出口ノードで構成される処理チェーンです。接続履歴を確認し、各層を順番に検証するほうが、クライアントを何度も再インストールするより原因を見つけやすくなります。