Clash 完全ガイド:基本概念からインストール、サブスクリプション、ルール分流、TUNモードまで

Clash は設定ファイル駆動型のルールベース・プロキシコアです。それ自体にグラフィカルなインターフェースはなく、起動時に YAML 形式の設定ファイルを読み込み、ローカルの複数ポートで待ち受けます。これらのポートに入ってくる通信をルールに従って上から順に照合し、そのコネクションを直接接続にするか、どのプロキシノード経由にするか、あるいは拒否するかを決定します。各種クライアントで見かけるオン/オフスイッチ、ノード一覧、モード切り替えは、すべてこの設定ファイルとマッチング処理を包んだものにすぎません。これを理解しておくと、以降の章がすっと理解できるようになります。

オリジナルの Clash コアは開発が終了しており、現在事実上の標準になっているのはコミュニティが引き継いだ Mihomo コア(Clash Meta と呼ばれることも多い)です。Mihomo は既存の設定形式に完全対応したうえで、より多くのプロキシプロトコル、ルールタイプ、DNS機能を追加しています。本サイトのクライアント一覧ページに掲載しているソフトウェアは、Mihomo を内蔵しているか、その設定形式と互換性があるものです。そのため本ガイドの例も基本的に Mihomo の挙動を前提としています。

クライアントとコアは別物です。コアが実際の通信転送を担い、クライアントはコアの管理役——サブスクリプションのダウンロード、設定生成、コアプロセスの起動、システムプロキシの設定、ノード遅延の表示などを行います。クライアントを変えてもコアの理解には影響しませんし、設定ファイルはクライアント間でおおむね共通なので、先に概念を理解してからソフトを選ぶのが理にかなっています。

設定ファイルは大きく5つの要素からなります:ポート宣言、ノード一覧(proxies)、プロキシグループ(proxy-groups)、ルール(rules)、DNS設定です。骨格は以下の通りです:

mixed-port: 7890        # HTTPとSOCKSを兼用する混合リスニングポート
mode: rule              # 動作モード:rule / global / direct
log-level: info

proxies: []             # ノード一覧、通常はサブスクリプションで自動入力される
proxy-groups: []        # プロキシグループ:ノードを選択可能な単位にまとめる
rules:                  # ルール:上から順に照合し、最初に一致した時点で確定
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ルールエンジンのマッチング方式には鉄則が一つだけあります——上から順に照合し、最初に一致したルールがそのコネクションの行き先を決定し、以降のルールは無視されます。つまりルールの順序=優先順位であり、精密なルールを上に、包括的なルール(兜底)を最後に置くという原則は、第6章全体を通じて貫かれます。

プロキシグループは、Clash が単純なプロキシツールとは一線を画す重要な抽象化です。ルールの出口は特定のノードを直接指すのではなく、あるグループを指します。グループ内でどのノードを使うかを決める仕組みで、手動選択も、遅延に基づく自動選択も可能です。サブスクリプションの更新やノードの増減はグループ内部で処理され、ルール自体を変更する必要がないため、長期的に保守しやすい設定になります。

最後にポートについて:コアはデフォルトでローカルループバックアドレス 127.0.0.1 のみで待ち受けます。ブラウザやシステムプロキシがこのポートに通信を渡すことで、コアが実際に動作し始めます。ポート番号やリスニングアドレスは変更可能ですが、LAN共有をする場合のみ開放が必要になります。詳細は第5章で解説します。

クライアントを選ぶ前に3つの質問に答えましょう:どのOSを使っているか、TUNモードで全トラフィックを乗っ取りたいか、設定に時間をかける気があるか。この3点が明確になれば、選択肢は自然と絞られます。以下は本サイトのダウンロードページに掲載しているクライアントの早見表で、クライアント一覧ページと内容は一致しています:

Clash Plus は全プラットフォームで最初に検討すべき選択肢です。Windows、macOS、Android、iOSの4環境をカバーし、リストの中でApp Storeに掲載されている唯一の存在——iOSユーザーにとってはこれ以外の正規ルートがありません。サブスクリプション、モード、ノード選択がひとつのメニューにまとまっており、デフォルト設定は初心者に優しく、上級者向けオプションも削られていないため、最初のクライアントとして適しています。

