Windows UWPアプリがClashプロキシを使えないときの対処法：ループバック制限を解除する2つの方法

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

ブラウザーはClash経由で正常に通信できるのに、Microsoft Store、Xbox、一部のメールアプリやストリーミングアプリだけが接続エラーになる場合、ノードの障害ではなく、WindowsのAppContainerネットワーク分離が原因かもしれません。UWPアプリは通常AppContainerサンドボックス内で動作するため、127.0.0.1 や localhost などのローカルループバックアドレスへ、既定では自由に接続できません。

Clash、Clash Meta（現名称はmihomo）と各種GUIクライアントは、通常ローカルホストでプロキシポートを待ち受けます。たとえば混合ポート mixed-port: 7890 は 127.0.0.1:7890 に対応します。システムプロキシを有効にすると通常のデスクトップアプリはこのアドレスへ接続できますが、制限されたストアアプリは接続できないことがあり、「Webページは開くのにストアアプリはオフライン」という差が生じます。

ループバック問題でよく見られる症状

Edge、Firefox、通常のデスクトップアプリはプロキシ経由で外部サイトにアクセスできる。
Microsoft Storeが長時間読み込み中のままになる、またはネットワークに接続できないと表示される。
Xbox、フィードバック Hub、旧版メールなどのパッケージアプリが接続に失敗する。
Clashのシステムプロキシを無効にするとアプリは直接接続できるが、再び有効にすると失敗する。
Clashのログに、そのアプリからの接続記録が見つからない。

まずローカルプロキシポートを確認する

クライアントの「設定」→「ポート設定」または「設定」→「Mihomo設定」を開き、現在使用しているのがHTTP、SOCKS、混合ポートのどれかを確認します。一般的な値は 7890 ですが、実際には 7897、7899、または任意に設定したポートの場合もあります。Windowsのシステムプロキシに設定されたアドレスは、クライアントの待受ポートと一致していなければなりません。

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

mixed-port は、同じポートでHTTPとSOCKSの接続を受け付ける設定です。ここでの allow-lan はLAN上のデバイスからプロキシへ接続できるかどうかを制御するもので、ローカルUWPのループバック権限とは別の設定です。true に変更しても、ループバックの例外設定の代わりにはなりません。

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

GUIクライアントに内蔵されたツールは、一般ユーザーにとって扱いやすい方法です。通常はインストール済みのAppContainerアプリを一覧表示し、選択したアプリに対してWindowsのシステムAPIでループバック例外を登録します。クライアントによってメニュー名は多少異なりますが、基本的な操作は同じです。

よくあるメニューの場所

Clash Verge Rev 2.x：「設定」→「システム設定」を開き、「UWPループバック」または「Loopback」の項目を探します。
クラシックUIのクライアント：「全般」または「General」を開き、「UWP Loopback」の横にある起動ボタンをクリックします。
一部のmihomoクライアント：「設定」→「ネットワーク」を開き、「UWPループバック制限を解除」を探します。

現在使用しているクライアントにこの項目がなくても、mihomoカーネルにプロキシ機能がないという意味ではありません。ループバック例外はWindowsの権限設定であり、通常はGUIまたはシステムコマンドで処理します。プロキシカーネルの設定ファイルに記述する項目ではありません。

具体的な操作手順

Clashクライアントを起動したままにし、システムプロキシが有効になっていることを確認します。
クライアントのUWPループバックツールを開き、アプリ一覧の読み込みが完了するまで待ちます。
プロキシを使用したいアプリ（Microsoft StoreやXboxなど）を探します。
対象アプリにチェックを入れます。すべての項目を一度に選択する必要はありません。
「保存」「適用」または「制限を解除」をクリックします。権限の確認ダイアログが表示されたら実行を許可します。
対象アプリを完全に終了してから、再度起動します。ウィンドウを最小化しただけでは、ネットワークプロセスが再生成されないことがあります。

どのアプリを選択すべきか

必要なアプリだけに権限を付与すると、原因を切り分けやすくなります。まず現在問題が起きているアプリだけにチェックを入れて保存し、すぐに動作を確認します。Microsoft Storeは復旧したのに別のアプリが失敗する場合は、2つ目のパッケージに例外を追加します。どの変更が効果をもたらしたか明確になり、後から取り消すのも簡単です。

対象	推奨操作	確認ポイント
Microsoft Store	該当するストアパッケージを選択	ホーム画面とアプリ詳細を読み込めるか
Xbox	メインアプリと認証コンポーネントを個別に確認	ログイン、ストア、ダウンロードキュー
フィードバック Hub	フィードバック Hubのパッケージだけを選択	アカウント状態とコンテンツ一覧
サードパーティ製ストアアプリ	表示名とパッケージファミリ名で特定	再起動後にClashのログを確認

方法2：CheckNetIsolationで例外を正確に追加する

