Clashクライアント初回インストール：システムアーキテクチャの選び方・権限確認・初期設定チェックリスト

インストール前：クライアント、カーネル、設定ファイルの入手元を確認

「Clashのインストール方法」を検索すると、ダウンロード一覧にデスクトップクライアント、Androidアプリ、単体カーネルが同時に表示されることがあります。ファイルサイズだけで選んではいけません。クライアントは画面、サブスクリプション更新、設定管理を提供し、カーネルはプロキシ接続、ルール判定、DNSなどの処理を担当します。カーネルの実行ファイルだけを入手しても、通常はトレイメニュー付きのデスクトップ画面は利用できません。

Clash Metaはその後、mihomoという名称で開発が続いていますが、クライアントによって搭載カーネル、バージョン、機能スイッチは異なります。設定に tun、proxy-providers、特定のプロトコル項目が含まれていても、Clashと名の付くすべてのアプリで読み込めるとは限りません。初回インストール時にクライアントとカーネルのバージョンを記録しておくと、後で互換性を判断できます。

まずネットワークの基準状態を確認：既存のプロキシやVPNを無効にし、学校やホテルのネットワークでWeb認証を済ませてから、普段直接アクセスできるサイトを開きます。
既存の設定を保存：同種のアプリを使ったことがある場合は、設定、オーバーライド、ルールを先にエクスポートし、以前のシステムプロキシ設定とポートを記録します。
リリースノートを確認：対象OSのバージョン、プロセッサアーキテクチャ、必要なランタイムを確認し、古いチュートリアルの最低要件を新しいインストーラーにそのまま適用しないでください。
サブスクリプション情報を保護：サブスクリプションURLにはアクセス情報が含まれることが多いため、完全なURLを公開スクリーンショットや不慣れなオンライン変換サービスへ送らないでください。

システムアーキテクチャの選択：x64、ARM64、インストーラーパッケージの形式

アーキテクチャはソフトウェアが対象とするプロセッサ命令セットを指し、通信速度やOSのバージョンを意味しません。x64とamd64は通常、同じ64ビットx86系アーキテクチャを示します。arm64とaarch64は通常、64ビットARMを示します。インストーラーをダウンロードできても、現在の端末で実行できるとは限りません。

プラットフォーム	確認場所またはコマンド	選択の基準
Windows 11	「設定」→「システム」→「システム情報」→「システムの種類」	x64プロセッサならx64、ARM端末ならプロジェクトが提供するARM64ビルドを優先します。
macOS	Appleメニュー →「このMacについて」で「チップ」または「プロセッサ」を確認	AppleシリコンならARM64、Intelプロセッサならx64を選択します。Universalビルドはリリースノートで確認してください。
Linux	`uname -m` と `cat /etc/os-release`	アーキテクチャとディストリビューションをそれぞれ確認します。Debian系は通常deb、Fedora系は通常rpmを使用します。
Android	端末の仕様。ADBを設定済みなら `adb shell getprop ro.product.cpu.abilist` も使用できます。	一覧に`arm64-v8a`が含まれていればARM64を検討し、32ビットABIのみの場合は対応するビルドを選びます。
iOS / iPadOS	「設定」→「一般」→「情報」→システムバージョン	アプリが利用できる配布経路で最低システム要件と設定形式を確認し、APK、EXE、DMGはインストールしません。

WindowsとmacOS：まずアーキテクチャを確認し、互換性に関する警告に対処

Windows 10では通常、「設定」→「システム」→「バージョン情報」→「システムの種類」から確認できます。「このアプリはお使いのPCでは実行できません」と表示されたら、まずOSのビット数、パッケージのアーキテクチャ、最低システム要件を確認してください。Windows on ARMで互換実行できても、すべてのプロキシサービスやドライバーが対応するとは限りません。メイン画面が起動するかだけで判断しないでください。

Appleシリコン搭載MacでIntelビルドを使う場合、Rosettaが必要になることがあります。プロジェクトがネイティブARM64パッケージを提供しているなら、リリースノートに従ってそちらを優先してください。DMGで配布されるクライアントは、説明に従ってアプリを「アプリケーション」フォルダへ移してから起動します。マウントしたイメージ内から長期間実行すると、更新や権限の保存先が不安定になることがあります。

