Clash完全ガイド:ゼロから使いこなすまで

Clashはルール駆動型のネットワークプロキシツールです。動作原理は一言でまとめられます:YAML形式の設定ファイルを読み込み、そこに定義されたルールに従って、各通信を直接送信するか、どこかのプロキシノードへ転送するかを判断する——というものです。この一文を理解すれば、以降の章はすべてその展開にすぎません。

コアとクライアント

「Clash」という言葉は日常的な文脈では2つの層を指しています。1つ目はコア:GUIを持たないコマンドラインプログラムで、実際の通信処理・ルールマッチング・プロトコル実装を担当します。オリジナルのClashコアは既にアーカイブされ、現在コミュニティで活発に開発が続く後継がmihomoコアです。2つ目はクライアント:コアを包むGUIで、サブスク管理・スイッチ切り替え・ログ表示といった操作面を担当します。Clash Plus、Clash Verge Rev、FlClashといった名前はいずれもクライアント層に属し、内部で動かしているのは同じ系統のコアです。これは「なぜ異なるクライアントで同じサブスクを使えるのか」という疑問への答えにもなっています——設定ファイルはコア向けに書かれており、クライアントは単なる運び役にすぎません。プロジェクト系譜の全体像はこちらのノートにまとめています。

避けて通れない4つの用語

• ノード(proxy):利用可能な1台のプロキシサーバーで、設定内の1件の proxies エントリに対応し、サーバーアドレス・ポート・プロトコル・鍵情報を含みます。
• サブスク(subscription):サービス提供者がホストするURLで、アクセスすると完全な設定またはノードリストが返されます。クライアントは定期的に取得するため、ノードの変更は自動的に反映され、手動でファイルを書き換える必要はありません。
• プロキシグループ(proxy-group):複数のノードを1つの選択可能な単位にまとめたもので、「手動選択グループ」「自動速度測定グループ」などがあります。ルールの出口はノードそのものではなく、プロキシグループを指します。
• ルール(rule):「マッチ条件+出口」を1行で表した宣言で、例えば「github.comで終わるドメインはプロキシグループへ」といったものです。ルールリストは上から下へ順に照合され、一致した時点で判定が止まります。

1本の通信がたどる全経路

ブラウザがアクセスを開始すると、通信はまずClashがリスンしているローカルポートに入ります。コアが宛先のドメインまたはIPを取り出し、ルールリストの先頭から順に照合していき、一致したルールが指定するプロキシグループに通信を渡します。プロキシグループは自身のタイプ(手動選択または自動速度測定)に応じて最終的なノードを決定し、データはそのノードを経由して宛先へ転送されます。この全過程はローカルマシン上でミリ秒単位で完了します。以降で説明するモード切り替え・ルール作成・TUNといった機能は、いずれもこの経路のどこか一段の振る舞いを変えるだけのものです。

クライアントの選択を間違えても損失は出ませんが、時間の無駄になります。選定に必要なのは3つの問いに答えることだけです:どのOSを使うか、TUNモードで全体の通信を制御する必要があるか、そのプロジェクトが現在もメンテナンスされているか。3つ目の問いは特に見落とされがちです——メンテナンスが止まったクライアントはコアの更新に追従せず、新しいプロトコルやルールタイプが使えなくなり、OSアップデート後に互換性の問題が出ることもあります。

プラットフォーム早見表

選定の実践的なコツ

Clash Plusは5つのプラットフォームすべてをカバーし、UIが統一されサブスク管理も充実しているため、迷ったときの安心な選択肢です。複数デバイスを使うユーザーは操作感が揃っている点で特に恩恵を受けます。Clash Verge Revはmihomoコアをベースにしており設定の自由度が最も高く、YAMLに触れることに抵抗がないユーザーやLinuxデスクトップ環境に向いています。FlClashは軽量志向でリソース消費が少なく、古い端末や常駐運用に適しています。Clash NyanpasuはWindows専用で独特なUIを持ち、機能はVerge Revに近いです。SurfboardはAndroid向けの軽量クライアントで、基本的なプロキシ機能に絞られ高度な機能は追求していません。

4つの観点(システム負荷・TUN対応・サブスク管理・使いやすさ)ごとの採点比較は横断比較ページにまとめており、より詳しい結論が確認できます。ブログの選定比較ノートでは具体的な利用シーンを補足しています。選択が決まったらダウンロードページへ進んでください、各プラットフォームのインストーラーは同じ順序で並んでいます。

