Windows版Clashのインストール・設定ガイド｜ダウンロードからシステムプロキシまで

1. Windowsのアーキテクチャとクライアントの種類を確認する

Windowsで「Clashをインストールする」と言う場合、通常はGUIクライアントを導入し、そのクライアントでプロキシコアを管理します。画面ではサブスクリプションや各種切り替え、ログを扱い、コアはポートの待ち受け、ルールの照合、ノードへの接続を担当します。Clash Metaは後継のmihomoとして開発が続いています。利用できる設定項目は、画面のタイトルだけで判断せず、コアのドキュメントと使用中のバージョンを確認してください。

この記事ではWindows 11の設定手順を紹介します。Windows 10では画面の名称が多少異なる場合があります。クライアントは、mihomoを使用するClash Verge RevのようなGUIを例にしています。特定バージョンのボタン配置が、すべてのクライアントで共通とは限りません。

「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。Windows 10では「システム」→「バージョン情報」にあります。
「x64 ベースプロセッサ」と表示される場合は、x64またはAMD64ビルドを選びます。AMD64はAMD製プロセッサ専用ではありません。
「ARM ベースプロセッサ」と表示される場合は、クライアントが提供するARM64ビルドを選びます。ダウンロードページに該当ビルドがない場合は、プロジェクトの対応OSを確認してください。x64インストーラーをネイティブARM64版として使うことはできません。
使用中のWindowsバージョンが、クライアントのリリースノートに記載された最低要件を満たしているか確認します。「64ビット」だからといって、すべてのWindowsで動作するわけではありません。

当サイトのダウンロードページからWindows用クライアントを選び、プロジェクトのリリースノートも確認してください。旧版のClash for Windowsは開発・保守が終了しています。既存の設定を移行する場合は、まずバックアップを取り、サポート中のクライアントに再インポートしてください。新旧のクライアントに同時にシステムプロキシを制御させないようにしましょう。

2. インストールと初回起動：通常権限とサービス権限の違い

インストール前に、元の状態へ戻せるよう準備する

以前使っていたプロキシクライアントを終了し、ログイン後にシステムプロキシを上書きし合わないよう、一時的にスタートアップを無効にします。
「設定」→「ネットワークとインターネット」→「プロキシ」に表示されている現在の設定を記録します。会社支給PCに設定済みのスクリプトアドレスやプロキシサーバーを、むやみに削除しないでください。
インストーラーは決まったフォルダーに保存します。ポータブル版はすべて展開してから実行し、圧縮ソフトのプレビュー画面から起動しないでください。

画面を開く、設定をインポートする、PC上のシステムプロキシを使うといった操作で、通常は常時管理者として実行する必要はありません。サービスのインストール、仮想ネットワークアダプターの設定、一部のネットワーク操作では、クライアントが権限の昇格を求めることがあります。ユーザーアカウント制御の確認画面が表示されたら、許可する前にプログラム名と配布元を確認してください。

SmartScreenとセキュリティソフトの警告は分けて対処する

「WindowsによってPCが保護されました」という表示は、SmartScreenの評価に関する警告の場合があります。マルウェアと判定されたことを意味するとは限りません。ダウンロード元、ファイルのプロパティに表示されるデジタル署名（提供されている場合）、プロジェクトのリリース情報を確認してください。配布元を確認できない場合は実行を中止し、安易に「実行」を選ばないでください。

Windows セキュリティがファイルを隔離した場合は、「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、検出名と対象のパスを確認します。問い合わせ時はその情報を伝えてください。PC全体のリアルタイム保護を無効にしたり、ダウンロードフォルダー全体を除外対象に追加したりしないでください。組織管理のPCは、管理者に相談してください。

3. サブスクリプションを追加し、設定が有効か確認する

サブスクリプションURLは、プロバイダーがノードや設定一式を配布するためのURLです。ログインサイトのアドレスとは異なります。Clashの完全な設定ファイルには通常、プロキシ、グループ、ルールなどが含まれます。ノード一覧だけのサブスクリプションは、クライアントや設定テンプレートと組み合わせて使う必要があります。形式エラーが出た場合は、プロバイダーが提供する形式がClashまたはmihomoに対応しているか確認してください。

クライアントの「サブスクリプション」または「設定」画面を開き、「新規作成」「インポート」などの操作を選ぶか、URL入力欄にサブスクリプションURLを貼り付けます。
ダウンロードまたは更新を実行し、サブスクリプション名が追加されただけでなく、処理が成功したことを画面で確認します。
追加した設定を選択して有効にします。複数の設定を保存できるクライアントでも、一度に使用できるのは通常1つです。
「プロキシ」画面を開き、プロキシグループが表示されていることを確認して、実際に使うグループで利用可能なノードを選びます。
ログを確認し、YAMLの解析エラー、存在しないプロキシ名、ルールプロバイダーの読み込み失敗がないか確認します。