LinuxとAndroid：ファイル形式とアーキテクチャを別々に確認

Linuxの.debと.rpmはパッケージ管理形式であり、CPUアーキテクチャを直接示すものではありません。インストール前に依存関係とディストリビューションの対応範囲を同時に確認し、インストールを通すために依存関係を無理に無視しないでください。Androidでは「ハードウェアは64ビットだが、システムは32ビットアプリ環境しか提供しない」端末もあります。利用可能なABIを基準にし、汎用パッケージがある場合は説明を確認して選択肢にしてください。ただし汎用パッケージは通常、容量が大きくなります。

権限の確認：インストール許可、サービス権限、VPN権限を区別

権限ダイアログは、直前に実行した操作と対応しているはずです。インストーラーを開いたときのインストール確認、TUNを有効にしたときのサービス権限、モバイルで初回接続するときのVPN許可は、それぞれ異なる段階のシステム動作です。関連する操作をしていないのに見慣れない管理者要求が表示された場合は、いったんキャンセルし、起動元のプログラムとファイルの入手元を確認してください。

Windowsのインストールとファイアウォール：インストーラーやサービスの追加でUACが表示されることがあります。ファイアウォールで許可するネットワークを尋ねられたら、他の端末から本機のプロキシへ接続する必要が本当にあるか確認してください。本機だけで使う場合、警告を消すためにすべてのパブリックネットワークからの受信を許可するべきではありません。
macOSのセキュリティ警告：まずアプリの入手元、署名に関する表示、バージョン要件を確認し、その後「システム設定」→「プライバシーとセキュリティ」を確認します。システム全体のセキュリティチェックを無効にすることをインストール手順にしないでください。「アプリが壊れている」などの表示が出たら、まず正しいインストーラーを再入手し、そのバージョンの説明を確認してください。
Androidのインストール許可：APKのインストール時、ブラウザやファイル管理アプリに「不明なアプリのインストール」を許可するよう求められることがあります。これはインストール元アプリへの許可であり、VPN権限ではありません。インストール後、不要になった許可は取り消せます。
モバイルの接続許可：AndroidのVPN接続リクエストやiOSのVPN構成追加の表示は、アプリがシステムのネットワーク拡張を通じて通信を処理するためのものです。意図したクライアントを有効にしていることを確認した場合のみ許可してください。

通知権限は主に状態表示と通知に影響し、バッテリーやバックグラウンド制限はAndroidで長時間接続の安定性に影響することがあります。これらを「初回に設定を読み込めるか」という問題と混同しないでください。まず前面で接続を確認し、ロック後に切断される場合だけ、そのアプリのバックグラウンド動作設定を確認します。最初から多くのシステム設定を変更するのは避けてください。

システムプロキシ、VPN、TUN：初回起動ではどれを選ぶか

システムプロキシはプロキシサーバーのアドレスをOS設定へ書き込み、その設定を参照するアプリだけが利用します。TUNは仮想ネットワークインターフェースとルーティングを通じてIP通信を引き継ぐため、通常はより多くの権限とDNS設定が必要です。モバイル端末に表示されるVPNは、システムの許可と通信を引き継ぐ仕組みを指し、クライアントが特定の遠隔VPNプロトコルを使っていることを意味しません。

方式	初回利用時の推奨	ここから判断できないこと
デスクトップのシステムプロキシ	まずブラウザでのアクセスを確認し、本機のアドレスと待受ポートを照合するのに適しています。	スイッチがオンでも、すべてのアプリやUDP通信が引き継がれるとは限りません。
デスクトップのTUN	システムプロキシに従わないアプリを処理する必要がある場合に、カーネルのドキュメントに従って有効にします。	有効化に成功しても、ノードがUDPに対応するとは限らず、すべてのルートが意図どおりになる保証もありません。
モバイルのVPNトンネル	有効な設定を読み込んだ後、アプリの接続ボタンから許可して起動します。	ステータスバーのVPN表示はトンネルの状態を示すだけで、遠隔ノードが利用可能だとは限りません。

