Clash for Windowsのインストール・設定ガイド｜システムプロキシ、TUNモード、ファイアウォールの注意点

まずシステムプロキシで動作確認し、その後TUNを設定

WindowsでClashを設定する際は、「クライアントをインストール → サブスクリプションを読み込む → ポリシーを選ぶ → システムプロキシを有効にする → 接続を確認する」の順に進めるのがおすすめです。ブラウザーで接続できたら、必要に応じてTUNを有効にします。一度に変更する項目を一つに絞ると、サブスクリプションの問題、ノードへの接続不良、PC側の通信制御の問題を切り分けやすくなります。

この記事ではWindows 11のシステムメニューを例に説明します。Clash Verge RevやFlClashなどのGUIクライアントでは、画面や項目の名称が異なる場合があります。システムプロキシ、サービスモード、TUNは、使用中のクライアントに表示されるスイッチで状態を確認してください。GUIクライアントは設定を管理し、mihomoなどのコアは設定の解析、ルールの照合、接続の確立を担います。それぞれのバージョンを個別に確認しましょう。

インストーラーの選び方：アーキテクチャとインストール版・ポータブル版

Windowsのシステムアーキテクチャを確認する

「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。一般的なIntel・AMD搭載PCではx64版を選びます。ARMデバイスでは、プロジェクトが明示的に提供している場合にARM64版を選んでください。Windowsが64ビットだからといって、x64版とARM64版を同じものとして扱うことはできません。

パッケージの種類	用途	注意点
EXE / MSI インストーラー	通常のデスクトップ利用	インストールウィザードに従ってください。サービスコンポーネントがインストールされるかどうかは、クライアントの仕様によります。
ZIPポータブル版	手動で展開して実行	まず固定のフォルダーに完全に展開してください。圧縮ファイル内から直接起動しないでください。
コアの実行ファイル	コマンドラインやサービスとしての運用	GUIクライアントとは別物です。設定ファイルと実行パラメーターを自分で用意する必要があります。

起動前に旧クライアントを整理する

旧クライアントのタスクトレイメニューからシステムプロキシを無効にしてから、クライアントを終了します。
ルートやDNS設定の競合を避けるため、ほかのVPNや透過プロキシツールを一時停止します。
新しいクライアントをインストールして起動し、まずコアが正常に起動したことを確認してから設定を読み込みます。
ポータブル版でサービスのインストールが必要な場合は、先に固定のフォルダーへ配置してください。フォルダーを移動すると、サービスの再インストールが必要になることがあります。

旧版のClash for Windowsは開発・保守が終了しているため、新規インストール時の標準選択には適しません。以前の設定を引き継ぐ場合は、まずクライアント選びのガイドを確認し、移行先クライアントとコアの互換性を確かめてから、サブスクリプションやオーバーライド設定を移行してください。旧クライアントのプログラムフォルダー全体を、新しいクライアントにそのまま上書きしないでください。

サブスクリプションの読み込み：形式、選択中の設定、更新結果を確認

サブスクリプションURLは通常、サービス提供元が発行します。クライアントのダウンロードURLはサブスクリプションURLとは異なります。Webサイトのログインページや決済ページも、設定として読み込むことはできません。URLにはアクセス用の認証情報が含まれる場合があるため、トラブルシューティングの際にURL全体やQRコード、設定ファイルを公開の場に投稿しないでください。

クライアントの「サブスクリプション」または「プロファイル」画面を開き、リモート設定の追加を選びます。
Clashまたはmihomoに対応したサブスクリプションURLを貼り付けてダウンロードし、解析エラーがないか確認します。
読み込んだ設定を選択し、一覧に表示するだけでなく、現在使用する設定として有効にします。
「プロキシ」画面でポリシーグループを展開し、利用可能なノードまたは自動選択グループを選びます。
出站モードを「ルール」に設定し、ログと接続画面を確認します。

「ダウンロード成功」でも「設定が有効」とは限らない

