Windowsストアアプリがプロキシに接続できない？CheckNetIsolationでUWPのループバック制限を解除

1. ブラウザーは接続できるのにストアアプリは失敗する：まずループバック制限を確認

Windows 10またはWindows 11でClash Metaのシステムプロキシを有効にすると、ブラウザーではサイトを開けるのに、特定のアプリではネットワークに接続できないことがあります。原因の一つとして、AppContainerによるネットワーク分離が考えられます。分離されたアプリは、通常のデスクトップアプリとは異なり、既定ではローカルのループバックアドレス上で動作するサービスに直接接続できません。

プロキシアドレスとしてよく使われるのは 127.0.0.1:7890 です。127.0.0.1 はこのPCを指し、7890 は例示用のポート番号です。すべてのクライアントで共通の固定値ではありません。アプリがシステムプロキシを読み込んでいても、このローカル待ち受けポートへの接続を禁止されると、リクエストはmihomoコアに届く前に失敗することがあります。

まず3つの項目を確認

通常のブラウザーで接続できるか：同じ接続先を開き、ノード、サブスクリプション、基本的なネットワークが使えることを確認します。
プロキシの待ち受けポートが正しいか：クライアントの設定または現在有効な設定で、HTTPポートや混合ポートを確認します。外部コントローラー用のポートをプロキシポートと取り違えないでください。
アプリのリクエストがコアに届いているか：クライアントの接続一覧やログを開き、アプリから再度リクエストします。記録がまったくない場合は、通信の取り込み経路を確認する必要があります。ただし、それだけでループバック制限が原因とは断定できません。

ループバックの例外設定で解決できるのは、アプリがローカルサービスへアクセスする権限の問題だけです。期限切れのサブスクリプション、無効なノード、リモートサーバーの障害は解決できません。また、もともとシステムプロキシを無視するアプリが、HTTPプロキシを使うようになるわけでもありません。

2. システムプロキシとmihomoの待ち受けポートを確認

Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」を開きます。Windows 11では通常、「プロキシサーバーを使う」の横にある「編集」をクリックします。アドレスとポートが現在のクライアントの設定と一致しているか確認してください。ローカルのmihomoを使う場合、よくある組み合わせはアドレスが 127.0.0.1、ポートが 7890 です。

Clash Metaの設定では、mixed-port がHTTPとSOCKSの両方のプロキシ接続を受け付けます。以下は待ち受け設定の一部です。サブスクリプションファイル全体を置き換えず、既存の設定に統合してください。

config.yaml · ローカル待ち受け設定

mixed-port: 7890
allow-lan: false
mode: rule

クライアントの上書き機能によって、最終的な設定が生成される場合があります。読み込まれていないYAMLを変更するのではなく、実際に有効な値を確認してください。UWPアプリからローカルプロキシに接続するために、LANアクセスを有効にする必要はありません。トラブル対処のために待ち受けアドレスを全ネットワークインターフェイスに変更するのも避けてください。

PowerShellでローカルポートを確認

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

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

1つ目のコマンドでTCPの待ち受けを確認し、2つ目のコマンドで通常のデスクトップアプリからプロキシを明示的に使用します。ポートは実際の値に置き換えてください。HTTPレスポンスが返れば、その時点でプロキシ経路が応答したことは確認できますが、分離されたアプリにループバックへのアクセス権があることまでは証明できません。接続拒否の場合は、まずコアが起動しているか、ポートが競合していないかを確認します。タイムアウトする場合は、ノード、ルール、接続先サイトを調べてください。

netsh winhttp show proxy の結果だけで、Windowsの設定画面に表示される設定を判断しないでください。WinHTTPプロキシとユーザー単位のシステムプロキシは別の設定です。また、アプリによって使用するネットワークインターフェイスが異なる場合があります。

3. CheckNetIsolationで特定のアプリにループバックの例外を追加

CheckNetIsolation.exe は、Windowsに付属するネットワーク分離の診断ツールです。ループバックの例外を追加または削除するときは、管理者としてWindows TerminalまたはPowerShellを開いてください。必要なアプリに限って操作し、最初に現在の一覧を保存してから、対象のパッケージだけを追加することをおすすめします。

手順1：現在の例外とアプリのパッケージ名を確認

CheckNetIsolation.exe LoopbackExempt -s

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

