ゼロから極める
Clash 完全ガイド

基本概念:まず4つの用語の役割を整理する

Clash の導入で詰まる人の9割は、操作そのものではなく用語で詰まっています。コア、クライアント、サブスクリプション、ルール。この4つの言葉がそれぞれ何を担っているのかを最初に整理すれば、以降の各章が一気に楽になります。

コアとクライアント:1つのエンジン、複数の顔

実際にトラフィックを処理するのはコアです。現在の主流実装は mihomo(コミュニティでは Clash Meta コアとも呼ばれます)。コアはコマンドラインプログラムで、YAML の設定ファイルを読み込み、ローカルポートを監視し、ルールに従って各接続をプロキシまたは直接接続に振り分けます。画面は持たず、見た目には関与せず、転送だけを担います。

デスクトップやスマートフォンで開く Clash Plus、Clash Verge Rev、FlClash といったアプリはクライアントです。内部でコアを組み込むか呼び出し、「設定ファイルを編集する」ことをスイッチやボタンに、「ログを見る」ことをグラフやリストに変換します。クライアントを変えてもコアは変わらないため、設定ファイルは異なるクライアント間でも基本的に共通です。だからこそ、本ガイドの原理部分はすべてのクライアントに当てはまります。

ノード・サブスクリプション・設定ファイル:3層のコンテナ

ノードは1台のプロキシサーバーの接続パラメータ(アドレス、ポート、プロトコル、パスワード)です。サブスクリプションは1つの URL で、アクセスすると複数のノード(通常は完成済みの設定にパッケージ化)が返されます。サービス提供者が管理しており、ノードが変更されてもサブスクリプションを更新するだけで済みます。設定ファイル(Profile)はコアが実際に読み込む YAML そのもので、ノードに加えてポート設定、DNS、プロキシグループ、ルールが含まれます。サブスクリプションから取得した内容は、最終的にこの1つの Profile にまとまります。3層の関係:ノードがサブスクリプションに収まり、サブスクリプションが設定ファイルを生成し、設定ファイルがコアに渡されます。

プロキシグループとルール:トラフィックの司令塔

プロキシグループは複数のノードを1つの選択可能なキューにまとめたもので、「手動選択」グループなら自分で選び、「自動速度測定」グループなら遅延に応じて自動切り替えします。ルールは上から順に照合される一覧で、ある接続がどのプロキシグループに入るか、あるいは直接接続するかを決めます。日本国内のサイトは直接接続、特定ドメインはプロキシ経由、それ以外はデフォルトルールで処理する、といった形です。ルールが命中した先に、トラフィックが渡されます。この仕組みは CH-06 で詳しく展開します。

用語はこれだけではありません。DNS 汚染、Fake-IP、GeoIP といった用語は、出てきたときに調べれば十分で、事前に覚える必要はありません。サイト内にはカテゴリ別に整理された用語集があり、本ガイドを読みながらいつでも乗り換えられます。

クライアント選び:プラットフォームごとに選ぶ

クライアント選びで答えるべき問いは2つだけです。使っているOSは何か、どこまでのカスタマイズが必要か。全プラットフォーム共通の一番の選択肢は Clash Plus です。Windows、macOS、Android、iOS すべてに対応版があり、UI が統一されていて、サブスク導入・モード切り替え・TUN の有効化もワンタップで済むよう設計されています。初心者から上級者まで十分対応できます。以下は本サイトのダウンロードページに収録されている、プラットフォーム別の組み合わせです。

選ぶときに見るポイント

3つの観点で十分です。メンテナンス状況――現在も活発に更新されているクライアントを優先しましょう。Clash for Windows と ClashX Meta は開発が停止しており、ダウンロードページにはアーカイブ入口を残していますが、新規ユーザーはここから始めないことを推奨します。コアのバージョン――クライアントが mihomo コアを使用しているかを確認すれば、新しいプロトコルや新しいルールタイプを完全にサポートできます。機能カバレッジ――TUN モードが必要ならそのプラットフォーム版で提供されているか確認し、細かいルール編集が必要なら Verge Rev のようなツール向けクライアントがより適しています。

