WindowsストアアプリがClashプロキシを使えない：UWPのループバック制限を解除する方法

まずUWPのループバック制限かどうかを確認する

典型的な症状は、ブラウザー、Git、メッセンジャーはClash経由で通信できるのに、Microsoft Storeだけが「再試行」と表示される、ページ画像が一部しか読み込まれない、またはアプリのダウンロードが「ライセンスを取得しています」のまま長時間進まない、といったものです。同じPCのXbox、フォト、メールなど、一部のストアアプリでも接続に失敗することがあります。このときClashの接続パネルにはブラウザーの通信は表示されても、該当するストアアプリの接続は表示されません。

この違いは、通常ノードの速度が原因ではありません。従来のWin32プログラムはローカルの待受アドレスへ直接接続できますが、AppContainerのネットワーク分離モデルを採用するUWPアプリやストアアプリには、既定でループバックアクセス制限が適用されます。Clashのシステムプロキシは通常、127.0.0.1:7890のようなローカルアドレスを指します。アプリがこのプロキシを使うには、まずローカルのループバックインターフェースへアクセスしなければなりません。Windowsがこの段階で接続を遮断すると、リクエストはClashに到達せず、接続履歴にも表示されません。

3つの簡単な確認ポイント

Clashが起動しており、現在の設定に少なくとも1つ利用可能なノードがあり、ブラウザーでウェブページを正常に開ける。
クライアントでシステムプロキシが有効になっており、Windowsのプロキシアドレスが127.0.0.1を指し、ポートがClashの実際の待受ポートと一致している。
Microsoft Storeの更新に失敗したとき、Clashの「接続」または「ログ」画面に該当する新しいリクエストが追加されない。

3つすべてに当てはまる場合は、Loopback Exempt、つまり指定したアプリにローカルループバックアクセスの例外を追加する処理へ進めます。これはAppContainerがローカルアドレスへ接続できるかどうかだけを変更するもので、プロキシルールの代わりになったり、ノードを自動選択したりするものではありません。最終的な通信は、Clashで現在選択しているルールモード、プロキシグループ、DNS設定によって決まります。

ループバック制限でClashのローカルポートが遮断される理由

Windowsストアアプリは通常、アプリIDを持つ分離コンテナー内で動作します。システムはアプリパッケージのIDに基づいてネットワーク権限を割り当て、コンテナーがローカルのループバックアドレスへ直接アクセスするのを制限します。これはアプリとローカルサービスを分離し、127.0.0.1上で動作するポートをアプリが無制限に探査するのを防ぐための設計です。

ClashのHTTP、SOCKS、またはmixed-portのリスナーは、まさにこのローカルサービスに当たります。一般的な設定では混合ポートに7890を指定します。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

システムプロキシを有効にすると、Windowsはシステムプロキシに対応したリクエストを127.0.0.1:7890へ渡します。通常のデスクトップアプリはこのローカル接続を確立できますが、制限されたAppContainerではポートに到達する前にシステムによって拒否されることがあります。そのため、ノードの遅延がわずか45 msでもMicrosoft Storeが読み込めず、Clashのログにも完全なプロキシハンドシェイクが一度も記録されない場合があります。

確認箇所	正常な結果	異常の意味
ブラウザーの通信	ウェブページが正常に開く	Clashの基本経路に問題が残っている
ローカルの待受ポート	127.0.0.1:7890が待ち受け中	ポート設定またはクライアントの起動に問題がある
Clashの接続パネル	ストアの更新時に新しい接続が表示される	記録がまったくない場合はループバック制限を優先して確認する
ルールの適用結果	リクエストが指定したプロキシグループに入る	Clash到達後に失敗する場合はルール、DNS、ノードを確認する

ループバック例外が解決するのは、「アプリがローカルプロキシへ接続できるか」という区間です。サブスクリプションの期限切れ、プロキシグループの選択ミス、ルールの誤判定、リモートノードのタイムアウトには対応しません。トラブルシューティングでは経路を「アプリ → ローカルのClashポート → プロキシルール → ノード → 目的のサービス」に分けて考えると、ノードを何度も変更しても本当の遮断箇所に届かない、といった事態を避けられます。