ルールモードと通信の引き継ぎ範囲は別々に設定

mode: ruleは、ルールに従って接続先を選ぶようカーネルに指示するもので、すべてのアプリをカーネルへ送る機能ではありません。逆に、TUNを有効にしても、すべての接続が同じプロキシノードへ送られるわけではありません。初回利用時は設定提供元が用意したルールモードを維持し、グローバルモード、DNSモード、TUNを同時に切り替えないことをおすすめします。テストが成功しても、どの変更が効果をもたらしたのか分からなくなるためです。

デスクトップではまずシステムプロキシを使い、モバイルではクライアントが提供するVPN接続方式で起動します。管理対象の端末では、一般ユーザーがサービスのインストールやルーティング変更を行えない場合があります。許可される接続方式は端末管理者に確認し、権限を上げて何度も試すのは避けてください。

初期設定チェックリスト：設定の読み込み、ポート確認、ポリシー選択

バージョン情報を確認。クライアントの「バージョン情報」またはバージョン表示画面で、クライアントとカーネルのバージョンを記録します。配布パッケージの名前が実際に動作するカーネルのバージョンと一致するとは限りません。
設定を読み込む。サブスクリプションURLはリモート設定の読み込み口から、ローカルYAMLはファイル読み込み口から追加します。単一ノードの共有リンクはクライアントが明確に対応している場合に限り使用でき、完全なYAMLとして読み込むことはできません。
有効化してログを確認。読み込みに成功しただけでは内容が保存されたことを示すに過ぎません。対象設定を選択し、カーネルの読み込みが成功したことを確認してください。未知の項目やYAML解析エラーが出た場合は、まず形式と互換性を確認し、急いでTUNを有効にしないでください。
ポリシーグループを確認。ルールが使用するポリシーグループが存在し、手動選択が必要なグループでは利用可能なノードが選ばれていることを確認します。自動速度測定グループと手動選択グループでは動作が異なります。
通信を引き継ぐ方式を1つだけ有効化。デスクトップでは先にシステムプロキシを有効にし、モバイルでは接続ボタンから許可します。初回テスト中は他のネットワーク設定を変更しないでください。

設定例：ローカルポートとルールモード

# 共通項目の説明のみ。接続可能な完全設定ではありません
mixed-port: 7890
mode: rule
allow-lan: false

mixed-port: 7890は、ローカルHTTPプロキシとSOCKSプロキシで共通の待受ポートを使う説明用の例です。実際のポートはクライアントの実行設定に従います。allow-lan: falseはLANへプロキシアクセスを公開しないことを示し、本機だけで使う場合の出発点として適しています。この3項目にはノード、ポリシーグループ、ルールが含まれないため、サブスクリプションの代わりにはなりません。

実際の待受アドレスが127.0.0.1:7890の場合、システムプロキシも同じアドレスとポートを指定する必要があります。ポートが使用中だと、ログにaddress already in useと表示されることがあります。まず古いクライアントがバックグラウンドで動いていないか確認してください。ポートを変更したら、システムプロキシや手動設定を使用するアプリ側も同時に確認します。YAMLだけを変更してはいけません。

接続確認：ローカル待受から実際の通信まで

速度測定ボタンに表示される遅延だけを、インストール完了の唯一の根拠にしないでください。速度測定は通常、特定のテスト先へアクセスするため、その宛先や測定方法の影響を受けます。1回のタイムアウトはすべてのWebページが開けないことを意味せず、1回成功しても対象アプリがプロキシ経由になった証明にはなりません。

カーネルの動作を確認。ログで設定の読み込みと待受開始の記録を探します。画面が開いていてもカーネルがエラーを出し続けている場合、システムプロキシが指定するローカルポートで接続を受け付けていない可能性があります。
実際のリクエストを確認。アクセス可能で利用できることが分かっているHTTPSサイトを開き、クライアントの「接続」またはログ画面で対象ドメイン、適用ルール、ポリシーグループ、最終的な出口を確認します。
直接接続の通信と照合。現在のルールで直接接続されるはずのサイトへアクセスし、出口がDIRECTまたは対応する直接接続として表示されることを確認します。プロキシ経由のリクエストだけをテストしないでください。
対象アプリをテスト。ブラウザで成功してから、実際に使いたいアプリを開きます。対応する接続記録がない場合は、すぐにサブスクリプションを替えるのではなく、まずそのアプリがシステムプロキシに従うか確認してください。
復旧を確認。システムプロキシを無効にするかVPNを切断し、クライアントを終了してから、もともと直接接続できたサイトが開くことを確認します。

