---

現象:通常のアプリはプロキシ経由できるが、ストアアプリだけ接続できない

Windows で Clash や mihomo コアのシステムプロキシを有効にしたり、TUN モードを有効にしたりした後、大半のデスクトップアプリ(ブラウザ、コマンドラインツール、従来型 exe プログラム)は正常にプロキシルールに従って通信できます。しかし Microsoft Store からインストールした一部のアプリ——特定のメールクライアント、一部ブラウザのストア版、クロスプラットフォームチャットツールの UWP パッケージ版など——は典型的な「プロキシが効かない」症状を示します。直接アクセスできるサイトには繋がるものの、プロキシ経由でしかアクセスできないアドレスは軒並みタイムアウトやネットワークエラーになり、システムプロキシ設定にローカルポートを正しく入力していても解決しません。

この種の問題は原因調査がずれやすいです。多くの人は最初にサブスクリプションノードの失効、コアのクラッシュ、ルール記述の誤りを疑い、クライアントの再起動やサブスクリプションの再インポートを繰り返しますが、効果はありません。理由は単純で、問題の本質はプロキシサービス側にはなく、Windows システムが UWP(Universal Windows Platform)アプリのネットワークアクセスに対して、通常のプロセスとは独立した分離制限をかけていることにあります。この制限はデフォルトで UWP アプリと 127.0.0.1 / localhost のループバック通信を遮断し、大半のローカルプロキシクライアント(Clash 系コアを含む)はまさにローカルのループバックアドレスをリッスンして HTTP/SOCKS5 プロキシポートを提供しているのです。

仕組み:UWP サンドボックスとループバック通信の分離

この制限を理解するには、まず UWP アプリの動作方式が従来の Win32 プログラムと全く異なることを知る必要があります。UWP アプリは AppContainer と呼ばれるサンドボックス環境で動作し、Microsoft は各 UWP アプリに独立したセキュリティ識別子(SID)を割り当て、ネットワーク分離(Network Isolation)機構を通じてアクセス可能なネットワークリソースを厳しく制御します。この機構の設計意図はセキュリティにあります——ストアアプリが未申請のままローカルネットワークや同一マシン上の他プロセスが開放するポートに自由にアクセスすることを防ぎ、横展開的な侵入や情報漏洩のリスクを低減するためです。

ネットワーク分離ポリシーには重要なルールがあります。UWP アプリはデフォルトで、同一マシン上でループバックアドレス(loopback、つまり 127.0.0.1 または ::1)でリッスンしているサービスへのアクセスが禁止されています。ただし、そのサービス自体が UWP アプリとしてパッケージ化されて動作している場合を除きます。これがこの問題がストアアプリだけに現れる理由です——従来のデスクトッププログラムは AppContainer の制約を受けず、ローカルの任意のポートに自由に接続できますが、UWP アプリはシステムプロキシ設定がグローバルに有効になっていても、発行する接続要求はネットワーク層に到達する前にこの分離チェックで拒否されます。接続先が 127.0.0.1:7890 のようなローカルプロキシポートの場合、特にこの現象が目立ちます。

注意すべき点として、この制限はプロキシソフト自体が「LAN 接続を許可」を有効にしているか、リッスンアドレスを 0.0.0.0 にしているか 127.0.0.1 にしているかとはあまり関係がありません——プロキシが全てのネットワークインターフェースでリッスンしていても、UWP アプリが発行するループバック要求はシステムレベルの分離ポリシーによって遮断されます。これはオペレーティングシステム層の挙動であり、クライアントの設定ファイル内のどのオプションでも回避できません。

まず確認:ループバック制限が原因かどうか

制限解除に取り組む前に、誤判定を避けるため簡単な検証を2ステップ行うことをお勧めします。

