WindowsでClashまたはmihomoコア搭載のクライアントを使っていると、ブラウザーは通常どおりプロキシに接続できるのに、Microsoft Storeアプリ、Xbox関連コンポーネント、「フォト」「メール」などのUWPアプリだけがオフラインになることがあります。この現象はサブスクリプションの無効化と誤解されがちですが、実際にはアプリがローカルプロキシのポートへ接続する前の段階で起きている可能性があります。Windowsのアプリコンテナーには、既定でループバックアクセスの制限があり、ローカルの 127.0.0.1 や localhost で動作するサービスへ自由に接続できません。
ここでいう「ループバック」とは、デバイスが自身のネットワークインターフェースへアクセスする経路を指します。ClashのHTTP、SOCKS、混合ポートはローカルアドレスで待ち受けることが多く、従来のデスクトップアプリは直接接続できます。一方、UWPアプリではAppContainerのネットワーク分離ポリシーも適用されます。対象アプリのループバック除外を設定したうえで、システムプロキシ、ポート、ルールモードを確認すれば、問題がどの段階で起きているかを特定しやすくなります。
1. UWPのループバック制限で起きる症状
UWPアプリはアプリコンテナー内で動作し、それぞれに独立したIDと権限境界があります。システムプロキシの設定によって、リクエストを特定のプロキシへ渡すことはできますが、ローカルで待ち受けるアドレスへアクセスできるかどうかは、ネットワーク分離ルールにも左右されます。Clashが正常に動作していても、すべてのアプリがローカルプロキシへのアクセス権を得ているとは限りません。
よくある症状として、Microsoft Storeは開くのにアプリのダウンロードがいつまでも保留になる、Xboxやゲームランチャー、天気アプリがサービスに接続できないと表示する、Windowsの設定でアカウント同期に失敗する、といったケースがあります。ブラウザーはClash経由で正常にアクセスできるのに、Storeからインストールしたアプリだけがネットワークなしと表示されることもあります。Clashの混合ポートをLANアドレスに変更すると一部のリクエストに変化が出る場合もありますが、待ち受け範囲、ファイアウォール、LANへの公開といった新たな要因が増えるため、最初の対処としてはおすすめできません。
UWPアプリと通常のデスクトップアプリも区別する必要があります。アプリ名が同じでも、ネットワークの仕組みが同じとは限りません。たとえばMicrosoft Storeからインストールした版はアプリコンテナーで動作する一方、公式サイトから入手したインストーラー版はWin32デスクトップアプリです。前者はループバック分離の影響を受けやすく、後者は通常、システムプロキシを使ったりローカルポートへ直接接続したりできます。
2. Clashの待ち受けアドレスとポートを確認する
ループバック制限を解除する前に、クライアントに利用可能なローカルプロキシの入口が実際に用意されているか確認します。Clashクライアントによって画面上の名称は異なりますが、基本的にはHTTPポート、SOCKSポート、混合ポートが設定されています。混合ポートはHTTPとSOCKSの両方のリクエストを受け付けられるため、システムプロキシの入口を1つだけ指定する場合に便利です。
- Clashクライアントの設定または一般設定を開き、現在有効なHTTP、SOCKS、混合ポートを控えます。
- 待ち受けアドレスが
127.0.0.1などのローカルループバックアドレスになっていること、またポートがほかのプログラムに使われていないことを確認します。 - Windowsの「設定 → ネットワークとインターネット → プロキシ」を開き、手動プロキシが同じアドレスとポートを指しているか確認します。
- Clashの接続画面またはログ画面で、UWPアプリの起動時にリクエストが記録されるか確認します。
システムプロキシにHTTPポートを指定するつもりで、実際にはSOCKSポートを入力していると、アプリによっては接続エラーが直ちに発生します。逆に、HTTPプロキシにしか対応していないシステムコンポーネントは、SOCKSポートを通常のHTTPプロキシとして利用できません。ポート番号は、現在のクライアント画面または設定ファイルに記載された実際の値を使い、別の端末の既定値を流用しないでください。
システムプロキシが別のソフトウェアに管理されていないかも確認します。VPN、ネットワーク高速化ツール、パケットキャプチャーツール、企業の管理ポリシーなどがWindowsのプロキシ設定を書き換えることがあります。ClashのログにUWPアプリのリクエストがまったく出ない場合は、プロキシの入口、アプリの権限、システムプロキシの選択段階に問題がある可能性が高いです。ログにリクエストが出ている場合は、ルールの判定とノードからの応答を確認します。
3. Windowsのツールでループバックアクセス制限を解除する
Windowsには、アプリコンテナーのネットワーク分離に対する例外を管理する CheckNetIsolation コマンドがあります。重要なのは、対象アプリのPackage Family Name、つまりパッケージファミリ名を特定することです。デスクトップのショートカットに表示される名前ではありません。パッケージ名を間違えると、コマンドが失敗したり、似た別のアプリに除外設定を追加したりする可能性があります。
方法1：GUIのループバック除外ツールを使う
信頼できる提供元のWindows向けループバック除外管理ツールを使い、接続が必要なアプリを選択して設定を適用する方法もあります。ツールの一覧には通常、アプリ名とパッケージ識別子が表示されます。対象アプリにチェックを入れて保存したら、そのアプリを完全に終了して再起動します。アプリの更新後もパッケージIDは通常維持されますが、異なる配布元の版をインストールした場合は、実際のパッケージ識別子を改めて確認してください。
GUIツールはコマンドラインに慣れていないユーザーに向いていますが、操作前にダウンロード元、ツールの説明、対象アプリ名を確認してください。ループバック除外はローカルネットワーク権限に関する設定です。ローカルプロキシへの接続が本当に必要なアプリだけを選び、一覧にあるすべてのアプリを無条件に許可することは避けてください。
方法2：PowerShellまたはコマンドプロンプトを使う
通常のユーザー権限でPowerShellまたはコマンドプロンプトを開き、まず現在のループバック除外リストを確認します。
CheckNetIsolation LoopbackExempt -s対象アプリのPackage Family Nameを確認したら、次の形式で除外を追加します。
CheckNetIsolation LoopbackExempt -a -n=アプリのPackageFamilyNameアプリのPackageFamilyName は実際の値に置き換える必要があり、例にある文字列をそのまま入力してはいけません。PowerShellでインストール済みアプリのパッケージ情報を取得し、表示名から絞り込むこともできます。たとえば次のように確認します。
Get-AppxPackage | Select-Object Name, PackageFamilyName追加後は、CheckNetIsolation LoopbackExempt -s をもう一度実行して、項目が表示されることを確認できます。その後、対象アプリを終了し、必要に応じてタスクマネージャーからバックグラウンドプロセスを終了して再起動します。ウィンドウを閉じるだけではUWPアプリのバックグラウンドインスタンスが終了しない場合があるため、再起動しても変化がないときは、まず完全終了を行ってください。
4. 制限解除後も接続できない場合の確認順
ループバック除外を設定してもUWPアプリがオフラインのままなら、「アプリの入口 → プロキシポート → クライアントログ → ルールとノード」の順に確認します。まずリクエストがClashへ到達しているかを判断し、その後に設定変更の必要性を検討できる点がこの順番の利点です。
1. アプリがシステムプロキシを使っているか確認する
すべてのアプリがWindowsの手動プロキシ設定に従うわけではありません。システムのWinINetプロキシを使うアプリもあれば、WinHTTPを使うアプリ、アプリ内に独自のネットワーク設定を備えるアプリもあります。まずWindowsのプロキシ設定、スイッチ、アドレスを確認し、次にアプリ側にプロキシ、ネットワーク、ダウンロード設定がないか確認してください。アプリがシステムプロキシを完全に迂回している場合、ClashのHTTPポートだけを変更しても効果はありません。
2. ポートの種類と待ち受け状態を確認する
システムプロキシでは通常、HTTPプロキシの入口が必要です。クライアントでSOCKSポートしか有効になっていない場合は、混合ポートを有効にするか、互換性のあるHTTPポートを正しく設定します。ポートが別のサービスに占有されている、クライアントの再起動後にポートが変わった、設定ファイルと現在の画面で使われている設定が一致していない、といった状態も、一見すると断続的な接続失敗の原因になります。
3. ログでリクエストの到達を確認する
UWPアプリを起動して一度更新し、Clashの接続ログで対象ドメインを探します。記録がまったくない場合は、アプリのプロキシ入口、ループバック除外、ファイアウォールの確認に戻ります。記録はあるものの拒否またはタイムアウトと表示される場合は、プロキシグループ、ノードの遅延、DNSの結果を確認します。直結と表示されているのにサービスへ到達できない場合は、ルールの判定または直結ネットワーク自体に問題がある可能性があります。
4. ルールモードとプロキシグループを確認する
ルールモードでは、リクエストが設定内のルール順に照合され、対応するプロキシグループへ渡されます。Microsoft関連、ログインサービス、更新サービス、静的リソースが異なるプロキシグループに振り分けられていることもあります。テスト時は一時的にグローバルモードへ切り替え、ルールによる振り分けが原因か確認できます。テスト後は日常利用に適したモードへ戻し、グローバルモードに常時依存するのではなく、ログを見ながらルールを調整してください。
5. DNS、時刻、システムのセキュリティポリシーを確認する
アプリがプロキシポートには接続できるのにドメインを解決できない場合は、ClashのDNS設定、システムDNS、現在のネットワークが関連する問い合わせを遮断していないか確認します。システム時刻が大きくずれていると、HTTPS接続やアプリストアの認証に影響します。企業管理端末では、グループポリシー、プロキシ自動構成スクリプト、セキュリティソフトによってアプリのネットワークアクセスが制限されることもあります。これらは端末管理のルールに従って対応してください。
5. TUNモードを検討するタイミング
TUNモードは仮想ネットワークインターフェースを通じて、より低い層のトラフィックを取り込みます。そのため、システムプロキシに従わない一部のプログラムもClashの処理経路へ入れられます。複数のアプリ、ゲーム、システムコンポーネントを対象にしたい場合に適していますが、有効化すると仮想NIC、ルーティング、DNS、管理者権限が関係し、トラブル対処は複雑になります。
目的が1つのUWPアプリをローカルHTTPプロキシへ接続することだけなら、まずループバック除外とシステムプロキシを確認します。複数のアプリがシステムプロキシを読み取らない場合や、アプリ自身にプロキシ設定がない場合に、TUNを検討してください。有効化する前に現在の設定を記録し、クライアントが対応するTUN実装を確認するとともに、ほかのVPN、仮想NIC、LAN共有ソフトとの競合にも注意します。
TUNを有効にした後も、Clashのログとルールの判定結果を確認してください。トラフィックがTUNに入ったからといって、必ずプロキシノードが使われるとは限りません。ルールによって直結、拒否、または特定のプロキシグループに振り分けられることがあります。LAN上の機器にアクセスできない、DNSループが発生する、ネットワークが切断されるといった場合は、まずTUNを無効にして影響範囲を確認し、ルーティングとDNS設定を順番に調べます。
6. 保存しておきたい簡易チェックリスト
- ブラウザーがClash経由で正常にアクセスでき、クライアントが動作中と表示されているか。
- UWPアプリがMicrosoft Store版か、アプリコンテナー環境で動作しているか。
- 対象アプリのPackage Family Nameが正しく、ループバック除外リストに表示されているか。
- Windowsのシステムプロキシのアドレス、ポート、プロキシ種別が、Clashの現在の待ち受け設定と一致しているか。
- アプリの起動や更新時に、Clashの接続ログへ対象ドメインが表示されるか。
- リクエスト到達後の判定が、プロキシ、直結、拒否のどれになっているか。
- ほかのVPN、プロキシソフト、企業ポリシー、ファイアウォールがネットワーク経路を変更していないか。
- システムプロキシでアプリをカバーできないことを確認してから、TUNモードや仮想NICの利用を検討する。
この種のトラブルで重要なのは、サブスクリプションを何度も入れ替えることではなく、リクエストがどの層を通っているかを確認することです。UWPのループバック制限は「アプリがローカルプロキシの入口へアクセスできるか」を解決し、ポート設定は「アプリがどのプロキシサービスへ接続するか」を決め、ルールとノードの確認は「Clashに入ったリクエストをどう転送するか」を明らかにします。層ごとに順番に検証すれば、権限、プロキシの入口、設定による振り分けを混同して変更する事態を避けられます。