デスクトップ向けオプション：明示的なプロキシテスト

curlがインストール済みで、ローカルHTTPプロキシが実際に127.0.0.1:7890で待ち受けている場合は、次のコマンドを実行できます。Windows PowerShellではcurl.exeを使うと、バージョンによるコマンドエイリアスの違いを避けられます。テストURLは公開HTTPSの例に過ぎないため、現在のネットワークで利用できると確認済みの宛先を使ってください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com

--connect-timeout 10は接続段階の待機を10秒に制限し、--max-time 20はリクエスト全体を20秒に制限します。どちらもテスト用のパラメーターであり、実測遅延ではありません。このコマンドはローカルプロキシを明示的に指定するため、成功してもOSのプロキシ設定が正しいことまでは証明しません。サイトがHEADリクエストに対応していない場合は、メソッドに関するエラーが返ることもあるため、ログと合わせて判断してください。

Clash初回インストールのよくある問題と完了基準

クライアントは開くのに、なぜWebページへアクセスできないのですか？

まずシステムプロキシを無効にするかVPNを切断し、もともと直接接続できたサイトが復旧するか確認します。復旧する場合は、カーネルが起動しているか、本機のポートが一致しているか、設定が有効か、ポリシーグループで利用可能な出口が選ばれているかを順に確認してください。クライアント終了後も通信できない場合は、システムプロキシが残っていないか確認します。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは現在のネットワーク接続の「詳細」→「プロキシ」から確認できます。復旧する前に元の設定を記録し、組織のネットワーク要件に関わる設定を上書きしないでください。

インストール後、TUNを必ず有効にする必要がありますか？管理者権限で常に実行すべきですか？

この2つを初期設定の前提にする必要はありません。ローカルプロキシポートとシステムプロキシだけを使うなら、通常はデスクトップTUNは不要です。サービスのインストールや仮想ネットワークインターフェースの作成には権限昇格が必要になる場合がありますが、具体的な要件はクライアントの実装によって異なります。クライアントが管理されたバックグラウンドサービスで処理する場合は、説明書に従って設定し、アプリ全体を常に高い権限で実行する方法を一般的な解決策にしないでください。

読み込み後にノードがありません。再インストールすると解決しますか？

まずサブスクリプションが正しい形式を返しているか、ログインページやエラーメッセージを誤ってYAMLとして保存していないか確認します。プロキシプロバイダーを使う設定では、プロバイダーの内容を追加で取得する必要がある場合もあり、メイン設定の読み込み完了がプロバイダー更新の成功を意味するとは限りません。エラーの種類を記録し、設定提供元に有効期限とクライアントの対応範囲を確認してください。再インストールでは、通常、サブスクリプションの内容や認証の問題は解決しません。

インストール完了までこの記録を残す

OSのバージョン、端末のアーキテクチャ、クライアントのバージョン、カーネルのバージョンを記録した。
設定を読み込め、ノードまたはプロキシプロバイダーが準備済みで、ローカル待受にエラーがない。
プロキシ経由のリクエストと、ルールに従った直接接続のリクエストについて、実際の出口を確認した。
通信を引き継ぐ方式が明確で、不要なVPNやプロキシツールを同時に実行していない。
終了後のネットワーク復旧をテストし、元の設定とローカルオーバーライドを別々に保存した。

これらの条件を満たしてから、自動起動、バックグラウンド実行、TUN、LAN共有を1項目ずつ検討します。設定は毎回1つだけ追加して接続確認を繰り返せば、異常時に直近の利用可能な状態へ戻せます。異なるクライアントのシステム対応状況やメンテナンス状態を比較する場合は、クライアント選定ガイドを参照してください。