クライアント、OSのアーキテクチャ、コアを確認する

WindowsでClashを使うには、通常、GUIクライアントをインストールし、クライアントからプロキシコアを起動します。ClashとClash Meta（現名称：mihomo）は別のバージョン系列です。画面が起動しても、コアがサブスクリプション内のすべてのプロトコルに対応しているとは限りません。インストール前にOSのアーキテクチャ、クライアントのメンテナンス状況、サブスクリプションの形式を確認しておくと、後からインストーラーを何度も入れ替える手間を減らせます。

インストール前に確認する3項目

  1. システムのアーキテクチャ：Windowsの「設定」→「システム」→「バージョン情報」で「システムの種類」を確認します。一般的なIntel・AMD搭載PCではx64版を選びます。ARMデバイスでは、クライアントが明示的に提供しているARM64版を選びましょう。インストーラーのファイルサイズだけで判断しないでください。
  2. メンテナンス状況：更新が継続され、現在のWindowsに対応しているクライアントを選びましょう。Clash for Windowsは開発が終了しています。古い解説にあるメニューの場所やドライバーの導入方法、トラブル対処を新しいクライアントにそのまま当てはめないでください。
  3. 設定の種類：サブスクリプションの提供元に、リンクからClashまたはmihomo用の設定ファイルを取得できるか確認します。共有リンクだけのノードリストではないかも確認してください。新しいプロトコルや設定項目によってはmihomoが必要で、旧バージョンのコアでは読み込み時にエラーになることがあります。

インストーラーは、当サイトのClashクライアントのダウンロードページからプラットフォームに合ったものを選べます。インストール前に、起動中の同種クライアントを終了してください。複数のプログラムが同時にシステムプロキシを変更したり、ポートを取り合ったり、仮想NICを重複して作成したりするのを防げます。既存の設定を引き継ぐ場合は、クライアントの設定管理機能から先にバックアップをエクスポートします。サブスクリプションの認証情報が含まれる場合があるため、管理されたローカルフォルダーに保存してください。

インストールとSmartScreen：警告が出たら入手元を確認

インストーラーを起動すると、Windows SmartScreenに「WindowsによってPCが保護されました」と表示されることがあります。こうした警告はファイルの評価や署名などに関係します。警告だけでファイルに問題があると断定することも、決まった手順として無視することもできません。まず、選んだプロジェクトの正式な配布元から入手したファイルか、ファイル名・アーキテクチャ・ダウンロード先が一致しているかを確認し、可能であればファイルのプロパティでデジタル署名も確認してください。

ブロックされたときの対処手順

  1. 入手元がはっきりしないインストーラーは閉じ、ダウンロードページと実際のファイルを確認し直します。チャットの添付ファイルや、出所不明のファイル共有サイトにあるコピーからインストールしないでください。
  2. 入手元が信頼でき、デバイスのポリシーで許可されている場合に限り、SmartScreenの「詳細情報」→「実行」を選んで続行できます。このボタンが表示されない場合は、システム保護を無効にして組織のポリシーを回避しないでください。
  3. セキュリティソフトによってファイルが隔離された場合は、「Windows セキュリティ」→「ウイルスと脅威の防止」→「保護の履歴」で検出内容を確認し、必要に応じてソフトウェアの配布元に報告します。ダウンロードフォルダー全体を除外対象にしないでください。
  4. インストール後は、まず通常どおり起動してください。システムプロキシを通常利用するだけなら、画面を常に管理者として実行する必要はありません。サービスモードやTUNに必要な権限は、後から個別に設定します。

ポータブル版は、完全に展開してから、固定した書き込み可能なユーザーフォルダーに置いてください。圧縮ソフト内から直接実行しないでください。設定の保存やコアの更新に失敗する場合は、権限を何度も昇格させるのではなく、フォルダーのアクセス権、セキュリティソフトの「コントロールされたフォルダーアクセス」の履歴、ファイルを使用中の別プロセスがないかを確認します。

サブスクリプションの読み込み：更新後に設定を有効化