Clash Verge Rev は Linux デスクトップの主力であり、本ガイドの Linux 例のデフォルトとしても採用しています。Mihomo コアを直接内蔵し、deb・rpm パッケージを提供、設定の上書き(Override)、Mergeスクリプト、サービスモードに対応しており、TUN関連の権限処理も比較的完成度が高いです。設定を深く追求したいユーザーには、細部まで見えるこのクライアントが向いています。

FlClash はFlutterで書かれており、デスクトップとモバイルのUIがほぼ同一です。スマホとPCを頻繁に切り替えて操作感を統一したい人には最も気楽な選択肢です。Clash Nyanpasu は Windows 向けの別の活発な派生版で、UIはより軽快、機能面は Verge Rev に近く、代替候補として十分信頼できます。

Android では Clash Plus のほかに、Clash Meta for Android がコアのネイティブな挙動に最も近く、設定項目がコアのフィールドに直結しているため、内部構造を把握したいユーザーに向いています。Surfboard は軽量志向で、サブスクリプションを導入すればすぐに使えます。Clash for Windows と ClashX Meta はいずれも開発終了済みで、既存ユーザーは手元のバージョンを使い続けることはできますが、新規インストールにはおすすめしません。

サーバーやルーターの用途ではGUIは不要で、Mihomo コア単体を直接デプロイします。1つのバイナリファイルと1つの設定ディレクトリで長期稼働が可能で、systemdでプロセス管理を行います。詳細は第8章・第9章で解説します。

すべてのインストールパッケージはクライアント一覧ページの各プラットフォーム用カードからダウンロードします。Linux ユーザーはまずディストリビューションとCPUアーキテクチャを確認してください:主流のデスクトップディストリビューションは基本的に x86_64(amd64)です。ダウンロード時はパッケージ名内のアーキテクチャ表記をよく確認し、arm64版をIntel/AMDマシンに入れないよう注意してください。

Ubuntu / Debian 系

.debパッケージをダウンロードしたら apt でローカルインストールします。apt は依存関係を自動的に解決・補完するため、dpkg で直接インストールするより依存関係のトラブルを避けられます:

sudo apt update
sudo apt install ./clash-verge-rev_amd64.deb

コマンド内の ./ は省略できません。これはaptに「これはリポジトリ内のパッケージ名ではなくローカルファイルだ」と伝えるためのものです。インストール完了後はアプリ一覧にアイコンが表示されるほか、ターミナルでプログラム名を入力して起動することもできます。

Fedora 系

sudo dnf install ./clash-verge-rev.rpm

dnf も同様に依存関係を処理してくれます。webkit2gtk のようなコンポーネントが不足していると表示された場合は、案内通りにインストールを許可してください。これはGUIの描画に必要なシステムライブラリであり、ソフトウェア自体の問題ではありません。

Arch 系

# ビルド済みバイナリパッケージがある場合はローカルインストール
sudo pacman -U clash-verge-rev.pkg.tar.zst

# またはAURからビルド(paruを例に)
paru -S clash-verge-rev

AUR経由の利点は今後のアップグレードがシステムのローリングリリースに追従することですが、ビルドに時間がかかるという欠点もあります。どちらの方法でも出来上がるものは同じなので、好みで選んでください。

その他のプラットフォーム

Windows はインストーラーをダブルクリックし、案内に従って完了させます。初回起動時にファイアウォールがネットワークアクセスの許可を求めてくるので許可してください。許可しないとコアがポートを待ち受けできません。macOS はアプリを「アプリケーション」フォルダにドラッグします。初回起動時にシステムにブロックされた場合は「システム設定 → プライバシーとセキュリティ」から「このまま開く」をクリックしてください。ダウンロード前に Apple Silicon 版か Intel 版かを見分けておきましょう。Android は APK を直接インストールし、「不明なアプリのインストール」権限を求められたら、ブラウザやファイル管理アプリに一度許可を与えれば完了です。iOS は App Store で Clash Plus を検索してインストールします。

