まずループバック制限が原因か確認する

ブラウザーではClash経由でWebページを開けるのに、特定のMicrosoft Storeアプリだけログインや一覧の読み込み、コンテンツの取得に失敗する場合、AppContainerのネットワーク分離が原因かもしれません。典型的なケースでは、アプリがシステムプロキシを読み取り、ローカルの 127.0.0.1:7890 に接続しようとしますが、Clashの待ち受けポートに到達する前に制限されます。この場合、ノードの変更やルールの調整をしても、接続段階の問題は解消しないことがほとんどです。

UWPアプリは通常AppContainer内で動作し、既定ではローカルのループバックサービスに自由にアクセスできません。ループバックの例外設定は、指定したアプリコンテナーからローカルサービスへの接続を許可するものです。プロキシ設定ではなく、ノードの指定やDNSの変更も行いません。アプリ側でClashを経由するネットワーク経路を利用する必要があります。

実行前に3つの条件を確認

  • Clashのコアが起動しており、通常のブラウザーから同じプロキシ経由で対象サービスにアクセスできる。
  • システムプロキシまたはアプリ独自のローカルプロキシ設定を使用している。クライアントのウィンドウを開いただけでは不十分です。
  • 問題が特定のアプリに限られている。すべてのアプリがネットワークに接続できない場合は、サブスクリプション、ノード、ポート、ネットワーク接続を先に確認してください。

ここで紹介するコマンドはWindows 10／11のPowerShellで使用できます。例ではポートを 7890 としていますが、実際の操作では現在有効な設定を確認してください。説明にある数値に合わせて、正常に動作しているクライアントの待ち受けポートを変更しないでください。

システムプロキシとClashの待ち受けポートを確認

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。Windows 10でも同じ項目から確認できます。手動プロキシまたはセットアップスクリプトの設定が、クライアントの現在の状態と一致しているか確認してください。ローカルの手動プロキシを使う場合、一般的なアドレスは 127.0.0.1 です。ポートにはClashのHTTPポートまたは混合ポートを指定します。

# 設定例：待ち受けポートの項目のみを示すもので、完全な設定ではありません
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port はHTTPとSOCKSの両方のプロキシ接続を受け付けます。Windowsの手動プロキシで使うのはHTTPプロキシの入口なので、SOCKS接続専用のポートを指定しないでください。設定で port と socks-port を個別に指定している場合は、前者を選びます。

PowerShellでポートが待ち受け中か確認し、明示的にプロキシを指定したリクエストでシステムプロキシの影響を切り分けます。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/
  • 待ち受けが見つからない場合：コアが起動しているか、設定が正常に読み込まれているか、ポート番号に誤りがないか確認します。
  • 待ち受け中でもリクエストがタイムアウトする場合：Clashのログでノード、ルール、対象サービスを確認してください。すぐにループバックの例外設定へ進まないでください。
  • HTTPレスポンスが返る場合：デスクトッププロセスからのプロキシリクエストは完了しています。リダイレクトやアクセス拒否が返された場合も、ネットワーク接続の成否とサービス側の権限を分けて確認してください。

この curl.exe コマンドはUWPアプリのテストではなく、ローカルプロキシの接続経路を確認するものです。netsh winhttp show proxy で確認できるのはWinHTTPのプロキシ設定であり、ユーザーのシステムプロキシ設定の確認にはなりません。UWPアプリ1つの問題を直すために、PC全体のWinHTTP設定をリセットしないでください。

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

一部のWindows向けClash GUIクライアントには、ループバックを管理する外部ツールへの入口があります。「UWP ループバック例外」「Loopback」「UWP Loopback」などの名前で表示される場合があります。入口の場所や機能の有無はクライアントとバージョンによって異なり、すべてのmihomoクライアントに同じメニューがあるわけではありません。見つからない場合は、次のセクションで紹介するシステムコマンドを使えます。別のプロキシクライアントをインストールする必要はありません。

  1. 現在の設定を保存し、問題が発生しているアプリ名を控えます。
  2. クライアントの設定からループバック管理ツールを開いて起動します。ユーザーアカウント制御の確認が表示されたら、プログラムの配布元を確認してから許可してください。
  3. アプリ一覧から対象アプリを探し、該当項目にチェックを入れます。ローカルプロキシへのアクセスが本当に必要なアプリだけを許可してください。
  4. ツール内の保存または変更の適用を実行します。チェックを入れただけで保存していない場合、システムの例外リストには反映されません。
  5. 対象アプリを完全に終了してから再起動し、同じログインや読み込み操作をもう一度試します。

