Clash初心者向け10問10答：サブスクリプション、ノード、プロキシモードを徹底解説

1. Clashはノードサービス？サブスクリプションURLの入手先

Clash、Clash Meta（現在は通常 mihomo と呼ばれます）、そして各種GUIクライアントは、設定の読み込み、ルールの照合、接続の転送を行います。これら自体がノードを提供するわけではなく、インストール後にサブスクリプションが自動生成されることもありません。サブスクリプションURLは、利用しているサービスの提供元で発行します。通常はサービスの管理画面にある「サブスクリプション」「ワンクリック購読」「クライアントへのインポート」などのページから取得できます。

サブスクリプションでは通常、YAML形式の設定またはエンコードされたノード一覧が返されます。完全なClash設定には、サーバーアドレスだけでなく、プロキシグループ、ルールセット、DNS、TUNのパラメータなどが含まれる場合があります。単一ノードの共有URLしかない場合は手動でインポートできますが、プロキシグループとルーティングルールは別途設定が必要です。

URLを取得したら、まず3点を確認

サービスの管理画面で提供されている形式がClashまたはClash Meta形式であり、他のクライアント専用形式ではないことを確認します。
コピー時は https://、パス、クエリパラメータ、トークンを含む完全なURLを保持し、末尾の文字を落とさないでください。
まずブラウザーでサービスの管理画面にアクセスし、アカウントとサブスクリプションが有効か確認します。ログインページのURLをサブスクリプションURLと取り違えないでください。

2. サブスクリプションのインポート方法と、更新が必要な理由

GUIクライアントによって項目名は少し異なりますが、操作の流れはほぼ同じです。一般的な画面では「サブスクリプション」→「新規サブスクリプション」と進み、URLを貼り付け、分かりやすい名前を入力してから「保存して更新」を選びます。別の画面では「設定」→「新規」→「URL」と表示されることもあります。インポートが成功すると、更新日時、設定ファイル名、プロキシ数を確認できます。

「保存」はURLを記録するだけで、「更新」を実行して初めてリモートの内容が取得されます。初回インポート後にノード一覧が空になる場合、URLを保存しただけで更新していないことが最もよくある原因です。自動更新間隔は、サービスが許可する範囲内で、たとえば1,440分に1回程度に設定するのがおすすめです。5分間隔にしても回線が安定するわけではなく、サーバー側のリクエスト制限にかかる可能性があります。

更新に失敗したときの確認手順

エラーが 401 または 403 か確認します。トークンの期限切れ、アカウント状態の異常、またはリクエスト拒否を示していることが多いです。
404 が表示されたらサブスクリプションURLをコピーし直し、パスとクエリパラメータが完全か重点的に確認します。
接続がタイムアウトした場合は、いったん現在のプロキシを無効にして再度更新します。直接接続でサーバーにアクセスできない場合は、利用可能な古い設定を一時的に有効にして更新を試します。
更新後もノード数が0の場合は、取得したものがYAMLやノード一覧ではなく、WebページのHTMLになっていないか確認します。
設定の解析エラーが出たら、ログに表示された行番号を確認します。サーバーから互換性のないフィールドが返されている場合は、Clash Meta形式に切り替えるか、mihomoカーネルを更新してください。

3. サブスクリプションのインポート後もノードが表示されない理由

まず「サブスクリプションが存在すること」と「現在の設定が有効になっていること」を分けて考えます。多くのクライアントでは複数の設定を保存できますが、同時に読み込めるのは1つだけです。「サブスクリプション」または「設定」ページで更新した設定を選び、「有効化」「現在の設定にする」「切り替え」などを実行します。その後「プロキシ」ページを開き、ポリシーグループにノードが表示されるか確認します。

設定が有効なのに選択肢がない場合は、ルールだけが定義され、proxies または proxy-providers が定義されていない可能性があります。プロキシプロバイダーの初回取得が完了していない場合もあります。provider設定なら「プロキシプロバイダー」ページから手動更新するか、ログでprovider名を検索してください。