2つ目のコマンドは、既定で現在のユーザーのアプリパッケージを一覧表示します。対象アプリを見つけたら、表示名、インストール先、バージョン番号付きの PackageFullName ではなく、PackageFamilyName を使います。アプリが多い場合は、名前の一部で絞り込めます。以下はMicrosoft Storeのパッケージを例にしていますが、ネットワークの問題を解決するために、常にStore自体へ例外を追加すべきという意味ではありません。

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

管理者権限のターミナルで別のアカウントを使っている場合、パッケージ一覧が普段使っているアカウントと異なることがあります。その場合は対象ユーザーのセッションに戻り、パッケージの情報を確認してください。パッケージが見つからないからといって、インストール済みのすべてのアプリに権限を付与しないでください。

手順2：対象のパッケージだけに例外を追加

次のPowerShellコマンドは、現在のユーザーにインストールされているMicrosoft Storeのパッケージを取得し、実際のパッケージファミリー名をシステムツールに渡します。他のアプリを対象にする場合は、前の一覧で正確な Name を確認してから、検索条件を変更してください。

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -eq $app) {
  throw "現在のユーザーにMicrosoft.WindowsStoreパッケージが見つかりません。ユーザーとパッケージ名を確認してください。"
}

CheckNetIsolation.exe LoopbackExempt -a "-n=$($app.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

出力に対象のパッケージが表示されたことを確認したら、対象アプリを完全に終了して再起動します。ウィンドウを閉じただけではバックグラウンドプロセスが残ることがあります。タスクマネージャーで対象アプリが終了しているか確認できますが、システムの重要なプロセスは終了しないでください。アプリから再度リクエストを送り、Clash Metaの接続一覧を確認します。

手順3：効果を確認し、元に戻す方法も把握

アプリがネットワークに接続できるようになり、mihomoのログに該当する接続が表示されれば、この通信経路は確立できています。それでも失敗する場合は、同じ例外を繰り返し追加しないでください。アプリがシステムプロキシを読み込んでいるか、独立したバックグラウンドコンポーネントがあるか、プロキシルールで接続先ドメインに想定したポリシーグループが割り当てられているかを確認します。

$app = Get-AppxPackage -Name Microsoft.WindowsStore

if ($null -ne $app) {
  CheckNetIsolation.exe LoopbackExempt -d "-n=$($app.PackageFamilyName)"
}

CheckNetIsolation.exe LoopbackExempt -s

上記のコマンドで、このパッケージの例外を削除できます。ループバックの許可によってアプリがローカルサービスへアクセスできるようになりますが、対象はClashのポートだけではありません。テストで効果がなかった場合や、アプリを使わなくなった場合は、該当する設定を削除してください。他のツールの設定に影響するおそれがあるため、個別の例外を削除する代わりに一覧全体を消去しないでください。

4. GUIで設定する：AppContainerのループバック例外ツール

Fiddler Classicがインストールされている場合は、WinConfigからAppContainer Loopback Exemption Utilityを開けます。ここで説明するのはFiddler Classicのツールであり、Fiddler Everywhereではありません。ボタンの位置はバージョンによって異なる場合があります。

Fiddler Classicを開き、ツールバーのWinConfigをクリックして、画面の指示に従って管理者権限を許可します。
AppContainerの一覧から対象アプリを探し、表示名が似ているだけで判断せず、パッケージの情報を確認します。
対象の項目にチェックを入れ、Save Changesをクリックして保存します。その後、対象アプリを完全に終了して再起動してください。
管理者権限のターミナルに戻り、CheckNetIsolation.exe LoopbackExempt -s を実行して、システムに登録された内容を確認します。

GUIツールもコマンドラインも、最終的には同じ種類のシステム例外設定を変更します。両方を実行する必要はありません。また、手間を省くためにすべてのアプリを選択するのも避けてください。出所の不明な「ワンクリック修復」スクリプトは、ファイアウォール、DNS、プロキシ設定まで同時に変更する可能性があります。トラブル対処では、複数の条件を一度に変更しないようにしましょう。

5. ループバックの例外とTUNモード：通信経路に合わせて選ぶ

システムプロキシでは、アプリがプロキシのインターフェイスを自分で使う必要があります。ループバックの例外を設定すると、分離されたアプリがローカルのプロキシポートに接続できるようになります。一方、TUNモードは仮想ネットワークインターフェイスとルーティングで通信を取り込むため、通常はアプリが 127.0.0.1:7890 に接続する必要がありません。そのため、システムプロキシを無視するアプリではTUNを試す価値があります。ただし、TUNは「より強力なループバック例外」ではありません。