インポート時に401や403が表示された場合は、サブスクリプションの有効期限、トークンの状態、デバイス数の上限を確認します。タイムアウトの場合は、サブスクリプションのドメインに接続できるか確認してください。何度更新しても認証エラーは解決しません。サブスクリプションURLにはアカウントのトークンが含まれることが多いため、スクリーンショットやログ、問い合わせ内容ではURL全体を隠してください。

リモートサブスクリプションを使う場合、ダウンロードしたメイン設定ファイルを直接編集するのは避けましょう。次回の更新で変更が上書きされる可能性があります。ポートやルールの上書きが必要な場合は、クライアントの設定機能やオーバーライド機能を優先し、再読み込み後に実行中の設定へ反映されたことを確認してください。

4. システムプロキシを有効にする：ポートを確認して通信をテスト

システムプロキシは、Windowsのプロキシ設定に従うアプリをローカルのプロキシ接続先へ振り向ける機能です。すべてのプログラムを制御するものではありません。ブラウザーは通常利用できますが、ゲーム、一部のコマンドラインツール、独自にネットワーク接続を管理するアプリでは使われない場合があります。また、HTTPプロキシだけであらゆるUDP通信を中継することはできません。

ローカルの待ち受けアドレスとポートを設定する

まずクライアントの設定で「混合ポート」または mixed-port を確認します。以下では例として 7890 を使いますが、すべてのクライアントで共通の既定値ではありません。mixed-port は同じポートでHTTPとSOCKSのプロキシ要求を受け付けます。HTTPポートとSOCKSポートが別々に設定されている場合は、プロトコルに対応するポートを使ってください。

項目	この記事の例	確認場所・用途
プロキシアドレス	`127.0.0.1`	PC自身を示すアドレスで、ノードのサーバーアドレスではありません。
混合ポート	`7890`	クライアントで現在有効な値を使います。
システムプロキシ	有効	Windowsの「ネットワークとインターネット」→「プロキシ」で確認します。
接続モード	`rule`	ルールに応じて接続先を選ぶ、日常利用に適したモードです。
LANからの接続を許可	無効	PC内だけで使う場合、通常は有効にする必要はありません。

コアが正常に動作していることを確認し、実際の混合ポート番号を控えます。
クライアントの「システムプロキシ」を有効にしてから、Windowsのプロキシ画面でサーバーアドレスとポートを確認します。PACスクリプトが設定されている環境では、手動プロキシの項目だけで判断しないでください。
モードを「ルール」にし、プロキシグループでノードを選択します。ルールモードでは一部のサイトが直接接続されることがあります。これはルールによる判断で、必ずしもスイッチの不具合ではありません。
接続を確認したいWebページを開き、クライアントの「接続」画面で接続先、適用されたルール、送信先の経路を確認します。

プロキシを明示するコマンドで問題を切り分ける

PowerShellで次のコマンドを実行します。テスト用ドメインは接続確認の例です。成功しても、今回のリクエストがローカルのプロキシ経由だったことを示すだけで、すべてのサイトやプロキシグループが正常とは限りません。

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

TcpTestSucceeded : True は、ポートへのTCP接続が確立できたことだけを示します。2つ目のコマンドでは、プロキシの処理、接続先への通信、TLSも関係します。200 Connection established が返ってきた場合、それはプロキシトンネル確立時の応答です。その後の接続先の応答やエラーも確認してください。curl.exe を使うのは、一部のPowerShell環境にある同名のエイリアスとの混同を避けるためです。

5. TUNとサービスモード：必要なアプリに応じて有効にする

TUNは仮想ネットワークインターフェースとルーティング設定を使い、条件に合うIP通信を取り込みます。システムプロキシに従わないアプリで役立ちます。サービスモードは、クライアントがバックグラウンドサービスや権限を管理する仕組みです。両者は別の機能です。サービスをインストールしてもTUNが有効になるとは限らず、TUNを有効にしてもすべての通信が必ずプロキシノードを経由するわけではありません。

まずシステムプロキシモードでサブスクリプション、ノード、ルールを確認します。ルーティングの競合を避けるため、ほかのVPNや仮想ネットワークアダプターを制御するツールは終了してください。
クライアントの「設定」で「サービスモード」または「サービス管理」を探し、使用中のクライアントの手順に従ってサービスをインストール・起動します。管理者権限を求められた場合は、操作元を確認してください。
「TUNモード」または「仮想ネットワークアダプターモード」を有効にし、権限不足、デバイス作成失敗、ルート追加失敗などがログに出ていないか確認します。
対象のアプリを起動し、「接続」画面にそのアプリの通信が表示されるか確認します。続いて、適用されたルールと最終的な接続先を確認してください。

mihomoの設定では、tun.enable がTUNの有効・無効を制御し、auto-route は関連ルートを自動設定し、dns-hijack は条件に合うDNSリクエストを捕捉します。クライアントがこれらの項目を自動生成する場合もあるため、ネット上のTUN設定をサブスクリプションにそのまま上書きしないでください。暗号化DNS、IPv6、LANアクセス、プロセス識別の動作は、設定や実行環境によっても変わります。