設定のダウンロード成功が示すのは、応答を受信できたことだけです。ログイン案内やエラーページが返される場合もあります。YAMLの解析エラー、未対応のプロキシタイプ、参照先のないポリシーグループなどが表示されたら、まず設定自体の問題を解決してください。システムプロキシを何度も切り替えても、これらのエラーは解消しません。

認証に失敗する場合：サブスクリプションの有効期限やURLのリセット有無を確認し、コピー時に空白が混入していないか確かめます。
ダウンロードがタイムアウトする場合：サブスクリプションのドメインを名前解決できるか確認します。無効なシステムプロキシを使用中なら、いったん無効にして再試行してください。
プロトコルがサポートされていない場合：クライアント名だけでなく、実際に動作中のコアを確認します。サービス提供元の設定形式がコアに対応しているかも確かめてください。
更新後に設定が消える場合：リモート設定の再ダウンロードで上書きされた可能性があります。ローカルでの変更は、クライアントが対応しているオーバーライドまたはマージ機能を使って保存してください。

ノードの接続テストに成功しても、テスト時点で対象にアクセスできたことしか分かりません。実際にアプリの通信がプロキシを経由するかは、ルールの適用結果と接続の詳細で確認してください。テスト時の遅延をダウンロード速度と混同しないようにしましょう。

システムプロキシ：アドレス、ポート、アプリの対応状況を確認

システムプロキシの影響を受けるのは、Windowsのプロキシ設定に従うアプリが中心です。PC全体の通信を制御する機能ではなく、すべてのUDP通信がプロキシを経由するわけでもありません。まずTUNを無効にしたまま、クライアントで「システムプロキシ」を有効にします。次にブラウザーで目的のWebサイトへアクセスし、クライアントの接続画面に該当する通信が表示されるか確認してください。

Windowsのプロキシアドレスを確認する

Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」→「編集」を開きます。クライアントがローカルHTTPまたは混合プロキシのポートを使う場合、アドレスは通常 127.0.0.1 です。ポートにはクライアントに表示されている実際の値を入力してください。外部コントローラー用のポートをここに入力しないでください。たとえば 9090 はコントロール用インターフェースに使われることが多く、プロキシポートではありません。

以下は各項目の意味を説明するためのmihomo設定例です。完全なサブスクリプションではないため、既存の設定と置き換えて使うことはできません。GUIクライアントがポートを上書きする場合もあるので、実行時の設定と実際の待ち受け状態を確認してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port は、同じポートでHTTPとSOCKSのプロキシリクエストを受け付けます。allow-lan: false は、LANからのアクセスを制限します。PC内だけで使う場合、ブラウザーを接続するためにLAN共有を有効にする必要はありません。

コマンドラインでプロキシの接続先を個別に確認する

curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://www.microsoft.com/

このコマンドはローカルプロキシを明示的に指定するため、「プロキシの接続先が使えない」のか「アプリがシステムプロキシを参照していない」のかを切り分けるのに役立ちます。HTTP応答を受信できた場合、そのリクエストで接続先サーバーと基本的な通信ができたことを示しますが、ほかのノードやWebサイトも使えるとは限りません。接続拒否が返る場合は、まずコアの稼働状態とポート番号を確認してください。

TUNモード：サービス権限、DNS、仮想ネットワークインターフェース

TUNは仮想ネットワークインターフェースとルート設定を使って通信を取り込み、システムプロキシを参照しないアプリにも対応します。システムプロキシとは異なる層で動作するため、TUNを有効にしても使えないノードが直るわけではありません。また、ルールモードでは引き続きルールに基づいて、直接接続、プロキシ、拒否が決まります。実際に使える機能は、コア、クライアント、設定の組み合わせによって異なります。

元に戻せる状態を保ちながら、順番に有効化する

