Windowsストアアプリがプロキシを使わないときの対処法｜UWPのループバック免除とCheckNetIsolationの使い方

まず確認：ループバック制限か、アプリがプロキシを使っていないのか

ブラウザーではClashクライアント経由で通信できるのに、特定のWindowsストアアプリだけ読み込みが続く場合も、サブスクリプションが無効とは限りません。クライアントがHTTPまたは混合プロキシの待ち受け先として 127.0.0.1 を使用していて、対象アプリが制限付きのAppContainerで実行されている場合、アプリからローカルの接続先にアクセスできないことがあります。その場合は、UWPのループバック免除を確認してみましょう。

ただし、Microsoft Storeはアプリの配布経路であり、実行方式ではありません。ストアから入手した従来型のWin32ソフト、パッケージ化されたデスクトップアプリ、UWPアプリでは、ネットワークの制限がそれぞれ異なります。AppContainerのループバック制限が関係していると確認できた場合に限り、免除設定が有効です。「ストアからインストールした」ことだけを理由に、免除が必要だと決めつけないでください。

UWP、AppContainer、127.0.0.1の関係

127.0.0.1はIPv4のループバックアドレスで、接続先はLAN内の別のPCではなく自分のPCです。Clash系のGUIクライアントは通常、ローカルでコアを起動し、HTTP、SOCKS、または混合ポートでアプリからのリクエストを受け付けます。Windowsのシステムプロキシは、この設定に従うアプリにローカルの接続先へリクエストを送るよう指示します。

AppContainerは、Windowsのアプリ分離機能です。アプリのIDや機能に基づいてリソースへのアクセスを制限し、ネットワークの利用範囲も制御します。プロキシサービスが同じPC上で動作していても、制限付きコンテナーから接続できるとは限りません。CheckNetIsolation.exeのLoopbackExemptサブコマンドを使うと、このようなループバックの例外を管理できます。

TUNモードとの違い

• システムプロキシ経由：アプリがプロキシ設定を読み取り、自分からローカルのプロキシポートへ接続します。この段階でループバック制限が発生することがあります。
• TUN経由：クライアントが仮想ネットワークインターフェイスとルーティングを使って、条件に一致するIP通信を取り込みます。通常、アプリからHTTPプロキシポートへ直接接続する必要はありません。
• 適用範囲：TUNの実際の効果は、ルーティング、DNS、権限、アプリの動作にも左右されます。TUNは「すべてのループバック免除」と同じ意味ではありません。

トラブルシューティングでは、まず通信を取り込む方法を1つに絞ってください。たとえばTUNを無効にし、システムプロキシと特定アプリのループバック接続だけをテストします。プロキシモード、DNS、ルール、免除を同時に変更すると、接続が回復しても原因を特定できません。

操作前に確認：プロキシの接続先とテストの基準

ここでは127.0.0.1:7890を例にします。7890はすべてのクライアントで共通のポートではありません。現在のクライアント設定と、実際に有効な設定を確認してください。mihomoの設定でmixed-portを使うと、HTTPとSOCKSの両方を利用できます。一方、socks-portだけのポートをWindowsのHTTPシステムプロキシに指定することはできません。

1. クライアントの設定でHTTPポートまたは混合ポートを確認し、コアが実行中であることを確かめます。
2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」→「プロキシ サーバーを使う」を開き、アドレスとポートを確認します。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」で確認できます。
3. クライアントがこれらの設定を管理している場合は、クライアント側のスイッチで変更してください。Windowsの設定画面とクライアントの状態が互いに上書きし合うのを防げます。
4. 対象アプリの名前、失敗した操作、発生時刻を記録しておくと、後で接続一覧やログと照合できます。

まずPowerShellで例のポートにTCP接続できることを確認し、次にプロキシを明示してHTTPSリクエストを送信します。

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

TcpTestSucceeded : Trueが示すのは、ポートに接続できることだけです。HTTPレスポンスを確認すると、プロキシ経由の通信が確立しているか判断する手がかりになります。リモート側から403などが返っても、プロキシポートが無効とは限りません。ここではcurl.exeを使い、Windows PowerShellでのcurlエイリアスによる引数の違いを避けています。