初回起動時の確認事項

どのプラットフォームでも、初回起動後に1分ほどかけて次の3点を確認してください。1つ目、トレイやステータスバーにプログラムのアイコンが表示されていること——メインプロセスが正常に動いている印です。2つ目、クライアントのログ画面を開き、コアの起動ログが表示されていて赤いエラーが出ていないこと。3つ目、設定画面で「起動時に自動起動」を見つけ、必要に応じてオンにすること。Linux デスクトップユーザーで、クライアントに「サービスモード」の提供があれば、この時点でインストールしておくのがおすすめです——十分な権限でコアを起動するシステムサービスを登録してくれるもので、第7章のTUNモードで使用します。

サブスクリプションとは本質的にはURLです。サービス提供者がノード一覧(通常は完全なClash設定、あるいはクライアントが変換できるノードリスト)をこのアドレスに置き、クライアントが定期的にそれを取得します。取得した内容はローカルの設定ファイルとして保存され、コアに読み込まれます。「サブスクリプション=リモート設定の取得元」という関係を理解しておくと、以降の更新・上書き・失効時の切り分けが自然に理解できます。

サブスクリプションの導入

各クライアントの手順はほぼ共通です:サービス提供者から発行されたサブスクリプションリンクを完全にコピーし、クライアントの「サブスクリプション」または「Profiles」画面を開き、入力欄に貼り付けて、インポートまたはダウンロードをクリックします。成功すると一覧に設定項目が表示されるので、それを有効化し、「プロキシ」画面に戻るとノード一覧が確認できます。ノード一覧が空の場合は、ダウンロードまたは解析の段階で問題が発生しています。同じ操作を繰り返すのではなく、以下の失敗時の切り分け手順に従ってください。

サブスクリプションの更新

サービス提供者側のノードは変動するため、サブスクリプションは定期的に更新が必要です。多くのクライアントはサブスクリプションに自動更新間隔(例:24時間ごと)を設定できるほか、いつでも手動で更新ボタンを押せます。ここで注意すべき点があります——サブスクリプションを更新するとリモートの内容でローカルファイルが上書きされます。サブスクリプションファイルに直接書き込んだ独自ルールは、次回の更新時に消えてしまいます。正しい方法は、クライアントの「上書き(Override)」や「Merge」機能を使い、独自の内容をサブスクリプションとは別の独立したファイルに置いて、更新時に自動で合成させることです。第9章で詳しく解説します。

インポート失敗時の切り分け

サブスクリプションのインポートでエラーが出た場合は、段階的に確認してください:リンクが完全か(末尾のパラメータが切れているケースがよくあります)、ブラウザでリンクを開いてテキスト内容が返るか(404やWebページが返っていないか)、サービス提供者がUser-Agentを制限していないか(Clash系のUAにしか設定を返さないサブスクリプションもあります)、返ってきた内容が正しいYAML形式か。項目ごとの完全なチェックリストは技術ノート「Clashサブスクリプションリンクの失効・解析失敗チェックリスト」を参照してください。

設定ファイルはどこにある

クライアントはサブスクリプションを自身の設定ディレクトリに保存します。Linuxでは通常 ~/.config や ~/.local/share 内のクライアント名のサブディレクトリに配置され、コア単体の場合は デフォルトで ~/.config/mihomo/config.yaml を読み込みます。この場所を知っておくと、バックアップに使えるほか、クライアントの表示がおかしいときに直接ファイル内容を確認して、設定側の問題かプログラム側の問題かを判断できます。

設定を手動で管理するユーザーは、サブスクリプションを一切使わない選択もできます:自分で config.yaml を書き、proxies にノードを記述し、クライアントで「ローカルファイル」としてインポートします。この方法は自由度が最も高いですが、各項目への理解も求められます。まずはサブスクリプションで一通り動かしてから、徐々に移行していくのがおすすめです。