画面上の状態	よくある原因	対処方法
サブスクリプションカードはあるが、プロキシページが古いノードのまま	新しい設定が現在の設定になっていない	新しい設定を選択して有効化または切り替えを実行
プロキシグループはあるが、グループ内が空	プロキシプロバイダーの取得に失敗している	providerを手動更新してログを確認
更新時に解析エラーが表示される	YAMLのインデント、フィールド、形式に互換性がない	サブスクリプション形式を切り替えるか、mihomoカーネルを更新
DIRECTとREJECTしかない	利用可能なプロキシ定義が設定に含まれていない	サービスの管理画面からエクスポートした設定形式を確認

4. ノードがすべてタイムアウトする理由と、遅延の見方

遅延テストは、ノードサーバーへ単純なネットワーク探査を1回行うだけのものではありません。Clashは通常、そのノード経由でテストURLへリクエストを送り、接続確立からレスポンス受信までの時間を計測します。そのため「タイムアウト」は、ローカルネットワーク、ノードの入口、テスト対象サイト、DNS名前解決、TLSハンドシェイクのいずれでも発生する可能性があります。

まずは3つのノードだけを個別にテストし、数十本の回線へ一度にリクエストを送るのを避けます。よく使われるテストURLは https://www.gstatic.com/generate_204 で、タイムアウトはまず5,000ミリ秒に設定します。このアドレスに現在のネットワークから到達できない場合は、サービス提供元が案内するHTTP 204検知用アドレスに変更してください。そうしないと、すべてのノードが同時にタイムアウトと表示されることがあります。

遅延結果を実用的に判断する目安

50〜120ミリ秒：Web閲覧、メッセージング、通常の動画視聴に適しています。
120〜250ミリ秒：通常利用には問題ありませんが、リアルタイム音声やリモートデスクトップでは反応の遅さを感じることがあります。
500ミリ秒超：別の回線に切り替えて再テストし、パケットロスや頻繁な切断がないか確認します。
常に0ミリ秒：実測値ではないことが多く、テストが実行されていないか、画面が更新されていない可能性があります。
すべてTimeout：まず直接接続のネットワークをテストし、次にシステム時刻、DNS、カーネルログ、テストURLを確認します。

5. ルール・グローバル・直接接続モードの選び方

初心者の日常利用では、まずルールモードを選ぶのがおすすめです。ルールモードは、ドメイン、IP、プロセス、ルールセットを上から順に照合し、接続を指定されたポリシーグループへ渡します。中国本土のサービスは直接接続し、プロキシが必要な接続だけノードを経由させるなど、LANや特殊なアドレスも設定に応じて個別に処理できます。

モード	接続の処理方法	適した用途
Rule	ルールを上から順に照合し、マッチしたルールのポリシーを使用	日常利用と常時運用
Global	プロキシ可能な接続の大部分をグローバルポリシーグループへまとめて渡す	アクセス失敗の原因がルーティングルールか一時的に確認する
Direct	プロキシノードを経由せず、接続を直接送信	プロキシの一時停止、ローカルネットワークのテスト、サブスクリプションの更新

特定のWebサイトがルールモードで開けない場合は、短時間だけグローバルモードに切り替えてテストします。グローバルモードで利用できるなら、ノード自体は正常である可能性が高いため、そのドメインにどのルールが適用されたか確認します。グローバルモードでも失敗する場合は、ノード、DNS、接続先サイトの状態を引き続き確認してください。テスト後はルールモードに戻し、すべての接続を同じノードへ集中させないようにします。

ログに記録されるルールのマッチ情報は重要です。ログレベルを一時的に info に設定して対象サイトへ再アクセスし、ドメインが最終的に DIRECT、REJECT、または特定のプロキシグループのどれに入ったか確認します。調査後も debug を常用する必要はありません。詳細ログはファイルサイズを急速に増やします。

6. システムプロキシとTUNモードの違い

