入門ガイド 読了時間の目安:12分

Clashクライアントの初回インストールと初期設定|Windows・macOS・Androidの手順と注意点

Windows・macOS・Android別に、Clashクライアントの初回インストール、権限設定、サブスクリプションの追加、ポートとシステムプロキシの設定を解説。起動しない、証明書の警告が出るなどの問題も紹介します。

インストール前に確認:クライアント、コア、システムアーキテクチャ

Clashクライアントは通常、グラフィカルインターフェースとプロキシコアで構成されます。画面上で設定の読み込み、ノードの選択、システムプロキシの設定を行い、コアがルールの解析、接続の確立、通信の転送を担います。Clash Metaは現在mihomoという名称で、コアのプロジェクトです。Clashの名を冠するクライアントでも、同じコアを使用しているとは限らず、対応する設定項目も異なります。

初回インストールの前に、デバイスのアーキテクチャ、クライアントが対応するOSのバージョン、サブスクリプションの設定が現在のコアに対応しているかを確認しましょう。旧版のClashコアはmihomoと同じものではありません。たとえばサブスクリプションにHysteria2などのノードが含まれる場合、そのプロトコルに対応したコアを内蔵するクライアントが必要です。

プラットフォーム確認場所インストーラーの選び方
Windows 11設定 → システム → システム情報 → システムの種類x64デバイスはx64を選択。ARMデバイスは、ネイティブのARM64版と互換性を確認してください
macOSAppleメニュー → このMacについてAppleシリコン搭載Macはarm64、Intelプロセッサ搭載Macはx64を選択
Android設定 → デバイス情報。プロセッサの仕様も確認してください比較的新しいデバイスではarm64-v8aを選択。古いデバイスは対応状況に応じてarmeabi-v7aを選択してください

Android端末のプロセッサが64ビットでも、OSが64ビットアプリの実行環境を備えているとは限りません。インストーラーに互換性がないと表示された場合は、OSが実際にサポートするABIを確認してください。ADBの操作に慣れている場合は、adb shell getprop ro.product.cpu.abilistを実行します。判断が難しい場合は、クライアントが提供する汎用パッケージを使い、Androidの最低要件も確認しましょう。

Windows:インストール、起動、ローカルプロキシポート

まず通常起動を確認し、その後に通信の振り分け方を設定

  1. システムアーキテクチャに合ったインストーラーをダウンロードします。インストール版はウィザードに従ってセットアップし、ポータブル版は固定のフォルダーに展開してください。圧縮ファイルのプレビュー画面から直接起動するのは避けましょう。
  2. まずは通常ユーザー権限で起動します。メイン画面が開き、ステータス画面にコアの稼働情報が表示されること、ログに起動失敗が繰り返し記録されていないことを確認してください。
  3. 設定を読み込んで有効にしたら、クライアントに表示されているHTTP、SOCKS、またはMixedポートを控えます。ここでは例として7890を使用しますが、実際の値は現在の設定に従ってください。
  4. 初回テストでは、まず「ルール」モードと「システムプロキシ」を使いましょう。仮想NIC、ルーティング、サービス権限の問題が加わるのを避けるため、TUNはまだ有効にしません。

Windowsファイアウォールの警告と管理者権限の要求は別のものです。ローカルループバックアドレス経由でプロキシに接続する場合、通常はパブリックネットワークからの受信接続を許可する必要はありません。他のデバイスからこのPCに接続する必要がある場合に限り、LANからの接続とファイアウォールルールを検討してください。その際は、接続認証を設定し、接続元も制限しましょう。

システムプロキシの接続先ポートを確認

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」から手動プロキシの設定を確認できます。クライアントでシステムプロキシを有効にすると、通常、アドレスは127.0.0.1になり、ポートはHTTPポートまたはMixedポートと一致します。SOCKS専用ポートをHTTPプロキシ欄に入力しないでください。

