WindowsストアアプリがClashを経由しない場合の対処法｜UWPのループバック制限を解除

システムプロキシ、アプリのサンドボックス、プロキシルールを切り分ける

ブラウザーではClash経由で通信できるのに、Microsoft Storeアプリの一つだけ接続エラーが続く場合、UWPのループバック制限が原因かもしれません。典型的な状況は、クライアントでシステムプロキシが有効になっており、プロキシサーバーが 127.0.0.1:7890 に設定され、対象アプリが制限付きのAppContainerサンドボックスで動作しているケースです。アプリがローカルプロキシへ接続しようとした時点で、リクエストがClashのコアに届く前に、Windowsのネットワーク分離ポリシーによって遮断されます。

UWPはUniversal Windows Platform（ユニバーサルWindowsプラットフォーム）、AppContainerはWindowsのアプリ分離機能です。ループバックアドレスは現在のコンピューターを指し、IPv4の 127.0.0.1 やIPv6の ::1 が該当します。ループバック例外を設定すると、指定したアプリコンテナーからローカルのネットワークサービスへ接続できます。Windowsファイアウォール全体を無効にする設定ではありません。

Microsoft Storeからインストールしたからといって、必ずUWPアプリとは限りません。ストアでは通常のWin32デスクトップアプリや、パッケージ化されたデスクトップアプリも配布されています。アプリのパッケージ、実行方式、接続ログを確認して判断しましょう。「ストアアプリがネットにつながらない」問題をすべてループバック制限のせいにすることはできません。

3つの仕組みで解決できる問題

システムプロキシ：Windowsのプロキシ設定を参照するアプリにHTTPプロキシのアドレスを提供します。すべてのプログラムのTCP・UDP通信を自動的に中継するものではありません。
ループバック例外：指定したアプリコンテナーからローカルプロキシへの接続を許可します。アプリ自体がそのプロキシ設定を使う必要があります。
ルールモード：通信がClashまたはmihomoのコアに届いた後、rulesに従って直接接続するかプロキシ経由にするかを決定します。コアに届く前にサンドボックスで遮断されたリクエストは修復できません。

ブラウザーで正常に通信できても、プロキシ経路の一つが使えると分かるだけで、対象アプリが同じローカルポートへ接続できるとは限りません。逆に、アプリがクライアントの接続一覧に表示されても、必ずリモートノード経由とは限りません。適用されたルールと最終的な出口も確認してください。

事前確認：ポート、システムプロキシ、接続ログ

まず、クライアントが使用しているローカルの待ち受けポートを確認します。ここでは mixed-port: 7890 を例にします。これはHTTPとSOCKS5で共通のポートです。実際の設定が 7897 なら、以降のアドレスや確認コマンドにはその値を使ってください。外部コントローラーのポートをプロキシポートと取り違えないようにしましょう。また、ローカルアプリからのアクセスのために、最初から allow-lan を有効にする必要はありません。

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシセットアップ」のアドレスとポートを確認します。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」→「プロキシサーバーを使う」を確認してください。PAC自動構成スクリプトを使っている場合は、手動プロキシを重ねて設定するのではなく、スクリプトが返すプロキシアドレスを確認します。
クライアントのコアが起動していること、選択中のノードが利用可能なことを確認し、ルールモードとグローバルモードのどちらを使っているか記録します。
クライアントの接続一覧またはログを開き、対象アプリでコンテンツを更新するなど、明確なネットワーク操作を一度行います。「接続記録がない」場合と「接続は記録されたが失敗した」場合を区別してください。
通信を中継する方法は一つに絞ってください。システムプロキシを調べるときは、どの経路が有効なのか分からなくならないよう、現在の設定を記録してからTUNを無効にします。

PowerShellでポートの待ち受け状態を確認し、HTTPプロキシへの接続を直接テストできます。2つ目のコマンドは、例示したサイトのレスポンスヘッダーを取得してポートと基本的なプロキシ経路を確認するものです。対象アプリにループバック接続権限が付与されたことを示すものではありません。

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

ポートが待ち受けていない場合は、まずクライアントの起動または設定の問題を解決してください。プロキシを明示したリクエストも失敗する場合は、ノード、認証、ルールを確認します。この段階でアプリ例外を何度も追加しても、待ち受けていないポートが使えるようにはなりません。

方法1：CheckNetIsolationで特定のアプリに例外を追加

CheckNetIsolation.exeはWindows標準のネットワーク分離管理ツールです。ローカルプロキシが本当に必要なアプリだけに例外を設定し、変更前に現在の一覧を保存しておきましょう。以下のコマンドは管理者として起動したPowerShellで実行します。アプリパッケージの検索は通常、現在ログインしているユーザーが対象です。別の管理者アカウントで昇格している場合、検索結果に元のユーザーのアプリが含まれないことがあります。

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