クライアントの「設定」または「Profiles」画面を開き、URLから読み込む項目を選択します。サブスクリプション提供元から発行されたURLをすべて貼り付けて、ダウンロードを実行してください。トークン付きのURLは認証情報と同じです。公開ログやスクリーンショット、オンライン変換サイトに貼り付けないでください。URLを公開してしまった場合は、ローカルの履歴を削除するだけでなく、提供元の管理画面で再発行してください。

  1. ダウンロード結果を確認：設定一覧に新しい項目が表示されていることを確認します。ログイン画面やセッション切れの通知、エラーページが返された場合は、ファイル名をYAMLに変えても読み込めません。
  2. 設定を有効化：読み込んだ項目を選択し、コアの再読み込みが完了するまで待ちます。サブスクリプションの更新成功はファイルを取得できたことを示すだけで、実行中の設定として有効になったとは限りません。
  3. ログを確認：まず、YAMLの解析エラー、未知のプロキシタイプ、プロキシグループの不足などのメッセージを確認します。エラー表示の行は、問題が検出された場所にすぎない場合があります。前の行のインデントや項目も確認してください。
  4. 出口を選択：ルールモードに切り替え、現在のルールから参照されているポリシーグループでノードを選びます。現在のルールで使われていない予備グループだけを変更しないでください。

サブスクリプションを初回取得できない場合は、まずシステムプロキシをオフにして、現在のネットワークから提供元のURLへ再接続します。この時点では利用可能なノードがない場合があり、サブスクリプション取得リクエストがプロキシ経由だとは限りません。提供元が許可し、クライアントも対応している場合に限り、更新専用のプロキシを設定してください。出所不明の変換サービスを安易に追加しないでください。

システムプロキシとポート：まずブラウザーで接続を確認

最初の動作確認ではシステムプロキシだけを有効にし、TUNはオフにします。システムプロキシの対象はWindowsのプロキシ設定に従うアプリで、すべてのプログラムを制御するわけではありません。ゲームやコマンドラインツール、独自のネットワーク処理を行うアプリでは使われないことがあります。まずこの経路を確認しておけば、ノードの問題と仮想NICの問題を切り分けやすくなります。

待ち受けポートとWindowsの設定を確認

クライアントの設定でHTTPポートまたは混合ポートを確認します。混合ポートが 7890 の場合、システムプロキシを有効にした後、「設定」→「ネットワークとインターネット」→「プロキシ」で「プロキシサーバーを使う」のアドレスとポートを確認できます。ローカルアドレスは通常 127.0.0.1 です。PACモードでは自動構成スクリプトを使うことがあるため、手動プロキシのスイッチだけでは有効かどうか判断できません。

PowerShellで次のコマンドを実行すると、例に挙げたポートが待ち受け状態か確認できます。何も表示されない場合は、コアの起動失敗、ポート設定の不一致、設定ファイルの読み込みエラーを先に調べてください。

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

ポートが使用中の場合は、表示されたプロセスIDから実行中のプログラムを特定し、競合するクライアントを終了するか、現在のクライアントのポートを変更します。見覚えのないシステムプロセスを終了しないでください。ポートを変更したら、システムプロキシを再度有効にし、アプリに手動入力したプロキシアドレスも更新します。

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

このコマンドはローカルのHTTPプロキシを明示して使います。HTTPポートまたは混合ポート用で、SOCKS専用ポートには使えません。HTTPレスポンスが返れば、そのリクエストがプロキシ経由で完了したことは確認できますが、すべてのWebサイトが利用できるとは限りません。続けて対象ページを開き、クライアントの「接続」またはログ画面で、対象ドメイン、適用ルール、ポリシーグループ、実際の出口を確認してください。遅延テストの成功はテスト先への接続確認にすぎず、この手順の代わりにはなりません。

ファイアウォールの許可：ローカルプロキシはLAN公開とは別