項目別の詳細比較、UI スタイルの違い、移行時のアドバイスは、サイト内の横並び比較ページにまとめてあります。決まったらクライアント取得ページでプラットフォームごとにダウンロードしてください。

インストール:5つのプラットフォームの要点

インストール自体は難しくありませんが、各プラットフォームのセキュリティ機構が別々の場所で足を止めます。本章はプラットフォームごとのインストール経路と許可方法を整理しています。インストール後はまず1度起動し、メイン画面が開くことを確認してから、次章のサブスク導入に進んでください。

Windows

ダウンロードページの Windows 欄からインストーラーを取得し、ダブルクリックで実行します。インストール先は日本語・全角文字やスペースを含むディレクトリを避けると、後でコアが設定ファイルを読む際のパス問題を減らせます。初回起動時に SmartScreen の警告が出たら「詳細情報 → 実行」を選択。ファイアウォールがネットワーク権限を尋ねてきたら、プライベートネットワークとパブリックネットワークの両方にチェックを入れてください。入れないとローカルネットワーク関連機能が使えません。

macOS

dmg をダウンロードしたら、アプリを「アプリケーション」フォルダにドラッグします。アーキテクチャに注意:Apple Silicon(M シリーズチップ)は ARM 版、Intel 機種は x64 版を選んでください。間違えると明らかに動作が遅くなるか、起動できません。初回起動時に「開発元を確認できません」と表示されたら、「システム設定 → プライバシーとセキュリティ」を開き、ページ下部の「このまま開く」をクリックします。クライアントが初めてシステムプロキシを設定するか補助サービスをインストールする際、管理者パスワードを求められますが、1度入力すれば済みます。

Android

APK をダウンロードしてインストールする際、システムが「不明なアプリのインストールを許可」を求めるので、表示された設定画面でブラウザやファイル管理アプリに1度権限を付与してください。初めて接続をタップすると、システムから VPN 接続のリクエストが表示されます。これは Android がトラフィックを引き受ける標準的な仕組みなので、必ず許可してください。許可しないとプロキシが機能しません。国内メーカー系 OS では2点に注意:クライアントを電池最適化のホワイトリストに追加し、バックグラウンド動作を許可することで、画面ロック後にプロキシがシステムに強制終了されるのを防げます。

iOS

iOS 版 Clash Plus は App Store で配布されており、ダウンロードページの iOS 欄からストアページに進んでインストールします。初回起動時、案内に従って VPN 設定プロファイルを追加すると、システムから1度パスワードまたは Face ID の確認が求められます。インストール完了後のサブスク導入手順は他プラットフォームと同じで、次章で説明します。

Linux

デスクトップ版は Clash Verge Rev の deb パッケージが推奨です。sudo apt install ./パッケージファイル名.deb で1手順完了し、依存関係も自動解決されます。Arch 系は AUR からコミュニティメンテナンス版を取得できます。デスクトップ環境のないサーバーやルーターのシナリオでは GUI を入れず、mihomo コアを直接実行します。方法は CH-09 で説明します。

サブスクと設定ファイル:ノードをクライアントに読み込む

クライアントを入れただけでは空の車です。サブスクリプションこそが乗客です。本章では導入操作、Profile の内部構造、複数の設定を併存させる際の管理方法を説明します。

サブスク導入の標準手順

サービス提供者からサブスクリプション URL をコピーします。クライアントの「設定 / Profiles」ページを開き、「URL からインポート」を選び、リンクを貼り付けて確定します。クライアントがサブスクリプションの内容をダウンロードし、1つの Profile として解析して自動的に有効化します。導入成功の目印:プロキシページにノードリストが表示され、ノード名が空でないことです。導入が失敗した場合は、まずリンクが完全にコピーされているか確認してください(一部の入力欄は行末の文字を欠落させることがあります)。その後サブスク更新失敗のトラブルシューティング記事のカテゴリに沿って1つずつ確認してください。

Profile の3段構成

