Clashゼロから精通までの完全マニュアル

01基本概念:コア、クライアント、設定ファイル

コアとクライアントは別々のもの

Clashのエコシステムは2層で構成されています。基盤となるのはコアです。コマンドラインで動くプログラムで、ローカルポートを監視し、アプリの通信を受け取り、ルールに照らして対応するプロキシサーバーへ転送するか直結で出すかを決めます。現在の主流コアは mihomo(Clash Metaブランチ)です。オリジナルのClashコアがアーカイブされた後も継続開発されており、アウトバウンドプロトコルやルールセット、TUNスタックが拡張されています。詳しくはブログ「mihomoコアとオリジナルClashの違いは何か」を参照してください。

上位層はGUIクライアントです。Clash Plus、Clash Verge Rev、FlClashなど名前は異なりますが、本質はいずれもコアの「操縦席」です。サブスクリプションの導入、ノードの切り替え、システムプロキシとTUNのオン/オフ、ログと接続状況の表示を担います。この点を理解すれば多くの疑問が自然に解消します。クライアント間の機能差は主にUIとパッケージングにあり、分岐能力そのものはコアに依存します。クライアントを変えてもサブスクリプションを変える必要はなく、設定ファイルはどのコア互換クライアントでも共通して使えます。

設定ファイルの3つの構成要素

コアの全動作は1つのYAML設定ファイル(通常 config.yaml、クライアント上ではProfileと呼ばれる)で決まります。ファイルがどれだけ長くても骨格は次の3つです。

1. インバウンドとグローバルパラメーター:待受ポート、LANアクセスの許可、動作モード、ログレベル、DNS設定。
2. proxies と proxy-groups:ノード一覧(各ノードはプロキシサーバーのアドレス・ポート・プロトコル・認証情報)と、プロキシグループ(ノードを戦略ごとにまとめ、ルールから参照できるようにしたもの)。
3. rules:分岐ルール一覧。各接続がどのプロキシグループを通るかを決めます。

最小限で読みやすいグローバルパラメーター部分は次のようになります。

mixed-port: 7890        # HTTPとSOCKS5を統合したハイブリッド待受ポート
allow-lan: false        # LAN内デバイスからの接続を許可するか
mode: rule              # rule / global / direct の3種類の動作モード
log-level: info         # silent / error / warning / info / debug
external-controller: 127.0.0.1:9090   # ローカルAPI制御用ポート

頻出用語クイックリファレンス

02クライアント選定:対応OSと選択基準

まずOS、次に好み

クライアント選びの第一の制約はOSです。下表はダウンロードセンターの収録内容と一致しており、各枠は推奨順に並んでいます。

Clash Plusは全プラットフォームでの第一候補です。5つのOSでUIと操作ロジックが一致しており、デバイスを変えても学習コストがかかりません。mihomoコアを内蔵し、サブスクリプション導入・TUN・ルール分岐がすぐに使えます。Clash Verge Revはデスクトップ版でより細かな設定機能を提供し、オーバーライドスクリプト、外部制御、コア切り替えの入口がすべて用意されています。ドキュメントを読み込む意欲がある人向けです。FlClashはFlutterで構築され、1つのUIでデスクトップとAndroidを横断します。シンプルな操作を好むなら適しています。Clash NyanpasuはWindows上のもう一つのVerge系分岐で、UIの雰囲気は異なりますが機能面は近いです。Clash Meta for AndroidはAndroidでコアのネイティブな挙動に最も近いクライアントです。SurfboardはClashの設定フォーマットに対応しており、Androidの代替候補として使えます。

03インストール:5つのOSを順に確認

Windows

ダウンロードセンターWindows欄からインストーラーを取得し、ダブルクリックして起動、ウィザードでインストール先を選ぶだけです。よくある2つの詰まりどころがあります。1つ目はSmartScreenが「PCを保護しました」と表示すること。これは新しく公開されたインストーラーに対するシステムの既定のブロックで、「詳細情報 → 実行」を選べば続行できます。2つ目はインストール完了後にウィンドウが見つからないこと。Clash系クライアントは起動後デフォルトでタスクバーのトレイに収まるため、トレイの猫アイコンをクリックしてメイン画面を呼び出します。TUNモードを使う予定がある場合は、初回起動時にクライアントが求めるサービスインストールや管理者権限の付与に同意してください。第7章で使用します。

macOS

.dmgイメージをダウンロードし、開いたらアプリアイコンをApplicationsフォルダにドラッグします。チップの種類に注意してください。Apple Silicon(M系)とIntelでは対応するインストーラーが異なり、ダウンロードページで分けて表示されています。初回起動時に「開発元を確認できません」と表示されたら、「システム設定 → プライバシーとセキュリティ」の下部から「このまま開く」を選ぶか、アプリアイコンを右クリックして「開く」を選び再度確認してください。クライアントが補助サービスのインストール(システムプロキシとTUNを扱うため)を求める際はパスワードを入力して許可します。