システムプロキシは、OSにHTTPおよびSOCKSプロキシのアドレスを書き込みます。システムプロキシ設定に従うブラウザーやアプリはClashへ接続を送ります。たとえば、ローカルでよく使われるmixedリスニングアドレスは 127.0.0.1:7890 です。設定が簡単でオン・オフもしやすい一方、一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワークスタックを持つソフトウェアはシステムプロキシを無視することがあります。

TUNモードは仮想ネットワークインターフェースを作成し、ルーティングによってより多くのTCP、UDP、DNSトラフィックを取り込みます。手動でプロキシを設定できないアプリに適していますが、仮想ネットワークアダプターの作成やルート変更の権限をOSから付与する必要があります。Windowsクライアントでは通常、先にサービスモードをインストールします。macOSではネットワーク拡張機能の権限が求められ、Linuxでは適切なネットワーク管理権限が必要です。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

上記はmihomo設定でよく使われるTUN構造です。実際に利用できるフィールドは、カーネルのバージョンとクライアントの管理方法によって異なります。GUIクライアントがこれらのパラメータを管理している場合は、まず「設定」→「ネットワーク設定」→「TUNモード」から有効にしてください。画面設定とサブスクリプションの上書き設定で、互いに矛盾する2つの設定を同時に管理しないようにします。

初心者向けの選び方

ブラウザーと一般的なデスクトップアプリだけ使う：まずシステムプロキシを有効にします。
ゲーム、ターミナル、またはシステムプロキシを読み取らない特定のアプリ：TUNを有効にします。
TUN有効化後にネットワークが切れた：TUNを無効にして通信を復旧し、サービスモード、ルーティング、DNSログを確認します。
一部のクライアントではシステムプロキシとTUNを連携管理できますが、複数のツールを別途インストールしてルーティングを重複管理しないでください。

7. 7890、7891、9090ポートの役割

ポートは、ローカルのプログラムがClashカーネルへ接続するための入口です。設定の mixed-port: 7890 はHTTPとSOCKSのプロキシ接続を同時に受け付けるため、ほとんどのデスクトップクライアントに適しています。古い設定では、HTTPを7890、SOCKSを7891に割り当てることがあります。external-controller: 127.0.0.1:9090 はGUIからカーネルを制御するためのもので、一般アプリに入力するプロキシポートではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

アプリからプロキシアドレスの入力を求められた場合は、ホストに 127.0.0.1、mixedポートに 7890 を指定できます。ブラウザーのプロキシ設定に 9090 を入力しないでください。LANにプロキシを共有する場合は、allow-lan を明示的に有効にしてリスニングアドレスを設定し、OSのファイアウォールで接続元を制限します。ローカルでのみ使うなら、無効のままにする方が管理しやすいです。

起動ログに address already in use と表示される場合、そのポートは別のプロセスが使用中です。「設定」→「パラメータ設定」でmixedポートを変更し、たとえば7890から7893にしてからカーネルを再起動します。変更後は、プロキシポートを手動設定していたブラウザー、ターミナル、その他のアプリも同じように更新してください。

8. ブラウザーは使えるのに、他のアプリが直結またはオフラインになる理由

ブラウザーでアクセスできるのは、そのブラウザーの接続がClashに入っていることを示すだけで、端末全体の通信が取り込まれているとは限りません。まずブラウザーに専用のプロキシ拡張機能が入っていないか確認します。拡張機能が 127.0.0.1:7890 を直接指定している場合、システムプロキシを無効にしてもブラウザーだけClashを使い続け、他のアプリは直接接続することがあります。

アプリの種類ごとに確認

一般的なデスクトップアプリ：「システム設定」→「ネットワークとインターネット」→「プロキシ」で、クライアントがアドレスとポートを正しく設定しているか確認します。
コマンドラインツール：ツールが HTTP_PROXY、HTTPS_PROXY、ALL_PROXY の環境変数を読み取るか確認します。
ゲームとUDPアプリ：通常のシステムHTTPプロキシでは対応できないため、UDP対応ノードを使い、TUNを有効にします。
Windowsストアアプリ：一部のUWPアプリはループバック制限の影響を受けるため、対象アプリにループバック免除を設定する必要があります。
仮想マシンとコンテナ：内部の 127.0.0.1 は仮想環境自身を指すため、そのままホスト側のアドレスとしては使えません。

