インストール前にシステム、アーキテクチャ、クライアントの種類を確認
Windows上の「Clash」は、通常ひとつのアプリ名ではなく、Clashまたはmihomoコアを使うGUIクライアントの総称です。公式のClash for Windowsは開発が終了しているため、古いインストーラーを使い続けると、コアの旧式化、サブスクリプション項目の互換性問題、システムプロキシが正常に戻らない問題などが起こります。新規インストールでは、現在も保守されWindows対応が明記されたクライアントを選び、mihomoコアを優先してください。
インストール前に「設定」→「システム」→「システム情報」を開き、Windowsのバージョンとシステムの種類を確認します。一般的な「64ビット オペレーティング システム、x64 ベース プロセッサ」と表示されるPCでは、ファイル名に x64、amd64、または x86_64 が含まれるインストーラーを選びます。Qualcomm SnapdragonなどのARMプロセッサ搭載機では arm64 を選択してください。x86 または ia32 は古い32ビット版Windows向けで、現在のクライアントでは提供されないことが多いです。
| システム情報 | 選択するアーキテクチャ | 一般的なファイル名の表記 |
|---|---|---|
| IntelまたはAMDの64ビットPC | x64 | x64、amd64、x86_64 |
| Windows on ARMデバイス | ARM64 | arm64、aarch64 |
| 古い32ビット版Windows | x86 | x86、ia32 |
インストール版とポータブル版の選び方
- インストール版:通常は
.exeまたは.msiのセットアッププログラムで、スタートメニューの項目、アンインストール項目、自動起動タスクを作成できます。個人用PCで常用する場合に適しています。 - ポータブル版:通常は圧縮ファイルで、解凍後にそのまま起動します。設定、ログ、コアのファイルが解凍先に保存される場合があるため、フォルダーを移動する前にクライアントを終了してください。
- Microsoft Store版:更新経路は統一されますが、アプリの権限、データ保存先、機能が通常のインストール版と異なる場合があります。インストール前にプロジェクトの説明を確認してください。
インストーラーをダウンロードして初回起動する
当サイトのダウンロードページから対象クライアントのWindows向けセクションに進み、アーキテクチャを確認してからインストーラーをダウンロードします。ダウンロード完了後は、ファイル名、拡張子、リリースバージョン、配布元ページが一致するか確認してください。プロジェクトがデジタル署名を提供している場合は、ファイルを右クリックして「プロパティ」→「デジタル署名」を選び、署名者と署名状態を確認できます。
Windowsのセキュリティ警告に対処する
ダウンロード数が少ない新バージョンを初めて起動すると、Microsoft Defender SmartScreenに「WindowsによってPCが保護されました」と表示されることがあります。この警告はファイルの評価に基づくもので、悪意のある動作が確定したことを意味しません。まず正式な配布経路から取得したファイルか確認し、「詳細情報」をクリックしてアプリ名と発行元を確認してください。配布元を確認できない場合は実行しないでください。
インストール時は、既定のインストール先をそのまま使うのが最も簡単です。ポータブル版を選ぶ場合は、圧縮ファイルのプレビュー画面から直接実行せず、書き込み権限のあるフォルダーへ完全に解凍してください。ユーザーフォルダー内のアプリ用フォルダーなどが適しています。管理者権限が必要なシステムフォルダーに置くと、コアの更新、設定の保存、ログの書き込みに失敗することがあります。
- 起動中の古いClashクライアントを終了し、ポートやシステムプロキシが古いプロセスに占有されないようにします。
- インストーラーを実行し、インストール先とスタートアップ項目の設定を確認します。
- 完了後、スタートメニューからクライアントを起動し、メイン画面とコアの状態が読み込まれるまで待ちます。
- 「設定」→「コア」または「設定」→「コア設定」を開き、コアが正常に起動できることを確認します。
- 初めて設定を読み込む前にTUNを有効にせず、まずシステムプロキシで基本動作を確認してください。
サブスクリプションを読み込み、設定が有効か確認する
クライアント自体に利用可能なノードは含まれていません。サービス提供元からClash YAML設定のURL、またはクライアントが明確に対応するサブスクリプションURLを取得する必要があります。サブスクリプションURLはアクセス用の認証情報なので、公開ページ、スクリーンショット、ログ投稿、共有ドキュメントなどに貼り付けないでください。
クライアントによって入口の名称は少し異なります。一般的には「設定」→「新規作成」→「URLから読み込む」、または「サブスクリプション」→「サブスクリプションを追加」です。完全なURLを貼り付け、名前と自動更新間隔を設定してから読み込みます。正常に完了すると、設定一覧に更新日時、プロキシグループ、ノード数が表示されます。空の設定だけが作成される場合は正常ではありません。
読み込みに失敗したら、まず3種類の問題に切り分ける
- URLにアクセスできない:ブラウザーで開くと403、404、タイムアウト、またはログイン画面が返るケースです。サブスクリプションの有効期限、コピー時の文字抜け、サーバー側のアクセス制限を確認してください。
- 形式に互換性がない:URLから内容は取得できるものの、クライアントでYAMLの解析失敗、
proxiesの欠落、未対応項目などが表示されるケースです。通常のBase64ノード一覧は、完全なClash設定としてそのまま利用できません。 - 読み込めるがノードがない:サブスクリプションのアカウントが無効、フィルターですべてのノードが除外されている、またはサーバーが空の設定を返している可能性があります。
動作するClash設定には通常、プロキシノード、プロキシグループ、ルールが含まれます。ルールモードでは接続が上から順に rules と照合され、最後に MATCH が未一致の通信を処理します。クライアントに「設定の読み込みに成功」と表示されても、ファイルを受け付けたことを示すだけで、ノードへの接続、ルールの正しさ、サブスクリプションの有効期限を保証するものではありません。
mixed-port: 7890
mode: rule
allow-lan: false
log-level: info
proxy-groups:
- name: ノード選択
type: select
proxies:
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,ノード選択
上の断片は構造の説明用であり、実際のサブスクリプションの代わりにはなりません。mixed-port: 7890 はHTTPとSOCKSの通信でローカルの7890番ポートを共有する設定です。クライアントによってはHTTPに7890、SOCKSに7891を個別に割り当てたり、GUIの設定で設定ファイルのポートを上書きしたりします。実際の確認では、クライアントの「設定」→「ポート設定」、または実行ログに表示される待受アドレスを基準にしてください。
システムプロキシを有効にして段階的に確認する
サブスクリプションの読み込みが完了したら、まず「プロキシ」ページで対象のプロキシグループからノードを選び、モードを「ルール」に設定します。次に「設定」→「システムプロキシ」を開き、システムプロキシを有効にします。クライアントは通常、Windowsのプロキシサーバーを 127.0.0.1 に設定し、ポートにはローカルHTTPポートまたは混合ポート、たとえば 7890 を指定します。
第1段階:コアとノードを確認する
- クライアントのステータスバーを確認し、コアが実行中になっていることを確認します。
- 「プロキシ」ページで遅延テストを実行します。表示される遅延値はテスト先に到達できることを示すだけで、すべてのサイトにアクセスできることを意味しません。
- 「ログ」を開き、レベルを
infoに保ったまま、認証失敗、接続タイムアウト、DNS失敗、ルール解析エラーが出ていないか確認します。 - 「接続」ページを開き、テストサイトへアクセスした後に新しいTCPまたはUDPセッションが表示されることを確認します。
第2段階:Windowsのシステムプロキシを確認する
Win + I を押して「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。有効化後、「プロキシサーバーを使う」の付近にローカルアドレスと対応ポートが表示されます。古いプロキシソフト、ブラウザーのプロキシ拡張機能、別のシステムプロキシツールを同時に有効にしないでください。最後に設定を書き込んだプログラムが、前の設定を上書きします。
コマンドプロンプトでWinHTTPプロキシを確認できます。ただし、WinHTTPと一般的なデスクトップアプリが使うWinINETのシステムプロキシは別の設定です。
netsh winhttp show proxy
このコマンドに「直接アクセス」と表示されても、Clashのシステムプロキシが無効とは限りません。ChromeやEdgeなどのデスクトップブラウザーは通常Windowsのシステムプロキシを読み取りますが、一部のシステムサービスはWinHTTPの設定を読み取ります。出力を変えるためだけに、確認なしで全体インポートを実行しないでください。対象プログラムがWinHTTPに依存すると確認できた場合に限り実行します。
第3段階:ブラウザーとコマンドラインを個別に検証する
ブラウザーでテストするときは、まずプロキシ拡張機能を無効にし、シークレットウィンドウで対象サイトを開きます。その後Clashの「接続」と「ログ」に戻り、記録を確認します。ブラウザーは使えるのにPowerShellが使えない場合、通常はコマンドラインプログラムがシステムプロキシを読み取っていないのであり、Clashコアの障害ではありません。
curl.exe を使うと、古いPowerShellにおける curl エイリアスの違いを避け、ローカルHTTPプロキシを直接指定できます。
curl.exe -I --proxy http://127.0.0.1:7890 https://example.com
curl.exe -I https://example.com
1つ目が成功して2つ目が失敗する場合、Clashの待受ポートとノードはおおむね正常ですが、ターミナルがシステムプロキシを自動利用していません。現在のPowerShellセッションで環境変数を設定できます。
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
これらの変数は、現在のターミナルとそこから起動した子プロセスにだけ影響します。小文字の変数しか認識しないツールや、独自のプロキシ引数を持つプログラムもあります。Gitは git config で設定でき、npm、Pythonのパッケージマネージャー、開発ツールもそれぞれのドキュメントに従って設定してください。ブラウザーの結果をすべてのコマンドラインプログラムにそのまま当てはめないようにしましょう。
ポート競合、システムプロキシの残留、LANアクセス
7890番ポートが使用中
コアのログに「address already in use」「bind failed」「ポートをバインドできません」などが表示される場合、別のプロセスがそのポートをすでに待ち受けています。管理者としてコマンドプロンプトを開き、次を実行します。
netstat -ano | findstr :7890
tasklist /fi "PID eq 1234"
1つ目のコマンドの右端にPIDが表示されます。2つ目の 1234 は調査例なので、実際に見つかった番号へ置き換えてください。プロセスの用途を確認したら、競合しているソフトを終了するか、「設定」→「ポート設定」で混合ポートを未使用の値、たとえば 7892 に変更します。変更後はシステムプロキシをいったん切り替え、Windowsに記録されたポートとクライアントの待受ポートを一致させてください。
終了後もシステムがオフラインになる
クライアントを強制終了した、システムがクラッシュした、更新に失敗した場合、Windowsに 127.0.0.1:7890 を指すプロキシ設定が残り、ローカルポートを待ち受けるプログラムがない状態になることがあります。「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「プロキシサーバーを使う」をオフにしてからクライアントを再起動します。ブラウザーにプロキシエラーが残る場合は、一部のプロセスがネットワーク設定をキャッシュしているため、ブラウザーを完全に終了してから再度開いてください。
LAN内のデバイスからローカルプロキシへ接続する
既定の 127.0.0.1 待受は、同じPCからのアクセスだけを許可します。スマートフォンや別のPCから接続する場合のみ、「LAN接続を許可」を有効にするか、allow-lan を true に設定します。その後、Windowsの現在のLAN側IPv4アドレス、たとえば 192.168.1.25 を確認し、別のデバイスにこのアドレスとClashのポートを入力します。
LANアクセスは、Windows Defenderファイアウォール、ネットワークプロファイル、ルーターのクライアント分離の影響も受けます。家庭内ネットワークは「プライベートネットワーク」に設定し、必要なネットワーク範囲でのみクライアントが待ち受けるようにしてください。公共ネットワークでローカルプロキシポートを公開することは推奨しません。
UWPアプリとTUNモードの違い
従来のシステムプロキシは、Windowsのプロキシ設定を自動的に読み取るアプリが主な対象です。一部のMicrosoft StoreアプリはUWPサンドボックスを使い、既定ではローカルのループバックアドレスへのアクセスが許可されません。そのため、ブラウザーが 127.0.0.1:7890 経由で動作していても、Storeアプリだけが直接接続したりネットワークエラーを表示したりすることがあります。
UWPのループバック除外
この機能に対応するクライアントには通常、「設定」→「UWPループバック」→「ヘルパーを起動」という項目があります。リストからプロキシを使うアプリにチェックを入れて保存します。ローカルプロキシへのアクセスが本当に必要なアプリだけを除外対象にし、すべてを選ぶ必要はありません。システムのアップグレードやアプリの再インストール後はパッケージIDが変わる場合があるため、再確認してください。
PowerShellでアプリのパッケージ名を確認できます。
Get-AppxPackage | Select-Object Name, PackageFamilyName
コマンドラインツール CheckNetIsolation.exe でもループバック除外を管理できますが、パッケージファミリ名は長く、選択を間違えやすいです。まずはクライアントが提供するGUIヘルパーを使い、変更後は対象のUWPアプリを完全に終了してから再起動してください。
TUNが必要になる場面
TUNモードは仮想ネットワークインターフェースを作成し、ネットワーク層でより多くの通信を引き受けます。システムプロキシを読み取らないアプリ、一部のゲームランチャー、コマンドラインツール、UDP転送が必要な場面に適しています。mihomoコアはWindowsでTUNを利用できますが、クライアントによっては初回設定時にサービスやドライバーのインストール、管理者権限が必要です。
一般的な有効化手順は「設定」→「サービスモード」→「インストール」です。完了後、「設定」→「TUNモード」でスイッチをオンにします。名称はクライアントによって異なります。サービスをインストールしても起動できない場合は、クライアントまたはWindowsを再起動し、仮想NICの作成失敗、ルート書き込み失敗、DNS待受ポートの競合がログに出ていないか確認してください。
| 方式 | 対象範囲 | 必要な権限 | 適した用途 |
|---|---|---|---|
| システムプロキシ | Windowsのプロキシ設定を読み取るアプリ | 通常、継続的な管理者権限は不要 | ブラウザー、一般的なデスクトップアプリ、基本的な動作確認 |
| UWPループバック | 除外登録したStoreアプリ | 変更時に権限の承認が必要な場合がある | Microsoft Storeアプリがローカルプロキシにアクセスできない場合 |
| TUNモード | より多くのTCP、UDP、およびプロキシ設定を読まないプログラム | 通常、サービスまたはドライバーが必要 | ゲーム、ターミナル、複雑なルーティング、透過的な通信の引き受け |
自動起動の失敗とバックグラウンドサービスを確認する
「自動起動」には少なくとも2つの段階があります。ログイン後にGUIクライアントが起動するか、そしてmihomoコアまたはサービスがクライアントとともに正常に動作するかです。タスクトレイのアイコンが見えてもコアがポートを待ち受けているとは限りません。逆に、サービスがバックグラウンドで動作していても、システムプロキシがWindowsに設定されているとは限りません。
クライアントの自動起動を確認する
- クライアントで「設定」→「自動起動」を開き、いったんオフにしてから再度オンにします。
- Ctrl + Shift + Esc を押してタスクマネージャーを開き、「スタートアップアプリ」に移動して、対象項目が「有効」になっていることを確認します。
- Win + R を押し、
shell:startupと入力して、古いクライアントが残した無効なショートカットがないか確認します。 - クライアントがタスクスケジューラを使う場合は、「タスクスケジューラ」を開き、最近の実行結果とトリガー条件を確認します。
クライアントによっては、インストール先を更新した後も、古いスタートアップ項目が削除済みの実行ファイルを指し続けます。その場合はアプリ内の自動起動をオフにし、クライアントを完全に終了してから再度起動し、自動起動を有効にしてください。ポータブル版でフォルダーを移動した場合も、スタートアップ項目の再作成が必要です。
起動後にシステムプロキシが自動で有効にならない
「設定」→「システムプロキシ」の周辺に、「起動時にシステムプロキシを復元」などの項目がないか確認します。異常終了後にネットワークが固定されるのを防ぐため、プログラムだけを起動してシステムプロキシは自動で有効にしないクライアントもあります。自動的にプロキシを適用するには、自動起動と起動後のシステムプロキシ有効化をそれぞれオンにし、セキュリティソフトがアプリによるプロキシ設定の変更を阻止していないことも確認してください。
TUNを使う場合は、サービスの状態も確認します。Win + R を押して services.msc と入力し、クライアントがインストールしたサービスが無効化されていないことを確認してください。サービス名はクライアントによって異なるため、インストールログとクライアントの設定画面を基に特定します。用途を確認できないシステムサービスは削除しないでください。
DNS、ルールモード、「接続できるのに開けない」問題
ノードの遅延は正常なのにWebページを開けない場合、DNS、ルール選択、IPv6ルーティング、対象サイトとのハンドシェイクのいずれかに問題がある可能性があります。まず「接続」ページでリクエストがどのルールとプロキシグループに一致したか確認し、次に「ログ」でエラーが名前解決、プロキシ接続、TLSハンドシェイクのどの段階で発生したかを確認します。
症状から原因を絞り込む
- ドメインは開けないが、IPアドレスならアクセスできる:DNS設定、53番ポートの競合、TUNのDNSハイジャック状態を優先的に確認します。
- すべてのリクエストがDIRECTになる:現在のモードが誤って「ダイレクト」になっていないか、またルール末尾で通信が誤ったポリシーグループへ送られていないか確認します。
- グローバルモードにすると使える:通常はルールのマッチングまたはポリシーグループの選択に問題があります。設定ミスを隠すためにグローバルモードを常用しないでください。
- UDPを使うアプリだけ失敗する:ノードのプロトコル、サーバー、クライアントがすべてUDPに対応しているか確認し、TUNが対象プログラムを実際に引き受けているかも確認します。
- ブラウザーが時々古い経路を使い続ける:ブラウザーのセキュアDNSまたはプロキシ拡張機能を無効にして比較テストを行い、バックグラウンドプロセスも完全に終了します。
ルールモードは日常利用の出発点として推奨されます。ドメイン、IP、プロセス、ルールセットに基づき、DIRECT、REJECT、または特定のプロキシグループを選択します。グローバルモードは大半の接続を指定したプロキシグループへ送るため、短時間の比較検証に適しています。ダイレクトモードはプロキシを迂回します。モードを切り替えたらリクエストを再実行し、接続記録で新しいセッションの送信先ポリシーを確認してください。
繰り返し使えるインストール確認リスト
- 「設定」→「システム」→「システム情報」でx64またはARM64アーキテクチャを確認します。
- 現在のWindowsバージョンに対応し、現在も保守されているクライアントを選びます。
- 正式なリリースページからインストール版をダウンロードするか、ポータブル版を完全に解凍します。
- 初回起動後にコアの動作を確認し、TUNの有効化は急がないでください。
- 「設定」または「サブスクリプション」ページからClash YAMLサブスクリプションを読み込みます。
- 「プロキシ」ページでノードを選び、動作モードを「ルール」に設定します。
- 「設定」→「システムプロキシ」を開き、ローカルアドレスとポートを確認します。
- ブラウザー、接続記録、ログを使って通信経路を確認します。
- ターミナルのプログラムは
curl.exe --proxyで個別に検証します。 - ポートエラーが発生したら
netstat -anoで使用中のプロセスを探します。 - UWPアプリがインターネットに接続できない場合は、ループバック除外を設定します。
- システムプロキシの検証が完了してから、サービスをインストールしてTUNを有効にします。
- 最後に、自動起動、設定の更新、異常終了後のプロキシ復元をテストします。
WindowsへのClashのインストールで重要なのは、インストールボタンを順にクリックすることではありません。インストーラー、コア、サブスクリプション、待受ポート、システムプロキシ、アプリの通信を段階的に対応付けることが重要です。一度に変更するのは1つの要素だけにし、「接続」と「ログ」を同時に確認すれば、多くの問題を明確な範囲まで絞り込めます。