Linux

デスクトップ向けディストリビューションでは.debパッケージが推奨です。Debian / Ubuntu系では直接インストールできます。

# ファイル名は実際のダウンロード内容に合わせて調整してください
sudo apt install ./clash-verge-rev_amd64.deb
# またはdpkgを使い、あとで依存関係を補う
sudo dpkg -i ./clash-verge-rev_amd64.deb
sudo apt -f install

インストール後はアプリメニューから起動します。TUNモードにはコアにCAP_NET_ADMIN権限を付与するか、サービス方式で実行する必要があります。クライアントの設定にはたいてい「サービスモード」のワンクリック入口があります。デスクトップ環境のないサーバーではGUIを使わず、直接mihomoコアを利用します。詳しくは第9章を参照してください。

Android

ダウンロードセンターAndroid欄からAPKを取得し、インストール時にシステムの案内に従い「このソースからのアプリ」を許可します。初回接続時にシステムがVPN接続要求のダイアログを表示します。これはVpnServiceの標準的な許可プロセスで、確認するとステータスバーに鍵アイコンが表示され、通信がクライアントに入っていることを示します。中華系Androidの一部OSはバックグラウンド管理がかなり厳しいため、クライアントを省電力ホワイトリストと自動起動許可リストに追加することをお勧めします。そうしないと画面ロック後しばらくしてシステムがプロキシを回収してしまいます。詳細はブログ「Clash Androidクライアント利用の要点」を参照してください。

iOS

iOSではApp Storeを通じてClash Plusを取得します。ダウンロードページiOS欄にストアへの直リンクと公式サイト clashplus.io を掲載しています。インストール後、初回起動時にもVPN構成の追加が要求され、「設定 → 一般 → VPNとデバイス管理」で対応するプロファイルを確認できます。サブスクリプション導入とノード切り替えの操作ロジックはデスクトップ版と同一で、以降の章の概念はすべて共通です。

04サブスクリプション導入と設定管理

サブスクリプションリンクとは

サブスクリプションはHTTPSのアドレスで、サービス提供者が生成し、ノードの変動に応じてリアルタイムに更新される完全な設定ファイルを返します。クライアントの「サブスクリプション導入」機能がしていることは、このアドレスにリクエスト → 返ってきたYAMLを1つのProfileとして保存 → 現在有効な設定として設定する、というだけです。したがってサブスクリプションリンクはアカウント認証情報と同等であり、公開の場に貼ったりスクリーンショットに映してはいけません。

導入と更新

1. サービス提供者のユーザーセンターでサブスクリプションリンクをコピーします。Clashまたはmihomoフォーマットのどちらかを選ぶよう注意してください(一部のパネルはコアによって出力内容が異なります)。
2. クライアントのProfile / 設定ページを開き、リンクを貼って導入をクリックします。一覧に新しい項目が現れ、トラフィックや有効期限(パネルが提供している場合)が表示されれば成功です。
3. その項目を選んで有効化します。以後、ノード一覧・プロキシグループ・ルールはすべてこの設定から取得されます。
4. 自動更新の間隔を設定します(一般的には24時間)。サービス提供者がノードアドレスを変更した際、ローカルを更新しないと「全ノードタイムアウト」になります。

ローカル設定と複数Profile管理

サブスクリプションのほかにクライアントは空のProfileの新規作成やローカルYAMLファイルの導入にも対応しており、自前サーバーを使う人やルールを完全に制御したい人に向いています。複数のProfileは互いに排他的な切り替え関係にあり、同時に有効なのは1つだけで、切り替えるとポート・ノード・ルールの3要素がまとめて置き換わります。よくある運用方法は「サブスクリプション1つ+ローカル実験用1つ」です。普段はサブスクリプションを使い、ルールをいじるときはローカルのコピーに切り替え、失敗したらいつでも元に戻せます。サブスクリプションは更新のたびにリモート内容で上書きされるため、サブスクリプション用Profileを直接変更した内容は失われます。永続的なカスタマイズには第9章のオーバーライド機構を使ってください。Profile構造の詳しい解説はブログ「Clashの設定ファイルとは何か」を参照してください。

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

3つの動作モード

設定のmodeフィールドには3つの値があります。rule(ルール):各接続をrules一覧に沿って1件ずつ照合し、命中したものに従います。日常的に推奨されるモードで、日本国内は直結、国外はプロキシ経由と干渉せず分けられます。global(グローバル):ルールを飛ばし、すべての通信を同じプロキシグループに通します。「ルールがうまく命中していないのか」を一時的に確認する用途に限られます。direct(直結):すべての通信がプロキシを経由しません。クライアントを起動したまま道を空けるのと同等です。切り替え入口はクライアントのメイン画面にあり、通常は横並びの3つの選択肢です。