コアには3つの動作モードがあり、設定内の mode フィールドに対応します。ルールモード(rule)は日常的なデフォルトで、コネクションごとにルール表を照合し、直結すべきものは直結、プロキシ経由にすべきものはプロキシ経由にします。速度と可用性のバランスが取れています。グローバルモード(global)はすべての通信をプロキシ出口に送ります。「本当にルール分流の問題かどうか」を一時的に検証するのには向いていますが、長時間つけたままにするのはおすすめしません——中国本土向けの通信まで海外ノード経由になり、遅くなるうえ通信量も無駄になります。直結モード(direct)はすべての通信をプロキシなしで流します。アプリを終了せずに一時停止する場合と同等の効果です。トラブルシューティング時に3つのモードを切り替えて比較するのは、問題を特定する最も手早い方法の一つです。

ポート:通信の入り口

モードが通信の行き先を決め、ポートが通信の入り口を決めます。現代的な設定では mixed-port(慣例的に7890)を1つだけ宣言することが推奨されます。これはHTTPとSOCKS5の両プロトコルを同時に受け付けるため、ブラウザ、システムプロキシ、コマンドラインツールをすべてこの1つのポートに向ければ十分で、port と socks-port を別々に管理する必要はありません。

「Clashは起動しているのにWebページがプロキシを通っていない」という問題の第一の原因は、通信がそもそもこのポートに入っていないことです。デスクトップクライアントの「システムプロキシ」スイッチが行っているのは、OSのプロキシ設定を 127.0.0.1:7890 に向けることです。このスイッチがオフだと、コアはただ空回りで待ち受けているだけになります。GNOMEユーザーは「設定 → ネットワーク → ネットワークプロキシ」で、KDEは「システム設定 → ネットワーク → プロキシ」で確認できます。いずれもループバックアドレスとポート番号が表示されているはずです。

ターミナルアプリはシステムプロキシを認識しない

Linuxでは多くのコマンドラインツール(curl、git、パッケージマネージャーなど)がデスクトップ環境のプロキシ設定を読み取らず、環境変数を参照します。現在のターミナルセッションに一時的にプロキシを設定するには:

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

~/.bashrc に書き込めば永続的に有効になりますが、シェル関数として必要なときだけオン/オフできるようにする方がおすすめです。プロキシを止めた後にターミナルの通信がすべて固まってしまうのを防げます。有効になっているかの確認は curl -I https://www.google.com がレスポンスヘッダを素早く返せば成功です。

LAN共有とポートの競合

デフォルトの 127.0.0.1 リスニングは、自分のマシンからしか使えないことを意味します。allow-lan を true にしてバインドアドレスを開放すれば、同じLAN内のスマホやテレビ端末をこのマシンをプロキシサーバーとして利用できます。設定方法、ファイアウォールの許可、セキュリティ境界の詳しい議論は技術ノート「Clash混合ポートとLAN共有プロキシの設定」を参照してください。もう一つ頻発する問題は起動時の address already in use エラーです——7890が別プロセスに占有されている状態で、特定と対処の全手順は「Clashのポートが使用中のときの対処法」にまとめています。mixed-port を変更したら、システムプロキシや環境変数側のポート番号も忘れずに同期してください。片方だけ変更すると「一部のプログラムだけつながらない」という奇妙な現象が起きます。

ルール分流はClashの核心です。各ルールは3つの要素で構成されます:タイプ,マッチ内容,出口——出口には特定のプロキシグループ、組み込みの DIRECT(直結)、REJECT(拒否)を指定できます。第1章で触れた鉄則をここで再確認します——上から順に照合し、最初に一致した時点で確定します。よく使われるルールタイプは以下の通りです:

特に注意すべき点が2つあります。1つ目、IP系のルールはドメイン解決を発生させます:コネクションの宛先がまだドメイン名の場合、コアは IP-CIDR と照合する前にIPを解決する必要があり、この解決処理が遅延や問い合わせの漏洩を招く可能性があります。純粋な内部ネットワーク向けのルールには no-resolve パラメータを付け、「もともとIPだったコネクション」だけにマッチさせるのが一般的です。2つ目、MATCH は必ず最後に配置する必要があり、これはすべてのルールが一致しなかった場合の兜底出口です。この兜底がどのグループを指すかによって、「見知らぬ通信」のデフォルトの行き先が決まります。

