Windows UWPアプリでClashプロキシが使えない場合の対処法｜ループバック免除の設定

まず、原因がローカルのループバック制限か確認する

Windows 10／11でブラウザーはClash経由で通信できるのに、特定のUWPアプリだけ接続エラーが続く場合は、AppContainerのネットワーク分離が原因か確認しましょう。Clashのシステムプロキシは通常、127.0.0.1:7890のようなローカルアドレスを参照します。AppContainerで動作するアプリは、通常のデスクトップアプリと異なり、既定ではローカルのループバックサービスにアクセスできません。そのため、通信がプロキシのコアに届く前に失敗することがあります。

ここでいう「ループバック免除」とは、指定したアプリにローカルのループバックアドレスへのアクセスを許可する設定です。プロキシルールの解除やアカウント制限の解除ではなく、アプリにネットワーク機能を自動で追加するものでもありません。対象はアプリパッケージであり、サブスクリプションやプロキシノードではありません。Microsoft StoreからインストールしたソフトがすべてUWPとは限りません。パッケージ化されたデスクトップアプリの中には、完全信頼プロセスで動作するものもあるため、インストール元だけで判断しないでください。

確認対象となるケース：同じPC・同じネットワークでブラウザーのプロキシ接続は正常なのに、特定のAppContainerアプリだけ通信できず、ローカルのシステムプロキシを使っている。
まずクライアントの問題を除外：ブラウザーも接続できない場合は、コアの動作状況、待ち受けポート、ノードへの接続を先に確認してください。
サービス側の問題も確認：特定のアカウント、ダウンロード、接続先ドメインだけでエラーになる場合は、ログイン状態、サービスの稼働状況、接続ログも確認してください。

手順1：システムプロキシとローカルポートを確認する

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」→「編集」を開きます。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」の手動プロキシ設定を確認してください。プロキシサーバーのアドレスとポートがクライアントの設定と一致しているか確認します。クライアントの「システムプロキシ」スイッチで設定を管理している場合は、クライアント側で切り替えてください。設定箇所が重複すると、互いに上書きされることがあります。

システムプロキシには、HTTPプロキシポートまたはHTTPに対応した混合ポートが必要です。SOCKS専用ポートや、プロキシコアのコントロールインターフェース用ポートを設定しないでください。コントロールインターフェースは設定管理や状態確認に使うもので、アプリのHTTPプロキシ通信を中継するものではありません。

PowerShellでTCPの待ち受けを確認する

PowerShell · ローカルポートの確認

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

出力のTcpTestSucceededを確認します。値がTrueでも、そのTCPポートに接続できることを示すだけで、ノード、DNS、接続先サイトが正常とは限りません。Falseの場合は、まずコアの起動状態やポート番号を確認してください。待ち受けていないサービスは、ループバック免除を追加しても直りません。

Windows標準のcurl.exeでプロキシを明示し、HTTPプロキシ経由の通信を確認することもできます。次のコマンドではタイムアウトを15秒に設定しています。これは診断用の例であり、実測結果ではありません。接続先サイトにアクセスできない場合は、到達できることが分かっているHTTPSアドレスに変えて確認してください。

PowerShell · HTTPプロキシを明示して確認

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

プロキシを明示したリクエストが成功しても対象アプリだけ失敗する場合は、続けてループバック権限を確認します。UWPアプリからローカルプロキシに接続させるために「ローカルネットワークへの接続を許可」を有効にしないでください。これは他のデバイスから待ち受けサービスへの接続を許可する設定であり、ローカルAppContainerのループバック分離とは別の機能です。

手順2：アプリのパッケージファミリー名を調べ、現在の免除を記録する

CheckNetIsolation.exeは、Windows標準のネットワーク分離管理ツールです。免除の追加・削除には管理者権限のターミナルを使います。アプリの検索は、対象アプリを実際に実行しているWindowsユーザーで行ってください。別の管理者アカウントで昇格すると、Get-AppxPackageが検索するユーザーも変わり、対象パッケージが見つからないことがあります。

対象アプリを終了します。バックグラウンドプロセスが残っている場合も終了してください。
対象ユーザーのPowerShellで、以下の検索コマンドを実行してアプリを探します。
「スタート」を右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を選び、ユーザーアカウント制御の確認に同意します。
免除一覧を確認するコマンドを実行し、確認や復元に備えて実行前の出力を保存します。