CheckNetIsolation.exe LoopbackExempt -s

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

-sは現在の例外一覧を表示します。PackageFamilyName（パッケージファミリー名）は、通常、パッケージ名と発行元の識別子から構成されます。バージョンやアーキテクチャなどを含むPackageFullNameとは異なります。-nに渡すのはパッケージファミリー名です。アプリの表示名をそのまま使わないでください。

手順2：対象パッケージを特定して例外を追加

以下では、パッケージ名がMicrosoft.WindowsStoreのMicrosoft Store本体を例に説明します。別のアプリで問題が起きている場合は、まず前の手順で一覧のNameを確認し、検索条件を置き換えてください。ストアからダウンロードしたアプリだからといって、Store本体だけに例外を設定しても解決しません。

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

if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
} else {
    Write-Warning "対象のアプリパッケージを1つに特定できません。ユーザーとアプリパッケージ名を確認してください。"
}

CheckNetIsolation.exe LoopbackExempt -s

-aは追加を意味し、-n=の直後にはパッケージファミリー名を指定します。コマンドの成功後、-sで該当する項目が追加されたことを確認します。続いて、バックグラウンドに残っているプロセスも含め、対象アプリを完全に終了してから再起動し、ネットワーク操作を行います。ウィンドウを最小化しただけでは不十分です。

手順3：必要に応じて個別の例外を取り消す