アプリ一覧に対象がない場合は、現在のWindowsユーザーにインストールされているか確認してください。アプリによっては複数のパッケージや独立したコンポーネントで構成されており、画面に表示される名前と実際に通信するパッケージ名が異なることがあります。その場合は、名前の似た項目を片端から選ぶのではなく、PowerShellでパッケージ識別子を調べてください。

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

1. PackageFamilyNameを調べる

現在ログインしているユーザーのPowerShellで、次のコマンドを実行します。例としてMicrosoft Storeのパッケージを使いますが、これは識別子の調べ方を示すためのものです。ダウンロードやログインの問題がすべてループバックの例外設定で解決するわけではありません。

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

一般的なパッケージファミリー名は Microsoft.WindowsStore_8wekyb3d8bbwe ですが、実際にはPC上の出力を確認してください。他のアプリは、現在のユーザーにインストールされているパッケージを一覧表示し、表示された Name で絞り込めます。

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

PackageFamilyName と PackageFullName は別のものです。後者には通常、バージョンやアーキテクチャなどの情報が含まれるため、下記の -n パラメーターにそのまま渡さないでください。アプリのインストール先パスも使用できません。何も表示されない場合は、パッケージ名、インストールしたユーザー、アプリの種類を確認してください。

2. 管理者権限のターミナルで例外を追加して確認する

スタートボタンを右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を選択します。できるだけ対象アプリと同じアカウントで管理者権限を取得してください。別の管理者アカウントの資格情報を入力してターミナルを起動する場合、取得したアプリパッケージが正しいユーザーのものか確認してください。

CheckNetIsolation.exe LoopbackExempt -s

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

CheckNetIsolation.exe LoopbackExempt -s

-s は既存の例外を一覧表示し、-a は指定したアプリを追加します。最初に一覧を取得して変更前の状態を控え、再度一覧を取得して結果を確認します。出力にアプリ名とSIDの両方が表示される場合があります。コマンドでエラーが出なかったことだけでなく、対象の項目があることを確認してください。

追加後、対象アプリを完全に終了して再起動します。必要に応じてタスクマネージャーでプロセスが終了したことを確認してください。通常、Windows全体を再起動する必要はありません。アプリがバックグラウンドで常駐する場合、ウィンドウを閉じるだけでは新しい接続が確立されないことがあります。

3. 個別の例外を削除する

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

CheckNetIsolation.exe LoopbackExempt -s

-d は指定したアプリの許可を取り消します。トラブルシューティング中に、すべての例外をまとめて削除しないでください。他の開発ツールやローカルサービスが既存の項目を利用している場合があります。アクセス拒否が表示されたら、まずターミナルが管理者権限で起動しているか確認してください。組織のポリシーで管理されている端末では、管理者に権限の範囲を確認してください。

例外を追加しても動作しない場合：接続段階ごとに確認

例外リストに対象アプリが表示されても、許可が登録されたことしか分からず、リクエストがプロキシを通った証拠にはなりません。Clashの接続履歴またはログを開いてから、対象の操作をもう一度試してください。ノードの変更、TUNの有効化、DNSの変更を同時に行うと原因を特定できなくなるため、一度に変更する条件は1つにしてください。

確認できた状況 優先して確認する項目 次に行うこと
Clashに該当する接続が表示されない アプリがシステムプロキシを使っているか、パッケージ識別子が正しいか アプリを再起動し、システムプロキシと実際に通信するコンポーネントを確認する
接続履歴でDIRECTに振り分けられている ルールの順序と現在の動作モード 適用されたルールを確認し、例外の追加を繰り返さない
プロキシに接続するがタイムアウトする ノードの状態、接続元の地域、対象サービス 同じ接続先で比較し、接続エラーを確認する
ドメイン名の名前解決に失敗する アプリ、システム、コアで実際に使われる名前解決経路 DNSリクエストを処理している箇所を確認し、該当する設定を調整する
ログインまたはダウンロードだけが失敗する 独立したバックグラウンドサービス、アカウント、サービス側の制限 ログイン、一覧表示、ダウンロードのリクエストを個別に確認する

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