この2つの確認はデスクトッププロセスから実行するため、UWPアプリにループバック接続の権限が付与されたことは証明できません。基準テストに失敗する場合は、コンテナーの権限を変更する前に、待ち受けポートや上流への接続を解決してください。そのために「LANからの接続を許可」を有効にしたり、待ち受けアドレスを0.0.0.0に変更したりしないでください。待ち受け範囲の拡大とループバック免除は別の設定です。

コマンドラインでループバック免除を確認・追加・削除する

1. 現在の一覧を記録し、正確なパッケージIDを確認する

スタートメニューでPowerShellを検索し、「管理者として実行」を選びます。別の管理者アカウントの資格情報で昇格した場合、パッケージ検索の対象が別のユーザーになることがあります。まず対象アプリを使うユーザーのセッションでパッケージ情報を確認し、その後、昇格したウィンドウで変更してください。

CheckNetIsolation.exe LoopbackExempt -s

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

-sは、現在の免除一覧を表示するオプションです。追加前に出力を保存するかスクリーンショットを撮っておくと、設定がもともと存在したか確認できます。Get-AppxPackageは既定で現在のユーザーのパッケージを表示します。表示名からパッケージ名を推測すると間違えやすいため、出力のPackageFamilyNameを確認してください。

たとえば、Microsoft Store自体のパッケージIDを調べるには、次のコマンドを実行します。

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

よくある結果では、パッケージファミリー名はMicrosoft.WindowsStore_8wekyb3d8bbweです。これはバージョン番号やアーキテクチャなどを含むPackageFullNameとは異なります。下の-nオプションには、パッケージファミリー名を指定してください。何も表示されない場合は、現在のアカウントにアプリがインストールされているか確認します。表示名をそのままコマンドに入力しないでください。

2. 対象アプリだけに免除を追加する

以下はMicrosoft Store自体を対象にした例です。ストアからダウンロードした他のアプリまで許可されるわけではありません。実際の検索結果が例と一致する場合に限り、そのまま実行してください。他のアプリには、それぞれ取得したパッケージファミリー名を使います。

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s

実行後、一覧に該当するIDが表示されることと、コマンドでエラーが発生していないことを確認します。「アクセスが拒否されました」と表示された場合は、ターミナルが管理者権限で起動しているか確認してください。名前や引数のエラーが出た場合は、パッケージIDと半角の英語引用符を見直します。一覧への追加に成功したら、対象アプリを完全に終了してから再起動し、失敗した接続が再利用されないようにします。

3. 今回追加した免除を取り消す

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s

-dは、指定したアプリの免除を削除します。取り消すのは今回追加した項目だけにしてください。操作前から存在していた項目を、テスト目的で削除してはいけません。すべてのパッケージに一括で許可を与えるスクリプトを実行したり、対象を絞った削除の代わりに一覧全体を消去したりしないでください。既存の開発ツールや他のアプリが、一覧の項目を必要としている場合があります。

GUIで設定：ループバック一覧から対象アプリを選択する

Windowsの「設定」には、UWPのループバック免除を一括設定する共通のチェックボックスはありません。Fiddler Classicがインストールされている場合は、ツールバーのWinConfigからループバック免除ツールを開けます。画面によっては「Tools」→「Win8 Loopback Exemptions」から開くこともできます。メニューにWin8と表示されていても、管理対象はWindowsのAppContainerループバック設定です。

1. まず前述の手順でプロキシポートを確認し、現在のシステムプロキシの値を記録します。
2. Fiddler Classicを開き、「File」→「Capture Traffic」のチェックを外して、キャプチャ用プロキシが今回のテスト通信を横取りしないようにします。
3. WinConfigを開き、表示されたら管理者権限を許可して、アプリコンテナーの一覧が読み込まれるまで待ちます。
4. 調査対象のアプリだけにチェックを入れ、「Save Changes」をクリックして保存します。「Exempt All」で一括許可しないでください。
5. ツールとFiddler Classicを終了し、Windowsのプロキシ設定が引き続きClashクライアントの実際のポートを指していることを確認してから、対象アプリを起動してテストします。

