Windows版Clashのインストールと接続設定｜ファイアウォール・UAC・システムプロキシのトラブル解決

インストール前に確認：システムのアーキテクチャとクライアントの種類

Windows版Clashクライアントは、通常GUIとプロキシコアで構成されています。GUIではサブスクリプションやプロキシグループ、システムプロキシ、サービスを管理し、コアはローカルポートの待ち受け、ルール判定、接続を担当します。Clash Metaは後にmihomoとして開発が続いていますが、mihomoを使うクライアントでもメニュー構成が同じとは限りません。トラブルの切り分けでは「Clash」とだけ記録せず、クライアント名・バージョン・コアのバージョンを控えてください。

この記事ではWindows 11の設定画面を例に説明します。Windows 10では一部の項目名が異なりますが、ローカル待ち受け、システムプロキシ、権限の確認方法は同じです。まず通常のシステムプロキシで接続を確認し、アプリの要件に応じてTUNを有効にしてください。ネットワーク経路を一度に複数変更するのは避けましょう。

インストーラーを選ぶ手順

「設定」→「システム」→「バージョン情報」を開き、「デバイスの仕様」で「システムの種類」を確認します。x64ベースのプロセッサでは通常x64版を選び、ARM搭載デバイスではクライアントが提供するARM64版を優先してください。
クライアントのダウンロードページで対応プラットフォームとアーキテクチャを確認してください。インストーラーとmihomoコア単体は別の配布物です。コアの圧縮ファイルには、通常サブスクリプション管理用のGUIは含まれていません。
クライアントのリリースノートで、Windowsの最低要件、必要なランタイム、メンテナンス状況を確認してください。旧版Clash for Windowsの画面を使った手順を、すべての新しいクライアントに当てはめないようにしましょう。
インストール前にほかのプロキシクライアントを終了し、現在のプロキシとVPNの設定を控えてください。ポータブル版は固定の場所に展開します。サービスを登録した後は、コアのファイルをむやみに移動しないでください。

初回接続：設定を読み込み、最小構成で接続する

インストール後、まず有効なサブスクリプションまたはローカルのYAML設定を読み込みます。サブスクリプションURLには認証情報が含まれる場合があるため、公開グループやスクリーンショットで共有しないでください。読み込み後、設定が現在のプロファイルとして選択されていること、プロキシグループに選択可能なノードが表示されることを確認します。「サブスクリプションを更新しました」と表示されただけでは、コアが正常に設定を読み込んだとは限りません。

クライアントのサブスクリプションまたは設定画面から読み込み、対象の設定を有効にします。ログにYAMLの解析エラー、未対応フィールド、ルールプロバイダーのダウンロード失敗がないか確認してください。
プロキシ画面でルールモードを選び、実際にルールから参照されているプロキシグループでノードを選択します。ルールが使っていないグループを選んでも、そのリクエストの接続先は変わりません。
コアが起動していることを確認し、実際のHTTPまたは混合プロキシポートを控えてください。以下では127.0.0.1:7890を例にします。これはすべてのクライアント共通の既定値ではありません。
クライアントでシステムプロキシを有効にし、ブラウザーから確認したいサイトにアクセスします。その後、接続一覧でルール、ポリシーグループ、接続先を確認してください。

設定がクライアントによって生成される場合、待ち受け設定はクライアントの設定画面、または対応する上書き機能から変更してください。サブスクリプションのキャッシュファイルを直接編集すると、次回の更新時に上書きされることがあります。以下はmihomoのローカル待ち受け設定例です。ノードやルールは含まれていないため、これだけでは接続用の完全な設定になりません。

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

混合ポートはHTTPプロキシとSOCKSプロキシの両方に対応します。自分のPCだけで使う場合は、ループバックアドレスで待ち受け、LANからのアクセスは無効にしてください。ブラウザーの接続を直すために待ち受け先をすべてのネットワークアダプターへ変更したり、プロキシポートをインターネットに公開したりしないでください。

プロキシを明示して問題を切り分ける