1. 影響を受けているのがストアアプリかどうかを確認する。スタートメニューのアプリアイコンを右クリックし、「アンインストール」以外に「高度なオプション」という項目が表示される場合、通常それは UWP アプリであることを示します。従来の Win32 プログラムは通常アンインストール項目のみです。設定の「アプリと機能」一覧でソース表示を確認することもできます。
2. プロキシサービス自体が正常に動作しているか確認する。ブラウザやコマンドラインツールで同じプロキシポートが利用可能かを手動でテストします。例えば curl でプロキシを指定して、プロキシ経由でしか開けないアドレスにアクセスしてみます。こうした従来型プログラムが正常に外部通信できるなら、プロキシ設定やノード自体の問題は概ね排除でき、問題は UWP のネットワーク分離に絞られます。

両方の条件が当てはまれば、接続失敗はほぼループバック制限によるものと確定できます。あとはこの特定の UWP アプリに対して個別にループバック免除を設定するだけです。

方法1:CheckNetIsolation コマンドで解除する

Windows システムには CheckNetIsolation.exe という標準のコマンドラインツールが付属しており、AppContainer のネットワーク分離ホワイトリストを管理するために使われます。これは公式に提供されている標準的な解決方法で、追加ソフトのインストールは不要です。

ステップ1:アプリの Package Family Name を確認する

管理者権限で PowerShell を開き、以下のコマンドを実行して現在システムにインストールされている全 UWP アプリとそのパッケージ名を一覧表示します。

Get-AppxPackage | Select-Object Name, PackageFamilyName

返された一覧から対象アプリに対応する項目を見つけ、その PackageFamilyName フィールドを控えます。形式は 12345Publisher.AppName_abcdefghijk1m のようになります。この文字列は後続のコマンドに必須の正確な識別子で、アプリの表示名では代用できません。

ステップ2:ループバック免除を追加する

PowerShell を閉じ、管理者権限でコマンドプロンプト(cmd)を開いて以下を実行します。

CheckNetIsolation.exe LoopbackExempt -a -n="12345Publisher.AppName_abcdefghijk1m"

コマンド実行後にエラーが出なければ追加成功です。特別な成功通知ポップアップは表示されません。このコマンドの効果は、指定アプリをループバック免除リストに追加し、以降そのアプリが本機の 127.0.0.1 でリッスンしているサービス(プロキシクライアントが公開する HTTP/SOCKS5 ポートを含む)に正常にアクセスできるようにすることです。

確認と取り消し

現在免除されているアプリの一覧を確認するには、以下を実行します。

CheckNetIsolation.exe LoopbackExempt -s

後で特定のアプリの免除を取り消したい場合(例えば他の問題を調査する際にデフォルトの分離状態に戻したい場合)、パラメータの -a を -d に置き換えるだけです。

CheckNetIsolation.exe LoopbackExempt -d -n="12345Publisher.AppName_abcdefghijk1m"

注意しておきたいのは、この免除リストは他のデバイスと同期されず、アプリをアンインストールして再インストールしても自動的には保持されません。再インストール後は再度追加コマンドを実行する必要があります。

方法2:GUIツールでの操作

コマンド入力に慣れていない、パッケージ名を打ち間違えるのが心配な場合は、GUIツールで同じ操作を行うこともできます。Microsoft コミュニティで広く利用されている EnableLoopback はオープンソースの小型ツールで、本質的には CheckNetIsolation.exe にインターフェースを被せたものです。底層の仕組みには変更を加えず、操作ロジックはコマンドラインと完全に一致しています。

1. 管理者権限でこのツールを実行すると、起動時に自動で現在システムにインストールされている全 UWP アプリの一覧を読み込み、それぞれの現在のループバック免除状態を表示します。
2. 一覧から制限を解除したいアプリにチェックを入れ(複数選択可能で、影響を受けている複数のストアアプリを一括処理できます)、「Modify」をクリックして変更を適用します。
3. ツールが実行する操作はコマンド手動入力と完全に等価で、チェックを入れると免除追加、チェックを外すと免除取り消しとなり、パッケージ名を記憶したりコピーしたりする必要がありません。