Windowsファイアウォールは主に、プログラム、ネットワークプロファイル、通信の方向に基づいて接続を制御します。ローカルアプリから 127.0.0.1 に接続するだけなら、通常、プロキシポートをLANに公開する必要はありません。Windowsの許可確認が表示されても、「プライベートネットワーク」と「パブリックネットワーク」の両方を選ぶ必要はなく、PC全体のファイアウォールを無効にする必要もありません。

利用シーン確認する項目対処の基本方針
このPCのブラウザーだけで利用ループバック待ち受け、ポートの競合、コアのログローカルからのアクセスに限定し、LANへの入口は追加で開放しない
スマートフォンからPCのプロキシを利用LAN接続の許可、待ち受けアドレス、受信規則信頼できるプライベートネットワークで、実際に使うTCPポートだけを許可
職場のデバイスからノードに接続できない送信規則、セキュリティソフト、管理ポリシー管理者に制限内容を確認し、保護機能を自分で無効にしない

LANで共有する必要がある場合は、まずクライアントが対応していることを確認し、「LAN接続を許可」を有効にして、待ち受けアドレスがLAN側のインターフェースを含むか確認します。「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「詳細設定」で、実際のプロキシポートに必要な受信規則だけを作り、信頼できるデバイスのアドレスまたはローカルサブネットに限定してください。HTTPプロキシは通常TCPを使います。接続先ノードのプロトコルにUDPが含まれていても、ローカルのUDPポートをすべて開放してはいけません。

GUIとコアは別々の実行ファイルである場合があります。画面からインターネットに接続できても、コアが組織の送信規則で制限されていないとは限りません。ログから実際にブロックされたプロセスを特定し、その実行ファイルのパスと規則を確認します。クライアントの更新でパスが変わり、以前の規則が適用されなくなることもあります。

UWPのループバック：ブラウザーは使えるのに一部アプリが接続できない

AppContainerで動作するアプリの一部にはネットワーク分離の制限があり、ローカルのループバックプロキシに直接接続できないことがあります。その場合、ブラウザーではアクセスできるのに、特定のアプリだけオフラインと表示されます。Microsoft Storeアプリがすべて該当するわけではなく、パッケージ形式で配布されるデスクトップアプリにも同じ制限があるとは限りません。まず、そのアプリが実際にシステムプロキシを使おうとしているか確認してください。

必要なアプリだけに例外を設定

  1. クライアントに「UWP ループバック」または「Loopback」ツールがある場合は開き、ローカルプロキシ経由の接続が必要なアプリだけを選択します。保存後、対象アプリを再起動してください。
  2. GUIツールがない場合は、ターミナルで CheckNetIsolation.exe LoopbackExempt -s を実行すると、現在の例外を確認できます。
  3. 新たに追加する場合は、ターミナルを管理者として起動し、確認した正確なパッケージファミリー名を -n= パラメーターに指定します。アプリの表示名、インストール先フォルダー、完全なパッケージ名で代用しないでください。
Get-AppxPackage |
  Select-Object Name, PackageFamilyName

CheckNetIsolation.exe LoopbackExempt -s

追加コマンドは CheckNetIsolation.exe LoopbackExempt -a -n= の後に、実際のパッケージファミリー名を指定します。解除する場合は -a を -d に変更し、同じ名前を使います。アプリや配布元によってパッケージ識別子が異なるため、そのままコピーできるパッケージ名は記載していません。設定後に対象アプリを再起動し、クライアントの接続履歴を確認します。リクエストが記録されない場合は、アプリ独自のプロキシ対応状況やネットワークポリシーも確認してください。

TUNモード：サービス権限、仮想NIC、DNS

システムプロキシに従わないプログラムも対象にしたい場合は、TUNを検討します。TUNは仮想ネットワークインターフェースとルーティングを使ってトラフィックをコアに渡しますが、個々の接続が処理されるかどうかはルート、除外設定、設定ファイルによって異なります。mihomoのTUNスタック設定、DNSの処理方法、クライアントのサービス導入手順はバージョンごとに変わるため、現在のクライアントの説明を確認してください。