まず、同じ設定でシステムプロキシを使って目的のWebサイトにアクセスできることを確認します。
クライアントの設定で「サービスモード」またはサービスのインストール項目を探します。バックグラウンドサービスで権限を処理するクライアントの場合は、先にインストールを完了し、サービスが動作していることを確認してください。
個別に動作を確認できるよう、システムプロキシを一時的に無効にしてから「TUNモード」を有効にします。クライアントによっては2つのスイッチが自動的に連動するため、実際の状態を確認してください。
ログを確認し、仮想インターフェースの作成が成功していること、権限不足、ルート追加の失敗、DNSポートの競合がないことを確かめます。
対象のアプリを起動し、接続画面でプロセス、接続先アドレス、適用ルール、最終的な通信先を確認します。

仮想インターフェースのインストールやルートの変更には、通常、権限の昇格が必要です。これらの操作をサービス経由で行うクライアントもあれば、管理者として起動する必要があるものもあります。「毎回管理者として実行」をすべてのクライアントに共通する要件と考えないでください。サービスを使っても失敗する場合は、ドライバーの再インストールを繰り返すのではなく、サービスの状態とコアのログを確認しましょう。

Webページが開けない場合は、まずDNSの問題を切り分ける

ログに名前解決の失敗が表示された場合は、現在の設定でDNSが有効か、上流のDNSサーバーに接続できるか、ほかのVPNによるDNS制御と競合していないかを確認します。mihomoのFake-IPとredir-hostは、DNSの処理方式が異なります。モードを切り替えると動作も変わるため、ログなどの根拠がないまま切り替えを繰り返さないでください。

ipconfig /all でアダプターとDNSの情報を、route print でルートを確認できます。これらのコマンドで分かるのはシステムの状態であり、すべてのリクエストがTUNに入っていることを証明するものではありません。ブラウザーのセキュアDNSが独立した暗号化経路を使う場合もあるため、クライアントの接続履歴もあわせて確認してください。

TUNを有効にした後、PC全体がネットに接続できなくなった場合は、まずTUNを無効にして元のネットワークが復旧するか確認します。基本のネットワークが復旧したら、サービスの権限、DNS、ほかの仮想ネットワークアダプターを順番に確認してください。企業管理下の端末でネットワークポリシーが設定されている場合は、管理者に許可された接続方法を確認しましょう。

Windowsファイアウォール：外向き通信とLANからの着信を切り分ける

PC上のブラウザーからローカルプロキシに接続する場合、通常、LAN全体からアクセスできる着信ポートを開放する必要はありません。Windowsファイアウォールでは、一般に外向き通信が許可されていますが、企業ポリシーやセキュリティソフトによって制限される場合があります。まず遮断されているのが、コアの外向き通信、サービスプログラム、LAN機器からPC上のプロキシへの接続のどれかを確認してください。

実際のプログラムとネットワーク範囲に合わせて許可する

PCからの外向き通信が遮断される場合：セキュリティソフトの記録を確認し、実際に接続を開始するコアの実行ファイルのパスを特定します。GUIプログラムだけを許可しても、独立して動作するコアは対象外になることがあります。
クライアントの更新後に動かなくなった場合：プログラムのフォルダーや実行ファイルのパスが変わると、パスを指定した既存のルールを更新する必要があります。
LANで共有する場合：クライアントのLAN接続許可設定、待ち受けアドレス、着信ルールをあわせて確認してください。ファイアウォールのポートを開くだけでは不十分です。
公衆Wi-Fiを使う場合：信頼できないネットワークにプロキシの待ち受けを公開しないでください。特に「パブリック」ネットワークプロファイルへの許可は慎重に設定しましょう。

詳細なルールを確認するには、Win + R を押し、wf.msc を実行して「セキュリティが強化された Windows Defender ファイアウォール」を開きます。LAN共有の着信ルールでは、対象のプログラムまたは実際のポート、プライベートネットワークプロファイル、信頼できる送信元アドレスを限定してください。共有が不要なら、allow-lan: false のままにします。

UWPアプリとポート競合：別々に切り分ける問題

