Clashの初回インストール・設定完全ガイド：全プラットフォーム共通の要点とよくある落とし穴

まずクライアント、コア、インストーラーを確認する

初回設定に失敗する原因は、ノードではなく最初に選んだファイルにあることが少なくありません。Clashはプロキシルール体系やコアを指す通称で、デスクトップやスマートフォンで実際に操作するのはグラフィカルなクライアントです。現在主流のコアはClash Meta（mihomo）です。クライアントはサブスクリプション管理、プロキシ選択、システムプロキシ、ログ表示を担当し、コアはプロトコル接続、ルール判定、DNS、トラフィック転送を担います。

ダウンロード前に、OS、プロセッサーのアーキテクチャ、インストーラー形式の3点を確認します。Windows 10 22H2やWindows 11の一般的なIntel・AMD搭載PCは通常x64を選びます。Windows on ARM端末はarm64です。Apple Silicon Mac（M1、M2、M3、M4シリーズ）はarm64またはuniversalを優先し、旧型のIntel Macはx64を選びます。Androidアプリに複数のアーキテクチャがある場合、近年の主流スマートフォンは通常arm64-v8aです。

OSにインストールをブロックされた場合の対処

• Windows：Microsoft Defender SmartScreenの保護メッセージが表示されたら、まずファイルがプロジェクトのリリースページまたは当サイトのダウンロードセンター由来か確認します。入手元を確認できたら、メッセージ内の「詳細情報」から続行します。会社や学校のPCで管理者ポリシーによりインストールが禁止されている場合は、端末管理者に相談してください。インストーラーを繰り返し実行してもポリシーは回避できません。
• macOS：アプリを「アプリケーション」に移動した後、初回起動がブロックされた場合は、「システム設定」→「プライバシーとセキュリティ」を開き、安全性に関する通知から起動を許可します。Gatekeeperを恒常的に無効化しないでください。
• Android：ブラウザやファイル管理アプリからの不明なアプリのインストールを許可するよう求められることがあります。許可は現在のインストール元に限り、インストール完了後は「設定」→「アプリ」→「特別なアプリアクセス」で無効にできます。
• Linux：ダウンロードしたAppImageには実行権限が必要です。ファイルのプロパティで有効にするか、chmod +x ファイル名.AppImageを実行します。Debian、Ubuntuでは.deb、Fedora、RHEL系ディストリビューションでは通常.rpmを使用します。
• iOS：mihomoまたはClashの設定形式に対応したプロキシクライアントをApp Storeから入手します。メニュー名はクライアントによって異なりますが、初回接続時にはシステムVPN構成の追加を許可する必要があります。

サブスクリプション追加前にリンクの状態を確認する

サブスクリプションリンクは通常のホームページURLではありません。アカウント識別情報を含み、YAML設定やノード一覧を返します。コピーする際にクエリパラメーターを欠落させたり、チャットアプリが生成したプレビュー用のリダイレクトURLをサブスクリプションURLとして使ったりしないでください。サブスクリプションリンクはアクセス資格情報に相当するため、スクリーンショット、フォーラム、公開コードリポジトリに掲載してはいけません。

デスクトップクライアントでは通常、「設定」または「Profiles」→「URLからインポート」→サブスクリプションURLを貼り付け→「インポート」という手順です。Androidクライアントでは、「設定」→右上のプラス→「URLからインポート」が一般的です。iOS対応クライアントでは、通常「設定」または「サブスクリプション」画面からリモートリソースを追加します。表示はバージョンによって変わりますが、基本操作は単一のプロキシノードを手動作成することではなく、リモート設定を作成することです。

追加後に確認できる状態

1. 設定一覧に新しいサブスクリプション名が表示され、最終更新日時が更新されます。
2. 「プロキシ」または「Proxies」画面に切り替えると、プロキシグループとノードが表示されます。
3. 設定ファイルにproxies、proxy-groups、rulesなどのキーが存在するか、サブスクリプション変換サービスが生成した同等の内容が含まれています。
4. 選択した設定が有効になっており、ローカル一覧にダウンロードされただけの状態ではありません。