設定を1つずつ変えて有効化

  1. まずシステムプロキシが使えることを確認し、現在のノード、ポート、正常に表示できるテストページを記録します。
  2. クライアントの「設定」にある「サービスモード」またはサービスのインストール項目から認証します。サービスのインストールには管理者権限が必要です。失敗した場合はエラー内容を確認し、ボタンを何度も押さないでください。
  3. TUNによる通信の変化を確認しやすくするため、システムプロキシをオフにしてからTUNを有効にします。ログで仮想インターフェースとルートが正常に作成されたか確認してください。
  4. DNS設定がサブスクリプション、上書き設定、クライアント管理の設定によって変更されていないか確認します。TUNがオンでも、DNSの引き継ぎや名前解決が正常とは限りません。

PowerShellで Get-NetAdapter -IncludeHidden を実行して仮想インターフェースを確認し、route print でルートを確認できます。インターフェース名に「Clash」が含まれるとは限らず、従来型のデフォルトルートが1つだけ表示されるとも限りません。自動ルーティング方式によっては、より具体的なルートが使われます。有効化の前後の変化とコアのログをあわせて確認し、ネットワークアイコンだけで判断しないでください。

ドライバーの読み込みに失敗した場合は、まず他のVPN、通信高速化ツール、仮想NIC関連ツールを停止し、クライアントがサポートする方法でサービスまたはドライバーを修復します。出所不明のサイトからDLLだけをダウンロードしてインストール先に上書きしたり、古いドライバーを動かすためにメモリ整合性などの保護を無効にしたりしないでください。互換性のないドライバー方式は避け、サポート対象のクライアントに更新してください。

TUNを有効にした後、LANプリンター、NAS、社内ネットワークに接続できなくなった場合は、プライベートネットワークのルート除外と直接接続ルールを確認します。ルール内の DIRECT とOSのルート除外は別の階層の設定です。DNSですでに名前解決できない場合は、直接接続ルールを追加するだけでは解決しないことがあります。会社のVPNを使う場合は、組織が許可するネットワーク構成を確認し、複数のプログラムが同時にルートやDNSを制御しないようにしてください。

インストール後の動作確認と終了時の復旧

設定が完了したら、以下の項目を順に確認してください。設定を一度に1つだけ変更し、確認した時刻とログのエラーを記録すると、ノードの切り替え、ドライバーの再インストール、DNSの変更を同時に行うより原因を特定しやすくなります。

  • 設定：読み込んだサブスクリプションが有効になっていること、コアのログに解析エラーがないこと、ポリシーグループで実際に使える出口が選択されていることを確認します。
  • ブラウザー：対象ページが開けること、クライアントに該当する接続が記録されていること、適用ルールが想定どおりであることを確認します。
  • 特定のアプリ：システムプロキシ、UWPのループバック制限、アプリ独自のプロキシ設定を切り分け、接続失敗の原因をすべてファイアウォールのせいにしないでください。
  • TUN：必要な場合にのみ有効にし、仮想インターフェース、ルート、DNSが正常に動作することと、ローカルネットワークのリソースに接続できることを確認します。
  • 終了時の復旧：先にTUNとシステムプロキシをオフにしてからクライアントを終了し、通常のネットワークに接続できることを確認します。

クライアントが異常終了してWebページを一切開けなくなった場合は、まずWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、停止したローカルプロキシや自動構成スクリプトが残っていないか確認します。組織管理のデバイスでは、既存のポリシーを上書きしないでください。TUNの使用後に限って発生する場合は、クライアントを再起動してTUNを正常にオフにし、ルートをクリアします。それでも復旧しない場合はPCを再起動してください。すべてのネットワークアダプターを削除したり、ネットワーク設定全体をリセットしたりしないでください。

ルールの調整、サブスクリプションの更新、自動起動の設定については使い方ガイドをご覧ください。Windowsの設定は全プラットフォームガイドのWindows編で解説しています。動作確認済みの基本設定を残し、機能を1つずつ追加していくと、後から問題を比較しやすくなります。