Clash初回インストール設定チェックリスト：マルチプラットフォームの初期設定とよくある落とし穴

Clashを初めて設定するときに確認すべき項目は、実はそれほど多くありません。クライアントとシステムのアーキテクチャが一致していること、設定が正常に読み込まれていること、プロキシグループが選択されていること、プロキシの入口が有効になっていることです。問題の多くは操作の順番にあります。たとえば、サブスクリプションを更新する前にシステムプロキシを有効にしたり、基本接続を確認する前にDNS、ルール、TUNを同時に変更したりすると、どの設定が原因で不具合が起きたのか判断しにくくなります。

Clashは、ルールベースのプロキシコアとそのクライアントエコシステムを指す一般的な呼び方です。デスクトップ版とモバイル版では画面上の項目名が異なる場合があり、基盤となるコアもClash Meta（現在はmihomoと呼ばれることが多い）の場合がありますが、初期設定の考え方はほぼ共通しています。以下のチェックリストは特定の画面構成に依存せず、Windows、macOS、Android、iOS、Linuxで利用される一般的な互換クライアントに対応します。

1. クライアント、システム、設定の入手元をインストール前に確認

ダウンロード前に、デバイスのプラットフォームとプロセッサーアーキテクチャを確認します。Windowsではx64が一般的ですが、一部の新しいデバイスではARM64が使われています。macOSではAppleシリコンとIntelを区別する必要があります。Linuxではアーキテクチャに加え、パッケージ形式とデスクトップ環境の対応状況にも注意が必要です。アーキテクチャが合わないと、プログラムが起動しなかったり、互換レイヤー経由で動作してもサービスのインストール、トレイ表示、性能に問題が出たりします。

インストール前チェックリスト

OSのバージョンを確認：クライアントのリリースノートに記載された最低システム要件を確認します。古いシステムでは、実行に必要なコンポーネントやシステムAPIが不足している場合があります。
プロセッサーアーキテクチャを確認：デバイスのブランドだけで判断せず、システム情報画面でx64、ARM64、Apple Siliconなどの表記を直接確認します。
サブスクリプションの入口を控える：サービス提供元から発行されたサブスクリプションURL、設定ファイル、または読み込み方法を準備します。サブスクリプションURLにはアクセス情報が含まれることが多いため、公開チャットやスクリーンショット、ログに貼り付けないでください。
現在のネットワーク設定を記録：システムに手動プロキシ、VPN、ネットワークフィルター、企業向けセキュリティソフトが設定されている場合は、現在の状態を控えておきます。接続に問題が出たとき、項目ごとに元へ戻しやすくなります。
同種のツールを同時に動かさない：複数のプログラムがシステムプロキシ、仮想NIC、DNS、ローカルポートを奪い合うと、初回確認の結果を正しく評価できません。

以前に別のプロキシクライアントをインストールしていた場合、プログラムを終了しただけではプロキシ設定が元に戻らないことがあります。WindowsとmacOSでは手動プロキシアドレスが残る場合があり、モバイルOSでもVPN構成が表示され続けることがあります。Clashクライアントをインストールする前にシステムのネットワーク設定を確認し、停止済みのプログラムを指すプロキシポートが残っていないことを確認してください。

2. プラットフォームごとにインストールし、必要な権限を許可

クライアントが開くのは、グラフィカルインターフェースが起動したことを示すだけで、システムの通信がプロキシコアに渡ったことを意味しません。初回起動時は、コアの状態、設定ディレクトリ、権限に関する表示を確認してから、システムサービスをインストールするか、仮想NICを有効にするか判断します。管理者権限はすべての操作に必要なわけではありませんが、サービスモード、TUNドライバー、一部のシステム設定では追加の許可が必要になることがあります。

Windows：まずコアの起動を確認し、その後でサービスモードを設定

Windowsへのインストール後は、まずクライアントを通常どおり起動し、コアが正常に動作しているか、ローカルプロキシポートが待ち受け状態になっているかを確認します。クライアントに「サービスモード」「管理者サービス」などの機能がある場合、通常は一般権限の画面からTUN、ルーティング、システム設定を管理するために使われます。初回のシステムプロキシテストで、すぐにサービスをインストールする必要はありません。基本プロキシで通信できることを確認してから、クライアントの案内に従ってインストールしたほうが問題を切り分けやすくなります。

インストーラーがシステムのセキュリティ警告でブロックされた場合は、ダウンロード元と発行元の情報を確認してください。システム保護を無効にして回避するのは避けます。会社や学校が管理するデバイスでは、ドライバー、サービス、プロキシ設定の変更が制限されている場合があります。このような権限についてはデバイス管理者に確認してください。

