Clashの初回インストールと初期設定｜全プラットフォーム共通の手順と注意点

初期設定の手順：まず設定を読み込み、次に通信をプロキシへ通す

インストールが完了しても、クライアントのファイルが端末に配置された段階にすぎず、プロキシが使えるとは限りません。デスクトップ版クライアントは通常、GUIとプロキシコアで構成されています。GUIはサブスクリプションやグループ、各種設定を管理し、コアは設定の解析、ポートの待ち受け、通信の転送を担います。Clash Metaは後継のmihomoとして開発が続いており、コアによって対応するプロトコルや設定項目は異なります。

初回は次の順番で設定してください。1つずつ完了してから次へ進めば、問題が起きても原因を特定しやすくなります。DNS、ポート、ノードを同時に変更する必要もありません。

1. 端末のアーキテクチャを確認して対応するクライアントをインストールし、クライアントとコアの名称・バージョンを記録します。
2. ネットワークを制御しているほかのプロキシアプリを終了し、端末から通常のWebページにアクセスできることを確認します。
3. サブスクリプションまたはローカルのYAMLファイルを読み込み、設定を選択してコアが起動するか確認します。
4. ルールモードにして、実際に通信を処理するグループでノードを選択します。
5. デスクトップではシステムプロキシを有効にします。AndroidではクライアントにVPN接続の権限を許可します。
6. ブラウザーでのアクセスと接続ログを確認し、最後にTUN、バックグラウンド実行、自動起動を設定します。

インストーラーと権限：プラットフォームごとに必要条件を確認

Windows：すべての不具合を権限不足のせいにしない

インストール後は、まず通常のユーザーで起動します。システムプロキシを有効にしただけでローカルポートのバインドに失敗する場合は、管理者として何度も起動するのではなく、まずポートの競合を調べてください。システムプロキシが切り替えるのはプロキシの入口であり、すべてのアプリが自動的にプロキシを使うわけではありません。一部のゲーム、コマンドラインツール、独自のネットワーク機能はこの設定を経由しません。

macOS：セキュリティ警告とファイル破損を見分ける

アプリの起動がシステムにブロックされた場合は、まずダウンロード元とインストーラーのアーキテクチャを確認します。入手元が信頼できることを確認したうえで、「システム設定」→「プライバシーとセキュリティ」に該当アプリの起動許可が表示されているか確認してください。クライアントを起動するためだけにシステム全体のセキュリティ機能を無効にしたり、出所不明のターミナルコマンドを実行したりしないでください。

Android：接続の権限とバックグラウンドの権限を分けて確認

VPNの許可は通信の入口を制御し、バッテリー最適化はバックグラウンドでの動作に影響します。アプリを開いている間は使えても、画面ロック後に頻繁に切断される場合は、「設定」→「アプリ」→該当クライアント→「バッテリー」でバックグラウンド制限を確認してください。項目名はメーカーやOSによって異なります。初回テストでは既定の設定を維持し、接続が安定したことを確認してから必要に応じて制限を緩和します。

サブスクリプションとYAMLの読み込み：内容・互換性・適用状態を確認

クライアントに利用可能なノードが自動で用意されるわけではありません。サブスクリプションURLは通常、利用中のサービスのアカウントページから取得します。URLにアクセストークンが含まれる場合があるため、パスワードと同様に扱ってください。URL全体を公開フォーラムに貼り付けたり、スクリーンショットや共有ログに載せたりしないでください。スクリーンショットを送る前に、ノードの認証情報も必ず隠します。

1. クライアントの「設定」または「サブスクリプション」画面を開き、URLから読み込むか、ローカルファイルをインポートします。画面の名称はクライアントによって異なります。
2. ダウンロードが終わるまで待ち、設定が一覧に表示されたことを確認します。失敗した場合はルールをすぐに変更せず、HTTPステータス、証明書、ネットワークのエラーを確認してください。
3. 読み込んだ設定を選択し、現在使用する設定にします。読み込みに成功した状態と、実際に使用中の状態は別です。
4. 実行ログを確認します。YAMLのインデントエラー、未対応プロトコル、ポリシーグループの不足がある場合は、システムプロキシを有効にする前に修正してください。