調査時はクライアントの接続一覧を開き、対象アプリから新しいリクエストを1回送ります。一覧に該当するドメインやプロセスがまったく表示されないなら、通信はまだカーネルに入っていません。接続が表示されても失敗する場合は、ルールのマッチ、ノード、DNSを確認します。この切り分けにより、「通信の取り込み」と「プロキシ」の問題を何度も行き来せずに済みます。

9. ルールが効かない理由と、カスタムルールの配置場所

Clashのルールは設定に記載された順番で上から下へ照合され、通常は最初にマッチしたルールで処理が止まります。そのため、より具体的なカスタムルールは広範なルールより前に置き、最後の MATCH ルールよりも前に配置する必要があります。MATCH の後ろに追加しても効果はありません。

rules:
  - DOMAIN,api.example.com,Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN は完全一致のドメインだけを照合し、DOMAIN-SUFFIX はそのサフィックスとサブドメインにマッチします。IP-CIDR はネットワーク範囲に使用します。末尾の no-resolve は、マッチングのためにドメインを能動的に名前解決しないことを示します。ルール末尾のポリシー名は、proxy-groups 内のグループ名と大文字・小文字や空白を含め完全に一致させてください。

サブスクリプションを更新すると元のYAMLが上書きされることが多いため、サブスクリプションファイルを直接編集するのはおすすめできません。上書きに対応したクライアントには通常、「サブスクリプション」→「上書き」または「設定」→「設定を統合」といった入口があります。ここからカスタムルールをリモートルールより前に挿入できます。保存後に設定を再読み込みし、接続ログで実際にマッチしたルールを確認してください。

10. プロキシが有効か確認する方法と、終了前の注意点

接続が有効かどうかをクライアントのスイッチだけで判断しないでください。まず直接接続モードで現在の出口情報を記録し、次にルールモードへ切り替えてノードを選び、確認ページを再度開きます。出口アドレスと地域が想定どおり変わり、クライアントの接続一覧にも該当ドメインが表示されれば、そのリクエストはプロキシを経由しています。

続いてDNSとルールを確認します。クライアントのログを開き、直接接続されるはずの中国本土のサイトと、プロキシ経由にする対象へアクセスし、それぞれ DIRECT と指定したプロキシグループにマッチすることを確認します。Fake-IP使用時に、アプリ側で 198.18.0.0/15 範囲のマッピングアドレスが表示されるのは一般的な動作です。実際のドメインはカーネルがマッピングを保持し、ルール照合に利用します。

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

現在の設定が有効で、サブスクリプションの更新日時とノード数が正常。
モードがRuleに設定され、対象ポリシーグループで利用可能なノードが選択されている。
システムプロキシまたはTUNの少なくとも一方が有効で、実際のアプリ種別に合っている。
接続一覧に対象リクエストが表示され、ルールのマッチ結果が想定どおり。
カーネルログにポート競合、DNSタイムアウト、provider更新失敗が継続的に記録されていない。
クライアントを終了するときは、システムプロキシとTUNのルートも同時に復元し、無効なプロキシアドレスがシステムに残らないようにします。

Clashを終了した後にWebページがすべて開けなくなった場合は、まずシステムのプロキシ設定でプロキシが無効になっているか確認します。TUNの異常が続く場合は、クライアント終了後にネットワークへ再接続し、必要に応じてシステムを再起動してルーティングを復旧します。再起動前に、7890を同時にリッスンしたりデフォルトルートを取り込んだりするプロキシクライアントを複数起動しないでください。

初心者のトラブル対処は、順番を固定するとスムーズです。まずローカルネットワーク、次にサブスクリプションの更新、設定の有効化、ノードへの接続、モードとポリシーグループ、最後にシステムプロキシまたはTUNによるアプリ通信の取り込みを確認します。一度に変更する項目を1つに絞り、接続一覧とログで結果を検証する方が、クライアントを何度も再インストールするより早く解決できます。