ローカルサービスへのアクセスが不要になったら、同じアプリパッケージ変数を使って該当する項目を削除できます。以下のコマンドは他のアプリの設定を保持します。一つのアプリの例外を取り消すために、例外一覧全体を消去しないでください。

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($pkg.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

アクセス拒否と表示される：PowerShellを管理者として起動しているか、デバイスが組織のポリシーで管理されていないか確認してください。
検索結果が空：パッケージ名のスペル、現在のユーザー、アプリのインストール状態を確認してください。通常のデスクトップアプリであれば、この方法で検索できない場合があります。
追加に成功しても接続できない：アプリがシステムプロキシを使っているか、通信が実際にコアへ届いているかを確認してください。成功メッセージだけでネットワークが復旧したと判断しないでください。

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

一部のWindowsクライアントには、UWPのループバック例外を設定するツールがあります。画面上では「UWP Loopback」「Loopback」「アプリコンテナーの例外」などと表示される場合があります。設定画面の場所はクライアントやバージョンによって異なるため、現在のバージョンの設定画面や説明を確認してください。他のクライアントのメニュー手順をそのまま当てはめることはできません。

クライアントの設定からループバック関連のツールを探し、画面の指示に従って管理者権限を許可します。使用中のクライアントにこの機能がない場合は、前述のWindows標準コマンドを使ってください。
一覧で対象アプリの名前とパッケージ識別子を確認し、ローカルプロキシ経由の通信が必要なアプリだけを選択して、保存または適用します。
対象アプリを終了して再起動し、クライアントに新しい接続が記録されるか確認します。
必要に応じて CheckNetIsolation.exe LoopbackExempt -s を実行し、Windows側に例外が実際に登録されたか確認してください。

この種のツールは、通常、同じWindows設定をGUIで操作できるようにしたものです。ノードを追加したり、サブスクリプションを修復したり、ルールを変更したりする機能ではありません。プロセス名だけが表示され、対象のアプリパッケージが明確に示されない場合は慎重に確認し、関係のないアプリまで許可しないようにしてください。

アプリごとの許可を優先してください。すべてのアプリを選ぶと、ローカルサービスにアクセスできる範囲が広がり、その後の原因調査も難しくなります。アプリの再インストールなどでパッケージの識別情報が変わった場合は、以前の例外が使えると決めつけず、一覧を確認し直してください。

方法3：mihomo TUNでアプリの通信を中継する

対象プログラムがシステムプロキシを参照しない場合、ループバック例外を追加しても127.0.0.1:7890を使うよう強制することはできません。その場合はTUNモードを検討できます。仮想ネットワークインターフェイスとルーティングを使い、本来はリモートへ直接送られる通信をmihomoに渡し、ルールに従って出口を決めます。mihomoはClash Metaの開発を引き継ぐコアですが、クライアントがTUNに対応しているかは、内蔵コアとシステムサービスにも左右されます。

WindowsでTUNを有効にするには、通常、管理者権限またはクライアントが事前にインストールして起動したサービスが必要です。まずはクライアント内の設定スイッチを使い、インターフェイスの作成、ルートの設定、DNS処理の開始が成功したか確認してください。既存の設定内容を把握せずに、サブスクリプション全体を置き換えないでください。

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

これはmihomoのTUN設定例であり、単独で動作する完全な設定ではありません。auto-routeはルートの設定に使い、auto-detect-interfaceは出口インターフェイスの自動検出に使います。dns-hijackは、対象となる通常のDNSリクエストをコアのDNSモジュールに渡す設定です。別途、有効なdns設定も必要です。ここで指定するany:53は、すべてのDoHやDoTなどの暗号化DNSを捕捉するという意味ではありません。

TUNのテストでは、元のループバック制限に再びぶつからないようにする

アプリが引き続きシステムプロキシを使ってローカルのループバックアドレスへ接続する場合、TUNを有効にしても、サンドボックスが遮断した接続を回避できるとは限りません。TUNをテストする際は、まず現在のシステムプロキシ設定を記録し、一時的にシステムプロキシを無効にして、アプリが通常の方法でリモートへ接続しようとした通信をTUNに中継させます。その後、アプリを完全に再起動して、実際の接続状況を確認してください。ローカルプロキシを明示的に必要とするアプリには、引き続きループバック例外が必要な場合があります。

通常のWebページと対象アプリの両方で通信できることを確認してから、適用されたルールを確認します。接続があるだけで、意図せず直接接続していないか確認してください。
ほかのVPN、仮想ネットワークアダプター、企業向けセキュリティソフトを同時に使用している場合は、デフォルトルートやインターフェイスの競合を確認してください。複数の全体通信中継方式を一度に有効にしないでください。
ドメイン名の名前解決に失敗する場合は、DNSを個別に調査してください。TUNを有効にしても、すべてのDNS上流へ自動的に接続できるわけではありません。
テスト後は予定していたシステムプロキシの状態に戻し、新しいルートによってローカルネットワーク、プリンター、社内ネットワークに影響が出ていないか確認してください。

3つの対処方法が適するケース

対処方法	適した状況	主な制約
CheckNetIsolationコマンド	アプリコンテナーからローカルプロキシへの接続が必要だと確認できている	アプリにシステムプロキシの使用を強制できない。パッケージファミリー名を正確に特定する必要がある
クライアント内蔵の例外ツール	画面からアプリごとの許可を管理したい	クライアントに設定画面が必要。Windowsの権限やポリシーによる制約も受ける
mihomo TUNモード	アプリがシステムプロキシを使わず、ルーティングによる通信の中継が必要	権限、ルート、DNSの設定が必要。明示的なループバック接続の制限を回避できるとは限らない

問題が一つのアプリだけで起きている場合は、まずパッケージの識別情報と個別の例外を確認しましょう。変更範囲を小さく抑えられます。システムプロキシに従わない複数のプログラムを中継する必要がある場合は、TUNを検討してください。企業管理デバイスでは管理ポリシーを守り、ファイアウォールの無効化やセキュリティポリシーの削除で原因調査を代替しないでください。

例外を設定しても通信できない場合の確認手順

まずコアにリクエストが届いているか確認：記録がない場合は、アプリのプロキシ利用状況、再起動、パッケージの識別情報、TUNのルートを確認します。ログのフィルター条件によって記録が非表示になっている可能性にも注意してください。
次に適用されたルールを確認：接続にDIRECTと表示される場合、現在のルールでは直接接続が選ばれています。例外を追加し続けるのではなく、対象ドメインとルールの順序を確認してください。
次に出口とプロトコルを確認：ログイン、画像、メディアコンテンツでは異なるドメインが使われる場合があります。機能によってはUDP通信も必要です。ブラウザーでホームページが開けても、アプリが使うすべてのサービスに接続できるとは限りません。
最後にアカウントとネットワークの問題を切り分ける：ログイントークンの期限切れ、システム時刻の誤り、サービスの地域制限、サーバー側の障害も、接続エラーの原因になります。そのために出所不明の証明書をインストールしたり、証明書検証を無効にしたりしないでください。

一度に変更するのは一つだけにし、変更前後の状態を記録してください。確認する項目は、ローカルポート、システムプロキシ、例外一覧、TUNの有効・無効、適用ルールです。復旧の判断基準は、コマンドが成功したかどうかではなく、対象アプリが正常に動作し、通信経路が想定どおりであることです。設定のインポートやルールモードを確認したい場合は入門ガイドをご覧ください。必要な通信中継方式に対応するクライアントを選ぶ場合は、プラットフォーム別のダウンロードページをご確認ください。