「設定ファイルの形式が正しくありません」というエラーは、必ずしもYAML自体の問題とは限りません。期限切れのサブスクリプションがログインページを返している、別のクライアント向け形式が返されている、ノード一覧だけで完全な設定が含まれていない、といった原因も考えられます。ファイルの冒頭が<html>なら、ルールを数行追加するのではなく、サブスクリプションのURLとアカウントの状態を確認してください。

設定項目に互換性がない場合は、まず実行中のコアを確認

mihomoで使えるプロトコルや拡張設定が、古いClashコアでは動作しないことがあります。クライアントの「バージョン情報」またはコア情報の画面で実際のバージョンを確認し、そのバージョンに対応したドキュメントを参照してください。インストーラーのファイル名だけでコアの対応状況を判断したり、チェックを通すために不明な項目を削除したりしないでください。

ポートの競合：7890を例にローカルの待ち受けを確認

以下はローカルの接続口の設定例です。7890はこの記事で使う例であり、すべてのクライアントで固定の値ではありません。mixed-portはHTTPプロキシとSOCKSプロキシの両方の接続を受け付けます。画面または適用中の設定で実際のポートを確認し、テストコマンドにも同じ値を指定してください。

# ローカル接続口の設定項目のみを示しています。サブスクリプション全体の設定ではありません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

この部分だけでサブスクリプションファイル全体を置き換えないでください。元のノード、ポリシーグループ、ルールが失われます。端末内だけで使う場合は、LANからのアクセスを無効にしてください。端末内のテストのために、ルーターのポートを開放したり、端末のファイアウォール全体を無効にしたりする必要はありません。

Windows：まず待ち受け中のプロセスを特定

netstat -ano | findstr :7890
tasklist /FI "PID eq 1234"

1つ目のコマンドで、指定したポートを含む接続記録を確認します。ローカルアドレスが:7890で終わり、状態がLISTENINGの行を探してください。最後の列にPIDが表示されます。2つ目のコマンドにある1234は例なので、実際のPIDに置き換えます。プロセスを特定してから通常の方法で終了し、システムプロセスをむやみに強制終了しないでください。

macOSとLinux：同じポートを確認

# macOS用。Linuxでもlsofをインストールすれば使用できます
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

ほかのユーザーのプロセス情報を確認するには、追加の権限が必要な場合があります。古いクライアントがバックグラウンドで動いている場合は、古いインスタンスを終了してから現在のコアを再起動してください。ポートを変更する場合、たとえば7892にするなら、手動のプロキシ設定、ブラウザー拡張、ターミナルの環境変数も合わせて更新します。設定ファイルだけを変更しても、アプリが古いポートに接続し続けることがあります。

プロキシモードとTUN：まずルールの経路を確認

初回はルールモードを選択してください。設定内のルール順に従って、通信を直接接続、拒否、または該当するポリシーグループへ振り分けます。グローバルモードは通信をグローバルポリシーに渡すもので、利用可能なノードを自動選択する機能ではありません。ダイレクトモードもクライアントの切断を意味するのではなく、通信の処理方法を変更するモードです。

ポリシーグループを開き、現在の選択を確認します。たとえばルールの末尾がProxyというグループを参照しているなら、そのグループが利用可能なノードを選んでいることを確認してください。別のテスト用グループの遅延だけを見ても判断できません。画面に遅延が表示されても、特定のテスト先にその時点で接続できたことを示すだけです。すべてのサイト、プロトコル、地域限定サービスが使えるとは限りません。

• デスクトップのブラウザでテスト：システムプロキシを有効にし、独自にプロキシを指定するブラウザ拡張機能を一時的に無効にして、確認したいサイトにアクセスします。
• ターミナルでテスト：プロキシを明示するオプションを指定し、ターミナルがシステムプロキシを読み込まないことをクライアントの不具合と誤認しないようにします。
• 接続ログ：クライアントで接続先のドメイン、適用されたルール、ポリシーグループ、最終的なノードを確認し、想定した経路で通信していることを確かめます。