Clashクライアント内蔵のUWP Loopbackツールを使う

一部のWindows向けGUIクライアントには、UWP Loopbackを管理する入口があります。内部ではWindowsのループバック例外機能が呼び出されます。クライアントやバージョンによってメニュー名は多少異なりますが、「設定」→「システム設定」→「UWP Loopback」、または「一般」→「UWPループバック」→「ツールを起動」といった経路が一般的です。旧版のClash for Windowsでは、入口がGeneralページに配置され、ボタン名がUWP Loopbackと表示されることがあります。

GUIでの操作手順

まずMicrosoft Store、Xboxなど、対象にするアプリを終了し、古い接続が残らないようにします。
Clashクライアントを開き、システムプロキシが有効であることを確認します。「設定」→「ポート設定」にあるmixed-portまたはHTTPポートを控えておきます。
「設定」→「システム設定」→「UWP Loopback」を開きます。クライアントから管理者権限を求められた場合は、確認して続行します。
ツールがアプリパッケージを列挙するまで待ち、一覧からMicrosoft Storeを探します。パッケージIDには通常Microsoft.WindowsStoreが含まれます。
Microsoft Storeにチェックを入れます。Xbox、フォト、その他のストアアプリにも同じ問題がある場合は、必要に応じてそれぞれ選択します。
「保存」「適用」、または「Save Changes」をクリックし、ツールに設定完了の表示が出るまで待ちます。
Microsoft Storeを再起動し、任意のアプリ詳細ページを開いて更新します。その後、Clashの接続パネルを確認します。

アプリ一覧には、表示名が似た項目が同時に表示されることがあります。判断する際はアイコンだけでなく、パッケージ名やPackage Family Nameを優先して確認してください。Microsoft Storeでよく見られるパッケージファミリ名はMicrosoft.WindowsStore_8wekyb3d8bbwe、Windowsアプリインストーラーは通常Microsoft.DesktopAppInstaller_8wekyb3d8bbweです。用途が異なるため、問題のある方だけを許可します。

保存後、通常はWindowsを再起動する必要はありません。ただし対象アプリは完全に終了してから再度開いてください。Microsoft Storeに古い状態が残る場合は、タスクマネージャーで該当プロセスを終了してからもう一度起動します。Win + Rを押してwsreset.exeを実行し、ストアのキャッシュを消去する方法もあります。この手順はキャッシュや画面状態を処理するもので、ループバック例外の追加は行いません。

クライアントに入口がない場合はコマンドラインで手動許可する

Windows標準のCheckNetIsolation.exeを使うと、AppContainerのループバック例外を確認、追加、削除できます。手動操作で重要なのは正確なPackage Family Nameを取得することです。アプリの表示名だけをコマンドに指定してはいけません。

手順1：Microsoft Storeのパッケージファミリ名を確認する

管理者としてPowerShellを開き、次を実行します。

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

出力例は次のとおりです。実際の結果は使用中のPCで確認してください。

Name              PackageFamilyName
----              -----------------
Microsoft.WindowsStore Microsoft.WindowsStore_8wekyb3d8bbwe

名前にXboxを含むアプリを検索する場合は、次を使用できます。

Get-AppxPackage *Xbox* |
  Select-Object Name, PackageFamilyName

手順2：ループバック例外を追加する

パッケージファミリ名を確認したら、管理者権限のターミナルで次を実行します。

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

-aは追加を表し、-nの後ろには完全なPackage Family Nameを指定する必要があります。コマンドが正常に完了したら、Microsoft Storeを終了して再度開き、動作を確認します。

手順3：現在の例外一覧を確認する

CheckNetIsolation.exe LoopbackExempt -s

出力一覧に、先ほど追加したパッケージIDが表示されているはずです。対象項目がない場合は、ターミナルの権限不足、パッケージファミリ名の入力ミス、またはコピー時に余分な空白が入った可能性があります。PowerShellの検索結果からもう一度コピーして、追加コマンドを実行してください。

不要になったら例外を削除する

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

