Clash 設定ガイド：サブスク登録から動作確認まで

Clash クライアント自体は回線を一切持っておらず、使えるノードはすべてサブスクから取得します。そのため設定の第一歩は常にサブスクの登録です。サブスクリンクはサービス提供元が発行し、https://sub.example.com/api/v1/client/subscribe?token=xxxx のような形式をとります。1本のリンクがプロキシノード、プロキシグループ、分流ルールを含む完全な YAML ファイルを返します。登録の前にリンクを最後までコピーしてください。登録に失敗する原因の多くはクライアント側ではなく、チャットアプリやメールでリンクが途中で切れ、末尾の token パラメータが数文字欠けた状態になっていることです。その場合クライアントが受け取るのは無効なレスポンスになります。

各クライアントの登録入口は次のとおりです。

• Clash Verge Rev（Windows / macOS / Linux）：左サイドバーの「サブスク」をクリックし、上部の入力欄にリンクを貼り付けて Enter キーを押すか「インポート」をクリックします。クライアントはすぐにサブスクアドレスへリクエストを送信します。
• Clash Plus（Windows / macOS / Android / iOS）：メイン画面で「サブスク」グループを開き、右上の「サブスクを追加」をクリックしてリンクを貼り付け、確定します。モバイル版では初回にネットワーク権限を求められ、許可して初めて設定がダウンロードされます。
• Clash Meta for Android：左側のドロワーから「設定」を開き、右下の＋をタップして「URL からインポート」を選び、リンクを貼り付けて判別しやすい名前を付けます。
• ClashX Meta（macOS）：メニューバーアイコンをクリック →「設定」→「管理対象設定」→「管理」と進み、ダイアログの Add をクリックして URL 欄にリンクを貼り付け、確定後にメニューへ戻ってこの設定を選択します。

登録成功の目安は3つあります。設定一覧に新しい項目が追加されること、その項目を展開するとノードやプロキシグループが表示されること、解析エラーが表示されないことです。3つすべて満たせば次のステップに進めます。「設定の解析に失敗しました」と表示される場合や一覧が空のままの場合は、まずブラウザでサブスクリンクを直接開いてください。YAML のテキストが返ればリンク自体は正常で、原因はクライアントのバージョンにあります。base64 の文字列やウェブページが返る場合は、提供元が汎用フォーマットを出力しているかリンクが失効しています。提供元の管理画面で Clash 形式に切り替えてから、リンクをコピーし直してください。

登録が終わったら、ついでに自動更新をオンにしておくのがおすすめです。サブスク内のノードは不定期に差し替わるため、一覧の設定を更新しないままだと数日後にまとめてタイムアウトすることがあります。Clash Verge Rev は設定項目の右クリックメニュー、Clash Plus はサブスクの詳細ページで更新間隔を設定できます。24時間を指定しておきましょう。手動更新も同じ右クリックメニューまたは詳細ページから行えます。ノードが広範囲で使えなくなったときは、他の原因を疑う前にまずサブスクを一度更新してください。

設定を登録すると、クライアント内にはノード、プロキシグループ、ルールの3つが同時に存在します。通信の流れ方を決めるのがプロキシモードで、主要なクライアントには4つの選択肢があります。

• ルールモード（rule）：デフォルトの選択肢で、普段もこのモードのままにしておきます。クライアントは設定の rules セクションを上から順に照合し、ヒットしたルールが指すプロキシグループに処理を渡します。どれにもヒットしなかった通信は末尾の MATCH が受け止めます。中国本土のサイトを直接接続、海外のサイトをプロキシ経由にする分流はこのモードが担います。
• グローバルモード（global）：すべての通信が現在選択中のプロキシグループを通り、ルールは完全に無視されます。使うのは次の2つの場面だけです。特定のノードが使えるかを単体でテストするとき、そしてあるサイトがルールの誤判定で直接接続になっていないかを確かめるときです。
• ダイレクトモード（direct）：すべての通信がプロキシを通りません。ローカルネットワークを一時的に元に戻したいがクライアントは終了したくない、というときに切り替えます。クライアントを終了して起動し直すより手早く済みます。
• スクリプトモード（script）：JavaScript でプロキシの選択を動的に書き換えるモードです。一部のカーネルだけが対応しており、通常の利用では触れる必要はありません。

設定場所はクライアントによって異なります。Clash Verge Rev は「プロキシ」ページ上部のモードドロップダウン、Clash Plus はメイン画面上部のモード切り替え、Clash Meta for Android は下部ナビの「プロキシ」ページ右上、ClashX Meta はメニューバーの「アウトバウンドモード」サブメニューです。

モードに加えて理解しておきたいのがプロキシグループです。プロキシページでは各プロキシグループが1枚のカードとして表示され、カード内に選択可能なノードや子グループが並び、上部に現在選択中の項目が表示されます。ルールモードであるルールにヒットすると、実際の出口はそのルールが指すプロキシグループで現在選択されているノードが決めます。つまり「ルールモード + 自動選択グループ」が普段もっとも手間のかからない組み合わせです。ルールがこの接続でプロキシを使うかどうかを、自動選択グループがどのノードを使うかを決めます。グループ内で手動でノードを選ぶと自動選択は上書きされるため、次にそのノードが使えなくなったときは手動で戻す必要があります。

設定ファイルでは、対応するフィールドは次のようになります。

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

クライアント画面でモードを切り替えるとすぐに反映され、カーネルの再起動は不要です。config.yaml を直接編集してクライアントに読み込ませる場合は、設定を再読み込みするかカーネルを再起動しないと新しい値が反映されません。モードを切り替えたら「接続」ページに戻っていくつか記録を確認し、新しいモードでの通信の流れが想定どおりであることを確かめてから次のステップに進みましょう。

