Windows UWPアプリがプロキシに接続できない場合：ループバック制限の解除と確認手順

まずUWPのループバック問題か確認する

「ストアが開かない」からといって、すぐにループバック例外を変更しないでください。Microsoft Store、メール、メディアアプリなどが接続できない原因は、システムプロキシが無効、Clashのコアが未起動、ルールの誤り、DNS障害、アカウントサービスの異常、Windowsサービスの状態異常など多岐にわたります。ループバック制限が説明できるのは、アプリがローカルプロキシ経由で接続しようとしている一方、AppContainerによってローカルの待ち受けアドレスへのアクセスが阻止されるケースです。

典型的な症状の組み合わせは、通常のデスクトップブラウザーはClash経由で正常にアクセスでき、Clashのシステムプロキシも有効なのに、対象のUWPアプリだけが「ネットワークに接続できない」と表示したり、読み込みが続いたり、接続に失敗したりする状態です。システムプロキシを無効にすると直通接続で復旧する場合もありますが、ネットワーク環境によっては失敗が続きます。この場合は、現在のモード、プロキシポート、アプリ名を記録してから対象を絞って対応します。

次の順番で基準状態を確認します

1. Clashクライアントでコアが実行中と表示されていることを確認します。画面のプロセスが開いているだけでは不十分です。
2. 通常のデスクトップブラウザーで利用可能なサイトを開き、システムプロキシの経路が少なくともWin32アプリでは機能していることを確認します。
3. Clashの接続履歴で対象ドメインを検索し、UWPアプリの起動時に新しい接続が発生するか確認します。
4. クライアント設定のHTTPポートまたは混合ポートを記録し、システムプロキシが同じポートを実際に参照していることを確認します。
5. 対象アプリを完全に終了してから再起動し、バックグラウンドプロセスが変更前の接続を使い続けないようにします。

対象アプリの起動時にClashの接続一覧へ関連リクエストがまったく現れず、ブラウザーのリクエストは正常に表示されるなら、ループバック制限を優先して確認します。反対に、リクエストがClashへ届き、ルール適用、DNSエラー、ノード接続失敗などが明確に表示される場合は、通信はAppContainerを越えてローカルプロキシまで到達しています。問題はルール、DNS、または上流ノードへ切り替えて調べます。

システムプロキシは正常なのにUWPアプリが失敗する理由

ClashまたはmihomoをWindowsで動かすと、通常はローカルポートで待ち受けます。たとえば混合ポートが127.0.0.1:7890で待ち受け、HTTPとSOCKSの両方を受け付ける場合があります。クライアントによってはHTTPポートとSOCKSポートを個別に設定します。システムプロキシを有効にすると、Windowsはプロキシアドレスを現在のユーザーのネットワーク設定へ保存し、その設定を使うアプリはリクエストをローカルのClashポートへ送信します。

通常のデスクトップアプリにとって、127.0.0.1への接続は一般的なローカル通信です。一方、UWPアプリや一部のパッケージアプリはAppContainerのサンドボックス上で動作します。AppContainerはネットワーク機能とローカルループバックへのアクセスに制限を設け、隔離されたアプリが同じ端末上の他サービスへ任意に接続するのを防ぎます。その結果、アプリがシステムプロキシのアドレスを読み取れても、そのアドレスへ接続できず、ネットワークリクエストがClashのコアに届く前に失敗します。

ループバック例外は、アプリ自体を「強制的にプロキシ経由」に変更するものではありません。指定したAppContainerにローカルのループバックインターフェースへのアクセスを許可するだけです。アプリがシステムプロキシを読み取るか、プロキシを迂回するか、UDPやQUICを使うかは、アプリの実装とWindowsのネットワークスタックによって決まります。そのため、例外を追加した後も接続履歴で通信経路を確認する必要があり、アプリの画面が一時的に復旧しただけで判断してはいけません。

対象アプリのループバック制限を解除する

ClashのWindowsクライアントには、「UWPループバック」「Loopback」「ループバック制限の解除」などの項目が用意されている場合があります。通常はWindowsのループバック例外機能を呼び出し、インストール済みのAppContainerアプリ一覧を表示します。ローカルプロキシ経由の接続が必要なアプリだけを選択してください。たとえば問題が発生しているMicrosoft Storeや特定のストアアプリが対象です。範囲を確認しないまま、すべての項目を一括で選択することはおすすめしません。

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

1. Clashクライアントを通常どおり起動し、コアが設定を正常に読み込んだことを確認します。
2. 設定、一般設定、サービスツールなどの項目を開き、UWP、Loopback、または「ループバック」を含む項目を探します。
3. アプリ一覧から対象プログラムを探します。一覧にはアプリ名、パッケージ名、パッケージファミリ名などが表示される場合があるため、似た項目と取り違えないように注意してください。
4. 対象プログラムを選択して保存し、Windowsが該当パッケージにループバック例外を追加できるようにします。
5. 対象アプリのウィンドウをすべて閉じ、タスクマネージャーでバックグラウンドプロセスが終了したことを確認してから、アプリを再起動します。