サブスクリプションから取得した YAML には通常3つの大きなセクションがあります。proxies がノードを定義し、proxy-groups がプロキシグループを定義し、rules が振り分けルールを定義します。骨格は以下の通りです(パラメータはすべて例です):

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "HK-01"
    type: ss
    server: server.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - HK-01

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

順に読むと:mixed-port はローカルの監視ポートで、HTTP と SOCKS のリクエストはすべてここから入ります。mode は起動時のプロキシモード。proxy-groups の中の PROXY という名前の select グループは、画面上で手動でノードを選ぶドロップダウンそのものです。rules は上から順に照合され、最後の MATCH がデフォルトルールとして受け止めます。この骨格が読めれば、どのサブスクリプションが生成する設定でも理解できます。

複数設定の併存と自動更新

複数のサブスクリプションを同時に導入できますが、ある時点で有効な Profile は1つだけで、切り替えると設定全体が入れ替わります。ノードとルールが一緒に切り替わり、2つの設定のルールが重なることはありません。管理のコツ:各設定に識別しやすい名前(サービス提供者名+用途)をつけ、使わなくなったものはすぐ削除して、誤って期限切れの設定に切り替えないようにしましょう。命名のコツとルールの上書き問題については複数プロファイルの切り替え管理記事を参照してください。

自動更新は設定の編集画面で設定でき、一般的なフィールド名は「更新間隔 / Update Interval」です。12〜24時間を推奨します。短すぎるとリクエストが無駄になり、長すぎるとサービス提供者側のノード入れ替えを取り逃します。手動更新の入口は通常、設定カードの更新ボタンにあります。更新前後でタイムスタンプの変化を確認し、実際に新しい内容を取得できたか確かめましょう。

プロキシモード:ルール・グローバル・直接接続の選び方

モードは「ルール一覧を判断に使うかどうか」を決めます。3つのモード、3つの動作:

普段はルールモードのままにしておきます。グローバルモードのまま日本国内のサイトにアクセスすると明らかに遅くなり、無駄に通信量も消費します。「何でもプロキシを経由してしまう」と感じたら、まずモードが Global に切り替わっていないか確認してください。

システムプロキシ:モードが機能する前提条件

モードを選んだだけでは不十分で、アプリ側にトラフィックを渡してもらう必要があります。クライアントの「システムプロキシ」スイッチを ON にすると、クライアントは OS に対して 127.0.0.1:7890(ポート番号は設定に準じます)をプロキシサーバーとして登録し、システムプロキシ設定に従うブラウザなどのアプリは自動的にこのポートへリクエストを送ります。ここには境界があります:システムプロキシに従うアプリだけが処理対象になります。多くのコマンドラインツールやゲームクライアントはこの設定を無視します。これこそが CH-07 の TUN モードが解決する問題です。

プロキシが有効かどうかの確認

感覚に頼らず、コマンドで検証しましょう。ターミナルで実行:

curl -x http://127.0.0.1:7890 -I https://www.google.com

HTTP/2 200 のようなステータス行が返れば、「ローカルポート → ノード → 目的のサイト」の経路全体が通っていることを意味します。止まったりエラーが出る場合は、問題はブラウザではなくノードか設定にあります。接続は成功しているのにページが開けない場合の完全なチェック順序は9項目チェックリストを参照してください。

ルール振り分け:トラフィックごとに適切な経路を選ぶ

ルール振り分けは、Clash が「ワンクリック全通しプロキシ」ツールと比べて根本的に異なる点です。同じ瞬間に、日本国内のトラフィックは直接接続、海外のトラフィックはプロキシ経由、広告ドメインは直接拒否といった処理が互いに干渉せず同時進行します。理解に必要なのは2点だけ――ルールがどんな形をしているか、どの順序で照合されるか。

よく使うルールタイプ

照合順序:上から下へ、最初に命中したら停止

ルール一覧は最初の1行から順に照合され、命中したら即実行、以降は見ません。したがって順序=優先度です。厳密なルールを前に、範囲の広いルールを後に、MATCH は必ず最後に置きます。典型的なルールブロックの例:

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

