Windows版Clashのインストール・設定ガイド｜システムプロキシ、防火壁、自動起動の注意点

まずシステムプロキシを使い、TUNモードは後から設定

WindowsでClashを設定するときは、クライアントのインストール、サブスクリプションの追加と有効化、ルールモードと利用可能なノードの選択、システムプロキシの有効化、サービスモード・TUN・自動起動の設定の順に進めるのが確実です。最初からすべての機能を有効にすると、通信できなくなったときに、サブスクリプション、プロキシポート、仮想ネットワークアダプターのルーティングのどこに問題があるのか特定しにくくなります。

この記事では、mihomoコアを使用するWindows向けGUIクライアントを主な対象としています。Clash Verge RevやClash Nyanpasuなどはボタン名が完全には統一されていないため、以下では機能名と確認方法をあわせて説明します。特定のクライアントのメニュー位置が、すべてのバージョンで共通とは限りません。オリジナル版Clashとmihomoでは設定できる内容が異なります。未対応のプロトコルや項目がある場合は、システムプロキシを何度も切り替えるのではなく、まず使用中のコアを確認してください。

1. システムのアーキテクチャとインストール先を確認

x64とARM64を確認する

Windows 11では「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。Windows 10では「設定」→「システム」→「詳細情報」で確認できます。一般的なIntel・AMD搭載PCにはx64版を選びます。ARMプロセッサ搭載端末では、クライアントが提供するARM64版を優先してください。「64ビットオペレーティングシステム」という表示だけで、プロセッサのアーキテクチャを判断しないようにしましょう。

1. ClashのダウンロードページからWindows版クライアントを選び、システム要件を確認してください。
2. インストール先は固定してください。ポータブル版を使う場合は、先にファイルをすべて展開してから本体を起動します。圧縮ファイル内から直接起動しないでください。
3. 初回起動時は、まず既定の設定のまま使います。Windowsのセキュリティ警告が表示されたら、ダウンロード元と発行元を確認してください。アプリを起動するために、セキュリティ機能全体を無効にするのは避けましょう。
4. 通知領域にアイコンが表示されたら、クライアントのコアの状態やログを確認します。ウィンドウが開いていても、バックグラウンドのコアがポートの待ち受けに成功しているとは限りません。

Windows 10 22H2とWindows 11 24H2では設定画面が異なります。上記のバージョンは設定画面の違いを説明するための例であり、すべてのクライアントがこれらのシステムへの対応を保証するものではありません。組織で管理されているPCでは、サービスのインストール、プロキシの変更、仮想ネットワークアダプターの作成が制限される場合があります。まず端末の管理ポリシーを確認してください。

2. サブスクリプションを追加し、設定が有効になったことを確認

クライアントの「サブスクリプション」「設定」または「Profiles」画面を開き、新しいリモートサブスクリプションを追加します。プロバイダーから案内されたClashまたはmihomoの設定URLを貼り付け、ダウンロードまたは更新を実行してください。サブスクリプションURLには認証トークンが含まれることが多いため、公開の掲示板に投稿したり、URL全体が見える状態でスクリーンショットを共有したりしないでください。

1. ダウンロード成功：設定一覧に項目が表示され、更新日時が変わっていることを確認します。401、403、404が返る場合は、URLの有効期限とコピー漏れを確認してください。
2. 設定が有効：設定をクリックし、「現在使用中」などの表示、または選択状態になっていることを確認します。サブスクリプションを一覧に追加しただけでは、実行中の設定に切り替わらない場合があります。
3. プロキシグループが利用可能：プロキシ画面を開き、ノードとプロキシグループが表示されることを確認します。ノードを選択するか、自動選択グループでノードが選ばれているか確認してください。
4. コアの起動に成功：ログに設定の解析エラー、未知のプロキシタイプ、プロキシグループが見つからないなどのメッセージがないか確認します。

更新に失敗しても、まずDNSやTUNを変更しない

サブスクリプションのダウンロードがタイムアウトする場合は、プロキシを使わずにサブスクリプション提供元へアクセスできるか、PCの日付と時刻が正しいかを確認します。特定のネットワークからしかアクセスできないサイトもあります。クライアントにサブスクリプション更新用プロキシの設定があれば利用できますが、すでに使えるプロキシ経路があることが前提です。初回の追加時に、まだ読み込まれていない設定を使ってダウンロードを中継することはできません。

ログインページやエラーページが返された場合、ダウンロード処理が成功と表示されても、有効な設定ファイルではありません。サブスクリプションの出力形式が使用中のコアに対応しているか確認してください。たとえば、mihomo専用の機能を含む設定は、古いオリジナル版Clashのコアでは読み込めないことがあります。設定項目をむやみに削除するのではなく、対応する出力形式またはクライアントを選んでください。

3. ルールモードとローカルプロキシポートを設定