システムプロキシの役割

「システムプロキシ」のスイッチをオンにすると、クライアントはOSにHTTP/SOCKSプロキシのアドレスを登録します。デフォルトは127.0.0.1:7890(前述のmixed-portのハイブリッドポート)です。ブラウザや大半のシステムプロキシ設定に従うアプリは、通信を自発的にこのポートへ送ります。限界も「自発的」という点にあります。コマンドラインツール、一部のゲーム、古いアプリはシステムプロキシ設定を読まず、通信がコアを経由しません。このようなケースは第7章のTUNモードに任せます。

回線が有効になっているかの確認

接続後、2ステップで確認します。1つ目はクライアントの接続パネルを見ることです。任意のサイトにアクセスし、パネルに新しい接続記録が現れ、命中したルールと出口が示されていれば、通信は確かに入っています。2つ目はコマンドラインで明示的にプロキシを指定してテストします。

# ローカルのハイブリッドポート経由でリクエストを送り、レスポンスヘッダーが返れば回線は利用可能
curl -x http://127.0.0.1:7890 -I https://www.cloudflare.com

直結は正常でプロキシ経由がタイムアウトする場合は、順にノードが使えるか(別ノードで再試行)、サブスクリプションが期限切れでないか、ローカルのファイアウォールがクライアントを遮断していないかを確認してください。

06ルール分岐:各接続を適切な経路へ

ルールの照合方法

rules一覧は上から下へ1件ずつ照合し、命中したら停止します。各ルールは「タイプ、マッチ値、対象ポリシー」で構成され、対象ポリシーは特定のプロキシグループでも、内蔵のDIRECT(直結)やREJECT(拒否)でも構いません。一覧の末尾には必ずMATCHを1つ置き、前段で漏れたすべての通信を受け止めます。よく使うルールタイプは以下の通りです。

順序への配慮が初心者が最もよく踏む落とし穴です。GEOIP,CN,DIRECTを国外ドメインのルールより前に置いてしまい、そのドメインがたまたま国内のCDNに解決される場合、接続は先に直結に命中してしまいます。原則は厳密なルールを前に、範囲の広いルールを後に、MATCHは常に最後です。

プロキシグループの4つの戦略

ルールの対象は一般に単一ノードではなくプロキシグループで、グループ内の戦略が実際の出口を決めます。selectは手動選択で、UI上でクリックしたノードを通ります。url-testは定期的にテストアドレスへレイテンシを測定し、最速のノードを自動選択します。fallbackは一覧順に最初に使えるノードを取り、前のものが落ちれば自動的に次へ進みます。load-balanceは接続を複数ノードに分散させます。そのまま流用できる構成例は次の通りです。

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, HK-01, JP-01, US-01]
  - name: AUTO
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, US-01]

rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  - RULE-SET,streaming,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

普段はPROXYグループをAUTOに設定して自動速度測定させ、地域を固定したい場合(動画配信の視聴制限解除など)は対応するノードに手動で切り替えます。ノードを選ぶ4つの観点(レイテンシ、倍率、地域、プロトコル)についての詳しい解説はブログ「Clashのノードはどう選ぶか」を参照してください。

DNSとFake-IP

正しく分岐させるための前提は、ドメイン情報が失われないことです。mihomoのdnsセクションは2つのモードに対応しています。redir-hostは実際に解決してからIPで照合し、fake-ipは予約ネットワーク帯を使って応答を偽装し、接続確立時に本来のドメインへ復元します。後者は解決時のレイテンシを大幅に下げ、DNSポイズニングによる分岐妨害も避けられます。実際のIPに依存する一部のアプリ(LAN内発見機能、一部のゲームプラットフォーム)はfake-ip-filterに書いて除外する必要があります。完全な仕組みはブログ「Fake-IPモードの動作原理を詳しく解説」を参照してください。

07TUNモード:システム全体の通信を引き受ける

原理と適用シーン

TUNモードではコアが仮想ネットワークアダプタを作成し、システムの既定ルートをそこに向けます。すべてのアプリの通信がネットワーク層で捕捉され、アプリがシステムプロキシ設定に従っているかどうかに依存しなくなります。コマンドラインツール、ゲームクライアント、UWPアプリなど「システムプロキシを認識しない」通信も、TUN下ではすべてルールエンジンに入ります。両方式の違いは次の通りです。

有効化の手順