クライアントによってメニューの場所は異なり、グラフィカルなループバックツールを搭載していないものもあります。項目がないからといって、mihomoコアにプロキシ機能がないわけではありません。ループバック制限はWindows AppContainerのポリシーであり、Clashのルールエンジンの設定ではないためです。その場合は、Windows標準のコマンドで確認・変更できます。

方法2：PowerShellでパッケージファミリ名を調べる

まずPowerShellを開き、アプリの表示名またはパッケージ名からPackageFamilyNameを検索します。次のコマンドで、現在のユーザーがインストールしているアプリパッケージとパッケージファミリ名を一覧表示できます。

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

一覧が長い場合は、キーワードで絞り込めます。たとえば名前にStoreを含むアプリを検索する場合は、次のようにします。

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

正確なパッケージファミリ名が見つかったら、ターミナルでループバック例外を追加するコマンドを実行します。サンプルの値は、検索結果に表示された実際のPackageFamilyNameに置き換えてください。

CheckNetIsolation.exe LoopbackExempt -a -n="対象アプリのPackageFamilyName"

コマンドの-aは追加を意味します。-nの後にはパッケージファミリ名を指定し、スタートメニューに表示されるアプリ名やインストール先のフォルダー名は指定しません。名前を間違えると、コマンドが失敗したり、意図しないパッケージが変更されたりする可能性があります。実行前にPowerShellの出力から値全体をコピーしてください。

既存の例外を確認・取り消す

現在のループバック例外一覧を確認するには、次のコマンドを実行します。

CheckNetIsolation.exe LoopbackExempt -s

テスト後に不要になった例外は、削除コマンドでアプリを既定の制限状態に戻せます。

CheckNetIsolation.exe LoopbackExempt -d -n="対象アプリのPackageFamilyName"

ローカルポートからルール適用までを段階的に確認する

例外の追加は権限を変更するだけなので、検証では各層を順番に確認します。Clashは一時的にルールモードで動かすのがおすすめです。ルールモードでは接続履歴にドメイン、宛先アドレス、適用ルール、プロキシグループが表示され、リクエストが想定どおり振り分けられているかをグローバルモードより判断しやすくなります。

ステップ1：待ち受けポートを確認する

Clashクライアントで現在の混合ポートまたはHTTPポートを確認し、続けてWindowsのシステムプロキシを確認します。両方のポートは一致していなければなりません。たとえばクライアントが127.0.0.1:7890で待ち受けているのに、システムプロキシが127.0.0.1:7897のままだと、システムプロキシを使うすべてのアプリが誤ったアドレスへ接続します。複数のClashクライアントを切り替えた後は、このようなポートの残留が特に起こりやすくなります。

設定内の待ち受けアドレスが、別のインターフェース専用の値に変更されていないことも確認します。ローカルアプリだけで使うなら、通常はループバックアドレスで十分です。LAN共有にはallow-lan、待ち受けアドレス、ファイアウォールが関係する別の設定経路があるため、単一端末のUWPアプリを直す目的でLANアクセスを直接公開しないでください。

ステップ2：対象アプリを再起動する

UWPアプリの中には、ウィンドウを閉じてもバックグラウンドタスクが残るものがあります。ループバック例外を変更した後は、タスクマネージャーで関連プロセスを終了するか、現在のWindowsユーザーからサインアウトして再度サインインしてください。アプリが古い接続を再利用していると、「設定を追加したのに反映されない」と誤認する原因になります。

ステップ3：Clashの接続履歴とログを確認する

アプリを再び開き、ページの更新、アップデートの確認、アカウント情報の読み込みなど、明確な通信操作を1回実行します。その後、Clashの接続一覧を確認します。

• 対象ドメインが表示され、データ転送が成功していれば、ループバック、ローカルポート、プロキシ入口が接続できています。
• ドメインは表示されるもののルール適用が誤っている場合は、ルールの順序、ルールセットの参照、プロキシグループの選択を調整します。
• 接続は発生するもののノードのハンドシェイクに失敗する場合は、プロキシグループ内の別の利用可能なノードを試します。
• リクエストがまったく発生しない場合は、アプリがシステムプロキシを使っているか、例外の対象が正しいか、またアプリがこのプロキシ入口で処理されないプロトコルを使っていないかを確認します。

ステップ4：設定のオン・オフを比較する

それ以外の条件を変えず、「システムプロキシを有効」と「システムプロキシを無効」の両方を個別にテストします。有効時だけ失敗し、無効時は直通接続が正常で、しかもClashに対象アプリのリクエストが一度も表示されないなら、通常はローカルプロキシ入口またはループバック権限の問題です。両方の状態で失敗する場合は、例外の追加を繰り返すのではなく、アプリのサービス、Windowsネットワーク、アカウント状態、DNSを確認します。

ループバック解除後も接続できない場合の切り分け順序

対象アプリがすでに例外一覧にあるのに正常に接続できない場合は、プロキシ入口から先を確認します。次の問題はループバック制限と似た症状になりますが、必要な対応は異なります。

