Clash 使用ガイド:ゼロから極める九つのステージ

クライアント選び:プラットフォームごとに導入対象を決める

各プラットフォームには選べるクライアントが複数ありますが、大半のユーザーにとって選択の道筋は短いものです。下表はダウンロードページのパッケージ一覧と一致しており、プラットフォームごとに第一候補と代替候補を示しています。

なぜ Clash Plus を第一候補に推すのか

Clash Plus は現時点で Windows、macOS、Android、iOS の全プラットフォームをカバーする唯一の選択肢で、画面構成と操作ロジックが各端末で統一されています。パソコンで覚えたサブスクリプション管理、ノード切り替え、モード選択の操作は、スマホに移っても改めて覚え直す必要がありません。mihomo コアを内蔵しバージョンに合わせて更新され、日本語表示にも対応しているため、Clash に触れたばかりのユーザーにとって学習コストが最も低い選択です。複数デバイスを使うユーザーには特に、全プラットフォームで同じクライアントに統一することをお勧めします。トラブル対応の際も、覚えておく画面が一つで済みます。

代替候補クライアントの位置づけ

Clash Verge Rev と FlClash はどちらも活発にメンテナンスされているオープンソースクライアントです。前者はデスクトップ向けに機能が充実しており、設定の上書きやスクリプト拡張に対応しているため、設定をいじり込みたいユーザーに向いており、Linux デスクトップでも推奨されます。後者は Windows、macOS、Android、Linux を横断し、画面がシンプルです。Clash Nyanpasu は Windows 版のみ提供されています。Clash for Windows と ClashX Meta については、いずれも開発が終了しコアやセキュリティの更新が受けられないため、ダウンロードページにアーカイブとして残しているのは旧設定の移行用途のみで、新規ユーザーはこれらから始めるべきではありません。開発終了の経緯については、サイト内の関連記事も参照してください。

対象が決まったら、ダウンロードページの該当セクションでインストーラーを取得してください:Windows 版クライアント、macOS 版クライアント。その他のプラットフォームは同ページの下部に掲載しています。

インストール:五つのプラットフォームでの注意点

インストール自体は複雑ではありませんが、各プラットフォームにはつまずきやすいシステムの仕組みが一つずつあります。本章ではプラットフォームごとに説明するので、お使いのデバイスに対応する節だけを読めば十分です。

Windows

ダウンロードしたインストーラーを実行し、ウィザードに従って完了させます。二点注意があります。一つ目は、Windows の SmartScreen が「PC を保護しました」という警告を表示することがある点です。これはダウンロード数の少ない実行ファイルに対するシステムの一般的な通知で、「詳細情報」→「実行」をクリックして進めます。二つ目は、インストール先のパスに全角文字や空白を含むディレクトリを避けることです。一部のコア機能(サービスモードなど)はパスの影響を受けやすいためです。インストール完了後の初回起動時、クライアントはシステムトレイに常駐アイコンを表示します。メインウィンドウを閉じても終了したことにはならず、以降のプロキシのオン/オフはトレイまたはメイン画面から操作します。第七章の TUN モードを使う予定がある場合は、設定画面で事前にシステムサービスをインストールしておくと、コアが十分な権限で動作できます。

macOS

dmg イメージを開き、アプリのアイコンを「アプリケーション」フォルダにドラッグします。初回起動時に Gatekeeper が開発者確認を求める場合があり、ブロックされた場合は「システム設定 → プライバシーとセキュリティ」に進み、ページ下部の「このまま開く」を選びます。クライアントが初めてシステムプロキシまたは TUN をオンにする際、システムはネットワーク拡張のインストールやネットワーク設定変更の許可を求め、管理者パスワードの入力が必要になります——これは macOS の通常の権限フローであり、拒否するとプロキシは機能しません。Apple Silicon と Intel チップではインストーラーが異なり、ダウンロードページにそれぞれ掲載されているので、「この Mac について」に表示されるチップの種類に合わせて選んでください。

Android

apk をインストールする際、システムが「不明なアプリのインストールを許可」を求めることがあります。表示された設定画面でブラウザやファイル管理アプリに一度許可を与えれば済みます。初回にプロキシを起動する際、システムから VPN 接続のリクエストが表示されるので必ず許可してください——Android クライアントは VpnService を通じて通信を制御しているため、この権限を拒否すると全く動作しません。また、クライアントを電池の最適化から除外するリスト(設定 → 電池 → 制限なし)に追加することをお勧めします。追加しないと、一部端末メーカーのシステムが画面消灯後にバックグラウンドプロセスを終了してしまい、「しばらく放置するとプロキシが切れる」という症状になります。

iOS

