インストール前に確認：Windowsクライアント・コア・サブスクリプションの違い
WindowsでClashを使うには、クライアント、コア、サブスクリプションの3つが関わります。クライアントは画面操作や設定管理、Windowsとの連携を担当し、コアはプロキシプロトコル、ルール判定、接続処理を担います。サブスクリプションにはノードのほか、プロキシグループやルールが含まれる場合があります。インストール後にクライアントが起動しても、利用可能なノードがあるとは限らず、Windowsの通信がプロキシ経由になったとも限りません。
Clash Metaはその後、mihomoとして開発が続いています。mihomoを使うクライアントと旧バージョンのClashクライアントでは、対応する設定項目が異なる場合があります。プロトコル非対応や設定項目の解析エラーが起きたら、システムプロキシを何度も切り替えるのではなく、実際に動作しているコアとバージョンを確認してください。旧版のClash for Windowsは開発終了しています。新規に導入する場合は、クライアントのメンテナンス状況と現在のWindows対応範囲を確認しましょう。
- クライアント：アプリ名、バージョン、インストール先を記録しておくと、設定画面やアップデート方法を確認しやすくなります。
- コア：クライアントのコア情報やログの冒頭で、名称とバージョンを確認します。アプリのバージョンとコアのバージョンは別です。
- 設定：サブスクリプションがClashまたはmihomo互換形式か確認してください。ノードURIだけのリストは、完全なYAML設定として読み込めるとは限りません。
インストールパッケージの選び方：システムのアーキテクチャと形式を確認
x64かARM64かを確認してからダウンロード
Windows 11では「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。Windows 10では通常、「設定」→「システム」→「詳細情報」で確認できます。IntelやAMDの一般的なデスクトップCPUでは、通常x64を選びます。ARMベースのデバイスでは、プロジェクトが提供するARM64版を選んでください。Windowsが「64ビット」だからといって、両方のアーキテクチャで同じパッケージを使えるわけではありません。
| 確認項目 | 選び方 | よくある間違い |
|---|---|---|
| CPUアーキテクチャ | x64またはARM64。リリースパッケージの表記に合わせる | ARM64とx64を取り違える |
| インストーラー | プロジェクトが案内するEXEまたはMSIのインストール手順に従う | パッケージ形式の違いをプロキシプロトコルの違いと混同する |
| ポータブル版 | データ保存先、アップデート方法、サービスのインストール手順を確認する | 展開先を移動した後も、古い自動起動パスを使い続ける |
| OSの対応状況 | 現在のバージョンが要求するWindowsのバージョンとランタイムを確認する | 古いWindowsでも最新クライアントがすべて動くと思い込む |
インストールと初回起動
- ダウンロードページからWindowsクライアントを選び、該当プロジェクトのリリースノート、公開者情報、システム要件を確認します。
- 起動中の他のプロキシクライアントを終了します。最初のトラブルシューティングでは、ポートやルートの競合を避けるため、動作するコアを1つだけにしてください。
- プログラムは固定の場所にインストールします。ポータブル版を一時的な展開先に置いたまま使ったり、設定後に名前を変えたりフォルダーごと移動したりしないでください。
- 起動後にログを開き、コアが繰り返し終了・再起動していないか、設定の解析エラーが出ていないか確認します。ランタイムが不足している場合は、該当バージョンのプロジェクトドキュメントに従って追加してください。
Windowsのセキュリティ警告が表示されたら、ダウンロード元、公開者、ファイルのプロパティを確認してから続行するか判断してください。インストールの問題を解決するために、システム保護を長期間無効にするのは避けましょう。会社のデバイスでは、組織のポリシーによってインストールやネットワークの権限が制限されている場合もあります。管理者に確認してください。
サブスクリプションの読み込み：ダウンロード後に設定を有効化
設定画面の名称はクライアントによって異なり、「サブスクリプション」「設定」「Profiles」などが使われています。以下では特定バージョンのボタン名に限定せず、機能に沿って説明します。読み込む前に、リンクがサブスクリプション提供元から発行されたもので、クライアントが認識できる形式を返すことを確認してください。
- 設定管理画面を開き、URLからのインポートを選択して、サブスクリプションのリンクを入力欄に貼り付けます。
- ダウンロードまたはインポートを実行し、結果を確認します。HTTP 401や403が返る場合は、認証、期限、アクセス制限を確認してください。ウェブページの内容が返された場合、それをYAML設定として使うことはできません。
- 読み込んだ設定を選択し、現在の設定として適用します。リストにサブスクリプションが表示されても、コアがその設定に切り替わったとは限りません。
- プロキシグループが存在し、ノード名が欠けていないことを確認します。次に、動作モードをルールモードに設定し、手動選択が必要なプロキシグループではノードを選びます。
- 遅延テストを実行します。失敗した場合は、ログに記録された具体的なエラーを確認してください。一度タイムアウトしただけで、Windowsのインストール失敗と判断するのは避けましょう。
ローカル編集とサブスクリプション更新は別々に管理
ダウンロードした設定ファイルを直接編集すると、次回のサブスクリプション更新時に変更が上書きされることがあります。ルールやDNSの変更を継続して反映したい場合は、クライアントが正式にサポートするオーバーライド、マージ、ローカル設定の仕組みを利用し、更新後に設定が適用されているか確認してください。すべてのクライアントで同じオーバーライド構文が使えるとは限りません。
サブスクリプションリンクには通常、アクセス認証情報が含まれています。トラブルシューティング用のスクリーンショットでは、リンク全体、トークン、管理用キーを隠してください。サードパーティのサブスクリプション変換サービスを使うと、そのサービスが設定内容にアクセスする可能性があります。信頼できるサービスか確認し、提供元が直接配布する互換設定を優先してください。
システムプロキシ：127.0.0.1と実際の待ち受けポートを確認
システムプロキシの設定が反映されるのは、Windowsのプロキシ設定に従うアプリが中心です。すべてのプロセスの通信を横取りする機能ではありません。コマンドラインツールやゲーム、独自のネットワーク接続を実装するプログラムは、この設定を自動で使わないことがあります。そのため「ブラウザーは開けるが、ターミナルは接続できない」場合も、必ずしも故障とは限りません。
ここでは混合プロキシポートの例として7890を使います。クライアントによっては7897など別の値を使う場合があるため、現在のコアの有効な設定と待ち受け状況を確認してください。HTTPポートとSOCKSポートが別々に設定されていることもあります。コントロールAPIのポートをシステムプロキシに設定しないでください。
# ローカル接続パラメーターの例。サブスクリプションを置き換えて使える完全な設定ではありません
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info- クライアントのシステムプロキシ機能を有効にします。
- Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートが現在のクライアントを指しているか確認します。環境によってはセットアップスクリプトを使うため、他のソフトが設定したスクリプトアドレスがないかも確認してください。
- PowerShellでローカルポートへのTCP接続を確認します。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://example.com/TcpTestSucceeded : Trueはローカルポートに接続できることを示すだけで、リモートノードが利用可能であることは証明しません。2つ目のコマンドではローカルHTTPプロキシを明示的に指定するため、「アプリがシステムプロキシを使っていない」のか「プロキシ経路自体に問題がある」のかを切り分けるのに役立ちます。curl.exeを使うと、一部のPowerShell環境でcurlのエイリアスによって引数の扱いが変わる問題を避けられます。テスト用ドメインは例です。実際に確認したい接続先に置き換えてください。
サービスモード、TUN、ファイアウォール：権限と通信の対象範囲を分けて確認
サービスモードは権限を補う機能。設定の検証とは別
Windowsクライアントによっては、サービスモードでコアを起動したり、管理者権限が必要な処理を実行したりします。サービスのインストール時にUACの許可を求められるのは、権限を昇格するためです。インストールしたクライアントからの要求であることを確認してください。実装はクライアントごとに異なります。サービスをインストールしてもTUNが有効になるとは限らず、ルーティングやDNSの設定が正しいとも限りません。
サービスのインストール後、まずクライアントでサービスの状態を確認します。さらに確認する場合は、Win + Rを押してservices.mscと入力し、サービス管理ツールを開きます。実際のサービス名と稼働状態はプロジェクトのドキュメントで確認してください。他のクライアントのサービス名をそのまま使ったり、正体のわからないシステムサービスを削除したりしないでください。
基本的な接続を確認してからTUNを有効化
TUNは仮想ネットワークインターフェースとルーティングを使い、対象となるIP通信を取り込みます。システムプロキシに従わない一部のアプリも対象にできます。通常は管理者権限に加え、ルーティングやDNSの処理が関係します。まず通常のローカルプロキシが動作することを確認してからTUNを有効にし、仮想インターフェースの作成失敗、ルートの追加失敗、権限不足がログに出ていないか確認してください。
- 他のVPNと併用する場合は、ルートの優先順位、DNS設定、仮想ネットワークアダプターを確認します。最初のトラブルシューティングでは、経路を制御する仕組みを一つだけ有効にして確認すると切り分けやすくなります。
- LAN内のデバイス、社内ネットワーク、リモートデスクトップに問題がある場合は、社内ネットワーク宛ての通信が誤ってプロキシに送られていないか確認してください。ルールの問題を隠すために、グローバルモードを常用するのは避けましょう。
- TUNでのDNSリダイレクトが適用されるのは、対象の経路を実際に通るリクエストだけです。ブラウザー内蔵の暗号化DNSや、他のVPNのDNSポリシーも個別に確認してください。
ファイアウォールはプログラムと用途に応じて許可
Windows Defenderファイアウォールの確認画面が表示されたら、コアの実行ファイルのパスを確認し、実際の利用環境に合ったネットワークの種類を選びます。ローカルのループバックプロキシだけを使う場合、通常はLAN向けの受信ポートを開放する必要はありません。他のデバイスと共有する場合に限り、待ち受けアドレス、allow-lan、該当する受信規則を確認してください。
テストのためにファイアウォール全体を無効にしないでください。サードパーティのセキュリティソフトや組織のポリシーが外向きの接続を制限している場合もあるため、ブロック履歴を確認します。コアの更新で実行ファイルのパスが変わると、以前のプログラム規則が適用されなくなることがあります。その場合は許可するパスを更新し、プログラムを限定しない広範な規則を追加しないでください。
よくあるトラブル：ポート競合、プロキシ設定の残留、設定エラー
ポート競合：プロセスを特定してから終了またはポート変更
ログにaddress already in useやバインド失敗が表示されたら、対象ポートを使用しているプロセスを確認します。以下の2つのコマンドは待ち受けアドレスとプロセスIDを調べるもので、プロセスを自動終了することはありません。
netstat -ano | findstr LISTENING | findstr :7890
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess表示されたPIDをもとに、タスクマネージャーの「詳細」タブで該当プロセスを確認します。古いクライアントや二重起動したコアであれば、まずその画面から正常に終了してください。他のプログラムにそのポートを割り当てる必要がある場合は、現在のクライアントの混合ポートを7891などに変更し、システムプロキシ、ターミナルのプロキシ環境変数、明示的なプロキシテストコマンドも合わせて更新します。
システムプロキシが機能しない：アプリ側とWindows側の設定を切り分ける
| 症状 | まず確認すること | 次の手順 |
|---|---|---|
| プロキシを明示したテストは成功するが、特定のアプリは失敗する | アプリがシステムプロキシに従うか、独自のプロキシ設定があるか | アプリ側でプロキシを設定するか、TUNの利用を検討する |
| ローカルポートに接続できない | コアの状態、実際のポート、設定解析のログ | まず待ち受けを復旧してから、リモート接続をテストする |
| ブラウザーは使えるが、コマンドラインは失敗する | ツール独自のプロキシ引数や環境変数が必要か | ツールのドキュメントに従ってプロキシを設定し、プロセスを再起動する |
| 接続ログに直接接続と表示される | 適用ルール、プロキシグループの選択、現在の動作モード | ルールの適用先またはグループ内の選択を修正する |
| TUNを有効にすると社内ネットワークに接続できない | ルート、DNS、他のVPN、社内ネットワーク向けルール | TUNを無効にして比較し、項目ごとに調整する |
WinHTTPとユーザー単位のシステムプロキシは、別々の設定です。netsh winhttp show proxyでWinHTTPの設定を確認できますが、その結果だけではすべてのブラウザーやデスクトップアプリのプロキシ状態はわかりません。特定のプログラムを直すために、コンピューター全体のプロキシ設定をむやみに変更しないでください。
終了後にネット接続できない：プロキシが停止したポートを指していないか確認
クライアントが異常終了し、Windowsのプロキシ設定が127.0.0.1:7890のまま残ると、システムプロキシに従うアプリが接続できなくなる場合があります。クライアントを再起動して待ち受けを復旧するか、Windowsのプロキシ設定で有効にした手動プロキシをオフにしてください。会社の設定で登録されたプロキシスクリプトは、むやみに削除しないでください。元の値を記録してから、管理者の指示に従って対応します。
設定の解析に失敗した場合はログに戻り、問題のある項目を確認します。YAMLのインデントにはスペースを使い、プロキシグループの参照先が実在すること、プロトコルが現在のコアに対応していることを確認してください。「接続できない」とだけ記録するより、エラー全文、行番号、コアのバージョンを残すほうが原因を特定しやすくなります。
自動起動：ログイン時の起動、サービス起動、プロキシの復旧を個別に確認
クライアントの「自動起動」は通常、ユーザーがWindowsにログインした後に画面を起動する機能です。バックグラウンドサービスはログイン前に起動する場合があり、両者は同じではありません。自動起動を有効にした後は、現在の設定が自動で読み込まれるか、システムプロキシが意図どおり復旧するか、TUNに必要な権限があるかも確認してください。
- クライアントの設定にある自動起動オプションを有効にします。起動用ショートカットを複数、手動で登録しないでください。
- Windows 11では「設定」→「アプリ」→「スタートアップ」、またはタスクマネージャーの「スタートアップ アプリ」で、該当項目が無効になっていないか確認します。サービスやタスクスケジューラで起動するクライアントは、別途ドキュメントに従って確認してください。
- クライアントを正常終了してから再起動し、選択中の設定、プロキシグループ、ポートが保持されていることを確認します。
- Windowsを実際に再起動してログインします。スリープからの復帰だけでは確認できません。ネットワーク接続が確立するまで待ってから、ローカルポートと接続先への通信をテストしてください。
- コアのプロセスが1つだけ動いていることを確認し、タスクトレイの画面、バックグラウンドサービス、現在の設定状態が一致しているか確認します。
再起動後はサブスクリプションの更新に失敗するのに、手動では成功する場合、起動時にWi-Fiがまだ接続されていなかった、システム時刻が同期されていなかった、サブスクリプションへのアクセス経路に問題があった可能性があります。まず時系列とエラーログを確認し、必要ならクライアントの遅延起動や更新再試行の設定を検討してください。すぐに再インストールする必要はありません。
設定完了後の確認リスト
- ローカルの待ち受けポートに接続でき、バインド失敗やコアの繰り返し再起動がない。
- 現在の設定がサブスクリプションの記録と一致し、プロキシグループで利用可能なノードが選択されている。
- 接続ログから、接続先に適用されたルールと最終的なアウトバウンドを確認できる。
- 正常終了後にネットワークが想定どおり復旧し、システムプロキシが待ち受けのないポートを指していない。
- 再起動してログインした後も設定が復元される。TUNが必要な場合は、仮想インターフェース、ルート、DNSの状態も個別に確認する。
この順序でインストールすれば、以降のトラブルはアプリのプロキシ設定、コアの待ち受け、サブスクリプション設定、ノードへの接続、システム通信の取り込みのいずれかに切り分けやすくなります。ルールやサブスクリプションの管理については使い方ガイドをご覧ください。権限やネットワークの問題はよくある質問も参考になります。