MANUAL · インストール完全ガイド

Clash 全プラットフォーム インストール・設定完全ガイド

五つのプラットフォーム、各1章構成。ダウンロード・インストール・サブスクリプション導入から、システムプロキシとTUNモード、各OS特有の落とし穴まで、マニュアルとして参照できるように整理した。冒頭2章は共通の準備知識とプロキシモードの仕組み、最終章は設定トラブル対処。

CH 01–08 · 全8章 · 必要な章から読んでOK

本ページと使い方ガイドは役割が異なる。使い方ガイドは最短ルートで、十数分で初回接続まで進められる内容。本ページは体系的なマニュアルとして、各プラットフォームの手順、仕組みの背景、既知の問題を網羅し、インストール中いつでも参照できるようにまとめている。Clash に初めて触れる場合はまず使い方ガイドを一通り試し、詰まったら本ページの該当章に戻ってくるとよい。全クライアントのインストーラーへの入り口はクライアントダウンロードページに統一されており、本ページの本文では手順のみを説明し、直接のダウンロードリンクは置かない。

CH 01準備:インストール前に揃えておくもの

揃えておくべき3つのもの

1つ目はサブスクリプションリンク。Clash クライアント自体は通信を振り分けるツールにすぎず、ノード情報はサブスクリプション提供元から配信される。サブスクリプションリンクは HTTPS のアドレスで、サービス提供元のユーザーパネルに表示される。インストールを始める前にこのリンクを手元に用意し、途中で途切れず完全にコピーされているか確認しておく——リンクの欠落はインポート失敗の最大の原因で、詳細はサブスクリプション解析失敗チェックリストを参照。

2つ目は使用する端末に合ったクライアント。同じサブスクリプションは複数の端末・複数のプラットフォームで使い回せるが、プラットフォームごとにクライアントが異なるため、選び方は次の表を参考にしてほしい。3つ目は数分間中断されない時間。インストール自体は短時間で済み、時間がかかるのは主に初回の権限承認と接続確認の部分。

クライアントの選び方

各プラットフォームで使えるクライアントと推奨順は以下の通りで、ダウンロードページと一致している。Clash Plus はデスクトップとモバイルの両方をカバーする全プラットフォーム共通の第一候補で、その他のクライアントはプラットフォームごとに得意分野が異なる。

プラットフォーム第一候補代替候補説明
WindowsClash PlusClash Verge Rev / FlClash / Clash NyanpasuClash for Windows は開発終了、アーカイブとしてのみ残存
macOSClash PlusClash Verge Rev / FlClashClashX Meta は開発終了、アーカイブとしてのみ残存
AndroidClash PlusClash Meta for Android / FlClash / Surfboardいずれも直接インストールする APK パッケージ
iOSClash PlusApp Store で配信、詳細はiOS ダウンロード欄を参照
LinuxClash Verge RevFlClashGUI なしのサーバーでは Mihomo コアを直接デプロイ

選び方の原則:同じ端末には1つのクライアントだけをインストールすればよい。複数のクライアントを同時に動かすとポートやシステムプロキシ設定を取り合ってしまい、トラブル対処の際に最初に確認すべき状況になる。開発が終了したクライアントを新たにインストールするのは推奨しない。既存ユーザーの移行手順はダウンロードページの該当カードに記載されている。

基本用語のクイックリファレンス

以降で繰り返し登場する用語をここで揃えておく。コア:実際に通信を処理する中核プログラムで、現在の主流クライアントに内蔵されているのは Mihomo コア、GUI はその外側の皮にすぎない。ノード:利用可能な1本のプロキシ経路。ポリシーグループ:複数のノードを1つにまとめ、自動速度測定やフェイルオーバーといった選択ロジックを定義したもの。ルール:あるリクエストがどのポリシーグループを経由するかを決める判定条件。この4つの関係やその他の概念は用語集を参照。ポリシーグループの3種類の詳細はポリシーグループの種類解説を参照。

