Clash for Windowsのインストール・設定ガイド｜ダウンロードから自動起動までの注意点

おすすめの手順：適切なインストーラーを選ぶ → コアを起動する → サブスクリプションを追加して有効化する → ノードを選ぶ → システムプロキシを有効にする → リクエストを確認する → ログイン時の自動起動を設定する。初回設定ではルールモードとシステムプロキシを使い、TUNはすぐに有効にしないでください。インストール、サブスクリプション、通信経路の問題を切り分けやすくなり、複数の設定を同時に変更して原因が分からなくなるのを防げます。

1. ダウンロード前にWindowsのアーキテクチャとクライアントの保守状況を確認

Windows 11では「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。Windows 10では「設定」→「システム」→「詳細情報」で確認できます。一般的なIntel／AMD搭載PCでは通常x64版を選びます。「ARMベースのプロセッサ」と表示される場合は、クライアントが提供するARM64版を優先してください。ブラウザーのビット数やインストーラーの容量でアーキテクチャを判断しないでください。

• x64 / amd64：通常は64ビット版のIntel／AMD搭載Windows PC向けです。名称にamd64とあっても、AMD製プロセッサ専用という意味ではありません。
• ARM64 / aarch64：対応するWindows on ARMデバイス向けです。クライアントとコアがそのプラットフォームをサポートしているかも確認してください。
• x86 / ia32：32ビットプログラム向けです。32ビット版Windowsでは、x64版しか提供されていないクライアントをインストールできません。

クライアントのダウンロードページからWindows版を選び、対応OSと保守状況を確認してください。Clash for Windowsはすでに開発・保守が終了しているため、古いガイドの画面を現在のクライアントの操作手順としてそのまま使うことはできません。mihomoベースのクライアントを使う場合も、クライアントとコアのバージョンを分けて確認し、問題を報告するときは両方を記録してください。

インストーラーは通常 .exe または .msi 形式で、ポータブル版は一般にアーカイブ形式です。ポータブル版は先に固定のフォルダーへすべて展開してから起動してください。アーカイブのプレビュー画面から直接実行しないでください。ダウンロード用の一時フォルダーに置いたまま後でファイルを削除すると、自動起動用のショートカットが使えなくなることがあります。

2. インストールを完了し、まずコアが正常に起動するか確認

1. システムトレイのバックグラウンドプロセスも含め、起動中の旧クライアントを終了します。最初の切り分けでは、プロキシクライアントを1つだけ起動してください。
2. インストーラーを実行して、ウィザードに従ってインストールします。ポータブル版は展開先のフォルダーから起動します。保護されたフォルダーへインストールする場合、管理者権限を求められることがあります。
3. クライアントの「設定」を開き、実際の待ち受けポート、コアの種類とバージョンを記録します。「ログ（Logs）」で起動結果も確認してください。
4. 設定の解析エラー、ポートのバインド失敗、コアの繰り返し終了がないことを確認してから、サブスクリプションの追加に進みます。

クライアントによって日本語メニューの名称は異なります。この記事では機能の場所を示すために「設定（Profiles）」「プロキシ（Proxies）」「ルール（Rules）」「ログ（Logs）」と表記します。特定のクライアントのボタン名を、すべてのバージョンに共通する手順として扱うものではありません。画面が開いているかより、コアが動作しているかが重要です。画面が正常でもコアが起動していなければ、システムプロキシを有効にしても、アプリのリクエストは応答するサービスのないローカルポートへ送られるだけです。

インストールが止められても、セキュリティ機能を先に無効にしない

提供元や発行元に関する警告が表示されたら、ダウンロード元、リリース情報、ファイルのデジタル署名を確認してください。入手元を確認できない場合は、インストールを中止します。必要なコンポーネントがないと表示された場合は、クライアントのプロジェクトが案内するランタイムをインストールしてください。無関係なダウンロードサイトからDLLを集め、プログラムのフォルダーに入れるのは避けてください。