CheckNetIsolation はWindowsに標準搭載されているコマンドラインツールで、AppContainerのループバック例外を確認、追加、削除できます。クライアントに内蔵機能がない場合、GUIの一覧読み込みに失敗する場合、または変更内容を明確に記録したい場合に適しています。

コマンドで重要になるのがPackage Family Nameです。日本語では「パッケージファミリ名」などと呼ばれ、PFNと略されます。スタートメニューに表示されるアプリ名でも、インストール先のフォルダー名でもありません。パッケージファミリ名を間違えると、対象アプリにコマンドが適用されません。

手順1：アプリのパッケージファミリ名を調べる

スタートメニューを右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を開きます。Microsoft Storeを調べるには、次のコマンドを実行します。

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

出力は通常、次のような構成になります。実際の末尾は発行元識別子によって異なります。

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

内部名が分からない場合は、タイトルのキーワードで全パッケージを絞り込めます。

Get-AppxPackage |
  Where-Object {
    $_.Name -like "*Store*" -or
    $_.PackageFamilyName -like "*Store*"
  } |
  Select-Object Name, PackageFamilyName

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

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

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

LoopbackExempt はループバック例外を管理する機能、-a は追加を示します。-n の後にはパッケージファミリ名を入力します。実行後はMicrosoft Storeを終了し、タスクマネージャーで関連プロセスが終了していることを確認してから再起動します。

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

CheckNetIsolation.exe LoopbackExempt -s

一覧に対象パッケージの名前またはセキュリティ識別子が表示されれば、例外は登録されています。コマンドが成功してもアプリが接続できない場合は、システムプロキシのポート、Clashのログ、ルールのマッチ結果を引き続き確認してください。

例外を取り消す場合は削除する

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

-d は削除を示します。取り消した後はアプリを再起動してください。システム更新やアプリの再インストール後はパッケージ登録情報が変わることがあります。問題が再発した場合は、古いコマンドをそのまま使わず、PackageFamilyNameを改めて確認してください。

アプリの通信が本当にClashへ入っているか確認する

アプリの読み込みが復旧しても、通信が想定どおりプロキシを経由しているとは限りません。一部のリクエストが直接接続されていたり、キャッシュによって正常に見えたりすることがあります。Clashの接続ログ、ルールのマッチ結果、出口IPアドレスを組み合わせて確認するのが確実です。

リアルタイム接続を確認する

Clashのモードを「ルール」モードにします。
クライアントの「接続」または「Connections」ページを開きます。
フィルター条件をすべてクリアし、現在の接続数を記録します。
対象のUWPアプリを完全に終了し、再起動してコンテンツを更新します。
新しいドメイン、宛先IP、プロセス、またはポリシーグループの記録が現れるか確認します。

たとえばMicrosoft Storeを開いた後、接続ページにMicrosoftのサービス関連リクエストが表示され、適用されたルールと最終ポリシーが確認できるはずです。使用されるドメインはWindowsのバージョン、地域、アカウント状態によって変わるため、特定の固定ドメインだけで判断しないでください。

一時的にグローバルモードで切り分ける

ルールモードでも失敗する場合は、一時的に「グローバル」モードへ切り替え、利用可能なノードを1つ選択します。グローバルモードで復旧するなら、ループバック接続は確立しており、問題はルールマッチ、DNS、またはノードへの到達性にある可能性が高いです。テスト後は「ルール」モードに戻し、すべての通信を長時間同じポリシーで処理しないようにします。

3つの結果を比較する

テスト結果	考えられる原因	次の手順
ログに新しい接続がまったくない	ループバック例外が反映されていない、またはアプリが再起動されていない	例外一覧を再確認し、アプリのプロセスを終了する
接続はあるが、すべてDIRECTに一致する	ルールによって対象通信が直接接続に設定されている	ルールの順序とポリシーグループの選択を確認する
プロキシ接続はあるがタイムアウトになる	ノードが利用できない、または対象サービスが接続を拒否している	ノードを切り替え、同じ対象へ再度テストする
グローバルモードでは正常だが、ルールモードでは失敗する	ルールまたはDNSの設定に問題がある	適用されたルールを特定し、ドメイン解決を確認する

それでも接続できない場合に確認する5項目

1. システムプロキシのポートとmixed-portが一致していない

mihomoが 127.0.0.1:7890 で待ち受けているのに、Windowsのシステムプロキシが古いポート 7897 を指していると、アプリにループバック権限があっても接続を確立できません。Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシがクライアントによって正しく管理されているか確認します。

通常、Windowsのプロキシを手動で設定しながら、クライアントのシステムプロキシ機能も有効にすることはおすすめしません。2か所の設定は、再起動やポート切り替え後に同期しなくなる可能性があります。現在のクライアントに一元管理させ、ポートを変更した場合はシステムプロキシをいったん無効にしてから再度有効にしてください。

2. クライアントがカーネルを正常に起動できていない