PowerShellで次のコマンドを実行します。ここではcurl.exeを指定し、Windows PowerShellで同名のエイリアスが使われた場合の引数の違いを避けています。例のURLは接続確認用であり、すべてのサイトの通信品質を示すものではありません。

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接続が確立できたことを示すだけで、リモートノードが利用可能であることは証明しません。
明示的なプロキシではHTTP応答が返るのにブラウザーで失敗する場合は、まずシステムプロキシ、ブラウザー拡張機能、アプリ固有の設定を確認してください。
127.0.0.1:7890に接続できないと表示されたら、まずポートとコアの状態を確認してください。すぐにリモートノードを変更する必要はありません。
ローカルポートへの接続後にTLSエラーやリモート側のタイムアウトが発生する場合は、ノード、ルール、システム時刻、クライアントログを確認してください。証明書の検証を無効にする方法を通常の対処として使わないでください。

UACとサービスモード：必要な機能に応じて権限を付与する

通常のローカルプロキシ待ち受けに管理者権限は必要ありません。保護されたフォルダーへのインストール、Windowsサービスの登録、仮想ネットワークアダプターの設定、ルートの変更などを行う場合に、UACが表示されることがあります。UACは権限昇格の確認であり、ネットワーク接続の許可ではありません。「はい」を選んでも、ファイアウォールが自動設定されたり、ノードが選択されたりするわけではありません。

サービスのインストールと状態の確認

クライアントの設定で、サービスモードまたはバックグラウンドサービスの項目を探します。メニュー名はクライアントによって異なるため、操作がそのクライアントから始まっていることを確認してください。
サービスのインストールを実行したら、UACの画面に表示されたプログラムのパスと発行元を確認します。パスが不自然な場合や入手元が不明な場合は、許可せずキャンセルしてください。
Win + Rを押してservices.mscと入力し、クライアントが登録したサービスを探して、状態と実行ファイルのパスを確認します。サービス名はクライアントによって異なります。
クライアントに戻り、サービスの状態を確認します。TUNを有効にする場合は、サービスのインストール成功表示だけでなく、仮想インターフェースとコアのログも確認してください。

「アクセスが拒否されました」と表示された場合は、サービスのインストール時に権限昇格が正常に行われたか確認します。「サービスファイルが見つかりません」や、起動直後に停止する場合は、ポータブル版のフォルダーを移動したか、セキュリティソフトがファイルを隔離していないか、既存サービスが古いパスを参照していないかを調べてください。古いサービスは、クライアントのサービス管理画面からアンインストールして再インストールするのが安全です。サービス名を推測して削除コマンドを実行しないでください。

システムプロキシ：Windows・ブラウザー・コマンドラインの違いを確認

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。「手動プロキシセットアップ」のアドレスとポートがクライアントの設定と一致しているか確認してください。この記事の例では、アドレスが127.0.0.1、ポートが7890です。クライアントがPACによる自動設定を使う場合は、手動プロキシを重ねて設定せず、「セットアップスクリプトを使う」とスクリプトのURLを確認してください。

EdgeとChromeは通常、システムプロキシに従いますが、拡張機能、起動オプション、組織のポリシーによって動作が変わることがあります。Firefoxでは「設定」→「一般」→「ネットワーク設定」から、別のプロキシ設定を選ぶこともできます。特定のブラウザーだけで失敗する場合は、まずそのブラウザーのプロキシ設定を確認してください。コア、DNS、ファイアウォールを同時に変更するのは避けましょう。

WinHTTPと環境変数は個別に確認する

netsh winhttp show proxy
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

netsh winhttp show proxyで確認できるのはWinHTTPの設定です。ブラウザーが使う現在のユーザーのシステムプロキシとは異なります。「直接アクセス」と表示されても、クライアントのシステムプロキシが無効とは限りません。開発ツールの中にはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照するものもあり、独自の設定ファイルを使うツールもあります。

アプリが参照するプロキシ設定を確認せず、現在のユーザープロキシをそのままWinHTTPに取り込まないでください。バックグラウンドサービスは別のアカウントで動作する場合があり、システム全体の設定を変更するとほかのソフトにも影響します。まず失敗しているプロセスを特定し、そのアプリのプロキシ設定の説明と実行アカウントを確認してください。

クライアントを終了するとブラウザーがすべてオフラインになる

まず、プロキシ設定が残っていないか確認してください。コアが停止した後もWindowsがローカルプロキシポートを参照している可能性があります。クライアントを再度起動してシステムプロキシを正しく無効にするか、Windowsのプロキシ設定で今回設定した手動プロキシまたはスクリプトをオフにしてください。組織で設定されたPACは、むやみに削除しないでください。接続が戻ったら、まず直接接続を確認し、その後クライアントを再起動します。