ウィンドウが一瞬表示されて消える場合は、まずクライアントのログを確認します。次に、Windowsの「イベント ビューアー」→「Windowsログ」→「アプリケーション」と、「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を確認してください。何度も再インストールするより、具体的なエラーメッセージを記録するほうが原因を特定しやすくなります。

3. サブスクリプションを追加し、現在使っている設定を確認

「設定（Profiles）」画面を開き、「インポート」または「URLからインポート」を選んでサブスクリプションURLを貼り付けます。YAMLファイルがある場合は、ローカルファイルからインポートしてください。サブスクリプションURLには認証トークンが含まれていることが多いため、パスワードと同じように管理し、公開の問い合わせ窓口やオンライン変換サイトに貼り付けないでください。

1. インポート後に更新を実行し、設定カードが一覧に追加されただけでなく、更新が成功したことを確認してください。
2. 追加した設定を現在の設定として選択し、コアが再読み込みされるまで待ちます。インポート後に自動で有効にならないクライアントもあります。
3. 「プロキシ（Proxies）」を開き、想定したプロキシグループとノードが表示されているか確認します。
4. 「ログ（Logs）」を開き、未対応のフィールド、参照先のないノード、ルールセットの読み込み失敗がないか確認してください。

サブスクリプション更新時にネットワークタイムアウトが表示されたら、「サブスクリプションサーバーに接続できない」のか「ノードを利用できない」のかを切り分けてください。サブスクリプションの取得に直結またはプロキシ経由を指定できるクライアントもあります。初回接続がまだ確立していない段階で利用できないプロキシ経路を選ぶと、更新が繰り返し失敗することがあります。提供元の案内に従って利用可能な取得方法を選び、サブスクリプションを追加するためだけにLAN向けの待ち受けを有効にしないでください。

4. ノードを選び、システムプロキシとルールモードを有効にする

まず「プロキシ（Proxies）」で、実際にルールから参照されているプロキシグループを見つけ、ノードを選んで遅延をテストします。次に「システムプロキシ」を有効にし、動作モードを「ルール（Rule）」に設定します。システムプロキシは通信の入口、ルールモードはコアが受け取った通信の振り分け方法です。別々の設定です。

• Rule：ルールの順序に従って、プロキシ経由、直接接続、または拒否を決定します。日常利用に適しています。
• Global：コアに入ったリクエストをすべてグローバルポリシーで処理します。一時的な比較には使えますが、システムプロキシを無視するアプリの通信を自動で取り込む機能ではありません。
• Direct：コアに入ったリクエストを直接接続として処理します。システムプロキシを有効にしていても、直接接続の出口になる場合があります。

遅延テストで120 msと表示されても、その時点でそのノードを経由したテスト先から応答があったことしか分かりません。すべてのサイトに接続できることや、ダウンロード速度を示すものではありません。タイムアウトの原因がテスト先に到達できないこともあります。実際の接続先へのリクエストと接続ログも確認してください。

Windowsの設定でシステムプロキシを確認

「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシまたはセットアップスクリプトの設定が、クライアントの現在のモードと一致しているか確認します。手動プロキシのアドレスには 127.0.0.1 がよく使われます。ポートはクライアントの表示に従ってください。PACモードではスクリプトがプロキシを使うリクエストを決めます。PACスクリプトのURLをローカルHTTPプロキシのポートと取り違えないでください。

最初の切り分けでは、クライアント標準のシステムプロキシ機能を使い、ブラウザーのプロキシ設定を変更する拡張機能は一時的に無効にしてください。Firefoxなどは独自のプロキシ設定を持つ場合があります。ほかのブラウザーも拡張機能や組織のポリシーによって設定が上書きされることがあります。システム側のスイッチがオンでも、すべてのアプリがその設定に従うとは限りません。

5. プロキシを明示したリクエストで検証し、Webページだけで判断しない