モードは分流の方式を決めるだけなので、システムの通信をクライアントに引き受けさせる必要があります。Clash クライアントには2つの方式があり、どちらか一方を有効にします。

システムプロキシ：OS にクライアントのローカル待受ポートを指す HTTP/HTTPS プロキシ設定を書き込みます。有効化が速く追加の権限も不要で、ブラウザやほとんどのデスクトップアプリをカバーします。一方、システムプロキシの設定を読まないアプリ（一部のコマンドラインツール、ゲーム、ストアアプリ、コンテナなど）には効きません。有効化する場所は、Clash Verge Rev が「設定」ページの「システムプロキシ」スイッチ、Clash Plus がメイン画面下部の「システムプロキシ」スイッチ、ClashX Meta がメニューバーの「システムプロキシとして設定」です。

TUN モード：クライアントが仮想ネットワークアダプタを作成し、IP 層でマシン全体の通信を引き受けます。すべてのアプリが対象になります。その代わり管理者権限が必要で、Windows では初回有効時にシステムサービスをインストールして起動する必要があり、macOS ではネットワーク拡張の承認が求められます。さらに DNS を正しく設定しないと、名前解決の異常や一部ドメインが開けないといった問題が起きやすくなります。有効化する場所は、Clash Verge Rev が「設定」ページの「TUN モード」スイッチで、初回はサービスのインストールが案内されます。Clash Meta for Android は「設定」→「ネットワーク」→「TUN」、ClashX Meta はメニューバーの「拡張モード」です。

2つの方式を同時に有効にしないでください。システムプロキシの設定と仮想ネットワークアダプタが同時に効くと通信経路が重なり、一部のリクエストは正常、一部はタイムアウトという症状が出て、原因の切り分けに時間がかかります。普段はシステムプロキシを使い、特定のアプリで効かないときに TUN へ切り替えましょう。

ポート設定：クライアントは既定でいくつかのローカルポートを待ち受けます。7890（HTTP と SOCKS5 の混合）、7891（SOCKS5）、7892（Redir）、9090（外部コントロール API）です。ポートが他のアプリに使用されていると、クライアントの起動に失敗したり、システムプロキシのスイッチがオンにできなくなったりします。使用状況を確認するコマンドは次のとおりです。

# Windows
netstat -ano | findstr :7890

# macOS / Linux
lsof -i :7890

使用中のプロセスを確認したら、設定の mixed-port を 7897 などの空いているポートに変更し、設定を再読み込みしてからシステムプロキシをいったんオフにして再度オンにします。OS 側のプロキシ設定はポート変更に自動追従しないため、オフにしてからオンにしないと新しいポートが書き込まれません。

LAN 内での共有：allow-lan: true にすると、同じネットワーク内の他の端末がこのマシンをプロキシとして利用できます。ファイアウォールの許可と bind-address の設定も合わせて行います。1台だけしか使わない場合は false のままで問題ありません。

接続が確立したら、スイッチの色だけで判断せず、次の4項目を順に確認してください。

1. 接続ページにリアルタイムの記録がある。クライアントの「接続」ページを開き、適当なウェブページを再読み込みすると、対応する接続エントリが一覧に表示されます。各記録にはヒットしたルール、使用中のプロキシグループ、出口ノード、送受信バイト数が表示されます。一覧がずっと空のままなら、通信がそもそもクライアントに届いていません。原因はノードではなく、システムプロキシや TUN が実際に有効になっているかどうかです。
2. 出口アドレスが変わる。ブラウザで任意の IP 確認サイトにアクセスし、表示される所在地がローカルの通信事業者ではなく、選択したノードと一致していることを確認します。この手順で、通信が実際にリモートを経由していることを確かめられます。
3. 分流が想定どおり。「接続」ページに戻り、具体的なドメインがどのルールを通ったかを確認します。中国本土のサイトは直接接続系のルールに、海外のサイトはプロキシグループにヒットするのが正常です。中国本土のサイトが大量にプロキシ経由になっている場合は、ルールセットが読み込まれていないか GEOIP データが欠けています。サブスクを一度更新すればたいてい復旧します。逆に海外のサイトが直接接続になっている場合は、ルールの順序に範囲が広すぎるルールが先にヒットしていないか確認してください。
4. ログにエラーが繰り返し出ていない。ログレベルを info または debug にしてしばらく観察します。正常なログは接続の確立と切断の記録です。DNS 解決の失敗、接続の拒否、TLS ハンドシェイクのタイムアウトが繰り返し出る場合は、ノードか DNS の設定に問題があります。ノードの選択や DNS の設定に戻って確認してください。

コマンドラインでの確認（任意）：

curl -s -x http://127.0.0.1:7890 https://api.ipify.org

返ってくるアドレスはノードの出口アドレスであるはずです。curl がタイムアウトするのにブラウザでは正常にアクセスできる場合、そのターミナルがシステムプロキシを引き継いでいないことを意味します。これは正常な動作で、コマンドラインツールはプロキシの引数を明示的に指定するか、TUN モードに切り替える必要があります。

確認が通れば、普段の利用でクライアントを触ることはほとんどありません。あとはサブスクの更新を保つこと、ノードが使えなくなったらプロキシグループ内で別のものに切り替えること、ときどきログを眺めることくらいです。より踏み込んだ設定項目、たとえば DNS と Fake-IP の仕組み、ルールの文法と優先順位、rule-providers の構造、TUN スタックの選択などは、10分で使い始める範囲を超えています。「はじめにから応用まで」の長編記事にまとめてあるので、章ごとに参照してください。