Windows UWPアプリがプロキシにつながらない?Clashのループバック制限を解除する方法

UWPアプリがローカルプロキシに接続できない原因と、クライアント内蔵ツール、CheckNetIsolation、TUNモードによる解決方法を解説。

UWPのループバック制限:ブラウザーは使えるのにストアアプリは接続できない

WindowsでClashの「システムプロキシ」を有効にすると、ブラウザーではサイトを開けるのに、Microsoft Storeや一部のUWPアプリでは読み込みが続くことがあります。すぐにサブスクリプションを切り替える必要はありません。ブラウザーが使えるのは、そのブラウザーのプロキシ経路が機能していることを示すだけで、サンドボックスアプリが同じローカルポートに接続できるとは限りません。

UWPアプリは通常、AppContainerの分離環境で実行されます。初期設定では、こうしたアプリからローカルのループバックアドレスへのアクセスが制限されています。Clash系クライアントは、HTTPプロキシまたは混合プロキシを127.0.0.1で待ち受け、システムプロキシはアプリのリクエストをこのアドレスへ転送します。アプリがシステムプロキシを参照していても、サンドボックスからループバックポートへの接続が許可されていなければ、リクエストはmihomoのコアに届く前に失敗します。そのため、ログに該当する記録が残らない場合もあります。

まず3つの仕組みを区別する

  • システムプロキシ:この設定を参照するアプリにローカルプロキシを使うよう指示します。すべてのプログラムの通信を中継するものではありません。
  • ループバックの除外:指定したAppContainerからループバックネットワークへのアクセスを許可します。アプリのプロキシ設定やClashのルールは変更されません。
  • TUNモード:仮想ネットワークインターフェースとルーティングを使い、条件に合う通信を取り込みます。アプリごとにHTTPシステムプロキシを参照させる必要はありません。

操作前の確認:待ち受けポート、システムプロキシ、ルールの適用状況

まずクライアントで実際の待ち受けポートを確認します。以下ではmixed-port: 7890を例にします。これはサンプル値で、すべてのクライアントの初期設定とは限りません。画面に混合ポートとして7897と表示されている場合は、後のコマンドも7897に変更してください。コントローラーのポートをプロキシポートと取り違えないようにしましょう。external-controllerはコアの管理用で、通常のHTTPプロキシリクエストは受け付けません。

  1. サブスクリプションが読み込まれ、クライアントが起動していることと、利用可能なプロキシグループの出口が選択されていることを確認します。
  2. Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシ セットアップ」のアドレスとポートが現在のクライアントと一致するか確認します。Windows 10の場合も「設定」→「ネットワークとインターネット」→「プロキシ」から確認できます。
  3. まずはTUNをオフにし、システムプロキシだけを有効にします。2つの通信制御方式が同時に働くことで起きる問題を避けられます。
  4. PowerShellでローカルポートへの接続を確認してから、プロキシを明示したリクエストで経路をテストします。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://www.microsoft.com/

TcpTestSucceeded: Trueは、PowerShellを実行しているデスクトッププロセスからローカルTCP接続を確立できたことを示すだけです。UWPのサンドボックスからのアクセスが許可されたことを意味しません。2つ目のコマンドでは、HTTPプロキシがHTTPSトンネルを処理できるかを確認します。HTTPレスポンスヘッダーが表示された場合、このテスト経路で応答を受け取れていますが、接続先がどの出口を経由したかはクライアントのログも確認してください。

「接続」または「ログ」画面で、接続先ドメインと適用されたポリシーを確認します。アプリのリクエストが記録され、DIRECTに一致している場合は、ループバックの除外を追加する前にルールを確認しましょう。ルールモードでは上から順に評価され、末尾のMATCHより前に記述されたドメインルールが優先されます。ループバック設定によってDIRECTルールがプロキシルールに変わることはありません。

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