読み方:まず必ず直接接続すべきダウンロードドメインを許可し、次に GitHub の全ドメインと google を含むドメインをプロキシ経由にします。LAN のセグメントは直接接続かつ DNS 解決を行わず(no-resolve により内部アドレスが誤って解決対象になるのを防ぎます)、IP の所属地が中国本土のものは直接接続、残り全部はプロキシ経由です。あるサイトが誤ったルートに入った場合、上から順に、それを最初に命中させたルールを探せば、答えはその1行にあります。

カスタムルールの正しい入れ方

サブスクリプションは更新ごとに Profile 全体を上書きするため、サブスクファイル内のルールを直接編集しても、次の更新で消えてしまいます。正しい方法は、クライアントが提供する永続化の仕組みを使うことです。Clash Verge Rev の「グローバル拡張設定 / Merge」や、各クライアントのオーバーライド機能を使えば、自分のカスタムルールを毎回のサブスク更新後に自動的に先頭へ合成できます。原則は同じです:カスタムルールはサブスクのルールより前に置くことで、優先的に命中させられます。

GeoIP データベース

GEOIP,CN,DIRECT が機能するのは、ローカルにある IP 所属地データベースのおかげです。データベースが古くなると、新しく割り当てられた国内 IP を海外と誤判定し、「国内サイトなのになぜかプロキシ経由になる」という現象が起きます。クライアントの設定には通常「GeoIP / Geo データを更新」ボタンがあるので、1〜2ヶ月に1度クリックすれば十分です。更新後はコアを再起動して反映させてください。

TUN モード:システムプロキシが届かないトラフィックを引き受ける

CH-05 で述べたシステムプロキシの限界:それは「紳士協定」であり、従う気のあるアプリしか制約できません。コマンドラインツール、一部のデスクトップソフト、ゲームクライアントはよくこれを回避して直接通信します。TUN モードは発想を変え、ネットワーク層で問題を解決します。

原理:仮想ネットワークカード

TUN を有効にすると、コアがシステム内に仮想ネットワークカードを作成し、デフォルトルートをそこに向けます。以後すべての送信トラフィックは、アプリが対応していなくても、まずこのカードを経由してコアに入り、同じルールセットで振り分けられます。システムプロキシは「アプリが自分を見つけに来てくれる方式」、TUN は「すべての車がこの検問所を必ず通る方式」です。代償として、より高い権限が必要になります(Windows では通常サービスモードの導入が、macOS ではシステム拡張の許可が必要)。さらに DNS 設定を合わせる必要があります。

DNS と Fake-IP

TUN のシナリオではコア側の DNS を必ず有効化する必要があります。そうしないとドメイン解決がコアを経由せず、ルール内のドメインタイプが機能しなくなります。推奨は Fake-IP モードです。コアが先に予約セグメントの偽 IP を返して接続をすぐに確立させ、実際の解決は転送時まで遅らせることで、待ち時間を1回省けます。設定例:

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

有効化の手順と検証

主要なクライアントは上記の内容をすでにスイッチ化しているので、手書きの必要はありません。Windows:先に設定で「サービスモード」をインストール(管理者権限が必要)し、状態が実行中になったら TUN スイッチを ON にします。macOS:TUN スイッチを ON にすると、システムの案内に従ってネットワーク拡張を許可し、パスワードを1度入力します。検証方法:システムプロキシのスイッチを OFF にして TUN だけを残し、システムプロキシを使わないコマンド(例:nslookup github.com)をターミナルで実行します。解決結果が 198.18 で始まる偽 IP セグメントであれば、DNS ハイジャックが機能し TUN が正しく動作していることを意味します。

日常メンテナンス:プロキシを長期安定させるための定期作業

設定が済んだらそこからが本番です。プロキシは長期運用する基盤なので、周期的にいくつかの小さな作業をしておくことで、「昨日まで普通に動いていたのに」という故障の大半を避けられます。

ノードの速度測定と自動切り替え

プロキシページの遅延テストボタンは全ノードに探索リクエストを1回送信し、数値は「ローカル → ノード → テスト先」の往復ミリ秒数を示します。経験値としては、200ms 以内なら日常的にスムーズ、500ms を超えるかタイムアウトが表示されたら切り替えましょう。手動で選ぶのが手間なら、よく使うアプリを url-test タイプの自動速度測定グループに向けておけば、コアが周期的に最適なものを選んでくれます。遅延は応答速度しか反映せず帯域幅を表すものではないので、動画がスムーズに再生できるかどうかはノード自体の品質も見る必要があります。