iOS では App Store から Clash Plus をインストールします。ストアへのリンクと説明はダウンロードページの iOS セクションを参照してください。インストール後、初めてプロキシを起動する際にシステムから VPN 設定の追加が求められるので、ポップアップで許可し一度認証すれば、以降のオン/オフで再度許可する必要はありません。

Linux

デスクトップ向けディストリビューションでは deb パッケージを例にすると、ダウンロード後にターミナルで以下を実行します:

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

dpkg -i ではなく apt install を使う利点は、依存関係を自動的に解決してくれることです。インストール後はアプリケーションメニューから起動します。TUN モードを使う場合、クライアントが特権を持つサービスプロセスのインストールを案内してくれます。サーバーやデスクトップ環境のない場合は GUI クライアントは不要で、mihomo コアを直接実行すれば十分です。方法は第九章を参照してください。

サブスクリプション導入:クライアントにノードを取得させる

クライアントをインストールした直後は画面が空の状態です——ノードが一つもないのは、ノード情報がサブスクリプションを通じてサービス提供者から提供されるためです。本章では導入、更新、よくある失敗の三つを扱います。

三つの導入方法

最もよく使われるのはURL 導入です。サービス提供者のユーザーパネルでサブスクリプションのリンク(https://sub.example.com/token/clash.yaml のような形式)をコピーし、クライアントの「設定」または「サブスクリプション」ページを開いて新規作成/インポートをクリックし、リンクを貼り付けて確定します。クライアントは即座にその URL にリクエストを送り、設定をダウンロードして全ノードを一覧表示します。次にクリップボード導入です。一部のクライアントはクリップボードにサブスクリプションのリンクがあることを検知すると、インポートするかどうかを自動で尋ねてきます。これは本質的に URL 導入と同じです。最後はローカルファイル導入です。すでに手元に完成した YAML 設定がある場合(自分で管理しているものなど、第九章を参照)、ファイルとして直接読み込めます。この方式の設定は自動更新されないため、変更は手動で行う必要があります。

更新の仕組み

URL で導入したサブスクリプションは更新に対応しています。サブスクリプション項目の更新ボタンを手動でクリックすると、クライアントは URL に再度リクエストを送り、返ってきた内容でローカル設定全体を置き換えます。多くのクライアントは自動更新の間隔設定にも対応しており(よくある値は12時間または24時間)。提供者側がノードのアドレスを変更した場合、サブスクリプションを一度更新すれば再び使えるようになります。「すべてのノードが突然タイムアウトする」という現象に遭遇したら、サブスクリプションの更新が常に最初に試すべき対応です。注意点として、更新は設定全体の置き換えなので、サブスクリプションの設定に直接加えた手動変更は上書きされてしまいます。永続的なカスタマイズはクライアントの上書き(オーバーライド)機能か、独立したローカル設定を使って実現すべきです。

導入に失敗する三つの原因

一つ目はリンクのコピーが不完全な場合です。サブスクリプションの URL は通常長く、チャットツールで転送する際に途中で切れたり改行が混入したりしやすいので、失敗した場合はまずサービス提供者のパネルに戻ってコピーし直してください。二つ目はネットワークが不通な場合です。一部のサブスクリプションサーバーは特定のネットワーク条件下でしかアクセスできないことがあるため、ネットワーク環境を変えて再試行してみてください。三つ目はフォーマットの不一致です。サブスクリプションには Clash 形式とその他の形式があり、「解析失敗」と表示される場合はほとんどが Clash 形式以外のリンクを使ってしまっているケースです。サービス提供者のパネルには通常複数の形式のリンクが用意されているので、「Clash」と表示されているものを選んでください。

導入が成功したら最初の接続に進みます。ノードグループの選択、遅延テスト、プロキシの有効化と確認という手順は、ガイドページの接続の手順を参照してください。遅延値の詳しい読み方と確認方法は記事「Clash 初回接続の全手順」をご覧ください。

プロキシモードとポート:通信はどこから入り、どう振り分けられるか

ノードに接続した後、体感を左右するのは二つの要素です。コアがどのモードで通信の行き先を決めるか、システムの通信がどの入口を通ってコアに渡されるかです。

三つの動作モード

ほとんどの時間はルールモードにしておくべきです。国内向けの通信は直接接続で速度を確保し、海外向けの通信はルールに従ってプロキシを経由します。グローバルモードは日常の選択肢ではなく、検証用のツールです——長期間グローバルにしておくと、国内向けの通信もノードを経由してしまい、速度と通信量の両方で不利になります。モード切り替えの具体的な操作はガイドページのモード選択の手順を参照してください。

受信ポート

コアはローカルマシンのポートを監視して通信を受け取ります。設定ファイル冒頭のポート設定セクションが監視の挙動を決めます:

mixed-port: 7890        # HTTP と SOCKS5 の混合ポート。基本的にはこれに統一するのがおすすめ
allow-lan: false        # LAN 上の他デバイスからの接続を許可するか
mode: rule              # 起動時のデフォルトモード
log-level: info         # ログレベル:silent / error / warning / info / debug
external-controller: 127.0.0.1:9090   # RESTful 制御用インターフェース。パネル系ツールから利用

mixed-port は現在の主流の書き方で、同一ポートで HTTP と SOCKS5 両方のプロキシリクエストを受け付け、以前の設定で分かれていた port と socks-port を統合したものです。7890 は慣習上のデフォルト値であって必須ではなく、他のプログラムに占有されている場合(クライアントのログに bind 失敗と表示されます)は任意の空きポートに変更すれば問題ありませんが、システムプロキシの設定も合わせて変更する必要があります。allow-lan を有効にすると、同じ LAN 内のスマホやテレビがこのパソコンの IP とポートをゲートウェイプロキシとして指定でき、プロキシの出口を共有できます。公共のネットワーク環境では無効にしておくべきです。

システムプロキシ:アプリに通信を渡してもらう

「システムプロキシ」のスイッチをオンにすると、クライアントは OS のプロキシ設定を 127.0.0.1:7890 に向け、ブラウザなどシステムプロキシ設定に従うアプリは自動的にリクエストをコアへ送るようになります。ここに限界もあります。「システムプロキシに従う」アプリだけがカバーされ、多くのコマンドラインツールや一部のデスクトップソフトはこの設定を無視します——これこそが第七章の TUN モードが解決する問題です。システムプロキシをオンにしたのにブラウザやターミナルがプロキシを経由していない場合は、ブラウザとターミナルの二つの経路をそれぞれ確認してください。方法は「Clash のシステムプロキシが効かないときの確認方法」を参照してください。

TUN と DNS:すべての通信を制御する

第五章でシステムプロキシの限界について触れました。プロキシ設定に従わないプログラムには手が届きません。TUN モードはネットワーク層でこの問題を解決するもので、デスクトップでの使い方が本格的になる分岐点です。

TUN の動作方式

TUN を有効にすると、コアはシステム内に仮想ネットワークカードを作成し、ルーティングテーブルを調整してそれをデフォルトの出口に設定します。以降はすべてのネットワーク通信——アプリがプロキシ設定に対応しているかどうかにかかわらず——がまずこの仮想ネットワークカードに入り、コアがルールに従って処理します。効果としては「デバイス単位の制御」と同じで、コマンドラインツール、ゲーム、システムコンポーネントの通信もすべて分岐対象になります。代償として、より高い権限が必要になります。Windows ではサービスモードでコアコンポーネントをインストールする必要があり、macOS ではネットワーク拡張の許可が必要、Linux では特権サービスが必要です。各クライアントの設定画面にはそれぞれワンクリックインストールの入口が用意されています。TUN を有効にしたらシステムプロキシのスイッチはオフにしておくべきで、両方を同時に有効にしても意味がなく、ループが発生する可能性もあります。

DNS の制御と Fake-IP

TUN モードでは DNS を必ずコアに処理させる必要があります。そうしないと「通信はプロキシを経由しているのに、ドメイン名解析だけローカルから平文で送信されてしまう」という漏洩が発生し、ドメイン名ベースのルールも機能しなくなる可能性があります。設定ファイルの dns セクションがこの部分の動作を制御します:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
  nameserver:
    - https://doh.example.com/dns-query

enhanced-mode には二つの値があります。redir-host は従来の方式で、まず実際にドメイン名を解析し、その結果に基づいて転送します。挙動は直感的ですが解析の遅延が一回増え、解析結果が汚染される可能性もあります。fake-ip は、アプリがドメイン名を問い合わせた瞬間に予約済みのネットワーク範囲(デフォルトは 198.18.0.0/16)内の仮の IP アドレスを即座に返し、コアが「仮の IP ↔ ドメイン名」の対応を記録します。アプリがその仮の IP に接続すると、コアはドメイン名でルールをマッチングして転送します。利点は応答が速く、ルールのマッチングが常に元のドメイン名に基づく点です。副作用として、実際の IP に依存する一部の場面(LAN 上のデバイス探索や一部の内部サービス)で異常が起きることがあり、その場合は該当するドメインを fake-ip-filter に追加して除外すれば解決します。nameserver には暗号化 DNS(DoH/DoT)の利用をお勧めします。上流の解析が妨害されるのを避けられます。

TUN が必要になるタイミング

判断基準はシンプルです。ニーズがすべてブラウザ内で発生するのであれば、システムプロキシで十分であり、TUN による権限の複雑さを導入する必要はありません。ターミナルのコマンドライン、開発ツール、ゲーム、その他システムプロキシを読まないプログラムが関わってくる場合は、TUN のほうがソフトごとにプロキシ環境変数を設定するより徹底した解決策になります。TUN が有効になっているかを確認するには、ターミナルから直接リクエストを発行して出口 IP を確認します。方法はガイドページの確認手順を参照してください。

日常メンテナンス:更新、ログ、トラブル対応表

設定が動くようになった後は、日常的にやることは多くありませんが、正しく行えば突発的なトラブル対応の大半を避けられます。

更新しておくべき三つのもの

サブスクリプション:自動更新を有効にするか、数日おきに手動で更新する習慣をつけましょう。提供者側のノード変更は更新した後にしか同期されません。クライアントとコア:クライアントの更新には通常コアの更新も含まれ、新しいコアはプロトコルやルール機能の進化に追従します。クライアントが新バージョンを通知してきたら早めに更新することをお勧めします。Geo データベース:GEOIP などのルールが依存する地理データベースは、多くのクライアントがワンクリック更新の入口を提供しています。データベースが古くなると一部の IP の帰属判定にずれが生じます。

ログの見方を覚える

クライアントのログ/接続パネルは、最も直接的なトラブル対応の入口です。接続ページでは、アクティブな各接続がどのルールに命中し、どの出口を通っているかを確認できます——「このサイトはなぜ直接接続になったのか」といった疑問は一目で答えが分かります。ログページはコアのイベントを記録し、起動失敗、ポート占有、サブスクリプション取得エラーなどが明確な情報として残ります。各パネルの機能区分については「Clash クライアント画面ひととおり」で詳しく解説しています。問題を調査する前には、まずログレベルを一時的に debug に上げて詳細な情報を取得し、解決したら info に戻してください。

よくあるトラブルの早見表

バックアップと自動起動

サブスクリプション URL、上書きスクリプト、自分で管理しているローカル設定は、パスワード管理ツールや個人用ノートに控えを残しておくことをお勧めします。機種変更や再インストールの際にも数分で元の状態に復元できます。デスクトップでは設定画面で「起動時に自動起動」と「自動接続」をオンにしておくと、TUN やシステムプロキシと組み合わせて再起動後も手動操作が不要になります。サーバー用途での自動起動方法は次の章を参照してください。

上級者向けルート:設定を使う立場から管理する立場へ

ここまでで、クライアントレベルの機能はひととおり揃いました。次のステップは、設定に対する制御権を段階的に自分の手に取り戻していくことで、おおよそ三つのステップに分かれます。

ステップ1:上書きと手動での微調整

サブスクリプションの更新は設定全体を上書きしてしまうため、永続的なカスタマイズの正しいやり方はクライアントの上書き(Override)機能を使うことです。自分の変更内容(ルールの追加、DNS の調整、ポートの変更)を独立した断片として書いておけば、クライアントはサブスクリプションを更新するたびに自動でマージしてくれます。第六章の文法にある程度慣れてきたら、さらに完全に手書きのローカル設定を管理することもできます。proxies セクションはサブスクリプションから抜き出し、それ以外のセクションは自分のニーズに合わせて組み立てます。YAML を書く際に最大の落とし穴はインデントです——階層はスペースのみで表し、同じ階層のフィールドは厳密に揃えなければなりません。タブ一つ混入するだけで設定全体の解析が失敗します。詳細は設定構造の詳細解説を参照してください。

ステップ2:コアを直接実行する

GUI から離れて mihomo コアを直接実行する方法は、サーバーや長期無人稼働の場面に向いています。ダウンロードページのコアセクションから対応するアーキテクチャのバイナリを取得し、展開後に設定ディレクトリを指定して実行します:

# 設定ファイルは ~/.config/mihomo/config.yaml に配置
./mihomo -d ~/.config/mihomo

# 設定の文法チェックのみ行い、起動はしない
./mihomo -t -d ~/.config/mihomo

-t パラメータは覚えておく価値があります。設定を変更したらまず一度検証を実行するほうが、起動に失敗してからログを追うより効率的です。Linux では systemd のサービスユニットを一つ書けば、自動起動とクラッシュ時の自動再起動を実現できます。external-controller を有効にすれば、Web パネルで接続状況を遠隔確認したりノードを切り替えたりでき、GUI がない不便さを補えます。

ステップ3:ルーターやサブルーターへの導入

コアをルーターやサブルーターで動かせば、家庭内のすべてのデバイス——クライアントを入れられないテレビやゲーム機を含む——がネットワークに接続するだけで自動的に分岐機能を得られ、デバイス側の設定は不要になります。この道筋はハードウェア選定、透過プロキシ、DNS の制御、自動起動の常駐化など一連のテーマを含みます。メインルーターとサブルーターという二つの構成の選び方と完全な導入方法については「ルーターとサブルーターで Clash コアを直接動かす:mihomo 導入方式の概観」を参照してください。