macOS：チップのアーキテクチャとネットワーク拡張の権限を確認

macOSでは、チップに合ったビルドを選択します。初回起動時には、システムからアプリの入手元を確認するよう求められることがあります。TUNや拡張モードを有効にすると、管理者パスワード、ネットワーク拡張、VPN構成の許可を求められる場合もあります。許可してもすぐに機能が有効にならないときは、クライアントを完全に終了して再起動し、システム設定のVPNとフィルター項目を確認してください。

初回起動時に、以前のクライアントのルール、スクリプト、オーバーライド設定をすべて移行しないでください。まず元のサブスクリプションを読み込んで接続テストを行うことで、システム権限の問題なのか、旧設定と新しいコアの互換性の問題なのかを切り分けられます。

AndroidとiOS：システムVPNの許可を理解する

モバイル版は通常、システムのVPNインターフェースを通じて通信を引き受けます。初めて接続ボタンをタップすると、システムにVPN構成の許可が表示されます。ユーザーが許可して初めて、ステータスバーのVPN表示とクライアントの接続状態に実質的な意味が生まれます。Androidではバッテリー最適化によってバックグラウンドのクライアントが停止することがあります。画面ロック後しばらくして通信が途切れる場合は、使用中のクライアントに対するバックグラウンド動作の設定を調整してください。メーカー独自OSでは項目名が異なるため、初回インストール時に省電力設定をすべて変更する必要はありません。まず本当にバックグラウンド停止が起きているか確認します。

iOSのクライアントは、システムが提供するネットワーク拡張の仕組みに従って動作します。サブスクリプションは読み込めるのにVPNを確立できない場合は、無効なVPN構成がシステムに残っていないか、デバイス管理ポリシーが新しい構成の追加を制限していないか確認してください。

Linux：実行権限、デスクトップセッション、プロキシの適用範囲を確認

Linuxクライアントは、ディストリビューションのパッケージ、圧縮ファイル、AppImageなどの形式で提供されることがあります。インストール後は、「プログラムが起動できること」と「デスクトップ環境がプロキシ設定を採用していること」を分けて確認します。デスクトップ環境によってシステムプロキシの対応は異なり、コマンドラインプログラムがデスクトップのプロキシを読み取るとは限りません。初回テストでは、クライアント内蔵の接続画面やシステムプロキシに明確に対応したブラウザーを使い、ターミナルの特定のコマンドだけでクライアント全体の不具合と判断しないでください。

3. サブスクリプションを読み込み、設定が確実に適用されたことを確認

サブスクリプションは、プロキシノード、プロキシグループ、ルールなどを含むリモート設定への入口です。URLをクライアントに貼り付けた後、ダウンロードまたは更新を実行し、取得した設定を現在の設定として適用する必要があります。URLを保存しただけで設定を有効化していない状態は、初回インストールで最もよくある見落としの1つです。

サブスクリプション読み込み後の4項目チェック

更新時刻：サブスクリプションが直前に正常更新され、空の状態や古いキャッシュのままになっていないことを確認します。
設定の状態：対象のサブスクリプションに対応する設定が選択され、コアのログにYAML解析エラー、フィールドエラー、ルールプロバイダーのダウンロード失敗がないことを確認します。
プロキシグループの内容：プロキシまたはポリシー画面を開き、よく使うプロキシグループに選択可能なノードが含まれていることを確認します。グループが空のままになっていないことが重要です。
更新方法：クライアントが定期更新に対応しているか確認し、必要に応じて適切な間隔を設定します。頻繁に更新してもノードの品質は改善せず、かえってサーバー側の制限を受ける可能性があります。

サービスによっては、クライアントからのリクエストに応じて異なる形式の設定を生成します。ブラウザーではサブスクリプションを開けるのに、クライアントで形式非対応と表示される場合、通常のノード一覧、別ソフト向けの形式、ログインページなどが返されており、Clash互換のYAMLではない可能性があります。その場合はサービス提供元の案内ページから対応するサブスクリプション形式を選び直し、拡張子だけをYAMLに変更しないでください。

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

上の断片は、いくつかの基本フィールドを理解するためだけのものです。mixed-portはローカルの混合プロキシポート、mode: ruleはルールに従って処理する設定、allow-lan: falseはデフォルトでLAN内のデバイスに公開しない設定を表します。実際のサブスクリプションには通常、プロキシ、プロキシグループ、DNS、ルールなど多くの内容が含まれるため、この断片を完全な設定としてそのまま実行しないでください。