ログを読んで問題を特定する

クライアントのログ(または接続)ページは調査の第一現場です。各レコードには宛先ドメイン、命中したルール、使われたノードが含まれます。「あるサイトが開けない」場合は、まずここでドメインを検索してください。DIRECT に命中しているのにプロキシが必要な場合はルールの問題、プロキシグループに命中しているのにタイムアウトする場合はノードの問題です。方向が決まれば、修正は速く進みます。

自動起動

デスクトップ版では設定で「起動時に自動実行」を ON にし、通常は「サイレント起動」と組み合わせてトレイアイコンだけを残します。Windows で自動起動に失敗する場合は、タスクマネージャーのスタートアップ項目がサードパーティの最適化ソフトによって無効化されていないか確認してください。Android は CH-03 のバックグラウンド維持設定を参照してください。その他の頻出する問題は、よくある質問ページで「基礎知識 / インストール設定 / 使い方のコツ / トラブル対応」の4分類に整理してあります。

上級ロードマップ:使えるようになる→理解する→手書きできるようになる

ここまでの8章を終えれば、日常的な利用に障害はなくなっています。さらに先へ進むなら、3つの方向を順に進めましょう。

方向1:設定の手書きとオーバーライド

サブスクリプションをブラックボックスとして扱うのをやめましょう。CH-04 の骨格を、現在有効になっている Profile と照らし合わせながら、段落ごとに理解します。次に小さな変更から始めます――オーバーライド機能で自分のルールを1本追加する、あるプロキシグループを select から url-test に変更する、DNS の nameserver リストを調整する。1箇所変更したらリロードし、ログで期待通りの動作か確認します。設定を手書きできるようになれば、どのクライアントを使っても本質的に同じものを操作できます。

方向2:コアを直接実行する

サーバー、NAS、ルーターには GUI がないため、mihomo コアを直接実行します。ダウンロードページのコア欄から対応するアーキテクチャの圧縮ファイルを取得し、展開後:

mkdir -p ~/.config/mihomo
mv config.yaml ~/.config/mihomo/
./mihomo -d ~/.config/mihomo

-d は作業ディレクトリを指定し、コアはそこから config.yaml と Geo データファイルを読み込みます。フォアグラウンドで動作確認ができたら、systemd サービスを設定して自動起動とクラッシュ時の再起動を実現します。同じ LAN 内の他のデバイスからは、このマシンの IP とポートをプロキシ先に指定します。設定に allow-lan: true を忘れずに入れれば、1台のマシンで家中のデバイスを支えられます。

方向3:外部コントロール API

設定に external-controller: 127.0.0.1:9090 を宣言すると、コアが RESTful なインターフェース群を公開します。ノードの切り替え、接続の照会、設定のリロードなどが HTTP リクエストで完結します:

curl http://127.0.0.1:9090/proxies

各種 Web パネル(metacubexd など)はこの API の上に構築されています。これを使いこなせば、定時切り替えや異常アラートといった自動化のスクリプトを書けるようになります。ここまで来れば、利用者から構築者へと歩みを進めたことになります。

ロードマップのまとめ

1. 1つの GUI クライアントに慣れ、ルールモードで日常的に意識せず使えるようになる(CH-01〜05);
2. ルールとログを読めるようになり、「このサイトがなぜ違う経路に入ったか」を自分で特定できる(CH-06、08);
3. TUN を有効にし、ネットワーク層での引き受けと DNS の連携を理解する(CH-07);
4. 設定を手書きし、コアを直接実行し、API を自動化する(本章)。

どの段階も前の段階の上に成り立っています。今どの駅にいるかに応じてその駅の道具を使い、実際に手を動かす必要があるときは使い方ガイドを見ながら操作し、道具選びはクライアント取得ページで行ってください。路線図はここにあります。発車の時間はあなたが決めるものです。