普段は「ルール / Rule」モードを選び、設定内のルールに通信を直接接続するかプロキシ経由にするかを判断させます。グローバルモードは一時的な比較テストには使えますが、選択中のプロキシグループやノードが利用できることが前提です。ダイレクトモードでは、プロキシノードが正常かどうかを検証できません。モードを切り替えても、既存の長時間接続は以前の経路を使い続けることがあります。確認するときはリクエストを新しく送信してください。

システムプロキシには実際の待ち受けポートを指定

クライアントのポート設定でHTTPポートまたは混合ポートを確認します。この記事では例として 7890 を使いますが、実際のポート番号はクライアントによって異なります。混合ポートは通常、HTTPとSOCKSの両方のプロキシ要求を受け付けます。管理用ポートの 9090 などは、ブラウザー用のプロキシポートとして使えません。

クライアントで「システムプロキシ」を有効にしたら、Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でアドレスとポートを確認します。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。クライアントによってシステムプロキシの設定方法が異なるため、画面の表示も同じとは限りません。単一のスイッチだけで判断せず、リクエストログもあわせて確認してください。

4. ログとコマンドでノードの障害とポート競合を切り分ける

ブラウザーでのテストに加え、プロキシを指定して確認

システムプロキシを有効にして対象サイトをブラウザーで開き、クライアントの接続ログを確認します。対象ドメインが記録されているか、どのルールが適用されたか、最終的に直接接続かプロキシグループ経由かを確認してください。ブラウザーに独自のプロキシ拡張機能が入っている場合は、Windowsの設定に従うようにして、Windowsのプロキシ設定が上書きされないようにします。

PowerShellで次のコマンドを実行して確認することもできます。curl.exeを明示することで、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを防げます。7890は実際のポート番号に置き換えてください。

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

• ローカルポートに接続できないとすぐに表示される：コアが起動しているか、ポート番号が正しいか、設定の読み込みが完了しているかを確認してください。
• ローカルプロキシへの接続後にタイムアウトする：ノードの接続エラー、対象に適用されたルール、リモートサービスの状態を確認します。ローカルポートに接続できても、ノードが利用できるとは限りません。
• 対象サイトから応答が返る：今回のプロキシ指定リクエストが対象サイトに到達したことを示します。実際の経路はログで確認してください。これだけで、すべてのアプリの通信がプロキシ経由になったとは判断できません。

「address already in use」が表示されたら、まず使用中のプロセスを確認

2つのクライアントが同時に7890を待ち受けると、後から起動したコアに「アドレスはすでに使用されています」と表示されることがあります。次のPowerShellコマンドで、待ち受け中のプロセスIDとプロセス名を確認できます。結果が表示されない場合は、確認時点でそのポートのTCP待ち受けが見つかりませんでした。

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

Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
  ForEach-Object { Get-Process -Id $_.OwningProcess }

別のプロキシクライアントがポートを使用している場合は、まず正常に終了してから現在のクライアントを起動してください。プロセスIDを見ただけで強制終了しないでください。ポートを7891などに変更する場合は、システムプロキシとアプリ内で個別に設定したプロキシアドレスもあわせて更新します。クライアントがシステムプロキシを自動管理する場合は、その機能をいったんオフにしてからオンにし、設定を再確認してください。

5. 防火壁の確認画面には適切に対応し、防火壁を無効にしない

Windowsの防火壁がネットワークへのアクセスを許可するか尋ねてきたら、まずプログラムのパスと、対象がGUIクライアントかコアかを確認します。一般的な既定のルールでは、許可されていない受信接続は制限されますが、送信接続は通常許可されています。127.0.0.1を使ってこのPCからプロキシに接続することは、LAN内の端末からこのPCへの接続を許可することとは異なります。

1. このPCだけで使う場合は「LANからの接続を許可」をオフにします。Webページが開かないからといって、すべての受信ポートを開放しないでください。
2. プロキシを共有する必要がある場合は、まず現在のネットワークが信頼できるか確認してください。そのうえで「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「ファイアウォールによるアプリケーションの許可」を開き、対象プログラムを確認します。
3. 通常は、信頼できるプライベートネットワークに必要な権限だけを付与してください。パブリックネットワークまで安易に選択しないでください。接続元アドレスやポート範囲を細かく設定する場合は、「詳細設定」を利用します。
4. クライアントの更新後にインストール先が変わった場合は、古いルールが以前のファイルを参照していないか確認してください。組織による制限がある場合は、防護サービスを無効にせず、管理者に相談してください。

「アプリの許可」で解決できるのは、該当する防火壁ルールの範囲内での接続問題です。期限切れのサブスクリプション、利用できないノード、誤ったルールによる通信の振り分けは修復できません。システムプロキシのテストが正常で、LAN内の別端末からだけ接続できない場合に、待ち受けアドレス、受信ルール、ネットワーク分離の設定を確認してください。

6. 必要に応じてサービスをインストールし、TUNモードを有効化