一部のWindows版Clashクライアントには、ループバックの除外を設定する機能が組み込まれています。設定場所はクライアントやバージョンによって異なるため、「設定」で「UWP」「ループバック解除」「Loopback」などの項目を探してください。この項目が実際にある場合のみ、この方法を使います。見当たらなくてもコアのプロキシ機能が使えないわけではありません。次のセクションで紹介するWindowsのコマンドを使用できます。

  1. 内蔵のループバックツールを開きます。Windowsのユーザーアカウント制御が表示された場合は、プログラムの提供元を確認してから許可してください。除外設定の変更には通常、管理者権限が必要です。
  2. アプリ一覧から、問題が発生しているパッケージ(Microsoft Storeなど)を探します。対象を絞って選択し、一覧全体を一度に許可しないでください。
  3. ツールの「保存」または「適用」をクリックします。設定がすぐ反映される方式の場合は、画面の案内に従ってください。
  4. 対象アプリを完全に終了してから、もう一度起動します。ウィンドウを閉じてもバックグラウンドで動作している場合は、タスクマネージャーで該当プロセスを終了してから再試行してください。
  5. 先ほど失敗した操作をもう一度行い、Clashの接続ログを確認します。次のセクションの照会コマンドも使い、除外設定が実際に登録されたか確認してください。

この種のツールは、Windowsのループバック除外リストを管理するもので、サブスクリプションの内容は変更しません。保存後も対象アプリが動作しない場合は、正しいパッケージを選択したか、アプリを完全に再起動したかを確認してください。画面でチェックが付いていることだけを、設定の確認手段にしないでください。

方法2:CheckNetIsolationで除外を個別に追加・削除する

CheckNetIsolation.exeはWindows標準のネットワーク分離診断ツールです。クライアントに設定項目がない場合、現在の除外状態を確認したい場合、または特定のアプリだけにアクセスを許可したい場合に便利です。追加・削除の操作は、現在ログインしているユーザーの管理者権限でPowerShellを開いて実行してください。別の管理者アカウントの資格情報を使う場合は、照会したアプリが対象ユーザーのものか特に注意して確認します。

1. パッケージファミリ名を確認する

スタートメニューでPowerShellを検索し、「管理者として実行」を選びます。まずMicrosoft Storeのパッケージ情報を確認します。

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

コマンドの戻り値にあるPackageFamilyNameが、-n=に指定するパッケージファミリ名です。バージョン番号やアーキテクチャ情報を含むPackageFullNameや、スタートメニューに表示される名前は使わないでください。ほかのアプリの場合は、まず現在のユーザーのパッケージ一覧を表示し、Nameを手がかりに探します。

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

2. 対象アプリを追加して結果を確認する

次のコマンドはMicrosoft Storeのパッケージファミリ名を自動取得するため、コピー時に空白が混入するのを防げます。パッケージが見つからない場合は、空の引数を渡さずに処理を中止します。

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $store) {
    Write-Error "Microsoft.WindowsStore パッケージが現在のユーザーに見つかりません。"
} else {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

-aは追加、-sは現在の除外項目の一覧表示を意味します。出力にはパッケージ名または対応するAppContainer SIDが含まれる場合があります。SIDを確認するには、Get-AppContainerProfile -Name *を実行します。追加後はMicrosoft Storeを完全に終了してから再起動し、元の操作をもう一度試してください。

3. 今回追加した項目を削除する

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -ne $store) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

-dは指定した項目を削除します。元に戻す場合は今回追加した項目だけを削除し、ほかのアプリに影響する一括削除コマンドは使わないでください。アプリの再インストールやパッケージ情報の変更、システムのリセット後は、以前の実行履歴だけで判断せず、現在の状態をあらためて確認してください。

方法3:システムプロキシを参照しないアプリをTUNで取り込む

対象アプリがシステムプロキシを参照しない場合、ループバックの除外を追加しても、自動的に127.0.0.1:7890へ接続するようにはなりません。その場合は、mihomoのTUNに対応したクライアントを検討できます。アプリは本来の接続先に接続し、仮想ネットワークインターフェースが通信を取り込みます。変わるのは通信がコアに入る経路であり、Windowsのネットワーク分離ポリシーがすべて無効になるわけではありません。

  1. アプリがローカルプロキシポートへの接続を試みないよう、まずシステムプロキシをオフにします。
  2. クライアントの案内に従ってサービスモードをインストールまたは起動し、「TUNモード」を有効にします。Windowsで仮想インターフェースを作成したりルートを設定したりするには、適切な権限が必要です。
  3. ほかのVPNや同種の仮想ネットワークアダプターを一時的に終了します。既存の設定は記録しておき、システムルートを直接削除しないでください。
  4. 対象アプリを完全に再起動し、接続画面で接続先アドレス、ルール、プロキシグループを確認します。
  5. 接続ログがない場合は、TUNのルート、DNS、アプリ自体のネットワーク権限を引き続き確認します。ログがある場合は、適用されたルールを基に原因を調べてください。