4. 変数を最小限にして初回接続を確認

設定が正常に読み込まれた後も、すぐにすべての高度な機能を有効にしないでください。初回接続の目的は、「アプリの通信がローカルプロキシポートに入り、設定に従って利用可能な出口を選べる」ことを確認することです。最も確実な方法は、ルールモードを使い、明確なプロキシノードを選択してシステムプロキシを有効にし、安定したサイトをいくつか開きながらログを確認することです。

推奨する確認手順

動作モードをルールモードに設定します。ルールのマッチングを確認でき、すべてのリクエストを同じポリシーへ強制するグローバルモードも避けられます。
主要なプロキシグループで、状態が正常なノードを1つ手動選択します。遅延テストの成功は、特定の探測リクエストに応答があったことを示すだけで、すべての接続先にアクセスできるとは限りません。
システムプロキシを有効にし、TUNは一時的に有効にしないでください。ブラウザーは通常システムプロキシを読み取るため、最初のテストに適しています。
一般的なウェブサイトを1つ開いた後、プロキシルールの対象となるサイトにもアクセスします。クライアントの接続一覧に、ドメイン、接続先アドレス、マッチしたルール、ポリシー名が表示されるか確認します。
アクセスできない場合は、まずシステムプロキシを無効にしてネットワークを戻し、ログにタイムアウト、接続拒否、DNS失敗、設定エラーがないか確認します。

ログレベルは通常infoで十分です。ログに接続記録が表示されるなら、アプリの通信はClashに入っています。ブラウザーでエラーが出るのに接続一覧へ新しいリクエストがまったく表示されない場合は、システムプロキシが有効か、ブラウザーが独自のプロキシ設定を使っていないか、ローカルポートが設定と一致しているかを優先的に確認します。接続記録があるのにタイムアウトが続く場合は、ノード、ポリシーの選択、リモートネットワーク、ルールの振り分けを確認してください。

ルールモードでは、各リクエストがルール一覧の上から下へ照合され、マッチした時点で指定されたポリシーに渡されます。設定の末尾には通常、前のルールにマッチしなかった通信を処理するフォールバックルールがあります。初回テストでルールの順番を変更する必要はありません。元のサブスクリプションが動作することを確認してから、必要に応じてドメインやプロセスのルールを追加します。

5. 基本プロキシの動作確認後にTUNとDNSを有効化

システムプロキシの影響を受けるのは、主にOSのプロキシ設定に従うアプリです。一部のゲーム、コマンドラインツール、バックグラウンドサービス、特殊なネットワークスタックを使うプログラムは、システムプロキシを迂回することがあります。TUNモードは仮想ネットワークインターフェースとルーティングを通じて、より広範な通信を引き受けます。その分、システム権限、ドライバー、ルーティングテーブル、DNS設定への依存も大きくなります。

TUNを有効にする前に、システムプロキシ使用時の正常な状態を記録します。その後、システムプロキシを無効にするか、クライアント推奨の方法で切り替え、トラブルシューティング時にどの入口から通信が入ったのか分からなくなる状態を避けます。クライアントによってはシステムプロキシとTUNを同時に有効にできますが、初期設定では主要な通信方式を1つに絞るのが安全です。TUNを有効にしたらブラウザーを再テストし、その後、これまでプロキシを使えなかったアプリをテストして、接続一覧に該当するリクエストが追加されるか確認します。

TUNの有効化に失敗したときの確認項目

クライアントに管理者権限、VPN権限、ネットワーク拡張の許可が与えられているか。
別のVPN、仮想NIC、ネットワークフィルターソフトが同時にルートを変更していないか。
TUNデバイスが正常に作成され、コアのログにルートまたはインターフェースのエラーが出ていないか。
ネットワークを切り替えた後にデフォルトのネットワークインターフェースが変わっていないか。たとえば有線からWi-Fiへ切り替えた場合など。
LAN、プリンター、開発環境のネットワーク範囲に、直接接続のルールが必要か。

DNSは、「接続済みなのにドメインを開けない」問題で重点的に確認すべき項目です。既知のサービスへ直接アクセスすると応答があるのに、ドメインへのアクセスだけが失敗する場合は、名前解決の経路を確認します。Clashまたはmihomoの設定では内蔵DNSが有効になっており、fake-ipやredir-hostなどの拡張モードが使われることがあります。これらは適用範囲と互換性が異なるため、元の設定設計を理解しないまま入れ替えないでください。