プロキシグループ:ルールの出口

ルールの出口はノードではなくグループを指し、グループのタイプが選択戦略を決めます:select は手動選択、url-test は定期的に遅延を測定して最速を自動選択、fallback は順番に最初に使えるものを探し、load-balance はリクエストを複数ノードに分散させます。グループは互いに入れ子にすることもできます——手動選択グループの中に自動測速グループを入れておき、普段は自動に任せ、特別な時だけ手動で指定する、というのが最も一般的な構成です:

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: []        # サブスクリプションのノードは通常providerで注入される

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,github,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この5行のルールは、そのまま使える最小限の骨格です。最初の2行は明確にプロキシが必要なドメインをPROXYグループに送り、3行目はローカルネットワークを許可し、4行目は中国大陸のIPを直結にし、最後は兜底でプロキシに流します。日常的な拡張は、より精密なドメインルールを前方に追加していくだけです。

最後に運用上の心構えをもう一度強調します——独自ルールをサブスクリプションファイルに直接書き込まないこと(次回更新時に上書きされます)。クライアントの上書き機能を使って、サブスクリプションのルールより前に注入してください。ルールは前に置くほど優先度が高いため、「自分のルールを上、サブスクリプションのルールを中、GEOIPとMATCHを下」という三段構成が安定した形です。GEOIPの判定はローカルデータベースに依存しており、長期間更新しないと所属地の誤判定が発生します。更新方法は第8章で解説します。

システムプロキシには先天的な限界があります——あくまで「お願い」であり、従うかどうかはアプリケーション側が決めます。ブラウザは従いますが、多くのゲームやチャットアプリ、UDPを使うプログラムはプロキシ設定をそもそも見ません。TUNモードは別のアプローチを取ります:コアが仮想ネットワークカードを作成し、ルーティング設定と組み合わせてシステム全体の送信トラフィックをこの仮想NICに引き込みます。アプリケーション側はこれに一切気づきません——それらの視点からは、ネットワークは元からそういう構造に見えているだけです。「すべてのプログラムを差別なく分流させる」を実現するには、TUNが正解です。

設定例

tun:
  enable: true
  stack: system          # system / gvisor / mixed から選択可能
  auto-route: true       # ルーティングテーブルを自動設定
  auto-detect-interface: true
  dns-hijack:
    - any:53             # 53番ポート宛のDNSクエリを乗っ取る

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

各項目の説明:stack は仮想NICのプロトコルスタック実装で、system はOSに依存し性能が良く、gvisor はユーザー空間実装で互換性の問題が少なく、mixed は両者の折衷です。Linuxではまずsystemを試すのが一般的です。auto-route と auto-detect-interface はルーティングテーブルの自動追加・削除を担い、通信を仮想NICに、コア自身の送信トラフィックを物理NICに流します。これらをオンにしないとルーティングを手動で管理する必要があり、自分でネットワークを遮断してしまうリスクが非常に高くなります。

なぜTUNはDNSも管理する必要があるのか

TUNが受け取るのはIP層のトラフィックです。DNS解決がシステム層で行われたままだと、コアが見るのはIPだけになり、ドメイン名による分流ができなくなります。そのため dns-hijack でDNSクエリもキャプチャします。fake-ip モードはさらに一歩進んでいます:コアは各ドメイン名の問い合わせに対して予約されたセグメントの偽IPをまず返し、アプリはその偽IPで接続を開始します。コアは偽IPから逆引きでドメイン名を特定し、ルールマッチングを行います——実際のDNS解決を1回省略できるため、遅延が低くなります。副作用として、IPを検証する一部のプログラムでは不具合が出ることがあり、その場合は redir-host モードに戻すか、特定ドメインに fake-ip-filter の除外設定を行います。

Linuxでの権限について

仮想NICの作成とルーティングの変更には CAP_NET_ADMIN 権限が必要です。デスクトップクライアントでは「サービスモード」を使うのが最も手軽です:クライアントがシステムサービスを登録し、そのサービスが特権を持ってコアを起動し、画面上のワンクリックでTUNをオン/オフできます。コア単体のユーザーはsetcapでバイナリに権限を付与すれば、毎回sudoする必要がなくなります:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