注意:サブスクリプションリンクはアカウント認証情報と同等の重要度を持つ。公開グループへの投稿やスクリーンショットでの外部流出は避けること。漏洩すると誰でもそれを使ってノードを取得し、通信量を消費できてしまう。

CH 02プロキシモード:システムプロキシと TUN の違い

5つのプラットフォームすべての設定手順で「システムプロキシ」と「TUN モード」という2つのスイッチが登場する。この章では先に仕組みを説明し、以降の各プラットフォーム章では操作場所のみを述べる。

システムプロキシの動作方式

システムプロキシを有効にすると、クライアントが監視しているローカルポート(デフォルト 7890)が OS のプロキシ設定に書き込まれる。ブラウザなどシステムプロキシ設定に従うアプリケーションは、まずこのポートにリクエストを送り、Clash がルールに基づいて振り分ける。利点は特別な権限が不要でスイッチが即時反映されること。制約は「システムプロキシに従う」アプリにしか効かない点で、コマンドラインツールやゲーム、バックグラウンドサービスの多くはこの層を経由せず直接通信してしまう。

TUN モードの動作方式

TUN モードはシステム内に仮想ネットワークアダプタを作成し、デフォルトルートをそこに向ける。これにより、システムプロキシに従うかどうかを問わずすべてのアプリの通信がこの仮想アダプタを経由して Clash に入る。その代償として高い権限が必要になる:Windows ではシステムサービスをインストールし管理者権限で承認、macOS ではシステム拡張を許可、Android と iOS では VPN 許可のポップアップとして現れる。TUN とシステムプロキシはどちらか一方を選べばよく、同時に有効にしても効果が重なるわけではない。

比較項目システムプロキシTUN モード
対象範囲システムプロキシ設定に従うアプリすべてのアプリとシステムプロセス
権限要件一般ユーザー権限管理者・システム拡張・VPN 許可
典型的な用途日常のブラウザ利用コマンドラインツール、ゲーム、プロキシ設定を無視するアプリ
終了後の残留異常終了時にプロキシ設定が残る場合がある仮想アダプタはサービス停止と同時に削除される

ルール・グローバル・直接接続

上記2つのスイッチとは独立した軸として、送信モードがある。ルールモードはルールセクションを1件ずつ照合し、マッチした条件に従って振り分ける、日常利用の推奨設定。グローバルモードは全通信が同じポリシーグループを経由し、「ルールがマッチしていないのでは」を検証する際に一時的に使う。直接接続モードは全通信がプロキシを経由しない。トラブル対処での定番手法は一時的にグローバルへ切り替えることで、グローバルでは使えてルールモードで使えない場合、問題はルールセクションに絞られる。設定ファイルの各セクションの意味はYAML構成セクション解説を参照。

CH 03Windows:インストール・サブスクリプション・サービスモード

ダウンロードとインストール

ダウンロードページ Windows 欄からインストーラーを取得する。第一候補は Clash Plus、代替候補は Clash Verge Rev、FlClash、Clash Nyanpasu。インストーラーは標準的なウィザード形式で、基本はそのまま「次へ」で進めればよい。インストール先はデフォルトのままにしておくことを推奨し、日本語や空白を含む深い階層のフォルダは避ける——一部のコンポーネントはパスに敏感なため。

初回起動時に Windows が青い SmartScreen の警告を表示することがある。これはダウンロード元の実績が新しい実行ファイルに対する OS の一般的な保護動作で、「詳細情報」→「実行」をクリックすれば続行できる。一部のセキュリティソフトはプロキシ系ソフトの仮想アダプタドライバを不審な挙動として検知することがあるが、インストールフォルダを信頼リストに追加すればよく、セキュリティソフト自体を無効にする必要はない。

サブスクリプションのインポート