mixed-port: 7890
mode: rule
allow-lan: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自動選択
      - DIRECT

上記のYAMLはキーの階層だけを示したものです。実際のポート、プロキシグループ名、ノードは設定によって異なります。「チュートリアルどおりに設定する」ために既存の設定を上書きしないでください。特にサブスクリプションが生成したproxy-groupsやrulesを削除してはいけません。YAMLはインデントに依存するため、Tab、スペース1つの不足、重複キーなどで読み込みに失敗することがあります。

サブスクリプション追加に失敗したときの切り分け

• 401または403：リンクの認証情報が無効、アカウントに問題がある、またはサーバー側でアクセスが制限されています。サブスクリプション提供元に戻り、URLを再発行してください。
• 404：URLのパスが不完全か、以前のサブスクリプション入口が削除されています。コピーした内容がhttps://から始まり、すべてのパラメーターを含んでいるか確認してください。
• リクエストがタイムアウト：まずClashを終了し、現在の直結ネットワークからブラウザでサブスクリプションのドメインにアクセスできるか確認します。必要に応じてスマートフォンのテザリングに切り替え、ローカルネットワークとサーバー側のどちらに問題があるか切り分けます。
• ダウンロードは成功したが解析に失敗：返された内容がHTMLのエラーページ、Base64形式のノード一覧、または現在のクライアントに対応していない設定形式である可能性があります。レスポンスの先頭がHTMLになっていないか確認し、クライアントが対応するサブスクリプション形式を確認してください。
• 設定はあるがノードが空：サブスクリプションの期限切れ、通信量の上限到達、または現在有効なのが追加直後の設定ではない可能性を確認します。

動作モードと最初に使えるノードを選ぶ

サブスクリプションの追加に成功したら、まず動作モードを「ルール」またはruleに設定します。ルールモードでは、ドメイン、IP、プロセスなどの条件を上から順に判定し、リクエストを対応するプロキシグループへ渡します。グローバルモードでは、ほとんどのリクエストを指定したプロキシ経由にでき、比較テストに便利です。直結モードではプロキシを経由しません。初回設定でグローバルモードを使い続けると、プロキシグループやルール設定の問題が見えにくくなるためおすすめしません。

ノードテストでは遅延の数字だけを見ない

「プロキシ」画面でメインのプロキシグループを探します。一般的な名前は「ノード選択」「PROXY」「手動選択」などです。まず遅延結果が返るノードを1つ選び、ウェブページを開いて確認します。遅延80msだからといってダウンロード速度が必ず速いとは限りません。遅延テストが示すのは、テスト時点で測定先に到達できたことだけです。3000ms、5000ms、Timeoutが連続する場合は、ノードの状態やネットワーク接続を優先して確認します。

1. 同じ地域の3つのノードに対して、それぞれ1回ずつ遅延テストを実行します。
2. 遅延の変動が小さく、2回連続で結果が返るノードを優先します。
3. プロキシが必要なウェブサイトを1つ開き、接続ログに新しいリクエストが表示されるか確認します。
4. ページを開けない場合は2つ目のノードに切り替えて再テストし、すぐにDNSを変更しないでください。
5. すべてのノードが同時にタイムアウトする場合は、サブスクリプション、システム時刻、直結ネットワークを確認します。

システム時刻のずれにより、TLS証明書の検証に失敗することがあります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」で時刻の自動設定を有効にします。macOSでは「システム設定」→「一般」→「日付と時刻」です。スマートフォンでも日付、時刻、タイムゾーンの自動設定を有効にしてください。時刻を修正したら、クライアントを完全に終了してから再接続します。

システムプロキシとTUNを無闇に同時に有効にしない

ノードが利用可能でも、アプリの通信がClashに入っているとは限りません。クライアントには少なくともシステムプロキシまたはTUNのどちらか1つによる通信の取り込みが必要です。初回設定では、経路が短く切り分けやすいシステムプロキシから試します。WindowsとmacOSのデスクトップクライアントには通常「システムプロキシ」スイッチがあります。有効にすると、システムプロキシに対応したブラウザやアプリがローカルの待受ポートへ接続します。