# Windows PowerShell用。curl.exeを明示して実行
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com/

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

このコマンドで確認できるのは、指定した接続先へのHTTPリクエスト1回だけです。サイトから応答があれば、そのリクエスト経路で通信できたことを示します。接続が拒否された場合は、まず待ち受けポートを確認してください。タイムアウトが続く場合は、ログを見てノードと接続先を調べます。例のURLに接続できても、ほかのURLで使えるとは限りません。実際の用途でもテストしてください。

TUNモードは最後に有効にする

TUNは仮想ネットワークインターフェースを通じ、そこへルーティングされた通信を処理します。システムプロキシを参照しないアプリで役立ちます。実際に制御される範囲は、ルート、除外設定、DNSにも左右されるため、すべての通信を必ず捕捉する機能ではありません。Windows、macOS、Linuxでは通常、サービス、ドライバー、システムのネットワーク権限が関係します。AndroidではシステムがVPNインターフェースの許可を管理します。

基本的な接続経路が正常に動作し、ほかのアプリの通信も制御する必要がある場合に限り、TUNを有効にしてください。有効にした後、社内ドメイン、会社のVPN、LAN内の機器に接続できなくなった場合は、まずTUNを無効にして比較し、ルートとDNSを1つずつ確認します。DNSの変更、Fake-IPの有効化、複数のルート設定を同時に行わないでください。関連項目はYAMLマニュアルのDNS設定とFake-IPの解説を参照してください。

自動起動と再起動後の確認：画面・コア・プロキシの状態をチェック

起動時に画面を開く、プロキシコアを起動する、システムプロキシを自動で有効にする、という設定は通常それぞれ別です。手動起動で安定することを確認してから、クライアントの設定で必要な項目を有効にします。Windowsでは「設定」→「アプリ」→「スタートアップ」で起動項目を確認できます。macOSでは「システム設定」→「一般」→「ログイン項目と機能拡張」でログイン項目やバックグラウンド項目を確認してください。項目名はOSのバージョンによって異なる場合があります。

Androidの自動起動とバックグラウンド動作の制限は、クライアントとシステムの仕様によって異なります。長時間接続する必要がある場合は、まず画面ロック後も正常にアクセスできるか確認してから、バッテリー制限を変更してください。システムの「VPNを常時接続」と「VPNを使わない接続をブロック」は別の設定です。後者を有効にするとVPNが使えないときにネットワーク接続が制限されるため、影響を理解したうえで設定してください。

初回の再起動後に各項目を確認

1. クライアントとコアが起動しており、想定したサブスクリプションが現在の設定になっていることを確認します。
2. 待ち受けポートが変わっていないこと、ルールモードとポリシーグループの選択が正しいことを確認します。
3. デスクトップではシステムプロキシまたはTUNが想定どおり復元されているか確認します。AndroidではVPN接続の状態を確認します。
4. 通常のWebページ、利用したいサービス、LAN内のリソースをそれぞれテストします。通知領域のアイコンだけで判断しないでください。
5. クライアントを通常の方法で終了し、デスクトップのシステムプロキシが無効になることを確認します。終了後にネットワークへ接続できなくなった場合は、プロキシ設定が残っていないか調べてください。

Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で、ローカルポートが指定されたままになっていないか確認できます。macOSでは「システム設定」→「ネットワーク」→現在の接続→「詳細」→「プロキシ」を確認してください。変更前に元の設定を記録します。特に組織で管理されている端末では、既存の組織プロキシを上書きしないでください。

以上の確認が済んだら、ルールの追加やDNSの変更に進みます。サブスクリプションの問題はサブスクリプションに関するよくある質問、モードの違いはプロキシモードの解説をご覧ください。設定は1つずつ変更し、元に戻せる状態を保ってください。