# PowerShell:ポートの待ち受け状態を確認する例
Get-NetTCPConnection -LocalPort 7890 -State Listen

# Windows標準のcurl.exeでローカルHTTPプロキシを明示して接続
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com

1つ目のコマンドで結果が表示されない場合は、ポート番号が正しいか、コアが動作中かを確認してください。2つ目のコマンドで確認できるのは、プロキシを明示した接続経路です。すべてのアプリがシステムプロキシを参照していることを示すものではありません。curlではなくcurl.exeを使うと、一部のPowerShell環境で発生するエイリアスの違いも避けられます。

macOS:アプリのインストールとネットワーク権限

  1. インストールイメージを開き、アプリを「アプリケーション」フォルダーにドラッグしてから、そのフォルダー内のアプリを起動します。読み取り専用のイメージから使い続けると、アップデートや補助コンポーネントのインストールに失敗することがあるため避けてください。
  2. インストーラーのアーキテクチャを確認します。Appleシリコン搭載Macではarm64版を優先してください。Intel Macでは、Appleシリコン専用アプリは動作しません。
  3. クライアントから補助ツールのインストールを求められた場合は、表示されたアプリ名と用途を確認してください。システムプロキシの設定やTUNインターフェースの作成には許可が必要な場合がありますが、サブスクリプションを読み込むだけなら通常は不要です。
  4. システムプロキシを有効にしたら、macOS 13以降では「システム設定」→「ネットワーク」→「現在のネットワークサービス」→「詳細」→「プロキシ」で、アドレスとポートを確認します。

システムのバージョンによって、メニュー名が多少異なる場合があります。Wi-FiやEthernetなど、現在接続中のネットワークサービスを確認してください。未接続のサービスだけを見ても判断できません。HTTP、HTTPS、SOCKSはそれぞれ異なるプロキシ接続方式です。どれを有効にするかはクライアントの実装によるため、すべてにチェックを入れる必要はありません。

ターミナルでシステムプロキシを確認する場合は、scutil --proxyを実行します。HTTP、HTTPS、SOCKSそれぞれの有効状態とポートを確認し、クライアントの設定と照らし合わせてください。ターミナルのツールはmacOSのシステムプロキシを参照しない場合があるため、テストコマンドでは--proxyを明示するのがおすすめです。

Android:VPNの許可とバックグラウンド設定

Androidクライアントは、システムのVpnServiceを使ってローカルVPNインターフェースを作成し、端末の通信をプロキシコアに渡すことがあります。VPNサービスを別途契約する必要があるという意味ではなく、すべての接続が必ずリモートノードを経由するということでもありません。実際の接続先は、ルール、プロキシグループ、アプリごとの設定によって決まります。

  1. APKをインストールするときは、インストーラーを開くアプリに限り、一時的にインストール権限を付与してください。一般的な設定手順は「設定」→「アプリ」→「特別なアプリアクセス」→「不明なアプリのインストール」です。項目名は端末のシステムによって異なります。
  2. クライアントを開き、設定を読み込んで現在の設定として選択します。ノードとプロキシグループが表示されたことを確認してから、接続または起動をタップしてください。
  3. システムのVPN接続リクエストを確認し、インストールしたクライアントからの要求であることを確認して許可します。ステータスバーにVPNアイコンが表示されても、インターフェースが作成されたことを示すだけで、リモートノードが利用可能とは限りません。
  4. 画面ロック後に通信が切れる場合は、「設定」→「アプリ」→「クライアント名」→「バッテリー」でバックグラウンド制限を確認してください。一部のメーカー製端末では、自動起動やバックグラウンド管理の設定で、継続動作を許可する必要もあります。

同じユーザーまたは仕事用プロファイルでは、VPNサービスを自由に複数同時使用できないことがあります。企業VPN、VPN方式のファイアウォール、他のプロキシツールが動作中の場合、新しいクライアントを起動すると既存の接続が切れることがあります。テスト前に現在どのVPNが接続されているかを確認し、サービスの切り替えをノード障害と誤認しないようにしましょう。