免除状態を頻繁に調整する必要がある、または一度に複数アプリを処理したいシナリオでは、GUIツールの方がコマンドを繰り返し入力するより手間が省けます。一方、単一アプリの問題を一時的に解決するだけであれば、直接コマンドラインを使う方が手早く、サードパーティツールを追加でダウンロード・インストールする必要がありません。

解除後の動作確認方法

免除設定を完了したら、以下の順序で検証することをお勧めします。「アプリの起動が速くなった」といった主観的な感覚だけで判断しないようにしましょう。

• アプリを完全に終了してから再起動する。UWP アプリのネットワークセッションは通常起動時に確立され、免除設定はアプリ実行中に即座にホットリロードされることは少なく、プロセスを完全に終了させて再起動しないと新しい分離ポリシーが適用されません。
• プロキシ経由でしか開けないことが明確なアドレスにアクセスする。アプリのホーム画面のようにローカルキャッシュがある可能性のあるコンテンツで判断するのは避け、必ずリアルタイムにネットワーク読み込みが必要で、かつプロキシルールの振り分け範囲に明確に含まれる機能でテストします。
• プロキシクライアントの接続ログやアクティブ接続パネルを確認する。クライアントの画面で該当アプリからの接続記録が見えれば、トラフィックが確実にプロキシ経路に入っていることを示します。ログに関連する記録が全く現れない場合は免除が有効になっていないことを意味し、パッケージ名の入力ミスやコマンドを管理者権限で実行したかどうかを再確認する必要があります。

もう一点見落とされがちな点として、一部の UWP アプリはループバック分離を解除しても、自身の「ネットワーク機能宣言」(Capability)に専用ネットワークアクセス権限が宣言されていないために依然制限を受けることがあります。これは主に企業向けカスタム配布アプリで見られ、一般的なストアアプリではあまり発生しませんが、分離解除後も効果がない場合はアプリのマニフェスト権限をさらに確認してみてください。

ループバック制限を回避する他のアプローチ

アプリ単位で分離を解除したくない、または影響を受けるアプリの数が多く頻繁に変動する場合、根本からこの制限を回避する方法が2つあります。

TUN モードへの切り替え

前述の通り、ループバック制限が対象とするのはアプリが主動的に本機のプロキシポートへ接続するというアクセス方式です。クライアントが TUN モードに対応していれば、有効化すると仮想ネットワークインターフェースがシステム内に構築され、全プロセス(分離制約を受ける UWP アプリを含む)のトラフィックがネットワークインターフェース層で一括して捕捉・転送されます。もはやアプリ自身が 127.0.0.1 上のプロキシポートに接続する必要がなくなるため、自然とループバック分離ポリシーの影響を受けません。ストアアプリの接続問題に頻繁に遭遇するユーザーには、直接 TUN モードに切り替える方が個別にホワイトリスト登録するより手間が省けます。

リッスンアドレスとファイアウォールルールをシステムプロキシと組み合わせて調整する

一部のシナリオでは、システムプロキシの適用範囲をより低レイヤーのネットワーク構成をカバーするように調整することも検討できますが、この種の調整には他の互換性上のコストが伴うことが多く、前述の2つの方法ほど直接的ではないため、一般的には第一選択とはしません。TUN モードもアプリ単位の免除も適用できない特殊な環境でのみ検討する価値があります。

---

ループバック制限は Windows システムレベルのセキュリティ設計であり、プロキシクライアントの欠陥ではありません。この点を理解しておくと、無意味な調査に費やす時間を大幅に減らせます。「ストアアプリだけプロキシに接続できない」という特徴が明確な問題に遭遇した場合、パッケージ名を確認して CheckNetIsolation コマンドまたはGUIツールで免除を解除すれば、通常数分で解決できます。対象アプリの数が多い、あるいはホワイトリストを維持したくない場合は、TUN モードへの切り替えがより手間の少ない長期的な対策になります。