Clash for Windowsのインストールと初期設定｜ダウンロードからシステムプロキシの有効化まで

1. インストール前に確認すること：クライアント、コア、サブスクリプション

Windows版Clashを使うには、クライアント、コア、設定情報の3つが必要です。クライアントは画面やタスクトレイ、システム設定への入口を提供し、コアは設定を読み込んで通信を処理します。サブスクリプションまたはローカルのYAMLファイルには、ノード、プロキシグループ、ルールが含まれます。インストールできても、利用可能な接続先があるとは限らず、ブラウザーの通信がプロキシ経由になっているとも限りません。

Clash Metaは後継のmihomoへと名称を変えて開発が続いています。mihomoベースのクライアントでは、mihomoがサポートする設定項目を利用できますが、旧Clashコアでは同じ設定を読み込めない場合があります。「未対応のプロキシタイプ」や「不明なフィールド」などのエラーが出たら、Windowsに何度も再インストールするのではなく、サブスクリプションの形式とコアの互換性を確認してください。

ダウンロード前に確認する3項目

OSとアーキテクチャ：Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。IntelまたはAMD搭載の一般的な64ビットPCではx64を選びます。ARMデバイスでは、クライアントがARM64版を提供しているか、対応状況の説明も確認してください。
クライアントとコアのバージョン：インストール後、「バージョン情報」などの画面でそれぞれのバージョンを確認して控えておきます。問題を報告するときは両方を伝え、「最新版」とだけ書かないようにしましょう。
設定の入手先：提供元から発行されたClashまたはmihomo形式のサブスクリプションURL、または利用可能なYAMLファイルを用意します。アカウント管理ページのURLは、通常サブスクリプションとしてそのまま読み込めません。

2. ダウンロードとインストール：まず通常のプロキシを使い、必要な権限を確認

当サイトのインストーラー配布ページからWindows対応クライアントを選び、システム要件、アーキテクチャ、メンテナンス状況を確認します。旧クライアントを使用中の場合は、先にシステムプロキシを無効にしてタスクトレイから終了し、新旧のプログラムが同じポートを取り合わないようにしてください。

インストールまたは展開します。インストーラーはウィザードに従って進めます。ポータブル版は C:\Tools\ClashClient などの固定フォルダーにすべて展開してください。圧縮ソフトのウィンドウから直接実行しないでください。
通常の方法で起動します。最初はシステムプロキシのみを試し、TUNはまだ有効にしません。通常のローカルプロキシを使うだけなら、画面を常に管理者として実行する必要はありません。
タスクトレイとコアの状態を確認します。ウィンドウを閉じても、通知領域でプログラムが動作し続ける場合があります。ログを開き、設定の読み込み失敗、ポートのバインド失敗、コアの繰り返し終了がないか確認してください。
自動起動は後回しにします。サブスクリプション、ルールモード、Webページへの接続を確認してから、「スタートアップに登録」や「起動時にシステムプロキシを有効化」を設定しましょう。トラブルシューティングで確認する要素を減らせます。

SmartScreenやセキュリティソフトによるブロック

ダウンロードしたファイルを開いたときに「WindowsによってPCが保護されました」と表示されても、それだけで安全かどうかは判断できません。まず入手元、ファイルのプロパティに表示される発行元、セキュリティソフトの検出名を確認してください。入手元を確認できない場合は実行を中止しましょう。リアルタイム保護の無効化をインストール手順にしないでください。

起動後にファイルが消えた場合は、「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」で、対象と処理理由を確認します。会社のPCでは、組織のポリシーによりアプリの実行やドライバーのインストールが制限されている場合もあります。管理者に確認してください。ファイルの入手元とリスクを確認したうえで個別に対処し、ダウンロードフォルダー全体を除外対象に設定するのは避けましょう。

3. サブスクリプションを追加：ダウンロード後に設定を有効化

クライアントの「サブスクリプション」「設定」「Profiles」などの画面を開き、「新規作成」「インポート」またはURL入力欄からサブスクリプションを追加します。メニューはクライアントによって異なりますが、「設定を取得」してから「現在の設定として選択」することが重要です。一覧に表示されているだけでは、コアがその設定を使用中とは限りません。

サブスクリプションURLを省略せずに貼り付け、前後に空白がないことを確認します。元のクエリパラメーターは削除しないでください。
ダウンロードまたは更新を実行して、結果を確認します。成功したら、ノードとプロキシグループが表示されるか確認してください。
追加した設定を有効にし、ログで読み込みの完了を確認します。
「プロキシ」または「プロキシグループ」の画面を開き、ルールで使われるメインのプロキシグループに利用可能なノードが選択されているか、設定済みの自動選択グループが選ばれているか確認します。