クライアントを開き、「サブスクリプション」または「設定」ページに進み、サブスクリプションリンクを URL 入力欄に貼り付けてインポートをクリックする。クライアントがサブスクリプションをダウンロード・解析し、成功するとプロキシページにノードとポリシーグループの一覧が表示される。インポートでエラーが出る、または一覧が空の場合は、まずリンクを丸ごと再コピーして試し、それでも解決しなければサブスクリプションチェックリストに沿って項目ごとに確認する。すぐに再インストールする必要はない。

システムプロキシと TUN

日常利用ではメイン画面で「システムプロキシ」スイッチを ON にすれば、ブラウザの通信が Clash を経由するようになる。コマンドラインやゲームの通信も接管したい場合は TUN に切り替える:主流のクライアントは TUN が依存するシステムサービスをワンクリックでインストールできるようにしており、初回有効化時に管理者権限(UAC ダイアログ)を求められる。承認後はサービスが常駐し、以後は TUN の ON/OFF で再度ポップアップは出ない。TUN を有効にする前にシステムプロキシのスイッチは切っておくこと。

プラットフォーム特有の問題

ポート競合:起動時に 7890 や 9090 ポートが使用中というエラーが出た場合、まずどのプロセスが使っているかを調べてから、プロセスを終了するかポートを変更するかを判断する。管理者権限でターミナルを開いて実行:

netstat -ano | findstr :7890
tasklist | findstr <前の手順で確認した PID>

1つ目のコマンドの最終列が占有プロセスの PID、2つ目でプロセス名が分かる。よくある占有元は終了しきれていない別のプロキシクライアント。ポート変更の全手順はポート競合対処の全手順を参照。

プロキシ設定の残留:クライアントがクラッシュしたり強制終了されたりすると、システムプロキシを元に戻す処理が実行されないことがあり、終了後にすべてのウェブページが開けなくなる症状として現れる。手動での復旧:「設定 → ネットワークとインターネット → プロキシ」で「プロキシサーバーを使う」をオフにする。自動起動:クライアント設定で自動起動と「サイレント起動」を有効にしておくと、起動ごとにメイン画面がポップアップしなくなる。

CH 04macOS:チップアーキテクチャ・Gatekeeper・システム拡張

先にチップアーキテクチャを確認してからダウンロード

macOS 版のインストーラーは Apple Silicon(M シリーズチップ)と Intel の2種類に分かれ、間違ったアーキテクチャを入れると明らかに遅くなったり起動できなくなったりする。機種が分からない場合はターミナルで実行:

uname -m

arm64 が表示されたら Apple Silicon 版、x86_64 なら Intel 版を選ぶ。その後ダウンロードページ macOS 欄で対応する dmg を取得する。第一候補は Clash Plus、代替候補は Clash Verge Rev と FlClash。

インストールと初回起動

dmg を開き、アプリのアイコンを Applications フォルダにドラッグし、Launchpad またはアプリケーションフォルダから起動する。初回起動時に Gatekeeper が「開発元を確認できません」と表示することがある:「システム設定 → プライバシーとセキュリティ」の下部で、ブロックされたアプリの横にある「このまま開く」を選んで確認する。「アプリが破損しているため開けません」と表示された場合は、ダウンロードファイルに隔離属性が付与されているためで、ターミナルで以下のコマンドを実行してから再度開く(パスは実際のアプリ名に置き換える):

xattr -cr /Applications/クライアント名.app

サブスクリプションのインポートとシステムプロキシ

サブスクリプションのインポート手順は Windows と同じ:サブスクリプションページにリンクを貼り付けてインポートし、ノード一覧が表示されるのを確認する。「システムプロキシ」を有効にすると、macOS はネットワーク設定の変更許可を求めるダイアログを表示するので、ログインパスワードを入力して一度確認すればよい。有効化後は「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」で HTTP/HTTPS プロキシが 127.0.0.1 の対応ポートを指していることが確認できる。これがスイッチが実際に有効になっているかを確認する確実な方法。