システムプロキシを正しく確認する方法

一般的な設定では127.0.0.1:7890をmixed-portとして使い、HTTPとSOCKSの通信を同時に受け付けます。古い設定では7890と7891を別々に使う場合もあります。ポートは現在の設定とクライアント画面の表示を基準にしてください。設定が7897なのにシステムプロキシが7890を指していると、クライアントは正常に動作していてもウェブページに接続できません。

• Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で現在のプロキシ状態を確認できます。
• macOSでは「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」で確認できます。
• ブラウザに独立したプロキシ拡張機能をインストールしている場合は、まず無効にして、拡張機能側のポートがシステムプロキシを上書きしないようにします。
• allow-lan: falseはLAN上の他の端末からのアクセスだけに影響し、本端末から127.0.0.1へ接続することは妨げません。

TUNが必要になるケース

TUNは仮想ネットワークインターフェースを作成し、システムプロキシに従わないアプリ、一部のコマンドラインツール、ゲームの通信を取り込みます。デスクトップクライアントでTUNを有効にすると、サービスモードのインストールや管理者権限を求められる場合があります。一般的なデスクトップクライアントでは、通常「設定」→「システム設定」でサービスモードをインストールしてからTUNを有効にします。AndroidとiOSでは、システムVPNの許可によって仮想インターフェースを作成します。

初回の切り分けでは、システムプロキシ、TUN、ブラウザ拡張機能、別のVPNを同時に有効にしないでください。まず他の通信取り込みツールを終了し、システムプロキシだけでウェブページをテストします。特定のアプリが直結したままなら、システムプロキシを無効にしてTUNだけを有効にし、単独でテストします。両方を有効にしても必ず競合するわけではありませんが、ルーティング、DNS、除外ルールの判断が難しくなります。

5つのプラットフォームで初回権限を確認する

Windows：サービスモードと残存プロキシ

通常のシステムプロキシには管理者権限は不要ですが、TUNやスタートアップ関連機能ではサービスモードが必要になる場合があります。サービスのインストールに失敗したら、まず旧バージョンのクライアントを終了し、タスクマネージャーに関連するコアプロセスが残っていないか確認します。クライアントが異常終了すると、Windowsに手動プロキシが残り、Clashを終了した後もブラウザが完全にオフラインになることがあります。その場合は「設定」→「ネットワークとインターネット」→「プロキシ」で無効な手動プロキシをオフにし、クライアントを再起動してからシステムプロキシを有効にします。

macOS：ネットワーク拡張機能とログイン項目

macOSで初めてTUNやネットワーク拡張機能を有効にすると、システムの許可ダイアログが表示されます。承認後、デバイスのパスワード入力やTouch IDが必要になる場合があります。クリックしても反映されない場合は、「システム設定」→「プライバシーとセキュリティ」の通知と、「システム設定」→「一般」→「ログイン項目と機能拡張」のネットワーク拡張機能の状態を確認します。同種のクライアントを複数インストールしないでください。ネットワーク拡張機能の権限を奪い合う可能性があります。

Android：VPNの許可とバッテリー制限

Androidでは起動をタップするとVPN接続のリクエストが表示されます。これはTUNインターフェースの作成に必要なシステム権限です。通常、同時に接続状態にできるVPNアプリは1つだけです。画面ロック後数分でプロキシが自動停止する場合は、「設定」→「アプリ」→現在のクライアント→「バッテリー」でバックグラウンド動作を継続的に許可する設定に変更します。メニュー名はメーカーによって多少異なります。ステータスバーに鍵またはVPNアイコンが表示されればインターフェースは作成されていますが、ノードの利用可否は接続ログで確認してください。

iOS・iPadOS：VPN構成とオンデマンド接続