PowerShell · アプリの識別情報と現在の一覧を確認

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

CheckNetIsolation.exe LoopbackExempt -s

追加コマンドで必要なのはPackageFamilyName（パッケージファミリー名）です。表示名や、バージョン・アーキテクチャなどを含むPackageFullNameではありません。パッケージファミリー名は通常、アプリ名、アンダースコア、発行元の識別子で構成されます。インストール先フォルダーの名前から推測して組み立てないでください。

Windows電卓を使ったコマンド例

以下ではMicrosoft.WindowsCalculatorを使って検索方法を説明します。通常の計算にプロキシは不要なため、電卓はコマンドの構造を示す例にすぎず、ネットワークの復旧確認には使えません。実際に作業する際は、検索名を前の手順で確認した対象アプリのNameに置き換えてください。

PowerShell · パッケージを名前で絞り込む

Get-AppxPackage -Name Microsoft.WindowsCalculator |
  Select-Object Name, PackageFamilyName

検索結果が出ない場合は、アプリが現在のアカウントにインストールされているか、名前が一致しているかを確認してください。Microsoft Store上の表示名と内部のパッケージ名が異なることがあります。まずパッケージ一覧全体を確認しましょう。通常のインストーラーで導入され、対応するパッケージIDを持たないデスクトップアプリには、パッケージファミリー名を使ったコマンドを適用しないでください。

手順3：CheckNetIsolationで対象アプリの免除を追加する

アプリの識別情報を確認したら、管理者権限のPowerShellで免除を追加します。以下は引き続き電卓を例にし、変数からパッケージファミリー名を取得して入力ミスを防ぎます。スクリプトは一致するパッケージが1つだけの場合に実行されます。対象を特定できない場合は停止し、一括変更は行いません。

管理者権限のPowerShell · パッケージを1つ追加

$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
    throw "対象のアプリパッケージが1つだけ見つかりません。現在のユーザーとアプリ名を確認してください。"
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -a "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -s

LoopbackExemptはループバック免除の管理、-aは追加、-n=の後にはパッケージファミリー名を指定します。-sは現在の一覧を表示します。AppContainer SIDを指定する方法もありますが、通常のトラブルシューティングではシステムから直接取得できるパッケージファミリー名を使うと、対象の取り違えを防ぎやすくなります。

追加コマンドでエラーが出ていないか確認します。「アクセスが拒否されました」と表示された場合は、ターミナルが管理者権限で実行されているか確認してください。
-sの出力で、対象の名前または対応するSIDを確認します。コマンドが完了しただけで、アプリの通信が復旧したと判断しないでください。
対象アプリを再起動し、先ほど失敗したのと同じネットワーク操作を行います。
Clashの接続画面またはログも確認し、リクエストがコアに届いているか、適用されたポリシーグループと最終的な出口が正しいかを確認します。

別の方法：クライアント内蔵のUWPループバックツールを使う

Windows向けの一部のGUIクライアントには、ループバック免除ツールへの入口があります。ただし、Clashやmihomoの設定ファイルで共通に使える項目ではありません。利用できるか、ボタン名や場所はクライアントとバージョンによって異なります。見つからない場合は上記のシステムコマンドを使えばよく、YAMLにいわゆるUWP用スイッチを追加する必要はありません。

旧版Clash for Windowsでの操作手順

開発が終了したClash for Windowsには、以前「General」→「UWP Loopback」→「Launch Helper」から開く機能がありました。すでにインストール済みの場合は、補助ウィンドウで対象アプリにチェックを入れて「Save Changes」をクリックし、保存できます。権限の確認が表示されたら、画面の指示に従って許可してください。この手順は既存環境向けの説明であり、旧クライアントへの乗り換えを勧めるものではありません。

ツールの一覧で対象アプリの名前を確認し、今回処理するアプリだけにチェックを入れます。
保存後、対象アプリを終了して再起動し、同じネットワーク操作をもう一度試します。
管理者権限のターミナルでCheckNetIsolation.exe LoopbackExempt -sを実行し、システムに反映された状態を確認します。
ほかのクライアントに同様の機能がある場合は、現在のバージョンの画面に従ってください。「サービスモード」「システムプロキシ」「ループバック免除」はそれぞれ別の機能です。

