Clashクライアント初回インストールガイド｜初期設定とよくあるトラブル

1. インストール前に確認すること：OS・アーキテクチャ・設定ファイルの入手先

Clashクライアントを初めてインストールする際は、まずOS、プロセッサのアーキテクチャ、利用可能な設定ファイルの有無を確認しましょう。クライアントをインストールしても、ローカルのプロキシ接続口が用意されるだけで、接続可能なプロキシノードが自動で作成されるわけではありません。設定ファイルがない状態では、システムプロキシやTUNモードを切り替えても、通常は問題を解決できません。

Clashは、プロキシコアとその関連エコシステムを指す一般的な呼び名です。クライアントは設定管理、ノード選択、システム設定を担います。Clash Metaは後にmihomoへ改称され、このエコシステムのコアとして利用されています。クライアントによって搭載コアが異なる場合があるため、画面が似ているだけで設定項目がすべて共通だとは限りません。インポート前に「バージョン情報」やコア情報を確認し、クライアントとコアのバージョンを記録しておくと、トラブル時の切り分けに役立ちます。

2. 初回起動：権限は用途ごとに確認

初回起動時は、まず画面が正常に表示されることを確認してから設定をインポートし、必要に応じてシステムプロキシや仮想ネットワークアダプターを有効にします。デスクトップ版では、システムプロキシ、コアの起動、TUNサービスに必要な権限はそれぞれ異なります。すべての権限確認を管理者権限が必須だと考えないでください。

Windows・macOS

• Windows：TUN機能でサービスのインストールや管理者権限を求められた場合は、まず表示されたプログラムのパスを確認してください。通常の画面操作を、管理者アカウントの常時使用で解決すべきではありません。Windows セキュリティでファイルがブロックされた場合は、「ウイルスと脅威の防止」→「保護の履歴」で対象を確認し、リアルタイム保護全体をいきなり無効にしないでください。
• macOS：起動がブロックされた場合は、まずダウンロード元と製品が対応するOSバージョンを確認してください。入手元が明確で、実際に起動する必要があるアプリは、システムの案内に従って「システム設定」→「プライバシーとセキュリティ」を確認します。警告を回避するために、システムのセキュリティ機能を一括で無効にしないでください。
• サービス権限：一部のクライアントは補助サービスを使ってルーティングを設定します。サービスのインストールに失敗した場合は、クライアントのサービス状態とログを確認してください。システムプロキシを有効にできても、TUNに必要なサービスがインストール済みとは限りません。

Android・iOS・Linux

• Android：初回のプロキシ接続時に、通常はシステムのVPN接続許可が表示されます。許可を求めているのが、インストールしたクライアントであることを確認してください。ローカルファイアウォールやフィルタリングツールなど、システムのVPN枠を使用している他のアプリは先に切断します。
• iOS：初回接続時は、システムの案内に従ってVPN構成を追加し、デバイス認証を行います。VPNの許可とサブスクリプションのインポートは別の操作です。サブスクリプションをインポートした後も、接続を開始する必要があります。
• Linux：GUIクライアントのシステムプロキシはデスクトップ環境に依存する場合があり、TUNには通常、追加の権限やサービスが必要です。製品の説明に従ってサービスを設定してください。クライアントのディレクトリ全体に過剰な権限を再帰的に付与したり、GUIを常にrootで実行したりしないでください。

モバイル端末では、システムが許可するVPN拡張機能やサービスを使って接続を処理するため、アプリを常に前面に表示しておく必要はありません。Androidで画面ロック後に切断される場合は、「設定」→「アプリ」→該当クライアント→「バッテリー」でバックグラウンド制限を確認してください。項目名はメーカーによって異なります。iOSではVPNの状態とクライアントの接続ログを確認し、「バックグラウンドでの終了を禁止する」設定で接続トラブルを代替しないでください。

3. 設定をインポート：内容を確認してから接続

1. クライアントの「設定」または「サブスクリプション」画面を開き、「新規作成」「追加」またはインポートの項目を選びます。製品によってメニュー名は異なりますが、設定を1件追加する操作です。
2. サービス提供元から案内された対応済みのサブスクリプションURLを貼り付けるか、ローカルのYAMLファイルを選択します。アカウント管理ページのURLをサブスクリプションURLとして使わないでください。
3. ダウンロードと解析が終わるまで待ち、更新日時、ノード一覧、プロキシグループが表示されることを確認します。サブスクリプション名が表示されただけでは、設定が利用可能だとは限りません。
4. この設定を現在の使用対象にします。クライアントに「ダウンロード」と「有効化」の項目が分かれている場合は、有効化も実行してください。
5. 「プロキシ」画面を開き、設定に含まれる選択グループからノードを選んで、接続をテストします。