よくあるトラブルは3つです。1つ目、TUNとシステムプロキシが同時にオンになっていて、通信が二重処理される——システムプロキシのスイッチをオフにすれば解消します。2つ目、ネットワークの切り替え(LANケーブルの抜き差し、異なるWi-Fiへの接続など)後にNetworkManagerがルーティングを書き換えて通信が切れる——TUNを一度再起動してauto-routeにルーティングを再構築させます。3つ目、コアが異常終了してルーティングの後始末ができなかった場合——Clashを切ったのにむしろネットにつながらないという現象になりますが、これも「一度オンオフする」かネットワークサービスの再起動で復旧できます。TUNをオンにした後の動作確認は、プロキシ設定に対応していない適当なコマンドラインプログラムでネットワークにアクセスし、クライアントの接続画面にそのプロセス名が表示されるかを見ればわかります。

設定が一通り動くようになったら、運用作業自体は多くありませんが、いくつか習慣化しておくと「突然つながらなくなる」確率を最小限に抑えられます。

定期的に更新すべき3つのもの

1つ目はサブスクリプション:自動更新をオンにするか、毎週1回手動で更新をクリックしてください。ノードの変更をサービス提供者が個別に通知してくれることはありません。2つ目はGeoIP / Geositeデータベース:第6章の GEOIP,CN,DIRECT はローカルデータベースを使ってIPの所属を判定しています。データベースが古いと、直結すべき通信がプロキシに送られたり、逆のことが起きたりします。多くのクライアントは設定画面にワンクリック更新の入口を用意しており、コア単体の場合は設定ディレクトリ内のデータベースファイルを置き換えて再起動すれば更新できます。3つ目はクライアント自体:インストールした方法でアップグレードしてください——aptで入れたならaptで更新、AURで入れたならシステムのローリングリリースに追従。同じマシンで2種類のインストール元を混在させないでください。「アンインストールが不完全で2つのバージョンが競合する」といった不可解な問題の温床になります。

ログを読めるようになる

ログはトラブルシューティングの第一現場です。設定の log-level: info は日常使いに適していますが、問題調査時には一時的に debug に変更して詳細を確認し、解決したら戻してください(debugは出力量が多く性能にも影響します)。よく見かけるログ行を覚えておくと便利です:dial tcp ... i/o timeout は通常ノードに到達できないことを示し、connection refused は宛先ポートが開いていないか、ローカルのファイアウォールに遮断されていることが多いです。ルールが一致した行は、あるコネクションが実際にどのルールにマッチし、どの出口を通ったかを教えてくれます——分流が期待通りに動かないときは、まずこの行を確認してください。ルールを闇雲に書き換えるのではなく。項目ごとの詳しい解説は技術ノート「Clashの実行ログを読み解く」を参照してください。

バックアップと復旧

バックアップすべきなのは設定ディレクトリだけです:サブスクリプションのアドレス、上書きファイル、独自ルールがすべてここに入っています。いつものバックアップフローに1つ追加しておけば、マシンを変えたり再インストールしたりする際に元のパスに解凍するだけで復元できます。コア単体の場合はコマンド1つで完了です:tar czf mihomo-backup.tar.gz ~/.config/mihomo。クライアントを使っている場合は、まず設定画面で設定ディレクトリのパスを確認してからまとめてください。

起動時の自動起動

デスクトップクライアントは設定画面で自動起動をチェックするだけです。サーバー上のコア単体はsystemdに管理を任せ、サービスユニットを書きます:

# /etc/systemd/system/mihomo.service
[Unit]
Description=mihomo daemon
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure

[Install]
WantedBy=multi-user.target

その後 sudo systemctl enable --now mihomo を実行すれば登録と起動が一度に完了し、journalctl -u mihomo -f でログをリアルタイムに追跡できます。Restart=on-failure はプロセスが異常終了した際に自動で再起動する設定で、長期間無人運用する場合には必須です。