-dは削除を表します。変更後にもう一度LoopbackExempt -sを実行すれば、対象項目が削除されたか確認できます。ループバック例外はアプリパッケージID単位で保存されます。アプリの更新では通常パッケージファミリ名は変わりませんが、アンインストール後の再インストール、システム移行、アプリIDの変更があった場合は、一覧を再確認してください。

許可後、Microsoft StoreがClashを経由しているか確認する方法

ストアページが表示されるようになっただけでは、通信経路を判断できません。ページ内容がキャッシュから表示されている可能性があるためです。より確実に確認するには、アプリの動作、Clashの接続履歴、ルールの適用結果を同時に確認します。

確認1：接続パネルを確認する

Clashクライアントの「接続」ページを開き、現在の絞り込み条件をすべて解除します。
Microsoft Storeを完全に終了してから、再度開きます。
これまで開いたことのないアプリ詳細ページを開き、スクリーンショットを切り替えるか、「更新プログラムを確認」をクリックします。
接続パネルに新しいHTTPS接続が表示されるか確認します。対象ドメインは、Microsoftのストア、ライセンス、コンテンツ配信、アカウントサービスなどに属している可能性があります。

リクエストが表示されれば、UWPアプリが少なくともローカルのClashポートへアクセスできたことを示します。次に、その接続にどのルールとプロキシグループが適用されたかを確認します。接続がDIRECTと表示されても、それはルールの結果であり、ループバック例外の失敗を意味しません。特定のドメインをプロキシ経由にしたい場合は、例外を繰り返し追加するのではなく、現在のルールセットを確認してください。

確認2：ポートとシステムプロキシの一致を確認する

PowerShellで、よく使われる7890ポートを確認します。

Get-NetTCPConnection -LocalPort 7890 -State Listen

結果が表示されない場合は、Clashの「設定」→「ポート設定」に戻り、実際のmixed-portを確認します。設定によっては7897、1080など、別のポートを使用します。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、アドレスとポートがクライアントの現在の待受値と一致している必要があります。ポート競合によってClashが別の値へ変更された場合、古いシステムプロキシ設定がストア接続の失敗を招くこともあります。

確認3：再現可能なストア操作を行う

Microsoft Storeの「ライブラリ」ページを開き、「更新プログラムを取得」をクリックします。
サイズの小さいアプリを1つ選び、ダウンロードが「保留中」から実際の進捗に変わるか確認します。
Clashのログで、連続した接続タイムアウトやDNSエラーが発生していないことを確認します。
プロキシグループのノードを切り替えてから再度更新し、新しい接続が現在選択しているポリシーを使用しているか確認します。

1回ダウンロードに成功しただけでは、その時点で経路が利用できたことしか分かりません。2回続けてテストし、Microsoft Storeを終了して再起動した後にも、もう一度確認することをおすすめします。これにより、キャッシュ、確立済み接続、一時的なネットワーク回復による誤判定を排除できます。

接続できない場合は決められた順番で確認する

ループバック例外を追加すると、問題の位置は通常「アプリがローカルポートへアクセスできない」段階から、Clash内部または上流ネットワークへ移ります。この時点で同じアプリを何度も選択せず、次の順番で層ごとに確認してください。

1. 設定とポートが有効になっていることを確認する

Clashクライアントの状態が実行中で、設定ファイルが正常に読み込まれていることを確認します。
システムプロキシのアドレスは127.0.0.1で、ポートはmixed-portまたはHTTPポートと一致している必要があります。
設定でSOCKSポートだけを有効にしている場合、そのポートをWindowsのHTTPシステムプロキシとして直接使用してはいけません。
YAMLを変更したら、まずインデントを確認し、クライアントで設定を再読み込みします。

2. ルールモードとプロキシグループを確認する

ルールモードでは対象ドメインを1つずつ照合します。Microsoft Storeはアカウント、ライセンス、アプリのメタデータ、コンテンツ配信など複数のサービスを利用するため、1つのドメインだけで全体の結果を判断できません。接続パネルにリクエストが表示されたら、Rule、Chains、プロキシグループの項目を重点的に確認します。ルールによって一部のサービスが利用できないノードへ送られると、ストアの画像は表示されてもダウンロードだけ失敗することがあります。