1. まず権限の前提を満たします。Windowsではクライアント設定でサービスモードをインストール(または管理者として実行)、macOSでは補助サービスの許可に同意、Linuxではクライアントのサービスモードを有効化するか、コアにネットワーク管理権限を付与します。
2. クライアント設定でTUNのスイッチをオンにします。Verge系クライアントでは同時にシステムプロキシのスイッチをオフにして、二重の引き受けを避けることを推奨します。
3. DNSハイジャックが有効になっていることを確認してください。そうでないとアプリがシステムDNSに直結して分岐をバイパスしてしまいます。

対応する設定セクション(クライアントのGUIスイッチは本質的にこれらのフィールドを書き込んでいます)。

tun:
  enable: true
  stack: system        # system / gvisor / mixed
  auto-route: true     # 既定ルートを自動的に引き受ける
  auto-detect-interface: true
  dns-hijack:
    - any:53           # 53番ポート宛のすべてのDNSクエリをハイジャック

08日常運用保守とトラブルシューティング

更新を保つべき3つの要素

サブスクリプション:自動更新をオンにし、間隔は24時間以内にします。サービス提供者がノード変更を告知した場合は手動で1回更新すれば即座に反映されます。クライアントとコア:メンテナンス中のクライアントはバージョン更新にあわせてコアも更新し、新プロトコルや修正はそれに依存します。アップグレード前に更新情報に設定フィールドの変更がないか確認してください。GEOデータとルールセット:GeoIP / GeoSiteデータベースとRULE-SETが参照する外部ファイルにはいずれも更新機構があります。クライアント設定には通常「GEOデータを更新」ボタンがあり、ルールの照合結果が期待と異なる場合はまず更新してから調査してください。

日常観察に使う2つの画面

ログページ:log-levelを一時的にdebugに上げると、各接続の照合過程を確認でき、「この通信がどのルールに命中したのか」を突き止めるのに最も直接的です。特定できたらinfoに戻し、ログが溢れてリソースを消費するのを避けてください。接続パネル:アクティブな接続の宛先、命中ルール、出口ノード、トラフィックをリアルタイムに一覧表示します。あるアプリが誤った出口を通っていると分かったら、ここから宛先ドメインを取得し、設定に厳密なルールを1つ追加してください。

トラブル対応表

09上級ルート:使いこなしから精通へ

オーバーライド:サブスクリプション更新後もカスタマイズを残す

サブスクリプションは更新ごとにProfile全体を上書きするため、ファイルを直接編集したカスタマイズは次の更新で消えてしまいます。正しい方法はオーバーライド(Merge / Override)です。クライアント内に独立したパッチを1つ維持し、サブスクリプション更新後に自動で設定へ重ね合わせます。典型的な使い方は独自ルールの追加、DNSセグメントの固定、TUNフィールドの強制有効化です。Clash Verge RevはJavaScriptスクリプトによるオーバーライドにも対応しており、条件に応じてノードやプロキシグループを一括で書き換えられます。ルール量が多いユーザーに向いています。

外部制御APIとWebパネル

コアはexternal-controllerを通じてRESTful APIの一式を公開しており、クライアントUI自体もその利用者の一つです。直接呼び出すこともできます。

# 現在の設定を確認
curl http://127.0.0.1:9090/configs
# あるselectグループの出口ノードを切り替える
curl -X PUT http://127.0.0.1:9090/proxies/PROXY \
  -d '{"name": "HK-01"}'

external-uiフィールドと組み合わせればWeb制御パネルをマウントし、ブラウザ上で稼働中のコアを管理できます。これはルーターやサーバー用途での標準的な運用方法です。

GUIなしの環境で直接コアを動かす

サーバー、ルーター、NASではGUIは不要で、ダウンロードセンターコア欄から対応アーキテクチャのmihomoバイナリ(AMD64 / ARM64 / ARMv7 / MIPSなど)を取得し、設定を指定ディレクトリに置いて起動します。

# -dで設定ディレクトリを指定、ディレクトリ内にconfig.yamlとGEOデータを置く
./mihomo -d /etc/mihomo
# systemdで常駐させ、起動時に自動起動
sudo systemctl enable --now mihomo

LAN内の各デバイスがゲートウェイまたはプロキシをこのマシンに向ければ、家族全員で同じ分岐ルールを共有できます。

推奨する上級学習の順序

1. Profile構造の入門と複数設定管理——第4章の設定骨格を完全に理解する。
2. ノード選択の4つの観点——自分なりのノード選定フローを構築する。
3. Fake-IPの動作原理——DNS層で何が起きているかを理解する。
4. mihomoとオリジナルコアの違い——手持ちのツールの境界を把握する。
5. 実践:オーバーライドを使って自分のルールパッチを維持し、遊休デバイスにコア単体を実際にデプロイしてみる。この5ステップを終えれば、本マニュアルの全9章の内容が本当に自分自身の知識になります。