TUN とシステム拡張

macOS で TUN を有効にするにはシステム拡張またはネットワーク拡張の許可が必要:初回有効化時の案内に従い「システム設定 → プライバシーとセキュリティ」で該当拡張の読み込みを許可する。機種によってはクライアントの再起動が一度必要になる。複数の「ネットワークロケーション」を使っていたり有線と無線を同時接続している場合、プロキシ設定はネットワークサービスごとに保存される。ネットワークを切り替えた後にプロキシが効かなくなったら、まず現在有効なネットワークサービスが設定時と同じものかを確認する。

プラットフォーム特有の問題

システム更新後に拡張の許可がリセットされることがあり、TUN が突然使えなくなったらまず「プライバシーとセキュリティ」で拡張が許可リストに残っているか確認する。クライアントのアンインストールはアプリ内蔵のアンインストール機能を使うか、アプリ内でシステムプロキシと TUN を先にオフにしてから削除するのがよい。そのままゴミ箱に入れるとプロキシ設定が残る場合があり、復旧方法は前節と同様に、ネットワーク詳細でプロキシを手動でオフにすればよい。

CH 05Linux:デスクトップクライアントとサーバー導入

デスクトップ版:Clash Verge Rev または FlClash をインストール

Debian/Ubuntu 系ではダウンロードページ Linux 欄から deb パッケージを取得してインストールする:

sudo dpkg -i ダウンロードしたパッケージ.deb
sudo apt-get -f install

2行目は依存関係を自動的に補完するためのコマンド。RPM 系ディストリビューションでは対応する rpm パッケージを、そのディストリビューション標準のパッケージマネージャでインストールすればよい。インストール後はアプリケーションメニューから起動し、サブスクリプションのインポート手順は他のデスクトップ環境と同じ。

デスクトップ環境のシステムプロキシ

Linux には統一された「システムプロキシ」の設定箇所がなく、クライアントのシステムプロキシスイッチは GNOME や KDE のデスクトッププロキシ設定に対して有効だが、その設定に従う GUI アプリにしか影響しない。ターミナルセッションでは別途環境変数を設定する必要がある:

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

これらの変数は現在のターミナルセッションにのみ有効で、ターミナルを閉じると無効になる。恒常的に有効にしたい場合は shell の設定ファイルに書き込めばよいが、もっと手間が少ないのは TUN モードでマシン全体を接管する方法。Linux で TUN を有効にするにも権限昇格が必要で、クライアントがサービスのインストールや root 権限のリクエストを案内してくれる。

GUI なしサーバー:Mihomo コアを直接デプロイ

サーバーやルーター用途では GUI クライアントは不要で、Mihomo コアを直接動かす。コアパッケージはダウンロードページのコア欄に用意されている。基本的な手順:バイナリを /usr/local/bin/mihomo に展開し、設定ファイルを /etc/mihomo/config.yaml に配置してから、systemd サービスを1つ作成する:

[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

/etc/systemd/system/mihomo.service として保存した後、以下を実行:

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo

ステータスが active (running) と表示されれば起動成功。設定ファイルの書式はデスクトップクライアントで使うものと完全に共通で、各セクションの意味は設定ファイル構成の逐次解説を参照。

プラットフォーム特有の問題

53番ポートの競合:設定で DNS モジュールが 53 番ポートを監視するようにしていると systemd-resolved と衝突し、起動ログに address already in use と出る。対処は二択:設定内の DNS 監視を 0.0.0.0:1053 など 53 以外のポートに変更するか、systemd-resolved のスタブリスナーを無効化する。ポート使用状況の確認:

ss -lntp | grep 7890

権限の問題:TUN モードはプロセスに NET_ADMIN ケーパビリティを要求する。systemd 方式では root で実行されるため自然に満たされる。手動でフォアグラウンド実行する際は sudo を付け忘れないこと。

CH 06Android:APK インストールと VPN 許可

APK のインストール

ダウンロードページ Android 欄から APK を取得する。第一候補は Clash Plus、代替候補は Clash Meta for Android、FlClash、Surfboard。ブラウザでダウンロードした APK を初めてインストールする際、システムが「不明なアプリのインストール」権限を求めてくる:ポップアップの案内に従い、使用中のブラウザまたはファイル管理アプリにこの権限を付与し、戻ってインストールを続行すればよい。これはストア以外の経路で配布されたパッケージに対する Android の標準的な流れ。

サブスクリプションのインポートと初回接続

アプリを開き、サブスクリプション/設定ページにリンクを貼り付けてインポートする。スマートフォンでよく使われる流れは、リンクをコピーしてそのままアプリを開くやり方で、多くのクライアントはクリップボードを検知してワンタップインポートを提案してくれる。初めて接続ボタンをタップすると、システムが「〇〇が VPN 接続の設定を求めています」という許可ダイアログを表示する——Android 上の Clash はシステムの VPN インターフェースを通じて通信を接管しており、デスクトップの TUN モードに相当する。「OK」を押しステータスバーに鍵のアイコンが出れば接管成功。このダイアログが出ない、または誤って拒否した場合は、「設定 → ネットワーク → VPN」で該当項目を削除してから再接続すれば再度表示される。

プラットフォーム特有の問題

バックグラウンドでの強制終了:メーカー独自 OS はバックグラウンド常駐アプリの掃除が積極的で、画面ロックから一定時間後にプロキシが切断される症状が出る。対処:クライアントを電池最適化の対象外に設定し、バックグラウンド動作と自動起動を許可する。設定項目の名称はメーカーごとに異なり、一般に「バッテリー」や「アプリ管理」内にある。プライベート DNS の競合:システムの「プライベート DNS」が特定のホスト名に設定されていると、クライアントの DNS 接管と干渉することがある。解析異常を調査する際はプライベート DNS を一旦「自動」に戻してから再テストする。アプリ別プロキシ:クライアント設定でどのアプリをプロキシ経由にし、どのアプリを直接接続にするか指定できる。銀行系アプリがプロキシに敏感な場合は、プロキシ全体をオフにするより直接接続リストに追加する方が手間が少ない。

CH 07iOS:App Store での取得と VPN 設定

クライアントの取得

iOS 版の Clash Plus は App Store で配信されており、ストアへの入り口と説明はダウンロードページ iOS 欄を参照。App Store でインストールを完了すればアプリの更新はストアが自動で担当し、インストーラーを手動で管理する必要がない。これが iOS と他プラットフォームの手順における最大の違い。

初回設定と許可

アプリを開き、サブスクリプションページにリンクを貼り付けてインポートする流れは Android と同じ。初めて接続する際、システムが「VPN 構成の追加」を要求し、Face ID またはパスコードでの認証を求める——iOS 上のすべてのプロキシクライアントはシステムの VPN フレームワークを通じて動作するため、この許可は必須の手順。完了すると「設定 → VPN」に該当項目が表示され、ステータスバーに VPN のマークが出れば接管成功。以降の接続・切断はアプリ内での操作でも、システム設定の VPN スイッチでも行える。

プラットフォーム特有の問題

ネットワーク切り替え後の切断:Wi-Fi とモバイルデータを切り替えると VPN トンネルが再構築され、たまにアプリに戻って手動で再接続が必要になる。クライアントに「オンデマンド接続」の選択肢があれば有効にしておくのがよく、必要な時にシステムが自動でトンネルを立ち上げてくれる。サブスクリプションの更新:iOS のバックグラウンド更新はシステムのスケジューリングに制限されるため、長時間アプリを開かないとサブスクリプションが期限切れになることがある。ノードが全て応答なしになった場合は、まずアプリを開いて手動でサブスクリプションを更新してから再テストする。ルールと設定:iOS 版クライアントが使うサブスクリプションと設定の書式はデスクトップ版と完全に共通で、ポリシーグループやルールの調整方法もそのまま使える。iOS 専用の設定を別途用意する必要はない。

CH 08設定に関するよくある問題:インストール後のトラブル対処マニュアル

YAML のインデントとフィールド名の誤字

設定ファイルを手動で編集する際、最も頻発するミスはインデント:YAML は半角スペース2つで階層を表現し、Tab 文字は禁止。同じ階層のフィールドは揃っている必要があり、リスト項目の - の後ろには半角スペースを1つ入れる。クライアントが「設定の読み込みに失敗しました」と表示して行番号を示した場合、まずその行と周囲のインデントが揃っているかを確認し、次にフィールド名の誤字を確認する——proxy-groupsproxy-group のように1文字違いで書いてしまうミスは、エラーメッセージだけでは分かりにくいことが多い。最小限の共通セクションの例:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-port は HTTP と SOCKS を同時に受け付ける混合ポート、external-controller はローカル管理インターフェース。この2つのポートが前述した各プラットフォームの「ポート競合」問題の当事者であり、どちらかを変更したらクライアントの再起動が必要。分割解説の全文はYAML構成セクション解説を参照。

ポート競合の共通判断手順

3つのプラットフォームでの使用状況確認コマンドはすでに各章で紹介済み(Windows は netstat、macOS/Linux は ss または lsof)。共通の判断手順:まず別のプロキシクライアントが終了しきれていないかを確認する。そうであれば古いクライアントを終了する。そうでなければローカルのポートを変更する——設定ファイルまたはクライアント設定で 7890 を他の空きポートに変更し、そのポートに依存している箇所(ブラウザ拡張機能、ターミナルの環境変数)も合わせて更新する。全手順はポート競合対処の専門記事を参照。

サブスクリプション関連の問題

インポートエラー、ノード一覧が空、更新失敗、これら3種類の症状はいずれも同じ確認の連鎖:リンクの完全性 → 返ってくる内容の形式 → サブスクリプションの期限 → クライアントの互換性。項目ごとの確認方法はサブスクリプションチェックリストを参照。ここで一つ汎用的なコツを補足する:ブラウザで直接サブスクリプションリンクを開いてみて、エラーページではなく文字列が返ってくるならリンク自体は有効で、問題はクライアント側にある。エラーページや空白が返る場合は、サブスクリプション提供元に直接連絡すること。

プロキシは有効なのにブラウザが証明書エラーを表示する

プロキシを有効にした後、ウェブページに「この接続はプライベートではありません」といった表示が出る場合、多くはクライアントの設定とは無関係:まずシステムの時刻を正しく合わせる(数分のズレでも証明書検証が失敗することがある)。それでも直らなければ別のノードに切り替えて再試行し、それでも再現するなら他の原因を検討する。エラーの種類別の切り分け方法は証明書エラー切り分けの専門記事を参照。

ポリシーグループが選べない・ノード切り替えが反映されない

ルールモードでは、手動でのノード切り替えは対応するポリシーグループ内で行う必要があり、ノード一覧から直接クリックするのではない——リクエストが実際にマッチするのはポリシーグループで、そのグループ内で現在選択されているノードが実際の出口になる。url-test タイプのグループは速度測定結果に基づいて自動選択されるため、手動指定が効かないのは設計上の仕様であり、手動で制御したい場合は使用頻度の高いグループを select タイプに設定すること。3種類のポリシーグループの仕組みと設定例はポリシーグループ詳解を参照。

それでも解決しない場合

症状別に分類したその他の Q&A はよくある質問ページに、概念的な疑問は用語集で確認できる。問題を報告する際は、プラットフォームとクライアント名・再現手順・クライアントログのエラー行の3点を添えると、やり取りを最短で済ませられる。