mihomoの設定を直接管理している方向けに、よく使われるTUNの項目を紹介します。以下の数行でサブスクリプション全体を置き換えず、既存の設定に統合してください。クライアントの画面からTUN設定を生成する場合は、実行時の上書きと手動設定が競合しないよう、画面から設定する方法を優先してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-routeは通信経路の自動設定、auto-detect-interfaceは出口インターフェースの検出に使います。dns-hijackは条件に一致する従来型DNS通信を対象とした設定であり、すべての暗号化DNSを取り込むものではありません。既存のdns設定が有効であることと、使用するプロトコルスタックが現在のクライアントおよびコアでサポートされていることも確認してください。

TUNは、ストアアプリのあらゆる問題を解決するものではありません。AppContainerの機能制限、組織のポリシー、アプリ独自のプロキシ実装、バックグラウンドサービスの通信方式が接続に影響することがあります。アプリが引き続きローカルHTTPプロキシへ明示的に接続する場合、ループバック制限が残る可能性もあります。そのため、TUNのテストではシステムプロキシをオフにし、アプリを再起動することが重要です。

3つの方法の選び方:変更範囲を絞ってから確認する

方法 適したケース 確認方法・元に戻す方法
クライアント内蔵のループバックツール アプリがシステムプロキシを参照し、クライアントにUWP管理機能がある 除外リストを確認し、対象アプリのチェックを外して保存
CheckNetIsolation パッケージを正確に指定したい場合、状態を確認したい場合、または個別の許可を取り消したい場合 -sで確認し、-dで指定項目を削除
TUNモード アプリがシステムプロキシを参照しない場合、またはより多くの通信を取り込みたい場合 接続ログとルートを確認し、TUNをオフにして元の通信制御方式に戻す

まずローカルポートが使えることを確認し、対象アプリ1つだけにループバックの除外を追加する方法がおすすめです。それでもアプリのリクエストがコアに届かない場合に、TUNを個別にテストしてください。一度に変更する設定は1つに絞りましょう。そうすれば、接続が回復した場合も、どの設定が有効だったのか特定しやすくなります。

まだ接続できない場合:ログの段階に応じて原因を調べる

接続ログがない

  • アプリを本当に再起動したか、現在のユーザーが使っているパッケージを変更したか確認します。
  • クライアントの再起動後にシステムプロキシのポートが変わっていないか、別のプロキシソフトがWindowsの設定を上書きしていないか確認します。
  • 会社や学校が管理するデバイスでは、ループバックの除外、仮想ネットワークアダプター、ルート変更が制限されている場合があります。デバイス管理ポリシーに従ってください。

接続ログはあるが、DIRECTになっている

ループバック経路が主な原因である可能性は低くなります。一致したルールの種類と内容、プロキシグループの選択を確認し、そのドメインをDIRECTとプロキシのどちらに設定すべきか判断してください。Microsoft Storeでは、ページ表示、サインイン、ダウンロードに異なるドメインやバックグラウンドサービスが使われる場合があります。一度の失敗を解決するために、すべてのMicrosoftドメインを同じポリシーに固定するのは避けましょう。

プロキシ経由だが、サインインやダウンロードに失敗する

失敗する段階を分けて記録します。ストアのトップページ表示、アカウントへのサインイン、ダウンロードURLの取得、インストーラーの実際のダウンロードをそれぞれ確認してください。トップページが開けても、ダウンロードサービスが同じネットワーク経路を使うとは限りません。そのうえで、ノードへの接続、DNSの応答、システム時刻、証明書エラーを確認します。netsh winhttp reset proxyは汎用的な解決策ではありません。WinHTTPの設定と、現在のユーザーのシステムプロキシ設定は別のものです。

調査が終わったら、必要な項目だけ除外設定として残し、一時的な変更は元に戻します。システムプロキシを参照するUWPアプリ1つにローカルプロキシを使わせるだけなら、ループバックの除外のほうが、TUNをシステム全体で常時有効にするより状態を確認しやすいでしょう。複数のプログラムがシステムプロキシを無視する場合は、TUNがシステム全体のルーティングやDNSに与える影響を検討してください。

Clash ダウンロード