サブスクリプションの更新に失敗したら、まずエラーが発生した段階を確認します。ダウンロードのタイムアウトは取得段階の問題です。ログインページ、認証画面、エラーページが返る場合は応答内容の問題です。YAMLの行番号やフィールド型のエラーが表示された場合に、設定の解析を調べます。すべての失敗をノードの無効化が原因だと決めつけないでください。

YAMLをローカルで編集する場合は、インデントにスペースを使い、Tabと混在させないでください。proxy-providers や rule-providers を含む設定では、リモートリソースの追加ダウンロードが必要になることがあります。メイン設定のインポート後も、プロバイダーの読み込み完了を確認してください。古いコアが新しいフィールドを認識できない場合は、エラーを消すために項目を適当に削除せず、設定の要件とコアの対応状況を確認します。

4. 初期設定：混合ポート・通信モード・ローカル待ち受け

デスクトップ版の初回設定では、まず「有効な設定」「コアの起動」「ルールモードの選択」「ローカル待ち受けポートの確認」を済ませてから、システムプロキシを有効にするのがおすすめです。AndroidとiOSでは通常、クライアントの接続ボタンからシステムVPNを起動するため、デスクトップ版のシステムプロキシ設定をそのまま適用する必要はありません。

ルール・グローバル・直接接続の違い

「ルール」は現在の設定のマッチ順に従って出先を決定します。「グローバル」はコアが処理するトラフィックを、グローバル選択グループに送ります。「直接接続」では、端末から接続先へ直接アクセスします。グローバルモードにしても、システムプロキシを使わないアプリが自動的にコア経由になるわけではありません。特定のサイトに接続できない場合は、ルールの問題を切り分けるため一時的にモードを切り替えてテストし、終了後に元へ戻してください。グローバルモードを、システム全体の通信を取り込むスイッチとして使わないでください。

最小限の設定例について

以下はmihomoでよく使われる項目を理解するための例です。接続に必要な設定一式ではなく、サブスクリプションを直接置き換えるものでもありません。ポートは端末の実際の設定に合わせてください。GUIクライアントがこれらの項目を自動生成または上書きする場合もあります。

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

127.0.0.1 はループバックアドレス、つまり自分の端末を示します。プロキシポートとコントローラーポートは用途が異なります。管理画面への接続に使うコントローラーアドレスを、ブラウザーのプロキシサーバー欄に入力しないでください。初回設定でコントローラーをLAN上のデバイスに公開する必要もありません。

5. 接続確認の手順：コア・明示的プロキシ・ブラウザー

トレイアイコンや接続スイッチの表示だけで、成功したと判断しないでください。以下の順にテストし、一度に変更する条件は1つに絞ります。まずログに設定の読み込み失敗や待ち受け失敗がないことを確認し、次にノードが選択されていることを確認してから、明示的なプロキシリクエストとブラウザーのアクセス結果を比較します。

リクエストを1回送ってローカルポートを確認

以下のコマンドは、混合ポートが実際に 7890 の場合を想定しています。Windows PowerShellでは、環境によって curl が別のコマンドとして解釈されるのを避けるため、curl.exe を使います。macOSとLinuxでは curl を使います。最大待機時間は15秒で、システムプロキシの設定は変更しません。

# Windows PowerShell
curl.exe -I --proxy http://127.0.0.1:7890 --max-time 15 https://example.com

# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://example.com

• 接続が拒否される：コアが起動しているか、ポート番号に誤りがないか、クライアントが別のアドレスだけで待ち受けていないかを確認してください。
• CONNECT成功の表示だけが出る：HTTPプロキシのトンネルは確立している可能性がありますが、その後に接続先からの応答が必要です。この表示だけでHTTPSリクエスト全体が成功したとは判断できません。
• 接続先から応答が返る：今回のリクエストがローカルプロキシ経由で完了したことを示します。403などの応答は接続先のポリシーによる場合もあり、すべての接続先にアクセスできるという意味ではありません。
• タイムアウトまたはTLSエラー：クライアントのログとあわせて、ノード、DNS、システム時刻、接続先を確認してください。証明書の検証を安易に無効にしないでください。

明示的なプロキシリクエストは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ拡張機能、独自プロキシ設定、システムの例外リストを確認してください。ブラウザーでは成功し、ターミナルからの直接リクエストが失敗しても、クライアントの障害とは限りません。ターミナルのツールは、デスクトップのシステムプロキシ設定を参照しないことがよくあります。コマンドの --proxy オプションを使うか、プロキシ環境変数に対応するツールには個別に設定してください。