サブスクリプションのエラーは応答内容で切り分ける

状況	まず確認する項目
HTTP 401または403	トークンの有効性、アカウント権限、提供元のアクセス制限を確認します。応答の説明を読み、再インストールで解決しようとしないでください。
HTTP 404	URLが完全か、提供元がサブスクリプションURLを変更していないか確認します。
タイムアウトまたはドメイン名の解決失敗	ローカルネットワークとサブスクリプションのドメインに接続できるか確認します。旧プロキシ設定が現在のダウンロードに影響していないかも確認してください。
YAMLの解析エラー	取得した内容がログインページやエラーページではないか、設定ファイルのインデントが崩れていないか確認します。
未対応のプロキシタイプ	サブスクリプションが現在のコア向けの形式か、クライアントに含まれるコアが使用中のプロトコルに対応しているか確認します。

4. ルールモードとシステムプロキシ：個別に設定して個別に確認

初めて使う場合は「ルール / Rule」モードがおすすめです。ルールによって、コアに届いた通信を直接接続、プロキシグループ、拒否のどれに振り分けるかが決まります。「全般 / Global」では通常、通信がグローバルポリシーの選択先に送られ、「直接接続 / Direct」ではリモートのプロキシノードを経由しません。モードの切り替えで変わるのはコアの処理方法であり、すべてのアプリが自動的にコアへ通信を送るわけではありません。

クライアントの「システムプロキシ / System Proxy」を有効にし、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの状態を確認します。クライアントがサーバーに 127.0.0.1 を設定し、現在のHTTPまたはmixedの待ち受けポートを指定する場合があります。別の方法でプロキシを設定するクライアントもあるため、説明書に従って判断してください。競合する手動設定を重ねて追加しないようにしましょう。

一連の接続で同じポート番号を使う

たとえば現在の設定が mixed-port: 7890 の場合、明示的なHTTPプロキシのアドレスは http://127.0.0.1:7890 です。mixedポートではHTTPとSOCKSのプロキシ接続を受け付けます。SOCKS専用ポートをWindowsの手動HTTPプロキシとして使うことはできません。また、管理インターフェースの external-controller はブラウザー用プロキシの接続先ではありません。

まず待ち受けを確認：コアが対象ポートで動作し、システムプロキシのアドレスとポートが一致していることを確認します。
次に通信を確認：EdgeまたはChromeで新しいページを開き、クライアントの「接続」一覧に該当するリクエストが表示されるか確認します。
最後に出口を確認：その接続に適用されたルール、プロキシグループ、最終ノードを確認します。ルールによって直接接続になるサイトで、ローカル回線から接続されるのは正常です。

ブラウザーの拡張機能、企業ポリシー、アプリ内のプロキシ設定がシステム設定より優先される場合があります。Firefoxでは、「設定」→「一般」→「ネットワーク設定」で「システムのプロキシ設定を使用する」が選択されているかも確認してください。「システムプロキシが有効」と「すべてのアプリがプロキシを使う」は同じ意味ではありません。

5. 初回の動作確認：ポート、ノード、アプリの問題を切り分ける

まずPowerShellでローカルポートを確認し、その後、プロキシを明示したリクエストを送ります。以下はmixedポート7890を使った例です。接続先はテスト方法を示すもので、結果は対象サイトやネットワークの接続状況によって異なります。実測値ではなく、特定の応答時間を保証するものでもありません。

PowerShell · ローカル待ち受けとプロキシを指定したテスト

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

TcpTestSucceeded: True はTCPポートに接続できることを示すだけで、リモートノードが利用可能とは限りません。2つ目のコマンドではプロキシを明示するため、「アプリがWindowsのシステムプロキシを使うかどうか」という要素を切り分けられます。ここでは curl.exe を使用し、Windows PowerShellで curl が別名として扱われることによる引数の違いを避けています。

ローカルポートに接続できない：コアが動作しているか、ポート番号が正しいかを確認し、まず設定の読み込みエラーや待ち受けエラーに対処します。
ポートに接続できるがプロキシ経由のリクエストが失敗する：選択中のノード、適用されたルール、認証情報、DNS、接続先を確認し、同じ時間帯のログを確認します。
プロキシを明示した接続は成功するが、ブラウザーでは失敗する：Windowsのプロキシ設定、ブラウザーの拡張機能、ブラウザー独自のネットワーク設定を重点的に確認します。
Webページは開くが、接続一覧に記録されない：直接接続、ブラウザーのキャッシュ、別のプロキシ設定を使っている可能性があります。新しいリクエストを送って確認してください。