免除を取り消すには、WinConfigを再度開き、今回追加したチェックを外して保存します。GUIツールとコマンドラインは同種のシステム設定を管理します。CheckNetIsolation.exe LoopbackExempt -sを実行すれば、相互に照合できます。このツールがインストールされていないPCでは、Windows標準のコマンドを使えばよく、この手順のためにキャプチャ環境を追加で用意する必要はありません。

動作確認の方法：アプリのリクエスト、ルールのマッチ状況、免除の解除を比較する

免除一覧にアプリ名が表示されても、設定が反映されたことを示すだけで、対象の機能が必ず復旧するわけではありません。同じ失敗操作を使って確認してください。たとえば、ストアのページを更新する、アプリ内のオンラインコンテンツを読み込むなどのテストを行い、同時にクライアントの接続記録も確認します。

1. テスト条件を固定する：同じサブスクリプション、プロキシグループ、ルールモードを維持し、キャプチャツールを終了して、テスト時刻を記録します。
2. 対象アプリを再起動する：必要に応じてタスクマネージャーで関連プロセスを終了し、再度開きます。ウィンドウを閉じただけでは、バックグラウンドプロセスが残ることがあります。
3. 接続を確認する：クライアントの「接続」または「ログ」画面で、対象ドメイン、接続先アドレス、マッチしたルール、出力先のポリシーを確認します。画面の名称はクライアントによって異なります。
4. 機能の結果を確認する：「リクエストがプロキシに到達した」ことと、「ログインやダウンロードに成功した」ことを区別してください。サーバー側の地域制限、アカウントの状態、証明書エラーには、それぞれ別途対処が必要です。
5. 必要に応じて免除を取り消して比較する：今回追加した項目だけを削除して同じ操作を再試行し、テスト後は必要に応じて設定を戻します。

システムサービスや補助プロセスが接続を開始する場合もあるため、プロセス名だけで絞り込まないでください。また、アプリがキャッシュからページを表示することもあります。1回「開けた」だけでは十分な証拠になりません。時刻、対象ドメイン、ルールのマッチ状況を合わせて確認する方が、ウィンドウに内容が表示されたかだけを見るより確実です。

通信がmihomoに届いているのにDIRECTにマッチする場合、通常、ループバックはすでに現在の阻害要因ではありません。ルールが順番どおりに評価された結果、ルールセットの更新状況、プロキシグループで期待するポリシーが選ばれているかを確認してください。ルールモードでも、すべての通信がプロキシ経由になるとは限りません。免除を追加しても、この動作は変わりません。

それでも解決しない場合の確認手順

免除一覧に表示されるのに、クライアントに接続が表示されない

まず、免除の対象が、実際にネットワークリクエストを開始するパッケージであることを確認してください。名前が似たランチャーではないかも確認します。次に、アプリがWindowsのシステムプロキシに従うか、独自のプロキシ設定があるか、再起動済みかを確認してください。システムプロキシを使わないアプリの場合、ループバック免除だけではプロキシ経路は作られません。現在の設定を残したうえで、TUNによる通信の取り込みを個別にテストできます。

クライアントに接続が表示されるのに、アプリの機能が失敗する

まず、マッチしたポリシーと接続エラーを確認し、DNSの名前解決失敗、上流へのタイムアウト、TLSエラー、HTTPエラーレスポンスを切り分けます。アプリのダウンロードでは複数のドメインに接続することがあり、トップページが表示されても、コンテンツ配信先が同じポリシーで接続されるとは限りません。実際に失敗している通信を対象に調整し、すべてのドメインに同じ出力先を設定しないでください。

アプリの更新後や再インストール後に、再び失敗する

通常のバージョンアップでパッケージファミリー名が変わることはあまりありません。ただし、配布元の変更、プレビュー版のインストール、Windowsアカウントの移行後は、実際のパッケージIDが異なる場合があります。パッケージ情報と-sを再度確認し、現在の環境に合わせてください。企業のデバイスがポリシーで管理されている場合は、管理者に制限を確認してください。対象を絞った許可の代わりに、ファイアウォールを無効にしてはいけません。

確認すべき順序は、ローカルプロキシが利用可能 → アプリがその接続先を実際に使用 → 必要なループバック権限が許可済み → 接続が想定したルールにマッチ → アプリのリクエストが成功です。この順序で確認すれば、Windowsのコンテナー制限、クライアントの設定、リモートサービスの問題を切り分けられます。