DNSを調べるときは、まずリクエストがコアに入っているかを確認します。次に、上流DNSへ接続できるか、ルールによってDNSリクエストが誤った出口へ送られていないか、システムやブラウザーで独自の暗号化DNSが有効になっていないかを確認します。ブラウザー内蔵のセキュアDNSはシステムの名前解決経路を迂回することがあるため、同じドメインでもブラウザーと他のアプリで結果が異なる場合があります。

6. 初期設定で起こりやすい落とし穴

落とし穴1：ノードの遅延が低ければ、すべてのアクセスが必ず速くなる

遅延テストが示すのは、特定の探測先がテスト時点で応答した状況だけです。実際の速度は、回線帯域、混雑、接続先、転送プロトコル、ローカルネットワークにも左右されます。ノードを選ぶときは接続の安定性と実際のアクセス結果も確認し、遅延値を何度も更新する必要はありません。

落とし穴2：サブスクリプションを読み込めば、ポリシーの選択は不要

サブスクリプションによっては、主要なプロキシグループが自動選択に設定されていることもあれば、利用できないノードのままになっていることもあります。読み込み後はプロキシグループを開き、現在の選択を確認してください。多層構成のプロキシグループを使っている場合は、上位グループが最終的にどのノードまたは自動テストグループを指しているかも確認します。

落とし穴3：接続ボタンが点灯すれば、通信はすでにプロキシ経由になっている

クライアントが実行中と表示されても、通常はコアまたはVPNセッションが起動したことしか分かりません。システムプロキシがまだ有効でない場合や、TUNルートの作成に失敗している場合もあります。1つのスイッチだけを見るのではなく、システムの状態、接続一覧、実際のアクセス結果を組み合わせて確認してください。

落とし穴4：問題が起きたら、コア、DNS、ルールを同時に変更する

複数の変数を一度に変更すると、トラブルシューティングの基準が崩れます。正しい手順は、元のサブスクリプションに戻し、カスタムオーバーライドとTUNを無効にして、システムプロキシだけでテストすることです。基本経路を確認した後、DNSのオーバーライド、ルールセット、スクリプト、仮想NICを1つずつ戻します。

落とし穴5：LANアクセスを有効にすれば、追加の制限は不要

allow-lanは、同じLAN内にある他のデバイスから本機のプロキシへアクセスできるようにする設定です。プロキシを共有する必要がある場合だけ有効にし、リッスンアドレス、ファイアウォール、認証設定と組み合わせてアクセス範囲を制限してください。通常の単体利用では無効のままにすると設定が簡単で、ポートの公開も抑えられます。

落とし穴6：サブスクリプションURLを一般公開のリンクとして扱う

サブスクリプションURLからアカウントに対応する設定を直接取得できる場合があるため、ログイン情報と同じように管理してください。問題を報告するスクリーンショットでは、完全なサブスクリプションURL、クエリパラメーター、設定内の認証フィールドを隠します。URLがすでに公開された場合は、ローカルの履歴を削除するだけでなく、サービス提供元の管理画面でリセットしてください。

7. インストール完了後の仕上げチェックリスト

初回接続が確認できたら、以下のチェックリストで仕上げを行います。各項目を完了してから次へ進むことで、後から問題が起きても既知の正常な状態へ戻しやすくなります。

クライアントのバージョンとシステムアーキテクチャが一致し、コアが安定して起動する。
サブスクリプションが正常に更新され、現在使用する設定として適用されている。
主要なプロキシグループで、利用可能なノードまたは適切な自動ポリシーが選択されている。
ルールモードでブラウザーが正常に動作し、接続一覧にマッチしたルールとポリシーが表示される。
システムプロキシを無効にするかVPNを切断すると、システムネットワークが元の状態に戻る。
必要な場合だけTUNを有効にし、ルーティング、DNS、LANアクセスを個別に検証する。
自動更新と自動起動は利用習慣に合わせて設定し、トラブルシューティング中に設定を頻繁に切り替えない。
サブスクリプションURLとログ内の機密情報を適切に保管し、公開スクリーンショットに含めない。

信頼できる初回インストール手順で重要なのは、すべての項目を有効にすることではありません。元の設定が読み込めること、システムプロキシが動作すること、ポリシーのマッチをログで確認できることという、明確な正常状態を作ることです。その後にTUN、カスタムルール、DNSのオーバーライドを追加しても、異常が起きたときにどの変更が原因かをすばやく判断できます。