ポート競合：待ち受けプロセスから設定の重複を特定

ログのaddress already in useは、通常、待ち受けポートの競合を示します。リモートノードの遅延とは関係ありません。クライアントを何度も再インストールする前に、ローカルポートを調べてプロセスIDから原因を特定してください。

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

netstat -ano | findstr ":7890"

1つ目のコマンドは、指定したポートでTCP待ち受け中の項目だけを表示します。2つ目のコマンドにはほかの接続も含まれる場合があるため、ローカルアドレスと状態を確認してください。プロセスIDを取得したら、「タスクマネージャー」→「詳細」でPIDからプロセスを探します。PID列が表示されていない場合は、列の見出しを右クリックして追加してください。

別のプロキシクライアントが原因なら、まず通知領域のメニューから正常に終了し、自動起動するバックグラウンドサービスも停止してください。
同じクライアントの別のコアインスタンスが原因なら、ポータブル版とインストール版を同時に起動していないか、サービスモードと手動起動のコアが重複していないか確認してください。
別の必要なプログラムがポートを使っている場合は、ローカルプロキシのポートを未使用の値（例：7891）に変更し、システムプロキシとアプリ内の設定も合わせて更新してください。

YAMLのポートだけを変更し、Windows側に古い値を残さないでください。待ち受け中のプロセスが見つからないのにaccess deniedが表示される場合は、セキュリティポリシーやシステムの予約ポートが原因の可能性もあります。プロセス競合と決めつけず、エラーの内容とシステムポリシーを確認してください。不明なプロセスを何度も強制終了するのは避けましょう。

ファイアウォールとセキュリティソフト：ブロック対象を確認

Windowsファイアウォールの確認画面は、ネットワークプロファイルごとのアプリの通信許可に関するものです。クライアントのGUI、プロキシコア、バックグラウンドサービスは、それぞれ別の実行ファイルである場合があります。GUIだけを許可してもコアのルールが正しいとは限りません。一方、自分のPC内だけで使うループバックプロキシのために、パブリックネットワークへの着信ポートを開放する必要はありません。

根拠を確認してブロックに対処する

「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」を開き、発生時刻、処理されたファイルのパス、検出名を確認します。
ファイルの入手元と、現在のクライアントのインストール先との関係を確認します。判断できない場合は記録を残し、クライアントの開発者またはセキュリティソフトの提供元に調査を依頼してください。
Win + Rを押してwf.mscと入力し、「セキュリティが強化された Windows Defender ファイアウォール」で、現在のコアのパスを対象にした送信規則と、明示的なブロック規則がないかを確認します。
許可設定を変更する必要がある場合は、対象のプログラム、通信の方向、適用するネットワークを限定してください。コアの更新でパスが変わった場合は、規則の対象も確認し直します。

明示的なブロック規則は許可規則より優先される場合があり、許可規則を追加するだけでは解決しないことがあります。サードパーティ製セキュリティソフトが独自のネットワークフィルターを備えている場合は、そのイベント記録も確認してください。保護機能をすべて無効にする、ダウンロードフォルダー全体を除外する、すべてのポートを開放するといった方法を、通常のトラブルシューティングとして行わないでください。

UWPのループバック制限：必要なアプリだけに対処する

AppContainerで動作する一部のアプリは、通常のデスクトップアプリのようにローカルのループバックプロキシへ接続できません。そのため、ブラウザーは使えるのに特定のストアアプリだけ失敗することがあります。Microsoft Storeからインストールしたアプリがすべて該当するわけではなく、すべてのアプリがシステムプロキシに従うわけでもありません。まずアプリの種類とエラーログを確認してください。

管理者権限でPowerShellを開き、既存のループバック免除と、PCにインストールされているパッケージ情報を確認します。以下はMicrosoft Storeのパッケージを調べる例です。結果が見つからない場合は、例のパッケージ名をそのまま使わないでください。

CheckNetIsolation.exe LoopbackExempt -s
Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

対象のパッケージが間違いないことを確認してから、変数を使って現在のユーザーにインストールされている実際のパッケージファミリー名を取得します。パッケージのフルネームやインストール先のフォルダーを、パッケージファミリー名として使わないでください。

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
}