以下ではローカルHTTPまたはmixedポート 7890 を例にします。これは確認用のコマンドであり、すべてのクライアントの標準ポートを示すものではありません。実際のポートが 7897 なら、それに合わせて変更してください。mixedポートはHTTPとSOCKSの両方を受け付けますが、SOCKS専用ポートをHTTPポートとして使うことはできません。

# PowerShellでローカルポートへのTCP接続を確認
Test-NetConnection 127.0.0.1 -Port 7890

# ローカルHTTPプロキシを明示してリクエストし、システムプロキシの継承を切り分ける
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://www.example.com/

Windows PowerShellでは curl が別名として扱われ、引数の解釈が異なることがあるため、curl.exe を使います。--noproxy "" は、今回のリクエストでプロキシ除外リストの影響を受けないようにする指定です。コマンド中の接続先は疎通確認用の例です。実際にアクセスしたいサイトに置き換えて再テストしてください。

1. TcpTestSucceeded が True：ポートがTCP接続を受け付けたことを示します。これだけでは、リモートのプロキシが利用可能かどうかは分かりません。
2. Connection refused が表示される：まずポート番号の入力ミス、またはコアの終了を確認してください。
3. プロキシを明示したリクエストは成功するのにブラウザーでは失敗する：ブラウザー側のプロキシ設定、PAC、キャッシュ、ルールの違いを重点的に確認してください。
4. リクエストが接続記録に表示されるものの、リモート側でタイムアウトする：適用されたルール、実際のプロキシグループ、ノード、DNSエラーを確認してください。

HTTPプロキシでHTTPSサイトにアクセスしたとき、出力の 200 Connection established が示すのはCONNECTトンネルの確立だけです。その後のTLS接続と接続先からの応答も確認してください。ローカルプロキシを明示していても、設定によってそのドメインがDIRECTに振り分けられる場合があります。「接続」または「ログ」でポリシーの経路全体を確認してください。リクエストがコアに届いたことだけを根拠に、リモートノードが使われたと判断しないでください。

6. ポート競合、ファイアウォール、管理者権限を個別に確認

ポート競合：プロセスを特定し、むやみに終了しない

ログに address already in use またはバインド失敗が表示されたら、PowerShellで次を実行します。

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

# 従来のコマンドでも待ち受け中のプロセスIDを確認できます
netstat -ano | findstr :7890

結果に表示されたプロセスIDを、「タスク マネージャー」→「詳細」タブのPIDと照合してください。別のクライアントや古いコアがバックグラウンドで動作しているのが、よくある原因です。該当するプログラムを通常の方法で終了するのが先です。ポートを変更する場合はクライアントの設定で変更し、システムプロキシを再適用してください。ブラウザーの拡張機能や、古いポート番号が直接書かれたターミナルの設定も更新します。

ファイアウォール：ローカル接続とLANからの受信を区別

127.0.0.1 を使ってこのPCからのみプロキシに接続する場合、通常は「LANに接続」を有効にする必要はありません。Windowsファイアウォールのネットワークアクセス確認が表示されても、パブリックネットワークからの受信を許可する必要があるとは限りません。スマートフォンなどLAN内の機器から実際に利用する場合に限り、待ち受けアドレス、プライベートネットワークの設定、該当する受信規則を確認してください。

セキュリティソフトがコアの外向き通信をブロックしている疑いがある場合は、ブロック履歴を確認し、プログラムの完全なパスを照合してください。「Windows セキュリティ」→「ファイアウォールとネットワーク保護」で関連する規則を確認します。必要最小限の範囲で通信を許可し、ファイアウォール全体を恒常的に無効にする方法で解決しないでください。組織のポリシーで制限された端末では、管理者に確認してください。

権限：通常のシステムプロキシとTUNは別の機能

現在のユーザーに適用するシステムプロキシ設定では、通常、常に管理者として実行する必要はありません。TUNは仮想ネットワークアダプターやルーティング、関連サービスを使用するため、権限の昇格が必要になるか、クライアントがあらかじめインストールしたサービスで処理されることがあります。毎回管理者として起動することを万能な解決策と考えず、クライアントが案内するサービスのインストール手順を使ってください。