対応クライアントを初めて起動すると、システムがVPN構成の追加を求めます。承認後は「設定」→「一般」→「VPNとデバイス管理」→「VPN」で確認できます。他のVPN、企業向けネットワークツール、フィルターが動作している場合は、先に切断してからテストします。オンデマンド接続はネットワーク条件に応じて自動起動するため、初回の切り分けでは自動化された条件を一時的に無効にし、手動で接続してクライアントログを確認します。

Linux：デスクトッププロキシと環境変数

Linuxのデスクトップ環境では、システムプロキシの対応が一様ではありません。GNOMEやKDEでシステムプロキシを有効にしても、ターミナルのプログラムが自動的に引き継ぐとは限りません。必要に応じてHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを設定し、ポートをクライアントの待受ポートと一致させます。より多くのプログラムを取り込むためにTUNを使う場合は、必要な権限が有効になっていることを確認し、ファイアウォール、ルーティングテーブル、NetworkManagerの競合も確認してください。

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

プロキシを有効にしても反映されない場合の確認手順

この段階で十数個の設定を無作為に切り替えないでください。通信が通過する層に沿って、設定から出口まで順番に確認します。各手順で変更する変数は1つだけにし、変更後は同じテストページを更新します。

1. 設定が有効か確認：設定一覧で現在選択されているのが、クライアント付属のサンプルではなく新しく追加したサブスクリプションであることを確認します。
2. ノードに接続できるか確認：メインのプロキシグループが無効なノードのままになっておらず、誤ってDIRECTを選択していないことを確認します。
3. 動作モードを確認：ルールモードを選択します。一時的にグローバルモードへ切り替えて1回テストすると、ノードの問題かルールの問題かを判断できます。
4. 待受ポートを確認：コアのログにポート競合がないか確認します。7890が別のプログラムに使用されている場合は、旧プロキシプログラムを終了してクライアントを再起動します。
5. 通信の入口を確認：システムプロキシまたはTUNのどちらか1つだけを有効にし、ウェブページを更新して接続ログを確認します。
6. ルールの一致を確認：リクエストがDIRECTに一致する場合は、そのドメインを直結にするルールになっていないか確認します。プロキシグループに一致する場合は、そのグループで実際に選択されているノードを確認します。
7. 最後にDNSを確認：ドメイン名の解決に失敗する、IPアドレスではアクセスできるがドメインではできない、またはログにDNSエラーが明確に表示される場合に限り、DNS設定を確認します。

ログで3種類の障害を切り分ける

ブラウザのセキュアDNSによって解決経路が変わることもあります。通常のウェブサイトは開けるのに特定のドメインだけ解決できない場合は、比較テストとしてブラウザのセキュアDNSを一時的に無効にします。原因を確認してから、システムDNS、クライアントDNS、ブラウザ指定のDoHのどれを使うか決めてください。3種類の設定を同時に変更しないでください。

初回設定後のチェックリスト

以下の項目を完了して、初期設定は安定した状態といえます。後から問題が起きた場合も、同じチェックリストでサブスクリプションの変更、ノードの停止、他のソフトによるシステム設定の変更をすばやく切り分けられます。

• インストーラーが現在のOSとプロセッサーアーキテクチャに合っており、クライアントが正常に起動する。
• サブスクリプションの追加に成功し、設定一覧に最終更新日時が表示され、プロキシ画面にプロキシグループが表示される。
• 動作モードがルールモードで、メインのプロキシグループに利用可能なノードが明確に選択されている。
• システムプロキシまたはTUNの少なくとも一方が有効で、2つ目のVPNが同時に通信を取り込んでいない。
• テストページを更新したとき、接続ログにドメイン、適用ルール、プロキシグループ、ノードが表示される。
• クライアントを終了するとシステムプロキシも同時に無効になり、使えなくなったローカルポートを指す設定が残らない。
• サブスクリプションの更新場所を把握しているが、自動更新間隔を短く設定しすぎていない。
• サブスクリプションURLを公開スクリーンショット、ブラウザの共有履歴、公開ドキュメントに載せていない。