ブラウザーは正常でも特定のアプリが直接接続する場合は、そのアプリがシステムプロキシに対応しているか、SOCKS/HTTPプロキシを個別に設定できるか確認してください。コマンドラインツール、ゲーム、バックグラウンドサービスの一部は、Windowsのユーザープロキシを参照しません。その場合は、システムプロキシのアドレスを変更し続けるより、TUNモードの利用を検討しましょう。

サービスモードを正しく確認する手順

1. クライアントの設定から「サービスモード」「サービスのインストール」またはサービス管理の項目を探します。インストール時にユーザーアカウント制御の確認画面が表示されることがあります。
2. サービスの状態が実行中になっていることを確認します。必要に応じてWin + Rを押し、services.mscと入力して開きます。クライアントの実際のサービス名を確認し、名前が似ているシステムサービスを推測で変更しないでください。
3. クライアントに戻ってTUNを有効にし、ログで仮想インターフェース、ルート、DNSの初期化が成功したか確認します。
4. 他のVPNや仮想ネットワークを制御するツールを終了して比較テストを行います。変更する設定は一度に1つにしてください。

サービスをインストールしただけでは、通信が自動的にTUNへ流れるとは限りません。クライアント側で関連設定を正しく生成する必要があります。自動ルーティング、インターフェースの検出、DNSの処理などはクライアントごとに管理方法が異なるため、別のクライアントのtun:設定をそのまま貼り付けるのは避けてください。TUNを有効にしても、すべての通信が必ずプロキシ経由になるわけではありません。コアに取り込まれた後も、ルールモード、プロセスの除外設定、ルートの範囲に従って処理されます。

7. 自動起動はログイン後に使えることまで確認

多くのGUIクライアントで「自動起動」とは、Windowsへのユーザーログイン後に起動することを指します。ログイン前からプロキシを利用できるという意味ではありません。バックグラウンドサービスの起動状態とGUIの自動起動設定も別のものです。サービスが動作中でも、サブスクリプションが有効か、システムプロキシが設定済みかは確認できません。

• まずクライアントの自動起動設定を有効にする：次にWindowsの「設定」→「アプリ」→「スタートアップ」またはタスクマネージャーのスタートアップアプリ一覧を確認します。タスクスケジューラで起動するアプリの場合は、タスクスケジューラも確認してください。
• 起動方法を重複させない：スタートアップフォルダーのショートカット、独自のタスク、クライアントの自動起動設定を同時に追加しないでください。複数のインスタンスが起動し、ポートを取り合うことがあります。
• インストール先を固定する：ポータブル版の保存先を移動すると、自動起動の記録が以前のパスを参照したままになることがあります。自動起動をいったん無効にしてから、再度有効にしてください。
• 実行権限の違いに注意：アプリ全体を常に「管理者として実行」にすると、通常のログイン時の自動起動に影響する場合があります。まずはクライアントが想定するサービス機能を使用してください。

再起動後に確認する4項目

設定を保存したらPCを再起動してログインし、通知領域のアイコン、現在の設定、ポートの待ち受け、実際のリクエストログを順に確認します。ネットワークに接続される前に自動起動することがあるため、初回のサブスクリプション更新が失敗しても、自動起動の不具合とは限りません。まずGUIとコアが動作していることを確認し、ネットワーク接続後に手動でサブスクリプションを更新してください。

クライアントを終了してもブラウザーがローカルポートに接続しようとする場合は、Windowsに手動のプロキシ設定が残っていないか確認します。いったんシステムプロキシ設定の「プロキシサーバーを使う」をオフにして直接接続に戻し、クライアントが異常終了した原因を調べてください。コアが動作していない状態でシステムプロキシのスイッチを何度も切り替えないでください。

設定完了後のチェックリスト

Windows版Clashを安定して使うには、最低でも次の6項目を確認してください。問題が起きたときは、むやみに再インストールするより、直近の変更を元に戻すほうが原因を特定しやすくなります。

1. クライアントのアーキテクチャがPCに合っていて、コアが起動し、ログに設定の解析エラーがない。
2. サブスクリプションの更新と有効化が完了し、プロキシグループに利用可能なノードがある。
3. ルールモードが想定どおりで、システムプロキシのアドレスと実際の待ち受けポートが一致している。
4. ブラウザーとプロキシ指定コマンドの両方で接続ログを確認でき、実際の接続経路を説明できる。
5. LANアクセスまたはTUNは必要な場合に限って有効にし、社内ネットワークとインターネット上のサービスをそれぞれ確認する。
6. 再ログイン後にクライアントが自動起動し、終了後に使えないプロキシ設定が残らない。サービスとGUIの状態を個別に確認できる。

さらに調べる場合は、Clash設定ガイドでプロキシ、ルール、DNSの説明を確認するか、よくある質問から症状に合った項目を探してください。問い合わせ時はクライアント名、バージョン、OSのバージョン、関連するエラー行を残し、サブスクリプションURL、ノードの認証情報、管理用APIキーは隠してください。