7. 自動起動を設定し、サインアウトまたは再起動して確認

デスクトップクライアントの「自動起動」は、通常、ユーザーのサインイン後に起動する設定です。サインイン前からプロキシを確立するという意味ではありません。まずクライアントの「設定」で「Windows起動時に起動」または「サインイン時に起動」を有効にします。必要に応じて「起動後に最小化」も有効にしてください。システムプロキシ、TUN、現在の設定が復元されるかは個別に確認します。自動起動だけですべての状態が戻ると思い込まないでください。

1. 「タスク マネージャー」→「スタートアップ アプリ」を開きます。Windows 10では通常「スタートアップ」という名前のページで、クライアントの項目が有効になっていることを確認してください。
2. クライアントが作成した起動項目を1つだけ残してください。スタートアップフォルダーにショートカットを追加したり、別のタスクを登録したりするのは避けます。
3. クライアントを通常の方法で終了してから再度起動し、現在のサブスクリプション、ルールモード、プロキシグループの選択が復元されることを確認してください。
4. サインアウトして再度サインインするか、PCを再起動します。ネットワーク接続が完了するまで待ち、システムトレイ、コアのログ、システムプロキシのポート、実際のWebリクエストを確認してください。

ポータブル版のフォルダーを移動すると、自動起動の設定が以前のパスを参照したままになることがあります。固定の場所に戻した後、クライアントで自動起動を一度オフにしてから再度オンにしてください。管理者として起動した場合だけ正常で、サインイン時の自動起動では失敗する場合は、サービスのインストール状態と権限設計を優先して確認します。手軽だからといって、Windowsユーザーアカウント制御を無効にしないでください。

起動後にすべてのノードがタイムアウトする場合、Wi-Fiへの接続がまだ完了していない、システム時刻が同期されていない、ネットワークが利用可能になる前にルールセットの更新が始まった、といった原因も考えられます。ネットワークが安定してからテストし、ログの時系列を確認してください。デスクトップが表示されたからといって、その時点ですでにサブスクリプションサーバーやノードに接続できるとは限りません。

8. 終了後にネット接続できない場合と最終チェック

クライアントを終了した直後にブラウザーがネットに接続できなくなった場合は、「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカルポートを指す手動プロキシやPACスクリプトが残っていないか確認してください。クライアントが異常終了すると、設定を元に戻せないことがあります。削除するのはそのクライアントが設定した項目だけにしてください。組織から配布されたプロキシ設定は自分で削除しないでください。

ターミナルだけ失敗する場合は、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を手動で設定していないか確認してください。これらの環境変数はWindowsのシステムプロキシとは別に管理されています。環境変数を永続的に変更した後は、通常、ターミナルを開き直す必要があります。ブラウザーが使えるようになっても、ターミナルに古いアドレスが残っていないか確認してください。

• インストール確認：クライアントとコアがどちらも起動し、ログに起動エラーが繰り返し記録されていない。
• 設定確認：サブスクリプションの更新に成功し、対象の設定が有効で、プロキシグループが参照するノードが存在する。
• プロキシ確認：ポートを指定したテストと実際のアプリからのリクエストが成功し、適用されたルールとポリシーの経路を確認できている。
• 自動起動確認：再度サインインしたときにクライアントが1つだけ起動し、ポート、設定、プロキシの状態が想定どおりになっている。
• 終了確認：通常の方法で終了した後も、直接接続が必要な通信を利用でき、使えないローカルプロキシ設定が残っていない。

さらに調査する場合は、Windowsのバージョン、CPUアーキテクチャ、クライアントとコアのバージョン、待ち受けポート、TUNの有効・無効、失敗したリクエストに対応するログをまとめてください。スクリーンショットを共有する前に、サブスクリプションURL、トークン、ノードのパスワード、管理インターフェースのキーを隠します。これらの情報をそろえて問題を再現するほうが、何度もインストールし直すより効果的です。