Clash 初回インストール設定ガイド｜Windows・macOS・Androidの注意点とトラブル対処
Clashを初めて使う方向けに、Windows・macOS・Androidでの選び方や権限設定、サブスクリプションの追加手順を解説。ポート競合や証明書の警告への対処法も紹介します。
1. インストール前に確認すること：クライアント・コア・デバイスのアーキテクチャ
Clashクライアントは通常、GUIとプロキシコアで構成されています。GUIではサブスクリプションの管理やモードの切り替え、システム設定を行い、コアは設定の読み込み、ルールの適用、接続の確立を担います。Clash Metaは後にmihomoとして開発が続いていますが、クライアントによって同梱されるコアや対応する設定項目は異なります。「Clash対応」と記載されていても、サービス提供元が従来のClash形式を求めているのか、mihomoの機能を使う設定なのかを確認しましょう。
- Windows：Windows 11の「設定」→「システム」→「バージョン情報」で「システムの種類」を確認します。一般的なIntel・AMD搭載PCではx64を選択し、ARMデバイスではクライアントが提供するARM64版を選びましょう。
- macOS：Appleメニューから「このMacについて」を開きます。Appleシリコン搭載モデルではarm64、Intel搭載モデルではx64を選択します。Universal版がある場合は、プロジェクトの案内に従ってください。
- Android：最近のスマートフォンは通常arm64-v8aですが、古い機種やエミュレーターでは異なる場合があります。判断できない場合は、プロジェクトが提供する汎用APKを選び、必要なAndroidの最低バージョンも確認してください。
ダウンロード前に、プロジェクトのメンテナンス状況とリリースノートも確認しましょう。クライアントをインストールできても、OSの権限や新しい設定項目に対応しているとは限りません。初めて使う場合は、プラットフォームに合ったクライアントをダウンロードページから選び、クライアントとコアのバージョンを記録しておくと、問題発生時の切り分けに役立ちます。
2. 初回起動時に確認する権限：3つのプラットフォーム別
初回起動時に、すべての機能をすぐ有効にする必要はありません。まず設定をインポートし、システムプロキシまたはAndroidのVPNで最低限の接続を確認しましょう。デスクトップのTUNは仮想ネットワークアダプター、ルーティング、DNSに関わるため、基本の接続を確認してから個別にテストするのがおすすめです。
| プラットフォーム | まず確認する権限 | 間違えやすいポイント |
|---|---|---|
| Windows | システムプロキシの設定を許可し、クライアントの要件に応じてサービスをインストールするか、TUNに必要な権限を付与します。 | ファイアウォールの「アクセスを許可」は、システムプロキシが有効になったことを意味しません。また、インターネットからの着信を許可する必要があるという意味でもありません。 |
| macOS | 初回起動時に提供元を確認し、必要に応じてネットワーク拡張機能を許可します。 | アプリの起動許可、補助サービスの権限、証明書の信頼設定は、それぞれ別の操作です。 |
| Android | クライアントによるVPN接続を許可します。 | VPNアイコンは端末内の通信がVPNに接続されたことを示すだけで、接続先ノードが利用可能とは限りません。 |
Windows：システムプロキシとサービスモードの違い
システムプロキシは通常、端末内のHTTPプロキシアドレスをユーザー設定に登録し、その設定に従うアプリで利用します。すべてのゲーム、ターミナル、UDP通信を経由させる機能ではありません。一方、TUNは仮想ネットワークアダプターを使い、ルーティング設定に該当する通信を処理します。管理者としての起動やサービスのインストールが必要かどうかは、クライアントの実装によって異なります。ウェブページが開かないからといって、すべてのプログラムを常に管理者として実行するのは避けましょう。
macOS：提供元を確認してからシステムの警告に対処する
アプリを「アプリケーション」フォルダに移動してから起動することをおすすめします。macOS 15では、提供元に関する警告を「システム設定」→「プライバシーとセキュリティ」で確認できます。インストールファイルがプロジェクトの公式配布元から入手したもので、警告が初回起動時の制限に関するものだと確認できた場合のみ、システムの手順に従ってください。アプリの破損、悪意のあるコンテンツ、署名の異常を示す警告が出た場合は起動を中止し、入手元を再確認しましょう。システムのセキュリティ機能を一括で無効にしないでください。
Android：VPNの許可とバックグラウンド動作を別々に確認
初回接続時にシステムのVPN許可画面が表示されます。許可すると、クライアントがVpnServiceを使って通信を処理できるようになります。同じユーザーまたは仕事用プロファイルでは、通常、一般的なVPNサービスを同時に1つしか有効にできません。VPN型のファイアウォールや通信フィルターが競合する場合もあります。画面ロック後しばらくして接続が切れる場合は、アプリのバッテリー制限を確認してください。標準に近いAndroid 14では「設定」→「アプリ」→対象のクライアント→「アプリのバッテリー使用量」から確認できます。メーカー独自OSでは項目名が異なる場合があります。
3. サブスクリプションの追加：形式・状態・現在の設定を確認
サブスクリプションURLは設定を取得するためのもので、ノードそのものやソフトウェアのライセンスキーではありません。アカウントのトークンが含まれていることが多いため、パスワードと同様に管理してください。スクリーンショット、ログ、問い合わせ内容にURL全体を載せないようにしましょう。個人用のサブスクリプションを、提供元が不明なオンライン変換サイトに貼り付けるのも避けてください。
- サブスクリプションの形式を確認。サービス提供元のページで、現在のクライアントコアに対応したClashまたはmihomo形式を選びます。Base64形式のノード一覧、単体の共有リンク、完全なYAML設定は、それぞれ別の入力形式です。
- リモート設定を追加。クライアントの「設定」または「サブスクリプション」画面でリモート設定を追加し、URLを貼り付けてダウンロードします。メニュー名はクライアントによって異なるため、実際の画面を確認してください。
- ダウンロード結果を確認。更新日時、解析状態、プロキシグループの内容を確認します。HTTP 401や403の場合は、トークン、アカウント権限、サービス側の制限を確認しましょう。タイムアウトする場合は、現在のネットワークからサブスクリプションのURLにアクセスできるかを先に調べてください。
- インポートした設定を有効化。設定がリストに表示されても、適用済みとは限りません。対象を選択し、コアが正常に起動したことを確認してから、プロキシグループで利用可能なノードを選びます。
YAMLの解析エラーが発生した場合は、まずログに表示された項目名と行番号を確認してください。取得した内容がログインページやサービスのエラーメッセージだったり、現在のコアが対応していないパラメーターを含んでいたりする場合があります。この場合、ノードを何度切り替えても設定の構文エラーは解決しません。エラー行を適当に削除するのではなく、正しい形式を取得し直しましょう。
4. 初回接続：ルールモードとプロキシ経路を確認
最初の動作確認にはルールモードを選び、実際にルールから参照されているプロキシグループでノードを指定しましょう。ルールモードでは設定のルールに従って直接接続かプロキシ経由かが決まります。グローバルモードにしても、利用できないノードは直りません。ダイレクトモードもクライアントの終了を意味するわけではありません。TUNが有効な場合は通信が引き続きローカルのコアを経由し、外部への接続先だけが直接接続になることがあります。
- 現在の設定が有効になっており、コアの起動失敗や再起動の繰り返しがないことを確認します。
- デスクトップではシステムプロキシを有効にします。Androidでは接続をタップし、VPNの許可を完了してください。デスクトップで初回テストを行う際は、TUNを併用しないでください。
- 対象のプロキシグループで遅延テストを実行し、実際に使うウェブサイトにもアクセスします。テストに成功しても、確認先に接続できたことを示すだけで、すべてのサイトにアクセスできるとは限りません。
- 接続ログを開き、新しいリクエストが記録されていることを確認します。適用されたルール、プロキシの経路、最終的なノードも確認してください。既存の接続は切り替え前の経路を使い続ける場合があるため、切り替え後は接続し直しましょう。
デスクトップではローカルプロキシを明示的に指定すると、「コアが通信を転送できるか」と「ブラウザーがシステムプロキシを参照しているか」を切り分けられます。以下では、実際の待ち受けポートが7890のHTTPまたはmixedプロキシを例にします。これはあくまで例の値です。必ずクライアントの設定を確認してください。テスト対象のウェブサイトは、確認したいHTTPSアドレスに置き換えられます。
# Windows PowerShell
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.com
# macOSのターミナル
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 10 https://example.comHTTPレスポンスヘッダーが返ってくれば、指定したプロキシ経由で応答を受け取れています。ステータスコードの意味は接続先のサイトに応じて判断してください。コマンドは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ拡張機能、ブラウザー独自の設定、システムプロキシを確認しましょう。接続拒否のエラーが出る場合は、DNSをすぐ変更するのではなく、待ち受けアドレス、ポート、コアの状態を確認してください。
5. ポート競合：プロセスを確認してから設定を変更
ログにaddress already in useやbindの失敗が表示される場合、待ち受けアドレスまたはポートが使用中の可能性があります。古いクライアントが完全に終了していない、同じプログラムが二重に起動しているといったケースがよくあります。以下では引き続きTCPポート7890を例にします。調査コマンドは、クライアントを実行しているPC上で実行してください。
# Windows：ポートを使用しているPIDを確認
netstat -ano | findstr :7890
# 次にタスク マネージャーの「詳細」タブでPIDからプロセスを探す
# macOS：このTCPポートを待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN- 古いプロキシのプロセスが見つかった場合：まず旧ソフトの画面から通常の手順で終了してください。正体の分からないシステムプロセスを直接終了しないでください。
- ポートを変更する必要がある場合：たとえば
7890から7895に変更したら、システムプロキシ、ブラウザーの手動プロキシ、ターミナルのプロキシ設定も更新します。 - ポートが待ち受け状態にならない場合：コアのログを確認し、設定の読み込みが成功しているかを調べます。コントロールパネル用ポートは通信を中継するプロキシポートとは別物で、互いに代用できません。
端末内だけで使う場合は、待ち受け先をループバックアドレスに設定し、不要なLANアクセス機能は無効にしておきましょう。HTTP、SOCKS、mixed、コントロール用インターフェースは用途が異なります。「接続できるようにする」ためだけに、すべての待ち受け先を外部公開しないでください。
6. 証明書・DNS・TUN：症状に合わせて対処
証明書の警告が出ても、証明書をインストールする必要があるとは限らない
通常のHTTPSプロキシ接続はトンネル経由で通信するため、クライアントが提供するルート証明書のインストールは不要です。ブラウザーで証明書の日付が無効と表示されたら、まずシステムの日付、タイムゾーン、自動時刻設定を確認してください。ホスト名の不一致や発行元が信頼されていないという警告が出た場合は、アクセス先のドメイン名が正しいか、公衆Wi-Fiのログイン画面が表示されていないか、ほかのHTTPS検査ソフトの影響がないかを確認しましょう。
サブスクリプションの取得時にTLSエラーが発生した場合も、サーバー証明書と端末の日時を確認してください。証明書の検証をスキップする方法を一般的な解決策として使わないでください。チャットで送られてきたものや、見知らぬサイトから入手したルート証明書をインストールするのも危険です。会社の管理対象デバイスで明確な証明書ポリシーがある場合は、管理者に確認してください。
ドメインに接続できないときは、どの段階で名前解決しているかを確認
システムDNS、ブラウザーのセキュアDNS、プロキシコアのDNS、リモートノードでの名前解決が同時に使われる場合があります。サイトが開かないときは、ログを確認し、ドメインの名前解決に失敗したのか、解決後の接続がタイムアウトしたのかを切り分けましょう。Androidの「プライベートDNS」やメーカー独自のネットワーク設定が、名前解決の経路に影響することもあります。現在の設定を記録したうえで一時的に変更し、比較してください。DNSの設定を一度にすべて変更するのは避けましょう。
基本動作を確認してからTUNを有効にする
システムプロキシに対応していないプログラムの通信も処理したい場合に限り、デスクトップのTUNをテストしてください。有効にする前に、既存のVPN、仮想ネットワークアダプター、DNS設定を記録します。有効にした後は、コアのログ、デフォルトルート、接続ログを確認してください。システムプロキシが正常に動作する一方で、TUNを有効にすると通信できなくなる場合は、まずTUNを無効に戻してから、権限、ルートの競合、DNSの制御を調べましょう。クライアントを再インストールする必要はありません。
7. インストール後の動作確認と終了時のチェック
初回設定が終わったら、「接続済み」と表示されるかだけでなく、次の項目も確認しましょう。再起動、ネットワークの切り替え、サブスクリプションの更新後に同じ問題を調べ直す手間を減らせます。
- 設定の確認：現在の設定名と更新日時が明確で、ログに解析エラーが続いていないことを確認します。必要なプロキシグループに利用可能なノードがあることも確認してください。
- 通信の確認：新しいウェブリクエストが接続ログに記録され、直接接続またはプロキシ経由になった理由を説明できることを確認します。
- 終了時の確認：クライアントを終了する前にシステムプロキシをオフにするか、正規の終了手順を使い、通常のネットワーク接続が利用できることを確認してください。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの設定が残っていないか確認できます。
- 再起動後の確認：クライアントを再起動しても設定が選択されたままになっていることを確認します。自動起動を設定している場合は、別のネットワークツールも同時に起動しないか確認してください。
- モバイル回線の確認：AndroidではWi-Fiとモバイルネットワークを切り替えた後に再テストし、画面ロック後もバックグラウンド接続が維持されることを確認します。
- 問い合わせに必要な情報：OS、クライアントとコアのバージョン、具体的なエラー、再現手順を記録します。ログは必要な部分だけ共有し、サブスクリプションのトークン、パスワード、個人用アドレスは必ず隠してください。
問題が起きたときは、正常に動作する最小限の設定を保ちましょう。まず1つの設定、1つのノード、1つの通信処理方式で確認してから、自動更新、TUN、カスタムルールを追加します。原因を切り分けやすくなり、設定変更後も動作確認済みの状態へすぐ戻せます。