GUIツールとコマンドラインは、同種のシステム免除設定を変更するもので、プロキシノードの品質は変わりません。補助ツールが起動しない、一覧が空、保存に失敗するといった場合は、サブスクリプションを何度も切り替えるのではなく、パッケージの識別情報と管理者権限を確認してください。

免除を追加しても通信できない場合：リクエスト経路を順に確認

状況	次に確認すること
ローカルの7890ポートに接続できない	実際の待ち受けポート、コアの動作状況、そのポートがHTTPに対応しているかを確認します。
ブラウザーは正常だが、免除一覧に対象パッケージがない	パッケージファミリー名、現在のユーザー、追加コマンドの権限とエラー出力を確認します。
免除は登録済みだが、クライアントに該当リクエストがない	アプリがシステムプロキシを使っているか、別のパッケージやバックグラウンドサービスが接続を開始しているかを確認します。
ログにリクエストはあるが、DIRECTに一致する	ルールの順序、接続先ドメイン、ポリシーグループを確認します。ループバック免除を追加しても、プロキシ経由になるとは限りません。
リクエストはプロキシに届くが、タイムアウトまたはエラーになる	ログを見てノード、DNS、接続先サイト、アカウントの状態を確認します。免除を繰り返し追加する必要はありません。

Microsoft StoreとXbox関連機能は個別に確認する

ストア画面の読み込み、アカウントへのログイン、アプリのダウンロードは、異なるコンポーネントがリクエストを送信する場合があります。一つの画面が復旧しても、すべてのバックグラウンド通信が同じパッケージIDやプロキシ設定を使うとは限りません。Xbox関連コンポーネントでも、独立したサービスやUDP通信など、異なるネットワーク要件が関係することがあります。失敗した操作、発生時刻、ログを個別に記録し、1つのパッケージに免除を追加しただけですべてのコンポーネントに適用されたと判断しないでください。

TUNモードはループバック免除のスイッチではない

mihomoのTUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、アプリがローカルHTTPプロキシへ直接接続する場合とは経路が異なります。アプリがシステムプロキシを参照しない場合、TUNは別の切り分け方法になりますが、クライアントの対応、必要な権限、適切なルーティングとDNS設定が必要です。すべてのAppContainerのネットワーク制限を自動で解除するものではなく、あらゆるUWPの通信経路で使えるとも限りません。

TUNをテストするときは、一度に変更する要素を1つにし、システムプロキシ、TUN、対象アプリの状態を記録してください。DNS、ルール、ノード、免除一覧を同時に変更すると、復旧しても何が効いたのか特定できません。関連用語は用語集、プラットフォーム別の設定は各プラットフォームのガイドをご覧ください。

元に戻す方法：今回追加した免除を削除する

ループバック免除はシステム設定に保存されるため、Clashを終了しても自動では解除されません。テスト後に不要になった場合、アプリが別のネットワーク経路に切り替わった場合、または元の分離状態に戻す場合は、-dで指定したパッケージを削除できます。以下は前述の電卓の例です。実際の復元時は、今回操作した対象パッケージを指定してください。

管理者権限のPowerShell · 削除して確認

$apps = @(Get-AppxPackage -Name Microsoft.WindowsCalculator)
if ($apps.Count -ne 1) {
    throw "対象のアプリパッケージが1つだけ見つかりません。操作前に記録したパッケージファミリー名を確認してください。"
}
$pfn = $apps[0].PackageFamilyName
CheckNetIsolation.exe LoopbackExempt -d "-n=$pfn"
CheckNetIsolation.exe LoopbackExempt -s

アプリをすでにアンインストールした場合は、現在のGet-AppxPackageの結果に頼らず、保存しておいたパッケージファミリー名で削除してください。GUIツールを使う場合は対象アプリのチェックを外して保存し、その後システムコマンドで状態を確認します。

完了後、対象アプリを再起動し、削除によって想定どおりの変化があったか確認します。作業前から対象アプリに免除が設定されていた場合、「整理」のために削除してはいけません。元に戻すとは、作業前の状態に戻すことです。「ローカルポートに接続できる」「対象パッケージの免除を確認済み」「ログでリクエスト経路を確認できる」「アプリの操作が成功する」の4点を記録すれば、偶然の成功を問題解決と取り違えずに済みます。