クライアントのホーム画面またはログを確認し、mihomoカーネルが実行中であることを確認します。ポート競合がログに出ている場合は、競合しているプロセスを終了するか、mixed-port を 7890 以外の空きポートに変更し、システムプロキシも同時に更新してください。

netstat -ano | findstr :7890

コマンド出力の最後の列はプロセスPIDです。タスクマネージャーの「詳細」ページでPIDからプロセスを特定できます。正体の分からないシステムプロセスを直接終了せず、別のプロキシクライアントまたは終了しきれていないカーネルのプロセスかどうかを確認してください。

3. ルールがMicrosoftのサービスを利用できないポリシーに振り分けている

ループバック例外で解決できるのは「アプリがローカルプロキシへ接続できるかどうか」だけで、ノードの選択までは行いません。「接続」ページで、リクエストがどのポリシーグループに一致したか確認します。ポリシーグループが利用不能なノード、拒否ポリシー、または誤った直接接続先になっていると、読み込みに失敗します。

テスト時は、該当するポリシーグループで遅延が安定したノードを手動選択できます。遅延テストの成功はテスト先へ到達できることを示すだけで、すべてのMicrosoftサービスにアクセスできるとは限りません。実際の接続状態も併せて判断してください。

4. DNSの解決結果に問題がある

ログにDNSタイムアウト、ドメイン解決失敗、または宛先アドレスが空になる状態が続く場合は、mihomo設定の dns.enable、上流DNS、動作モードを確認します。TUNモードを有効にしている場合は、クライアントのサービスモードや管理者権限が正常に設定されていることも確認してください。そうでなければDNSのリダイレクトが機能しない可能性があります。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

この設定は構成例にすぎず、現在のサブスクリプション設定を無視してそのまま上書きすることはできません。サブスクリプションには、ルール、フォールバックDNS、Fake-IPのフィルターリストがすでに設定されている場合があります。変更前に元の設定を保存し、まずはクライアントのオーバーライド機能を使用してください。

5. アプリのプロセスが完全には再起動されていない

ウィンドウを閉じても、ストアアプリがバックグラウンドで実行され続けることがあります。タスクマネージャーの「プロセス」または「詳細」ページで該当タスクを終了し、5秒待ってから起動してください。Windowsアカウントからサインアウトして再度サインインし、AppContainerプロセスに権限を再読み込みさせる方法もあります。

よくある質問

ブラウザーは正常なのに、Microsoft Storeがオフラインになるのはなぜですか？

通常のデスクトップブラウザーは 127.0.0.1 上のClashプロキシへ接続できますが、一部のAppContainerアプリには既定でループバック制限があります。まずMicrosoft Storeにループバック例外を追加し、アプリを再起動してください。

ループバック制限を解除した後、パソコンの再起動は必要ですか？

多くの場合、必要ありません。対象アプリのプロセスを完全に終了して再起動すれば十分です。それでも古いネットワーク状態が残る場合は、アカウントからサインアウトするか、Windowsを再起動して再度確認してください。

UWPアプリをすべて一度に選択できますか？

技術的には、すべて選択できるツールもあります。ただしトラブルシューティングでは、プロキシが必要なアプリだけを対象にすることをおすすめします。必要なものだけ追加すれば効果を確認しやすく、後から CheckNetIsolation.exe LoopbackExempt -s で一覧を確認するのも簡単です。

Clashクライアントを切り替えたら、再設定が必要ですか？

ループバック例外はWindowsに保存されるため、通常はクライアントを変更しただけで消えることはありません。ただし、新しいクライアントの待受ポート、システムプロキシ、TUN設定が異なる場合があります。Windowsが現在稼働中のプロキシポートを指していることを確認してください。

CheckNetIsolationが成功したのに、アプリがネットワークに接続できない場合は？

アプリが完全に再起動されているか、システムプロキシのポートが一致しているか、Clashの接続ログにリクエストが出ているか、そして適用されたルールとポリシーを順に確認します。グローバルモードでは正常でルールモードだけ失敗する場合は、ルールとDNSを重点的に確認してください。

対処手順のまとめ

通常のデスクトップアプリがClash経由でインターネットに接続できることを確認する。
ローカルの待受ポートとWindowsのシステムプロキシが一致していることを確認する。
クライアント内蔵ツールで対象UWPアプリにループバック例外を追加する。
GUIの項目がない場合は、PowerShellでパッケージファミリ名を調べてから CheckNetIsolation を実行する。
対象アプリを完全に終了し、再起動する。
Clashの接続ページでリクエスト、適用ルール、最終ポリシーを確認する。
それでも失敗する場合は、ノード、DNS、TUNサービス、ポート競合を確認する。

この種の障害では、2つの問題を分けて考えることが重要です。ループバック例外はアプリがローカルプロキシへ接続できるかどうかを決め、Clashの設定は接続後の名前解決、ルーティング、転送方法を決めます。まずリクエストがログに現れることを確認し、その後にルールとノードを調べると、原因を直接切り分けられます。