遅延テストの結果は、クライアントが特定のテスト先に対して測定した値です。ダウンロード速度を示すものでも、すべてのサイトに接続できる証明でもありません。プロキシグループの選択項目を確認してから、「接続」画面やログに記録されたルールと出先を調べ、実際にどの経路でリクエストが処理されたかを確認しましょう。

6. 初回インストール時のよくあるトラブル：症状から原因を特定

ポート競合：同じアドレスを待ち受けできるのは1つのプロセスだけ

ログに address already in use やバインド失敗が表示されたら、古いプロキシクライアント、重複起動したコア、同じポートを使うデバッグツールを終了してください。Windowsでは netstat -ano | findstr :7890 を実行し、ローカルアドレス、状態、PIDを確認します。リモートアドレスにだけ7890が表示されている接続を、待ち受けプロセスと誤認しないでください。macOSでは lsof -nP -iTCP:7890 -sTCP:LISTEN、Linuxでは ss -ltnp を実行して待ち受け状態を確認します。プロセスの詳細確認には追加の権限が必要な場合があります。

プロセスの種類を確認してから停止し、正体のわからないシステムプロセスを終了しないでください。7891 に変更する場合は、新しいポートが使われていないことを確認したうえで、システムプロキシ、ブラウザーの独自プロキシ設定、テストコマンドも更新します。クライアントのポートだけを変更すると、他のアプリは引き続き古いアドレスに接続します。

画面は開くが、コアが起動しない

まずログを確認し、実行ファイルの欠落、アーキテクチャの不一致、設定の解析失敗、権限不足のどれに該当するか切り分けます。セキュリティソフトがコアを隔離している場合、画面は起動してもコアが動かないことがあります。保護の履歴とクライアントが参照するコアのパスを両方確認してください。入手元、検知内容、製品の説明を確認してから該当ファイルに対処し、ダウンロードフォルダー全体を恒久的な除外対象にしないでください。

TUNを有効にするとネットに接続できない、または社内LANにアクセスできない

まずTUNを無効にして、動作確認済みのシステムプロキシ経由の接続に戻します。その後、他のVPNが動作中でないか、補助サービスが正常か、ルートが社内LANを上書きしていないか、DNS設定が現在のネットワークと競合していないかを確認してください。TUNはルーティングと名前解決に関わるため、tun: の設定を一部コピーしただけでは、すべてのプラットフォームやネットワークで動作するとは限りません。会社の端末では管理ポリシーに従い、テスト目的で管理対象のルートを無理に変更しないでください。

クライアントを終了してもブラウザーでネットに接続できない

この場合、ブラウザーの再インストールではなく、システムプロキシ設定が残っていないか確認します。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」の手動プロキシを確認します。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を確認してください。停止中のローカルポートが設定されている場合は、インストール前の状態に戻します。組織で管理されているPACやプロキシアドレスは、許可なく削除しないでください。

7. インストール完了チェックリストと今後のメンテナンス

• インストーラーのアーキテクチャが適切で、クライアントとコアの両方が起動し、ログに同じエラーが繰り返し出ていないことを確認します。
• 現在の設定が有効になっており、プロキシグループに選択可能なノードがあり、サブスクリプションのプロバイダーリソースが読み込まれていることを確認します。
• 実際の混合ポートと現在の通信モードを記録し、この記事の例示ポートを端末固有の値だと思い込まないようにします。
• デスクトップ版では明示的なプロキシテストとブラウザーでのアクセスをそれぞれ1回行います。モバイル端末ではシステムVPNの状態を確認し、対象ページを実際に開いてみます。
• 端末を再起動し、クライアントが想定どおり起動するか、システムプロキシまたはVPNの状態がクライアントの動作状況と一致するか確認します。
• インストール前のプロキシ設定と設定ファイルのコピーを保管し、接続を切った後に通常のネットワークへ戻せることを確認します。

初回接続が確認できてから、スタートアップ、サブスクリプションの自動更新、TUNを有効にするか判断しましょう。サブスクリプションの更新頻度はサービス提供元の指定に従い、接続トラブルの解決に毎分更新する必要はありません。クライアントをアップグレードする前に、バージョンと現在の設定を記録します。アップグレード後は、設定の読み込み、ポートの待ち受け、よく使うアプリを確認してから、複雑なルールやLAN共有を再設定してください。

問い合わせる際は、OSバージョン、プロセッサのアーキテクチャ、クライアントのバージョン、コアのバージョン、操作手順、エラー発生時刻前後のログを伝えてください。「明示的なプロキシでは成功するが、ブラウザーでは失敗する」のように状況を具体的に伝えると、「接続できない」だけの場合より原因を特定しやすくなります。ログやスクリーンショットからサブスクリプションの認証情報を削除してください。特定のサイトで起きる問題なら、ルールモードの場合だけ発生するかどうかも伝えます。