アプリコンテナーによるローカルループバック制限

一部のUWPアプリなど、アプリコンテナーの制約を受けるアプリでは、ローカルループバックプロキシの利用が制限される場合があります。その結果、ブラウザーは正常でも特定のアプリだけネットに接続できないことがあります。ただし、Microsoft Storeからインストールしたアプリがすべて該当するわけではなく、ストアアプリの通信障害がすべてループバック制限によるものでもありません。

管理者ターミナルで以下のコマンドを実行すると、現在のループバック免除を確認できます。状態を表示するだけで、アプリの設定は変更しません。

CheckNetIsolation.exe LoopbackExempt -s

免除を追加する必要がある場合は、対象アプリのパッケージファミリー名を確認し、アプリごとに設定してください。すべてのパッケージを一括で免除しないでください。クライアントにUWPのループバック管理機能がある場合も、ローカルプロキシを使うアプリだけを選びます。TUNを使う場合は通信経路が異なるため、システムプロキシ利用時の診断結果をそのまま当てはめることはできません。

ポート7890が使用中の場合は、まず待ち受けプロセスを特定する

ログに address already in use またはバインド失敗が表示された場合は、ターミナルで次の2つのコマンドを実行します。2つ目のコマンドではPID 4321 を例にしています。実際には、1つ目の出力に表示されたPIDに置き換えてください。

netstat -ano -p tcp | findstr ":7890"
tasklist /FI "PID eq 4321"

ローカルアドレスのポートが 7890 で、状態が LISTENING の記録を確認します。出力にはリモートポートや似た数字が含まれることもあるため、数字が並んだ行を見ただけでポート競合と判断しないでください。よくある原因は、旧クライアントがタスクトレイに残っている、バックグラウンドサービスが動作している、新しいクライアントを重複して起動している、などです。

該当するプログラムの終了機能やサービス停止機能を使ってポートを解放してください。プロセス名が分からないシステムプロセスを終了しないでください。空いている値、たとえば 7891 にプロキシポートを変更する方法もありますが、システムプロキシと、手動でプロキシを設定したアプリもあわせて更新する必要があります。YAMLだけを変更してアプリ側のポートを変えないと、接続が拒否されます。

インストール後の動作確認とWindows起動時の設定

Webページが1つ開けただけでは、設定が完了したとは限りません。次の順に確認すると、日常的な再起動や異常終了で起こりやすい問題をチェックできます。

ルールの確認：ルールモードのまま、直接接続する宛先とプロキシを使う宛先にそれぞれアクセスし、接続画面で適用ルールと最終的なポリシーを確認します。
アプリの確認：ブラウザーだけでなく、実際にネット接続が必要なアプリを個別に起動します。必要に応じてUDPなどの通信も確認してください。
終了時の確認：システムプロキシとTUNを無効にしてからクライアントを終了し、通常のネットワーク接続が維持されることを確認します。
再起動後の確認：Windows起動時にクライアントを起動する設定を行ってPCを再起動し、クライアント、設定、バックグラウンドサービスが想定どおりに動作するか確認します。
更新後の確認：サブスクリプションまたはコアの更新後に、設定の解析、ポート、TUNの状態、重要なルールを再確認します。

クライアントのWindows起動時の実行、バックグラウンドサービスの自動起動、システムプロキシの自動有効化は、それぞれ別の設定です。Windows 11の「設定」→「アプリ」→「スタートアップ」で確認できるのは、一部のスタートアップ項目だけです。バックグラウンドサービスは services.msc でも確認できます。複数の起動タスクを作成すると、プロセスの重複やポート競合につながるため注意してください。

トラブルシューティングでは、発生時刻、クライアントとコアのバージョン、エラーログ、システムプロキシとTUNの状態を記録しておけば十分です。ログを公開する前に、サブスクリプションのトークン、認証情報、ノードの接続情報を削除してください。基本操作は使い方ガイド、よくある接続トラブルはよくある質問をご覧ください。