初回インストール時に「常時接続VPN」と「VPNなしの接続をブロック」をすぐ有効にするのはおすすめしません。まずサブスクリプション、ノード、インターネット接続が正常であることを確認してから、必要に応じて有効にしてください。ブロック機能を有効にしたままクライアントを停止した場合、端末がインターネットに接続できないのはシステムの想定どおりの動作です。

サブスクリプションの追加:更新成功後に設定を有効化

URL、取得内容、現在の設定を順に確認

  1. クライアントのサブスクリプションまたは設定画面でURLからの読み込みを選び、完全なURLを貼り付けます。クエリパラメーターを手動で削除したり、Webページに表示されたタイトルをサブスクリプションURLと取り違えたりしないでください。
  2. ダウンロード後、更新日時と解析結果を確認します。ダウンロードに成功しても、ログインページやエラーメッセージ、別のクライアント用の形式が取得された場合は、有効な設定として利用できません。
  3. 新しい設定を現在の設定として選択します。リストにサブスクリプションが表示されていても、コアがその設定に切り替わったとは限りません。
  4. プロキシグループ画面を開き、利用可能なノードまたは自動選択グループを選択します。ルールの振り分け先が手動選択グループの場合、そのグループで選ばれている項目が通信の出口に直接影響します。

「サブスクリプションの更新に失敗しました」と表示されたら、まずURLの有効期限、提供元への接続、サーバーから有効な内容が返されているかを確認します。クライアントに「プロキシ経由で更新」の項目があっても、利用可能なノードをまだ設定していない初回セットアップでは、その方法で更新できないことがあります。提供元の案内に従って、利用可能な更新方法を選んでください。

自動更新は、まず24時間ごとに設定するとよいでしょう。これは初期設定の目安であり、すべてのクライアントの既定値ではありません。GUIからサブスクリプションを更新すると、通常はローカルの設定が置き換わります。ダウンロードしたファイルを直接編集すると、次回の更新で変更が失われることがあります。変更を維持するには、クライアントが対応する上書きまたはマージ機能を使い、事前にバックアップしてください。

完全な設定ファイルとプロキシプロバイダーを区別する

完全なYAML設定には、proxies、proxy-groups、rules、DNS設定をまとめて記述できます。一方、proxy-providersは設定ファイル内からノードの提供元を参照するためのものです。intervalフィールドを、GUIクライアント全体のサブスクリプション更新間隔と一律に見なすことはできません。ノード一覧だけを受け取った場合も、振り分けルールが含まれているとは限りません。

初期設定:ポート、ルールモード、TUNの使い分け

初回動作確認では、クライアントを1つだけ起動してください。複数のクライアントが同時にシステムプロキシを書き換えたり、複数のコアが同じポートを待ち受けたりすると、原因の切り分けが難しくなります。以下はノード情報を含まないローカル設定項目の例で、これだけではインターネットに接続できません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
  • mixed-port:同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。例では7890を使用しています。ポートが使用中の場合は、空いている別の番号に変更し、接続する側の設定も合わせて更新してください。
  • allow-lan: false:LANからの接続を許可しません。初めて単独の端末で使用する場合は、不要な公開範囲を減らすため、無効のままにしてください。
  • mode: rule:ルールに従って、直接接続、プロキシ経由、または拒否を選択します。全体モードは一時的な比較テストに便利ですが、ルールの適用状況を確認する代わりにはなりません。
  • log-level: info:通常は標準のログレベルを使用します。問題の調査中のみ一時的にデバッグレベルへ切り替え、ログを共有する前にサブスクリプションの認証情報、ノードのパスワード、個人のアクセス履歴を削除してください。

システムプロキシが有効なのは、該当する設定に従うアプリだけです。すべてのUDP通信、ゲーム、自前のネットワークスタックを使うプログラムが自動的にプロキシ経由になるわけではありません。デスクトップのTUNは仮想NICとルーティングを使って、より多くの通信を転送する仕組みで、通常は管理者権限または補助サービスが必要です。AndroidのVPNによる通信制御も、デスクトップのシステムプロキシと同じスイッチとして単純に扱うことはできません。