インストール自体は難しくありませんが、各プラットフォームにはOSレベルの壁が1つあります:デスクトップOSのセキュリティ警告、モバイルOSのVPN許可です。どんな表示が出て、どのボタンを押せばいいかを事前に知っておけば、最初の一歩で詰まることはありません。

Windows

ダウンロードページからインストーラーを取得し、ダブルクリックで実行します。初回起動時にSmartScreenが「Windows によって PC が保護されました」と表示する場合がありますが、これは未署名またはダウンロード数の少ないプログラムに対する一般的な警告であり、ウイルス警告ではありません。「詳細情報」をクリックし、続けて「実行」を選べば進めます。インストール先は既定のままで問題ありません。後でTUNモードを使う場合は、初回起動時にクライアントの案内に従ってシステムサービスをインストールし、1度許可すれば以降は確認されません。

macOS

「.dmg」イメージをダウンロードし、開いたらアプリのアイコンをApplicationsフォルダへドラッグします。初回起動時はGatekeeperがネットワーク経由でダウンロードされたアプリであることを表示するので、「開く」を選んで確認します。チップの種類には注意が必要です:Apple Silicon機(Mシリーズ)はarm版、Intel機はx64版をダウンロードしてください。間違ったアーキテクチャを入れると変換レイヤーを経由して動作し、性能が明らかに低下します。拡張モードやTUNを有効にする際、システムがパスワード入力を求めて補助ツールをインストールしますが、これは正常な許可プロセスです。

Android

APKをインストールする際、システムが「不明なアプリのインストールを許可しない」と表示する場合がありますが、設定でブラウザやファイル管理アプリに一時的にその権限を付与すれば解決します。初回接続時には「XXがVPN接続の設定を求めています」というダイアログが表示されます——AndroidクライアントはシステムのVPNインターフェースを通じて通信を制御するため、同意しないと動作しません。この確認は一度だけ表示されます。一部メーカーのシステムはバックグラウンドを強力に整理するため、電池最適化の設定でクライアントをホワイトリストに追加しておくことを推奨します。そうしないと画面ロック後に接続が切断される場合があります。

iOS

iOSの配布経路はApp Storeで、「Clash Plus」を検索するか、公式サイトclashplus.ioが提供する導線から入手します。インストール後の初回起動時にも同様にVPN構成の追加許可が求められるので、システムのポップアップで確認し、Face IDまたはパスコードで一度認証すれば完了です。iOSのプロキシはシステムのネットワーク層で機能するため、すべてのアプリが統一的にクライアントのルールに従い、アプリごとの個別設定は不要です。初回設定のスクリーンショット付き手順は、ブログのiPhone初回設定ノートを参照してください。

Linux

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

sudo apt install ./clash-verge.deb
# 依存関係が不足していると表示された場合:
sudo apt --fix-broken install

Fedora系では「.rpm」パッケージと「dnf install」を使用します。GUIのないサーバーではmihomoコアのバイナリを直接ダウンロードし、展開後にsystemdと組み合わせて常駐実行できます。コアのダウンロード入口もダウンロードページのコアセクションにあります。

クライアントをインストールした直後は空の状態です——ノードが1つもなく、どこにも接続できません。ノードデータはサブスクを通じてクライアントに入ってきます。これが全体の流れの中で唯一、外部から用意する必要があるものです。

サブスクの正体

サブスクとはサービス提供者がホストする1つのURLです。クライアントがそこにアクセスすると、proxies、proxy-groups、rulesの3つの主要セクションが書き込まれた完全なClash設定(またはノードリスト)が得られます。以降クライアントは設定した間隔で再取得を行い、サービス提供者がサーバーを入れ替えたりノードを増減したりしても、ローカル側は自動で同期されます。導入方法はどのクライアントでも同じです:サブスクリンクをコピーし、サブスクまたは設定ページに貼り付けて、ダウンロードを確定します。プラットフォームごとの具体的な操作箇所はチュートリアルページで手順ごとに解説しているので、ここでは繰り返しません。

設定ファイルの骨格を理解する

サブスクをダウンロードすると1つのYAMLテキストが得られます。自分で書けるようになる必要はありませんが、骨格を理解しておくとトラブル対応で非常に役立ちます。最小構成のグローバルセクションは次のようになります:

mixed-port: 7890          # HTTPとSOCKSが共用するローカル待ち受けポート
allow-lan: false          # LAN内の他デバイスからの接続を許可するか
mode: rule                # 起動時のプロキシモード
log-level: info           # ログレベル。トラブル対応時は一時的にdebugに変更可
external-controller: 127.0.0.1:9090   # ローカル制御インターフェース