システムプロキシのアドレスまたはポートが残っている

Windowsのシステムプロキシに、以前使っていたクライアントのポートが残ることがあります。クライアントの異常終了、ポータブル版とインストール版の切り替え、複数のプロキシツールの併用後に起こりやすい現象です。まず他のプロキシソフトを終了し、現在のClashクライアントでシステムプロキシを設定し直します。クライアントのボタン表示だけで判断せず、Windowsに実際に保存されているプロキシアドレスを確認してください。

アプリがシステムプロキシを使っていない

すべてのアプリが、現在のユーザーに設定されたシステムプロキシに従うわけではありません。独自のネットワークスタックを実装するアプリ、UDPやQUICを使う接続、別のサービスプロセスから通信するバックグラウンドコンポーネントもあります。この場合、ループバック例外が正しくても、HTTPのシステムプロキシですべての通信を取得できるとは限りません。mihomoのTUNモードを試すことはできますが、有効にする前に必要な権限、仮想NICコンポーネントの利用可否、DNSの取得やルーティングの変化を確認してください。

TUNモードはネットワーク層で通信を取得する仕組みであり、「アプリが127.0.0.1のシステムプロキシへ自発的に接続する」仕組みとは異なります。システムプロキシを読み取らないアプリでよく使われますが、すべてのUWP問題を解決できるとは限りません。TUNを有効にしてもリクエストがない場合は、ルート除外、インターフェース競合、セキュリティソフトのポリシー、アプリ自身のサービス状態を確認します。

ルールによって必要なリクエストが誤ったプロキシグループに振り分けられている

Microsoft Storeなどのアプリは、コンテンツ配信、アカウント、証明書、更新の各サービスへ同時にアクセスすることがあります。メインドメインだけが成功しても、依存するすべてのリクエストが正常とは限りません。接続履歴で失敗または繰り返し再試行されているドメインを確認し、ルールが上から順にどのように適用されているかを確認します。Clashは1つのルールに一致すると後続のルールを確認しないため、前方にある広すぎるルールが後方の詳細なルールを上書きすることがあります。

切り分け中は、利用できることを確認済みのプロキシグループへ一時的に切り替えて比較できます。ただし、ルールの問題を隠すためにグローバルプロキシを長期利用することはおすすめしません。具体的なドメインと失敗原因を特定したら、修正内容をルール設定へ反映し、最後のフォールバックルールも残します。

DNS名前解決とプロキシ接続は別の段階で処理される

ログに名前解決の失敗、異常なアドレスの返却、継続的なタイムアウトが表示される場合は、現在の設定のdnsセクション、DNSサーバーへの到達性、ClashのDNS待ち受け状態を確認します。fake-ipを使っている場合は、アプリが仮想アドレスや特定ドメインに互換性上の要件を持たないかも確認してください。UWPアプリで発生した症状だからといって、DNS層の確認を省略しないでください。

ポート競合とコアの起動失敗

クライアントの画面が開くことは、プロキシポートが待ち受けていることを意味しません。設定構文エラー、ポートの使用中、コアの起動失敗があると、システムプロキシがサービスのないアドレスを参照し続ける場合があります。クライアントログで設定の読み込み結果と待ち受けエラーを確認し、必要なら未使用のポートへ変更してシステムプロキシも同時に更新します。

企業ポリシーや管理対象デバイスによる制限

会社や学校の端末、集中管理ポリシーが有効なWindows環境では、グループポリシー、ファイアウォール、エンドポイント保護によってAppContainer、ローカルプロキシ、ネットワークインターフェースが制限されることがあります。コマンドが成功しても、後からポリシーによって設定が上書きされる可能性があります。このような環境では、まず端末管理の要件を確認し、集中管理されている設定を繰り返し変更しないでください。

復旧確認チェックリスト

変更が完了したら、次のチェックリストで最終確認します。各項目が明確な層に対応するため、後から再現や切り戻しを行いやすくなります。

• Clashまたはmihomoのコアが正常に起動し、現在の設定に解析エラーがない。
• ローカルのHTTPまたは混合ポートが待ち受け中で、他のプログラムと競合していない。
• Windowsのシステムプロキシアドレスが現在のクライアントポートと一致している。
• 対象UWPアプリのパッケージファミリ名がループバック例外一覧に追加されている。
• 変更後、対象アプリを完全に終了して再起動している。
• Clashの接続履歴に、アプリが生成したドメインまたは宛先アドレスが表示される。
• リクエストが想定したルールとプロキシグループに一致し、上流ノードへの接続を正常に確立できる。
• DNSクエリが継続的にタイムアウトせず、名前解決結果が現在の設定モードに合っている。
• テスト後、不要になった一時的な変更を取り消し、最終的に有効な設定を記録している。

修復成功の基準は「ページが開く」だけではありません。対象リクエストが安定してClashへ入り、想定したルールに一致し、データ転送まで完了することが重要です。このように層ごとに検証すれば、AppContainerの権限、ローカルプロキシポート、ルール、DNS、ノードの問題を区別でき、同じ設定を何度も操作せずに済みます。