一時的な診断では、対象のプロキシグループを、利用可能と確認済みで遅延が約50～150 msのノードへ切り替えてから、ストアの更新を再試行できます。グローバルモードは短時間の比較に使えますが、テスト後は普段使うルールモードへ戻し、具体的なルールの特定を続けてください。

3. DNSを確認する

接続がすでにClashへ到達しているのに、ログに名前解決の失敗、タイムアウト、異常なアドレスが表示される場合は、DNS設定を確認します。mihomoカーネルを使用している場合は、設定内のdns.enable、待受アドレス、nameserver、拡張モードの組み合わせを確認してください。Fake-IPを有効にしている場合は、システムの通信が実際にClashで処理されていることも確認します。アプリが別のDNS経路を使うと、名前解決と接続先が一致しなくなることがあります。

4. ファイアウォールとセキュリティポリシーを確認する

ローカルファイアウォールによってClashの待受ポートが遮断されたり、アプリコンテナーのネットワークが制限されたりすることがあります。まず、Clash本体と使用中のカーネルが現在のネットワークプロファイルで動作できることを確認し、127.0.0.1:7890または該当プロセスを対象とするブロックルールがないか確認します。会社のPCでは、グループポリシーによってMicrosoft Store、プロキシ、AppContainerのネットワーク権限が管理されている場合があり、その場合はローカルの変更がポリシーで上書きされることがあります。

5. システムプロキシとTUNモードを区別する

システムプロキシモードは、アプリがWindowsのプロキシ設定を読み取ることを前提としているため、UWPのループバック例外とローカルプロキシポートが直接関係します。一方、TUNモードは仮想ネットワークインターフェースを通じて、より多くの通信を取り込みます。システムプロキシに従わないプログラムには、こちらの方が有効です。mihomoのTUNを有効にすると、一部のストアアプリは従来の127.0.0.1 HTTPプロキシ経路に依存しなくなる場合があります。

ただし、TUNはループバック問題を一般的に置き換える手順ではありません。管理者権限、サービスモード、ルーティング、DNSの横取り、ファイアウォールとの互換性も関係します。Microsoft Storeだけに問題があり、他のプログラムがシステムプロキシ経由で安定して動作しているなら、まず対象アプリにLoopback Exemptを追加してください。変更範囲が小さいためです。複数種類のプログラムがシステムプロキシに従わない場合や、UDPなどの通信も取り込みたい場合に、TUNモードを検討します。

よくある誤解と対処の結論

システムプロキシを有効にすればUWP制限も自動で解除される

システムプロキシは、プロキシサーバーの場所をアプリに知らせるだけです。AppContainerがそのローカルアドレスへアクセスできるかどうかは、ループバックポリシーが別途決定します。両方を個別に確認する必要があります。

ポートに7890と入力すれば必ず正しい

7890は一般的な既定値であり、固定の要件ではありません。設定ファイル、クライアントの上書き設定、ポートの使用状況によって実際の待受値は変わります。現在のクライアント画面と待受状態を基準にしてください。

Microsoft Storeを許可すれば、すべてのストアアプリが対象になる

例外はパッケージファミリ名単位で記録されます。Microsoft Store、アプリインストーラー、Xbox、その他のアプリは通常それぞれ異なるアプリIDを持つため、実際の障害に応じて個別に確認し、追加する必要があります。

接続がClashに入れば、プロキシ経路全体が正常に使える

接続が表示されるのは、アプリがローカルプロキシに到達したことを示すだけです。その後もルールの適用、DNS、ノードとのハンドシェイク、リモートサービスの制限、ネットワークポリシーによって失敗する可能性があります。次の対応を判断するには、ログでどの段階にエラーが出ているかを確認してください。

最終的には、次の簡単な基準で判断できます。通常のデスクトップアプリは正常なのにストアアプリのClash接続記録がまったくない場合は、UWPのループバック例外を確認します。接続記録はあるのにリクエストが失敗する場合は、ポート、ルール、DNS、ノードを調べます。複数のプログラムが同時に異常なら、Clashの基本経路とローカルネットワークに戻って確認します。この順番で進めれば、問題を通常は明確な層まで絞り込めます。