最後にトラブルシューティングの大原則を挙げます——一度に変更する変数は1つだけにすること。ポートを変えたらまずポートを検証し、ノードを変えたらまずノードをテストしてください。3箇所同時に設定を変えて問題が起きたら、どこが原因なのか特定できなくなります。起動関連の障害(クラッシュ、白画面、コアが起動しないなど)の切り分けは「Clashクライアントの起動時クラッシュと落ちる問題の対処法」を参照してください。

第8章までを終えれば、日常使いに支障はなくなります。この章では、さらに深く踏み込みたいユーザーに向けてロードマップを示します。それぞれの方向に明確なメリットがあるので、必要に応じて選んで進めてください。すべて制覇する必要はありません。

方向1:上書きと設定のマージ

第4章で触れたように、サブスクリプションの更新はローカルの変更を上書きしてしまいます。その解決策が上書き機能です:独自のポート設定、TUN設定、プライベートルールを独立した上書きファイルに記述しておき、クライアントがサブスクリプションを読み込むたびに自動でマージします。Clash Verge Rev はMerge(YAMLレベルでのフィールド合成)とスクリプト(コードで最終設定を書き換える)の2方式を提供しており、前者で9割のニーズをカバーでき、後者は本当に特殊なケース向けです。上書きを使いこなせば、独自の設定はサブスクリプションから完全に分離されます——サブスクリプションやサービス提供者を変えても、自分の設定は1行も失われません。

方向2:providerによる分割

proxy-providers と rule-providers は、ノードとルールをメイン設定から切り出し、それぞれ独立したリモートまたはローカルファイルにして、個別に更新周期を設定できるようにします。ルールセット(rule-set)は特に実用的です。コミュニティが用途別に分類したドメインリストを維持しており、設定内ではドメインを1つずつ書く代わりにリスト名を参照するだけで済みます。ルール表は数百行から十数行に縮まり、可読性・保守性が大きく向上します。

方向3:外部コントロールインターフェース

設定に external-controller: 127.0.0.1:9090 を宣言すると、コアはRESTfulなAPI群を公開します。ノードの切り替え、コネクションの確認、遅延テストなどをHTTPリクエストで行えるようになります。コミュニティ製のWebパネルと組み合わせれば、ブラウザから稼働中のコアを管理できます——これはまさにサーバー用途での標準的な操作方法であり、「クライアントは結局何をしてくれていたのか」を理解する最良の教材でもあります。クライアント画面上の各ボタンは、その裏側でこのインターフェースへの呼び出しが行われているだけなのです。

方向4:サーバーでのコア単体デプロイ

第8章のsystemdユニット、この章の外部コントロールインターフェース、第7章のTUNを組み合わせれば、透過ゲートウェイやソフトウェアルーターとしての完全な構成が実現できます。LAN内の機器のゲートウェイをこのマシンに向ければ、家中の全機器が統一的に分流され、端末側には何もインストールする必要がありません。この方向はルーティングとDNSの基盤に手を入れるものなので、実際のネットワークに適用する前に一度仮想マシンで試しておくこと、そしてゲートウェイを経由しない管理用の通路を必ず自分用に残しておくことをおすすめします。

学習リソースの使い方の順番

おすすめの参照順序:概念に関する疑問はまず用語集で確認(コアとクライアント、プロキシプロトコル、ルールと分流、ネットワークとポート、設定ファイルのフィールドの5分類で整理されています)。操作の流れを振り返るには使い方ガイドを見直してください。具体的な不具合は技術ノートの該当記事を項目ごとに確認してください。頻出の短い疑問はFAQ系のコンテンツにすでに答えがあることが多いです。本ガイド自体もコアやクライアントのエコシステムの変化に合わせて随時更新されます。実際の画面と内容が合わない箇所があれば、クライアント内の最新の表示を優先し、考え方自体は変わりません。

使いこなすことに近道はありませんが、明確な目安があります——あるログを見てそれがどの工程のものか説明できる、見知らぬ設定を渡されてその分流の挙動を予測できる、ネットワークが異常なときにまずどのモードに切り替えるべきか、どの行を見るべきかがわかる。そこまで来れば、このガイドは役目を終えたことになります——順調に進みますように。