HTTPS通信で出力される 200 Connection established は、HTTP CONNECTトンネルが確立したことを示すだけです。その後のTLSハンドシェイクと接続先からの応答も確認してください。接続先が403を返しても、プロキシポートが使えないとは限りません。出力全体を見て、接続先サイトの拒否かプロキシ経路の失敗かを判断します。

6. インストール時によくある問題：ポート競合、権限、設定の上書き

7890が使用中：プロセスを特定し、見覚えのないサービスを終了しない

ログに address already in use やバインド失敗が表示されたら、PowerShellでポートを使用中のプロセスを確認します。以下のコマンドは情報を表示するだけで、プログラムを停止しません。プロセスの詳細を確認するには、管理者権限が必要な場合があります。

PowerShell · ポートの使用状況を確認

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

旧プロキシプログラムが原因だと確認できたら、通常の方法で終了します。そのポートを使い続ける必要がある場合は、現在のクライアントのポート設定または永続的な上書き設定で、7891 などの空きポートに変更できます。Windowsのシステムプロキシと明示テスト用のコマンドも更新してください。サブスクリプション管理クライアントは更新時に元のYAMLを上書きすることがあります。キャッシュファイルを直接編集しても、設定が維持されない場合があります。

権限不足：ファイルへの書き込みとTUNサービスを切り分ける

「設定を保存できません」というエラーは、フォルダーのアクセス権、読み取り専用ファイル、セキュリティソフトによる書き込みのブロックが原因の場合があります。まずエラーに表示された実際のパスを確認してください。TUNサービスのインストール、仮想ネットワークアダプター、ルートの変更には、管理者の許可が必要な場合があります。システムプロキシが使えているなら、通常のWeb閲覧のためにTUNを無理にインストールする必要はありません。システムプロキシに対応していないアプリの通信も処理する必要がある場合は、クライアントの説明に従ってサービスをインストールし、権限を確認してください。

コントロールインターフェースのエラー：9090を通信ポートとして使わない

external-controller は画面からコアを管理するための設定で、127.0.0.1:9090 がよく使われる例です。このポートが競合すると、画面でノードや接続一覧を取得できなくなる場合がありますが、変更しても mixed-port の設定変更にはなりません。ローカルホストでの待ち受けを維持し、アクセスキーを設定してください。トラブルシューティングのために、すべてのネットワークインターフェースで公開しないでください。

7. プロキシが効かない・終了後にネットにつながらない場合

ブラウザーは使えるのに、ターミナル、ゲーム、その他のアプリで接続できない場合は、まずそれらのアプリがシステムプロキシに対応しているか確認します。独自のネットワーク処理を使うアプリや、通信の一部にUDPを使うアプリは、WindowsのHTTPプロキシ設定を変更するだけではプロキシ経由になりません。ターミナルツールによっては、専用の引数やプロキシ環境変数だけを参照します。netsh winhttp show proxy で表示されるWinHTTPの設定は、Windowsの設定画面にあるユーザープロキシと同じものではありません。

TUNは通信を引き受けるための次の選択肢であり、初期設定に必須ではありません。仮想ネットワークアダプターとルーティングを使って、設定で指定した範囲の通信を処理しますが、実際の動作はルート、DNS、除外設定、コアの対応状況によって異なります。有効にする前に、この記事の手順でプロキシを明示したテストを済ませてください。基本となるノードが使えない状態では、TUNに切り替えても自動では解決しません。

クライアントの終了後にインターネットへ接続できない

クライアントを再起動し、「システムプロキシ」を無効にしてから通常の方法で終了します。その後、Windowsのプロキシ設定が元に戻ったか確認してください。
クライアントを起動できない場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、停止中のローカルポートが指定されたままになっていないか確認します。
個人のデバイスでは、対象クライアントが設定した残存の手動プロキシだと確認してから削除します。職場のネットワークで共通プロキシや設定スクリプトを使っている場合は、元の値を控え、管理者に相談してください。
ブラウザーを再起動して接続を確認します。それでも失敗する場合は、他のVPN、ネットワークフィルタリングソフト、DNSを確認してください。最初からすべてのネットワーク設定をリセットするのは避けましょう。

問い合わせる際は、Windowsのバージョン、クライアントとコアのバージョン、使用中のモード、待ち受けポート、エラー発生時刻前後の機密情報を伏せたログを添えてください。一度に変更する項目を1つに絞り、同じテストを繰り返すことで、原因がサブスクリプション、ノード、システム設定、特定のアプリのどれかを判断できます。