有効にした後、社内ネットワークに接続できない、ネットワークプリンターが使えない、スリープ復帰後にネットワークが切れるといった問題が起きたら、まずTUNを無効にして元のネットワーク状態へ戻し、ルートとDNSを順に確認します。いきなりWindowsのネットワーク設定をすべてリセットしないでください。VPN、固定IP、仮想スイッチに影響する可能性があります。

6. よくあるトラブルを「入口・ルール・出口」の順に確認する

ブラウザーではプロキシが使えないが、プロキシを指定したコマンドは成功する

この場合、ローカルの接続先と少なくとも1つの通信経路は動作していると考えられます。まず、ブラウザーがどのプロキシ設定を参照しているか確認してください。EdgeとChromeは通常Windowsのシステムプロキシ設定を使いますが、拡張機能、起動オプション、組織のポリシーによって上書きされることがあります。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、「システムのプロキシ設定を利用する」を選択します。変更後は、すべてのブラウザーウィンドウを閉じてから開き直してください。

接続ログも確認します。リクエストが表示されていて DIRECT に一致する場合は、ルールとプロキシグループを確認してください。該当する接続がまったく表示されない場合は、ブラウザーが参照しているプロキシ設定を調べます。Webサイトに表示される出口IPアドレスは参考情報にすぎず、接続ログの代わりにはなりません。

プロキシを有効にしたら、すべてのWebページが開けなくなった

まずシステムプロキシを無効にして、元のネットワークに接続できるか確認します。元のネットワークも使えない場合は、Wi-Fi、LANケーブル、認証ページ、ルーターを先に確認してください。
ローカルポートのテストに失敗する場合は、コアが起動しているか、address already in use といったエラーが出ていないか確認します。
ポートが正常なのに接続先がタイムアウトする場合は、同じプロキシグループ内の別のノードに切り替え、接続タイムアウト、TLSエラー、名前解決エラーのどれが起きているか確認します。
一部のドメインだけで問題が起きる場合は、そのドメインに適用されるルール、DNSの応答、接続先サイトの状態を確認します。すぐに全体を再インストールする必要はありません。

7890を待ち受けているプロセスを確認するには、PowerShellで次のコマンドを実行します。最後の列に表示されるのはPIDです。タスクマネージャーの「詳細」タブでプロセスを確認してください。所有元を確認する前に、見覚えのないプロセスを終了しないでください。特にシステムや企業のセキュリティ関連プロセスには注意が必要です。

netstat -ano | findstr LISTENING | findstr ":7890"

混合ポートを7891に変更する場合は、Windowsのシステムプロキシに加え、ブラウザー拡張機能、コマンドライン環境変数、手動でプロキシを設定したアプリも更新してください。クライアントがシステムプロキシを自動更新する場合も、変更が反映されたか実際に確認しましょう。

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

Windowsのプロキシ設定が、すでに停止したローカルポートを参照している可能性があります。クライアントを再起動してシステムプロキシを無効にするか、Windowsのプロキシ画面で今回の設定による手動プロキシを削除してください。以前から会社のプロキシや自動構成スクリプトを使っていた場合は、記録した元の設定に戻します。TUNを使っている場合は、クライアントの手順に従って仮想ネットワークアダプターの制御を解除してから終了してください。

7. 設定後の確認リスト

バージョン：「バージョン情報」でGUIクライアントとコアのバージョンをそれぞれ記録します。問い合わせ時に「最新版」とだけ伝えないようにしてください。
サブスクリプション：現在の設定が有効で、更新が成功し、使用するプロキシグループでノードが選択されている。
接続先ポート：Windowsのプロキシポートがコアの待ち受けポートと一致し、別のクライアントが定期的に設定を上書きしていない。
通信経路：接続ログでプロキシ経由のリクエストと、想定どおりの直接接続リクエストを1件ずつ確認し、それぞれに適用されたルールを把握している。
再起動後の動作：設定が安定してからスタートアップを有効にし、再起動後にサービス、コア、システムプロキシが正しい順序で起動することを確認している。
終了後の復旧：プロキシを無効にするかクライアントを終了しても、元のネットワークを正常に利用できる。

クライアントを更新するときは、サブスクリプションの配布元と必要なオーバーライド設定を引き継げば十分です。旧クライアントの実行ファイルをすべて新バージョンのフォルダーへコピーする必要はありません。問題が起きたら、「ローカルポートが待ち受けているか → アプリの通信がコアに届いているか → どのルールが適用されたか → ノードに接続できるか」の順に確認すると、スイッチを片っ端から切り替えるより原因を特定しやすくなります。用語は用語集で確認できます。設定項目の意味を調べる場合はプロトコルガイドをご覧ください。