続いて proxies(ノードリスト)、proxy-groups(プロキシグループ)、rules(ルールリスト)が並びます。3セクションの関係は:ルールがプロキシグループを指し、プロキシグループがノードを指すというものです。いずれかの名前が一致しないと設定の読み込みに失敗し、クライアントのログに具体的な行番号が表示されます。

サブスク変換とは

サービス提供者が他形式のノード情報(汎用の共有リンクなど)しか提供しない場合、「サブスク変換」サービスを経由してClash設定形式に変換する必要があります。変換処理はサードパーティのサーバーを経由するため、サブスクの内容がそこから見える状態になり、情報漏洩のリスクが生じます。ネイティブなClashサブスクが手に入るならそれを優先し、変換が必須な場合は信頼できる自前構築またはオープンソースの変換サービスを選びましょう。

複数デバイスで1つのサブスクを共有する場合、設定ファイルを相互にコピーするのではなく「サブスクリンクの一元管理」を推奨します。3つの同期方法のメリット・デメリットは複数デバイス同期ノートを参照してください。

モードは「ルールリストが判定に関与するかどうか」を決めます。3つのモードは互いに排他的なグローバルスイッチで、クライアントのメイン画面からワンタップで切り替えられ、設定内の mode フィールドに対応しています。

よくある誤用はGLOBALを長期間使い続けることです。グローバルモードでは国内サイトへの通信も海外ノードを経由してしまい、速度が逆に低下し、通信量も無駄に消費されます。正しい使い方は、99%の時間をRULEで過ごし、GLOBALとDIRECTは短時間のトラブル診断ツールとして使うことです——「GLOBALに切り替えるとアクセスできるが、RULEに戻すとできない」ならルールの問題、「DIRECTに切り替えてもアクセスできない」ならプロキシとは無関係な問題だと分かります。

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

もう1つ混同しやすいスイッチが「システムプロキシ」です。これは3つのモードには含まれず、「OSが通信をClashに送るかどうか」を決めるものです。有効にすると、システムレベルのプロキシ設定がClashのローカルポートを指すようになり、その設定に従うアプリ(ブラウザなど)の通信だけが入ってきます。従わないアプリ(一部のゲームやコマンドラインプログラム)は完全に迂回されます。すべてのプログラムを例外なくClashに通したい場合は、第7章のTUNモードが必要です。階層関係は一言で覚えておいてください:システムプロキシ/TUNは通信が入ってくるかどうかを決め、モードは入ってきた後の振り分け方を決めます。

ルール分岐はClashを単純なプロキシツールと区別する核心的な機能であり、RULEモードの背後にあるロジックそのものです。サブスク付属のルールセットは大半のニーズをカバーしますが、いずれ「あるサイトの振り分けがおかしい」という状況に必ず出会います——そのときにはルールを読み解き、必要なら自分で1行追加できる必要があります。

ルールの文法

各ルールはカンマ区切りの1行の宣言です:タイプ,マッチ値,出口。出口はプロキシグループ名のほか、組み込みの DIRECT(直接接続)や REJECT(遮断)も指定できます。よく使われるタイプは次の通りです:

順序がすべてを決める

ルールリストは上から下へ照合され、最初に一致したルールが即座に適用され、それ以降は無視されます。そのため配置には決まった作法があります:厳密なものを前に、広範なものを後に、フォールバックを最後に置きます。最小限で使える国内外振り分けのルールセットは次の通りです:

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-SUFFIX,openai.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

読み方:既知の海外ドメインに一致したらプロキシ経由、「.cn」サフィックスは直接接続、解決されたIPが中国本土に属するなら直接接続、それ以外はフォールバックとしてプロキシ経由になります。注意点として、GEOIPはIPを得るために先にDNS解決が必要なので、ドメインルールをその前に置くことで、多くの通信が解決前に振り分けを完了できます。IP-CIDRルールに no-resolve パラメータを付けると、純粋なドメイン接続に不要な名前解決が発生するのを防げます。

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

上の例の PROXY はプロキシグループ名です。よく使われるグループタイプ:select は手動選択、url-test は定期的な速度測定で最速を自動選択、fallback は優先ノードに障害が起きたときに自動的にバックアップへ切り替えます。典型的な組み合わせは次の通りです:

proxy-groups:
  - name: PROXY
    type: select
    proxies: [AUTO, 香港節点, 日本節点]
  - name: AUTO
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港節点, 日本節点]

手動選択グループの中に自動速度測定グループを組み込むことで、普段は AUTO を選んでおけば手間がかからず、特殊な要件があるときだけ手動で特定のノードに固定できます。

ルールが効かないときのトラブル対応手順

1. 現在RULEモードになっているか確認する——GLOBALとDIRECTではルールは一切関与しません。
2. クライアントの接続パネルを開き、対象の通信を見つけて、実際にどのルールに一致したかを確認する。ほとんどの「振り分けミス」は、リストのより前にある広範なルールに横取りされているケースです。
3. 自作したルールがサブスクのルールより後に書かれていないか確認する——MATCHの後に追加したルールには決して順番が回ってきません。
4. ドメインルールが効かずIPルールは効く場合、通常はDNS層の干渉が原因なので、第7章のfake-ipと合わせて調査する。

実際の事例を交えた実践的な解説は、ブログのルール分岐実践ノートを参照してください。

第5章では1つの穴を残していました:システムプロキシは「システムプロキシ設定に従う」アプリにしか効きません。コマンドラインツール、一部のゲームクライアント、一部のチャットソフトは自前で接続を確立し、プロキシを完全に迂回します。TUNモードはこの穴を埋めるための仕組みです。

動作原理

TUNを有効にすると、クライアントはシステム内に仮想ネットワークアダプタを作成し、それを既定のルートに設定します。すべてのアプリの通信は——プロキシ設定に従うかどうかに関わらず——まずこの仮想アダプタを経由してClashコアに入り、そこでルールに基づいて振り分けられます。効果としてはモバイル端末のVPN制御と同等で、アプリ側は何も意識せず、振り分けはシステム全体に及びます。代償として、より高いシステム権限が必要になります:Windowsではサービスとして実行するか管理者権限を付与し、macOSではシステム拡張の許可が必要で、Linuxでは相応のネットワーク管理権限が必要です。各クライアントは初回有効化時に許可の手順を案内し、一度許可すれば長期間有効です。

設定例

tun:
  enable: true
  stack: system
  auto-route: true              # ルーティングテーブルを自動設定
  auto-detect-interface: true   # 物理的な出口ネットワークアダプタを自動検出

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://120.53.53.53/dns-query

GUIクライアントではこれらの項目は既製のスイッチとして用意されていることが多く、手書きの必要はありません。ここに掲載したのは、スイッチの裏で何が変わっているかを知ってもらうためです。stack はプロトコルスタックの実装で、実装によって互換性がわずかに異なるため、特定のアプリで異常が出たときは別の実装に切り替えて試すことができます。

なぜTUNは常にfake-ipとセットで語られるのか

TUNが通信を制御している状態では、DNS解決もClashが一括で処理しなければ、「解決は外部で行われ、通信は内部を通る」というずれが生じ、ドメインルールが機能しなくなります。fake-ip モードでは、コアがドメイン解決のたびに予約されたネットワーク範囲内の仮想IPを返し、アプリはその仮想IPで接続を開始します。コアはマッピングテーブルから元のドメインを復元してルール照合を行います——これにより実際の名前解決を待つ必要がなくなり、かつドメインルールが常に確実に機能します。副作用として、IPに敏感な一部のプログラム(LAN内の探索や一部のログイン検証)が正しく動かないことがあり、その場合は該当ドメインを fake-ip のフィルターリストに追加すれば解決します。

設定が動くようになったのはまだ始まりに過ぎません。プロキシは長期利用する基盤インフラであり、10分ほどかけて低コストな保守の習慣を作っておく価値があります。ある日突然すべて繋がらなくなって慌てる事態を避けられます。

サブスク更新の方針

クライアントでサブスクの自動更新間隔を設定します。24時間に1回が妥当な既定値です。サービス提供者がサーバー変更を告知したときは、手動で即時更新を実行します。更新に失敗しても既存のノードが消えることはなく、クライアントは前回のキャッシュを使い続けるため、一時的な更新失敗を過度に心配する必要はありません。数日連続で失敗する場合のみ、サブスクアドレスがサービス提供者側でリセットされていないか確認してください。

ログ:トラブル対応の第一現場