完了したら対象のアプリを終了して起動し直し、通信がクライアントに届くか確認します。免除を取り消す場合は、同じパッケージファミリー名を指定して削除します。

$app = Get-AppxPackage -Name Microsoft.WindowsStore
if ($app) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

ループバック免除で変わるのは、対象アプリによるローカルループバックへのアクセス制限だけです。プロキシの設定、サブスクリプションの修復、ルールの変更は行われません。クライアントにループバック管理ツールがある場合も、必要なアプリだけを選び、すべてのパッケージをまとめて許可しないでください。TUNを有効にするとアプリの通信経路が変わる場合もありますが、ストアアプリの問題すべてに有効な決まった解決策ではありません。

TUNとDNS：基本接続を確認してから通信の取り込み範囲を広げる

明示的なプロキシとブラウザーのシステムプロキシは正常なのに、ゲーム、コマンドラインツール、プロキシ設定に対応していないアプリが直接接続してしまう場合は、TUNの利用を検討してください。mihomoのTUNによる通信の取り込み範囲は、仮想インターフェース、ルート、除外設定、DNS設定の影響を受けます。スイッチを有効にするだけで、すべての通信が取り込まれるとは限りません。

TUNを有効にする前に、クライアントが必要とするサービスや権限が利用可能な状態か確認してください。ログで仮想インターフェースの作成エラーやルート設定のエラーを調べます。
企業VPN、ほかの仮想ネットワークアダプター、プロキシツールが同時に動作していないか確認してください。自動ルーティングが複数あるとデフォルトルートの競合が起こる場合があります。一度に変更するのは1項目にしてください。
接続一覧で対象アプリの通信が表示されるか、適用ルールと接続先を確認します。通信が記録されていない場合は、プロキシグループを変更する前に、通信が取り込まれる経路を調べてください。
ドメイン名では失敗するものの既知のIPアドレスには到達できる場合は、DNSを確認します。Resolve-DnsName example.comでシステムの名前解決を調べられますが、これだけではコア内部の名前解決が正常とは証明できません。

共通の解決策として、すべての設定にパブリックDNSを指定しないでください。システムDNS、コアのDNS、プロキシノードのドメイン解決、ブラウザーのセキュアDNSは、それぞれ異なる経路を使う場合があります。変更前に元の値を控え、一度に1項目だけ変更して、コアのログに名前解決のタイムアウトや上流サーバーへの接続失敗がないか確認してください。TUNやルーティング設定については、全プラットフォームのインストールガイドで各プラットフォームの設定範囲も確認できます。

症状に合わせてトラブルシューティングの順序を絞り込む

Windows版Clashのよくあるトラブルと最初に確認する項目
症状	最初に確認すること	次に行うこと
クライアントは起動するが、プロキシポートが待ち受けない	コアの状態と設定の解析ログ	設定エラーを修正し、実際のポートを確認する
明示プロキシでは接続できるが、ブラウザーでは失敗する	システムプロキシ、PAC、ブラウザー拡張機能	ブラウザーが参照するプロキシ設定を統一する
ポートが使用中と表示される	待ち受け中のPIDと重複したコア	競合するプログラムを終了するか、ポートを合わせて変更する
サービスのインストールに失敗する、またはすぐ停止する	UAC、サービスのパス、隔離の記録	パスを修正してサービスを再インストールする
特定のストアアプリだけが失敗する	AppContainerの制限とアプリのプロキシ動作	必要な場合に限り、対象パッケージのループバック免除を確認する
TUNを有効にした後、ネットワークに問題が起きる	仮想インターフェース、ルート、DNS、VPNの競合	TUNを無効にして元の状態に戻し、項目ごとに確認する
クライアントを終了してもインターネットに接続できない	システムプロキシやスクリプトの設定が残っていないか	元のプロキシ設定に戻してから、直接接続を確認する

トラブルの記録には、Windowsのバージョンとアーキテクチャ、クライアントとコアのバージョン、発生時刻、待ち受けポート、明示プロキシのテスト結果、前後の時間帯のエラーログを含めてください。共有する前に、サブスクリプションURL、認証トークン、ノードのパスワード、個人のドメイン情報を削除します。変更は一度に1項目に絞ることで、権限、待ち受け、ルール、接続先のどこに問題があるかを切り分けやすくなります。