ループバックの例外設定を追加しても、アプリがWindowsのプロキシ設定を使うようになるわけではありません。独自のネットワークスタックを使う、リモートサーバーへ直接接続する、システムサービスが代わりにリクエストを送信するといった場合、前面のアプリに例外を設定しても実際の通信経路には影響しないことがあります。ストアのページは開けてもダウンロードに失敗する場合、ダウンロード時に別のサービス経由へ切り替わっている可能性もあります。

ルールには一致するが、接続元の地域が要件に合わない

接続がClashに記録されている場合は、mode: rule で適用されたルールと、ポリシーグループで最終的に選ばれた接続先を確認してください。接続先の地域、アカウントの状態、アクセス頻度などに応じて、サービス側がエラーを返すことがあります。この種の応答は、ループバックの許可を追加しても解決しません。ノードの遅延テストが成功しただけで、対象サービスも必ず利用できると判断しないでください。

ファイアウォール、組織のポリシー、ネットワーク機能

ローカルファイアウォール、エンドポイントセキュリティポリシー、アプリが宣言するネットワーク機能によって、接続が制限される場合もあります。ループバックの例外設定は、あらゆるネットワーク制限を解除するものではありません。具体的なエラーコード、発生時刻、関連ログを記録し、個々のプロセスに適用されるポリシーを確認してください。長期的な対処として、ファイアウォール全体を無効にすることは避けてください。

TUNに切り替える場合とシステムプロキシを使う場合

アプリがシステムプロキシを明確に無視し、ClashでそのIP通信を処理する必要がある場合は、mihomoのTUNモードを検討できます。TUNは仮想ネットワークインターフェイスとルーティングを使って通信を処理するため、アプリごとにHTTPプロキシポートへ接続させる必要はありません。ただし、対象範囲はルーティング、除外ルール、DNS設定、システム権限の影響を受けます。

  • 一部のAppContainerアプリだけがローカルプロキシを必要とする場合：影響範囲を絞りやすいよう、まずシステムプロキシと必要なアプリだけのループバック例外を使います。
  • アプリがプロキシ設定を使わずに直接通信する場合：基本設定を確認したうえでTUNを個別にテストし、実際の接続履歴を確認します。
  • TUNを有効にしてもシステムプロキシを使い続ける場合：アプリが引き続きローカルプロキシに接続することがあり、ループバック制限も残る可能性があります。TUNを有効にすれば必ず例外設定が不要になるわけではありません。
  • 企業VPNや他の仮想ネットワークアダプターを使用している場合：ルーティングとDNSの競合を先に確認してください。複数の通信制御機能を同時に有効にして解決を期待しないでください。

allow-lan: true はループバックの例外設定の代わりにはなりません。この項目は他の端末からプロキシの待ち受けに接続できるようにする設定であり、ローカルのAppContainerからループバックへのアクセスを許可する設定とは異なります。UWPの問題を直すためだけに待ち受け範囲を広げると、追加のアクセス制御が必要になります。

設定後の動作確認と管理

  1. 追加前後の LoopbackExempt -s の出力を保存し、意図したアプリだけが追加されたことを確認します。
  2. 対象アプリを再起動し、起動ページだけでなく、ログイン、コンテンツの読み込み、ダウンロードを個別にテストします。
  3. Clashの接続履歴で対象ドメイン、適用ルール、選択されたポリシーを確認し、通信経路が想定どおりか確かめます。
  4. トラブルシューティングのために変更した一時的なグローバルモード、DNS設定、その他の無関係な項目を元に戻してから、もう一度テストします。

通常のアプリ更新でパッケージファミリー名が変わることはほとんどないため、アップデートのたびに再許可する必要はありません。アプリのアンインストール後に再インストールした場合、配布元を変更した場合、Windowsのアカウントを切り替えた場合、またはシステムを再構築した場合は、パッケージ識別子と例外リストを改めて確認してください。

原因の調査では、問題が発生している段階を特定してください。ローカルポートが待ち受けているか、アプリがループバックにアクセスできるか、リクエストがコアに届いているか、ルールがどの接続先へ振り分けたか、対象サービスが何を返したかを順に確認します。この順序で調べると、AppContainerの権限問題をサブスクリプション、ノード、DNS、サービス側の問題と切り分けられます。