すべてのクライアントにログパネルが用意されています。通常は info レベルで十分です。トラブル対応時には一時的に debug に切り替えると、各通信のルール一致・DNS解決・出口選択が確認できます。ログを見る基本の姿勢:問題を再現させ、最新の数行をすぐに確認する。キーワードは通常 error・timeout・refused です。特定できたら info に戻すことを忘れないでください。debugのログ量は多く、長期間有効にするとディスクを無駄に消費します。

バックアップと複数デバイスの一貫性

バックアップが必要なものは実はそう多くありません:サブスクリンク本体、自作したルールの断片、クライアントで変更した設定項目です。サブスクリンクはパスワード管理ツールに保存し、自作ルールは別途テキストとして保管しておきます。複数デバイスの場面では、設定ファイルを手動で運ぶのではなく、各デバイスがそれぞれ同じサブスクを取得する方式を優先してください。一部のクライアントはWebDAVバックアップに対応しており、UI設定も同期できます。3つの方式の詳しい比較は複数デバイス同期ノートを参照してください。

クライアントのアップグレード

クライアントの更新には通常コアの更新も伴うため、追随することを推奨します。新しいルールタイプやプロトコル対応はコアのバージョンに依存します。アップグレード前にリリースノートで設定の非互換に関する記載がないか確認してください。主要なクライアントはアップグレード時にサブスクと設定を保持しますが、大きなバージョンをまたぐ前にサブスクリンクをメモしておく手間はほぼゼロで、得られる安心感は絶大です。新バージョンのインストーラーは常にダウンロードページの該当プラットフォームから取得してください。

前8章を読み終えれば、日常利用に支障はなくなっています。この章では、さらに深く進むための3つの方向を、投資対効果の順に紹介します。

方向1:自分のルールを掌握する

サブスク付属のルールはサービス提供者による汎用的な設定であり、上級者への第一歩は自分自身のルール層を構築することです。多くの現代的なクライアントは「設定オーバーライド」や「Merge/Script」といった仕組みに対応しており、サブスクの原文を変更せずに、自作ルールをルールリストの先頭に注入できます——サブスクの更新であなたの修正が消えることはありません。小さく始めましょう:日常で出会った振り分けミスを1つずつ直していけば、3か月ほど積み重ねると自分の使い方に完全にマッチしたルール層が手に入ります。rule-providers(ルールセット)はより工程的な整理方法で、ルールを用途別に独立して更新できるリモートファイルに分割するもので、ルール数が100を超えたら導入する価値があります。

方向2:mihomoの拡張機能を理解する

mihomoコアはClashの伝統的な設定形式の上に多くの機能を拡張しています:より多くのプロトコル対応、より細かいDNS制御、プロセス単位のマッチルール、送信インターフェースのバインディングなどです。これらの機能はほとんど設定断片を手書きしないと有効化できず、公式ドキュメントが唯一の権威ある情報源です。学習方法は1項目ずつ実験することです:1回に1つのセクションだけ追加し、読み込みに成功したら次のセクションを追加します。設定にエラーがあればログが行番号まで正確に示してくれます。サーバーやソフトウェアルーターにコア+systemdを直接デプロイするのは、この方向の卒業課題です——GUIによる保険がない状態で、すべての動作を自分で書いたYAMLが決定します。

方向3:生態系を理解し、情報を見極める

Clashのエコシステムはプロジェクトが多く改名も頻繁で、検索して見つかる記事はすでにアーカイブされた古いプロジェクトを前提にしていることが多く、そのまま実行すると落とし穴にはまります。系譜を把握しておくこと——どのコアが活発に開発されているか、どのクライアントがそれを使っているか、どのプロジェクトがメンテナンス終了しているか——を知っておけば、記事の有効期限をすぐに判断できるようになります。オープンソース系譜のまとめが入り口です。その後は二次転載ではなく、各プロジェクトのリリースページを直接追うようにしてください。

推奨する学習の順序

1. チュートリアルページで基本の流れを一通り実行し、2週間安定して使う。
2. 第6章に戻り、サブスク付属のルールリストを理解し、実際に遭遇した振り分けミスを1つ修正する。
3. TUNを有効にし、fake-ipを理解して、コマンドラインや全体的なシーンをカバーする。
4. 設定オーバーライドを導入し、自分のルール層を構築する。
5. 空いている端末にコア単体をデプロイし、利用者から管理者への転換を果たす。

各ステップは前のステップで得た経験の上に成り立っており、順番を飛ばすことはお勧めしません。具体的な用語が分からなくなったら用語集に戻り、クライアントに関する疑問は横断比較を確認し、ツール本体は常にダウンロードページから入手してください。