初回テストに成功しても、対象のアプリがシステムプロキシを参照しない場合に限り、TUNを検討してください。有効にする前に元の設定を記録し、他のVPNと同時に動作しないようにしましょう。DNSモード、ルートの除外、TUNのプロトコルスタックは、コアとクライアントのドキュメントに従って設定してください。Web上のYAMLをそのままサブスクリプションに上書きする必要はありません。

初回接続の確認とよくあるエラー

3つの手順でローカル接続、ルール、ノードを切り分ける

  1. ローカル接続を確認します。コアが動作し、ポートが待ち受け状態であることを確認します。デスクトップではプロキシを明示したコマンドでテストし、AndroidではVPNが起動していることと、アプリごとのルールで対象アプリが除外されていないことを確認してください。
  2. 接続履歴を確認します。新しいWebページを開き、クライアントの接続画面でドメイン、適用されたルール、出口までの経路を確認してください。DIRECTと表示されるのはルールどおりの場合もあり、システムプロキシが機能していないとは限りません。
  3. リモート側の応答を確認します。異なる2つのサイトで比較し、同じプロキシグループ内の別のノードも試してください。遅延テストに数値が表示されても、それはテスト対象への結果にすぎず、すべてのWebサイトにアクセスできることを示すものではありません。
インストール後、ダブルクリックしても起動しない場合の確認項目

まずシステムトレイまたはメニューバーに、すでに起動中のインスタンスがないか確認します。次にアーキテクチャと最低OSバージョンを確認してください。Windowsではタスクマネージャーでプロセスを確認し、必要に応じてアプリのログやイベントビューアーを調べます。リリースノートで特定のランタイムやWebView2が必要とされている場合は、公式の依存関係の案内に従ってインストールしてください。不明なサイトからDLL単体をダウンロードしないでください。ポータブル版の場合は、すべてのファイルが展開済みで、フォルダーに書き込み権限があることも確認します。

ログにaddress already in useと表示された場合の対処

通常は、待ち受けポートがすでに使用中という意味です。Windowsではnetstat -ano | findstr :7890でプロセスIDを確認できます。macOSではlsof -nP -iTCP:7890 -sTCP:LISTENで待ち受け中のプロセスを確認します。まず、重複して起動しているクライアントを終了するか、ポートを変更してください。ポートを変更した場合は、システムプロキシと手動で設定したアプリの両方も更新する必要があります。

HTTPSサイトで証明書エラーが出たら、証明書のインストールが必要?

通常のHTTP CONNECT、SOCKS、TUNによる転送では、クライアントのルート証明書をインストールする必要はありません。まず端末の日付とタイムゾーン、サイトのドメイン、証明書の有効期限を確認し、ネットワークにログインポータルや企業のHTTPS検査がないか調べてください。エラーを消すために配布元不明のルート証明書をインストールしたり、skip-cert-verifyを標準の対処としてtrueに変更したりしないでください。

ノードのTLSハンドシェイクログにエラーが表示される場合は、ノードのサーバー名、SNI、サーバー証明書を確認し、サービス提供元に設定の修正を依頼してください。ブラウザーでアクセスしたWebサイトの証明書エラーとは、発生する段階が異なります。

クライアントを終了すると、かえってブラウザーがネットに接続できない場合

まず、システムプロキシが停止中の127.0.0.1:7890を接続先として残していないか確認します。クライアントを再起動できる場合は、システムプロキシを無効にしてから通常の手順で終了してください。クライアントを起動できない場合は、システムのプロキシ設定から残った手動プロキシを削除します。Androidでは「VPNなしの接続をブロック」が有効になっていないか確認し、必要に応じて元の設定に戻してください。

クライアントをダウンロード