方式	適したケース	主な制約
システムプロキシ	アプリがユーザーのプロキシ設定に対応し、それを読み込む	すべてのアプリやUDP通信を取り込めるとは限らない
システムプロキシ＋ループバックの例外	分離されたアプリがローカルプロキシに接続する必要がある	アクセス権を追加するだけで、アプリにプロキシの使用を強制するものではない
mihomo TUN	アプリがシステムプロキシを無視する場合や、IP通信を取り込む必要がある場合	権限、ルーティング、DNSの連携が必要で、他のVPNと競合することがある

TUNの設定例と有効化の条件

まず、使用中のWindowsクライアントにあるTUN設定から有効にし、案内に従ってサービスのインストールや管理者権限の付与を行ってください。メニュー名はクライアントによって異なります。手動で設定する場合は、以下のmihomo用TUN設定を使用できます。既存のノード、プロキシグループ、ルール、DNS設定はそのまま残してください。

config.yaml · TUN設定

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns-hijack は、mihomoのDNS機能が有効で正常に動作していることを前提とします。DNS設定全体を構成するものではなく、あらゆる暗号化DNSを捕捉できるわけでもありません。auto-route は通信を取り込むルートを自動設定し、auto-detect-interface は外向きのインターフェイスを識別します。複数のネットワークアダプター、企業VPN、仮想マシンのネットワークが共存する環境では、自動選択が想定どおりにならないことがあるため、個別に確認してください。

効果を切り分けるには、システムプロキシを一時的に無効にし、TUNだけを有効にして比較テストを行うと、リクエストが古いローカルプロキシ経路を使うのを避けられます。テスト前に元の設定を記録し、終了後に必要な設定へ戻してください。複数のプロキシソフトのTUNやVPNによる通信取り込みを同時に有効にしないでください。また、ネットワーク確認のためにファイアウォール全体を無効にするのも避けてください。

6. 例外を追加しても解決しない場合：接続記録から原因を調べる

コアにアプリの接続が表示されない

まず、アプリを完全に再起動したか、実際にネットワークリクエストを送信するパッケージに例外を追加したかを確認します。ログイン、メディア再生、更新などを別プロセスで処理するアプリもあり、メイン画面のパッケージに例外を追加しても、関連コンポーネントには適用されない場合があります。アプリがもともとシステムプロキシを使わないなら、ループバックアドレスを変え続けずにTUNを試してください。

接続はコアに届くが、DIRECTまたは誤ったプロキシグループに割り当てられる

mode: rule が有効か確認し、接続に適用されたルールを調べます。Clash Metaのrulesは上から順に照合され、先にあるルールが後のルールより優先されます。特定のアプリを再び接続させるために、グローバルモードへ恒久的に切り替えないでください。まず接続先のドメインとポリシーを確認し、サブスクリプションの上書き設定で必要なルールだけを変更します。これにより、次回のサブスクリプション更新でローカルの変更が上書きされるのを防げます。

ログイン、ダウンロード、動画機能だけが失敗する

これらの機能では、異なるドメイン、プロセス、通信プロトコルが使われることがあります。HTTPシステムプロキシで処理できる通信と、アプリがUDPを直接送信する通信は別の経路です。失敗した時刻、接続先アドレス、コアのログを記録し、DNS、ノードの対応状況、ルールを個別に確認してください。ループバックの例外を追加しても、上流ノードが対応するプロトコルは変わりません。

変更は一度に1項目だけ

現在のプロキシポート、システムプロキシの状態、TUNの状態、既存の例外一覧を記録します。
まず通常のデスクトップアプリからローカルプロキシを使い、接続先サイトにアクセスできることを確認します。
対象パッケージだけに例外を追加し、アプリを再起動して接続記録を確認します。
効果がなければ不要な例外を削除し、TUN経路だけを個別にテストします。
解決しない場合はエラーメッセージと適用されたルールを記録します。ログを共有する前に、サブスクリプションURL、アクセストークン、個人情報を削除してください。

修復できたか判断するときは、アプリの機能が復旧したか、通信が想定したコアに届いているか、ルールが想定した経路に適用されているかをあわせて確認します。「例外の追加に成功」と表示されただけでは、プロキシの通信経路全体が正常になったとは限りません。