Windows UWPアプリでClashが使えない：ループバック制限の解除と確認手順

Windowsでよくあるプロキシ障害の一つに、ブラウザーや従来型のデスクトップソフトはClash経由で正常に通信できるのに、Microsoft Storeからインストールした特定のアプリだけがオフライン表示になったり、ログインできなかったり、コンテンツを更新できなかったりするケースがあります。この場合、サブスクリプションのノードに問題があるとは限らず、ルールの記述ミスとも限りません。原因は、UWPアプリが利用するAppContainerのネットワーク分離と、Clashのローカルプロキシがループバックアドレスで待ち受けている点の違いにある可能性があります。

Clash、Clash Meta、mihomoのGUIクライアントでシステムプロキシを有効にすると、通常はWindowsがHTTPおよびHTTPSリクエストを、たとえば 127.0.0.1:7890 のようなローカルの待ち受けアドレスへ渡します。従来型のWin32アプリはこのアドレスへ接続できますが、AppContainerの制約を受けるストアアプリは、ローカルのループバックインターフェースにアクセスできない場合があります。その結果、同じシステムプロキシ設定でもデスクトップソフトでは機能する一方、特定のUWPアプリでは機能しません。

ループバック制限が一部のWindowsアプリだけに影響する理由

ループバックアドレスは、現在使用しているコンピューター自身を指します。Clashがローカルでプロキシポートを起動すると、アプリはまずこのコンピューター上のポートへ接続し、プロキシコアがルールに従ってDIRECT、REJECT、またはいずれかのプロキシグループを選択します。アプリから見ると、最初の接続先は目的のWebサイトではなく、ローカルで動作するプロキシサービスです。

UWPアプリや、AppContainerによる分離を採用する一部のコンポーネントには、独立したネットワーク権限の境界があります。Windowsは通常、分離されたアプリとローカルサービス間の無許可通信を減らすため、これらのコンテナーによるローカルのループバックインターフェースへのアクセスを制限します。システムプロキシにローカルプロキシのアドレスが登録されていても、各AppContainerアプリのループバックアクセスが自動的に許可されるわけではありません。そのため、設定画面でプロキシが有効になっていても、すべてのストアアプリがClashの待ち受けポートへ接続できるとは限りません。

よくある症状

Microsoft Store、電卓のオンライン機能、天気アプリなどのストアアプリで、接続できないというメッセージが表示される。
Chrome、Firefox、従来型のデスクトップクライアントなどのWin32プログラムは、通常どおりインターネットにアクセスできる。
問題のアプリで更新操作を実行しても、Clashのログに対象ドメインへのアクセス記録が表示されない。
システムプロキシを無効にするとアプリが直接接続できるようになる場合があるが、プロキシを再び有効にすると同じ問題が起きる。
同じアプリが、ループバック除外設定済みの別のコンピューターでは正常に動作する。

Microsoft Storeからインストールしたソフトが、すべてこの制限を受けるわけではありません。ストアアプリの中には、実際にはパッケージ化された従来型デスクトッププログラムもあり、別のネットワークコンポーネントを使うアプリもあります。トラブル対策では、インストール元だけで判断せず、アプリのパッケージID、実際のログ、接続動作を基準に確認してください。

変更前にClashの待ち受けとシステムプロキシを確認する

ループバック除外設定で解決できるのは、AppContainerがローカルのプロキシポートへアクセスする権限の問題だけです。Clashが起動していない、ポートが一致していない、システムプロキシが古いポートを指しているといった状態では、除外設定を追加しても接続は復旧しません。まずは次の順番で基本項目を確認してください。

プロキシコアが動作していることを確認します。使用中のClash GUIクライアントを開き、設定が読み込まれていること、プロキシノードまたはプロキシグループで遅延テストを実行できることを確認します。
システムプロキシが有効であることを確認します。クライアントの「システムプロキシ」スイッチがオンになっている必要があります。手動設定を使用している場合は、Windowsのプロキシアドレスがクライアントに表示されるHTTPポートまたはmixed-portと一致していることを確認します。
ポートが別のプロセスに使用されていないことを確認します。クライアントの起動失敗を繰り返したり、ログに待ち受けエラーが表示されたりする場合は、使用中のプロセスを終了するか、ポートを変更します。
接続ログを確認します。正常に動作するデスクトップブラウザーでWebページを開き、Clashのログに接続記録が作成されることを確認します。その後、問題のアプリを操作し、新しいリクエストが表示されるか比較します。
一時的にルールの影響を切り分けます。問題のアプリからのリクエストがすでにログに表示されている場合、原因はループバック制限ではなく、ルールのマッチング、プロキシグループ、DNS、またはノードにある可能性が高くなります。

PowerShellで、現在のユーザーに適用されているInternetプロキシ設定を確認できます。このコマンドは確認専用で、設定は変更しません。

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

ProxyEnable が有効で、ProxyServer がローカルアドレスを指している場合は、手動のシステムプロキシが登録されています。クライアントによってはPACスクリプトを使用するため、その場合は AutoConfigURL も確認してください。また、WindowsのWinHTTPプロキシと、現在のユーザーに適用されるInternetプロキシは別の設定です。netsh winhttp show proxy の結果だけで、Clashのシステムプロキシが機能していると判断しないでください。

UWPアプリのパッケージファミリ名を特定する

CheckNetIsolation で使用するのはPackage Family Name、つまりパッケージファミリ名です。スタートメニューに表示される日本語名でも、完全なバージョン番号を含むPackage Full Nameでもありません。項目を間違えると、コマンドが対象アプリに適用されない場合があります。

PowerShellで検索する

Windows電卓を例に、PowerShellを開いて次のコマンドを実行します。

Get-AppxPackage -Name "*WindowsCalculator*" |
  Select-Object Name, PackageFamilyName

出力される PackageFamilyName は、たとえば Microsoft.WindowsCalculator_8wekyb3d8bbwe のような値です。アプリごとに異なるため、実際の端末で取得した結果を使用してください。パッケージ名が分からない場合は、現在のユーザーにインストールされているアプリを名前順で一覧表示できます。

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

アプリ数が多い場合は、名前の一部を指定して候補を絞り込めます。たとえばMicrosoft Storeを検索する場合は次のようにします。

Get-AppxPackage -Name "*WindowsStore*" |
  Select-Object Name, PackageFamilyName

2種類のパッケージ識別子を混同しない

項目	用途	識別のポイント
`PackageFamilyName`	ループバック除外に使用	通常はパッケージ名と発行元IDで構成され、バージョンやアーキテクチャを含まない
`PackageFullName`	インストール済みの特定バージョンを識別	通常はバージョン番号、CPUアーキテクチャ、リソース情報を含む
`Name`	PowerShellでの検索とパッケージ識別	スタートメニューの表示名より安定していますが、パッケージファミリ名をそのまま代用することはできません

コンピューターに複数のWindowsユーザーがいる場合は、実際にアプリを実行するアカウントで検索してください。特定のユーザーだけにインストールされているパッケージもあるため、管理者アカウントで取得したアプリ一覧が、普段使うアカウントと完全に一致するとは限りません。

CheckNetIsolationでループバック除外を追加する

対象アプリとClashの基本接続が正常であることを確認したら、Windows標準の CheckNetIsolation.exe でAppContainerのループバック除外を管理できます。まず対象アプリを終了し、管理者権限でPowerShellまたはWindowsターミナルを開くことをおすすめします。

単一アプリに権限を付与する

次のPowerShellコマンドは、まず電卓のパッケージを取得し、端末で実際に確認したパッケージファミリ名をシステムツールへ渡します。

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -a -n="$($pkg.PackageFamilyName)"

検索結果が複数のパッケージを返した場合は、そのまま一括実行しないでください。各項目の Name と PackageFamilyName を確認し、対象を特定してから追加します。確認済みのパッケージファミリ名をコマンドへ直接記述することもできます。

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

コマンドの -a は追加を、-n の後ろはパッケージファミリ名を示します。実行後は対象アプリを完全に終了してから再度開いてください。ウィンドウを閉じるだけではバックグラウンドプロセスが終了しないことがあるため、タスクマネージャーでアプリが停止していることを確認します。

現在の除外一覧を確認する

CheckNetIsolation.exe LoopbackExempt -s

一覧を見ると、除外設定が登録されているか確認でき、以前の設定の残りも見つけられます。出力形式はシステム識別子に近く、スタートメニューの表示名と一致しない場合があります。PowerShellの検索結果と照合してください。

権限付与後にプロキシ、ルール、DNSを確認する

ループバック権限の追加に成功しても、アプリがローカルプロキシへ接続を試行できるようになっただけで、その後のプロキシ経路が必ず正常になるわけではありません。アプリ、Clashログ、ルールのマッチング、接続先サービスの4つの観点から順番に確認してください。

対象アプリを再起動します。ログイン、更新、コンテンツの読み込みをもう一度実行し、エラーメッセージに変化があるか確認します。
Clashのログを確認します。対象ドメインや接続記録が表示され始めた場合、アプリはローカルのプロキシポートへ到達できています。
適用されたルールを確認します。リクエストが想定したプロキシグループに入っていることを確認し、REJECT、誤ったドメインルール、または意図しないDIRECTルールで遮断されていないか確認します。
利用可能なプロキシを切り替えます。プロキシグループで、接続できることを確認済みのノードを選択し、ノード障害とループバック権限の問題を混同しないようにします。
DNSを確認します。ログにドメイン解決エラーが表示される場合は、ClashのDNS設定、システムDNS、Fake IPの互換性、アプリが特殊な名前解決方式を使用していないかを確認します。

接続記録が表示されるのにアプリが失敗する場合は、一時的にルールが単純な設定へ切り替えて比較します。目的は分流を恒久的に回避することではなく、原因がルール層にあるのかアプリ層にあるのかを切り分けることです。テスト後は元の設定に戻し、実際のドメインに合わせてルールを調整してください。

アプリによっては、認証、コンテンツ配信、テレメトリ、証明書状態の確認などで複数のサービスへ同時にアクセスします。メインドメインだけを許可しても十分とは限りません。ログから必要なリクエスト全体を特定し、名前だけでドメインを推測しないでください。直接接続が必要なWindowsサービスには明確なDIRECTルールを作成し、プロキシが必要なコンテンツドメインは対応するプロキシグループへ入れます。

システムプロキシとTUNモードの違い

システムプロキシは、アプリがWindowsのプロキシ設定を自ら読み取り、Clashが公開するローカルHTTPポートまたは混合ポートへ接続する仕組みです。UWPのループバック制限は、この接続段階で影響します。一方、TUNモードは仮想ネットワークインターフェースを通じて、より広範囲の通信を引き受けます。システムプロキシに従わないアプリも対象にできる場合があります。

ただし、TUNはループバック問題に対する万能な代替策ではありません。TUNを有効にすると、管理者権限、仮想NIC、ルーティング、DNSハイジャック、ファイアウォール、ほかのVPNソフトとの互換性なども関係します。少数のUWPアプリで既存のシステムプロキシを使いたいだけなら、正確なループバック除外を追加するほうが検証しやすいでしょう。多数のアプリがシステムプロキシを読み取らず、ルーティングとDNSの設定を理解したうえで運用できる場合は、mihomoコアがサポートするTUNモードの利用を検討するのが適切です。

それでも接続できない場合の段階的なトラブル対策

Clashのログにリクエストがまったく表示されない

まず除外一覧のコマンドをもう一度実行し、対象パッケージが登録されていることを確認します。次に、アプリが別のパッケージに該当していないか、更新後にパッケージIDが変わっていないか、現在の実行ユーザーがパッケージ情報を検索したユーザーと一致しているかを確認します。システムプロキシのアドレスが本当にループバックアドレスであること、アプリがシステムプロキシを迂回していないことも確認してください。

ログにリクエストは表示されるが接続がタイムアウトする

通常、これはループバック段階を通過していることを示します。次にノードの接続性、プロキシグループの選択、接続先ポート、ネットワーク環境を確認します。同じサービスへデスクトップブラウザーからアクセスして比較できますが、ブラウザーとアプリではアクセスするドメイン群が異なる場合がある点に注意してください。

ログにDIRECTと表示された後に失敗する

ルールの順番を確認します。Clashのルールは設定に記載された順序で評価されるため、広すぎるDIRECTルールが対象ルールより先に適用されることがあります。変更時はルールの意味を明確に保ち、一覧の末尾に適切な最終処理を置いてください。たとえば MATCH に対応するプロキシグループを指定します。

TUNを有効にしても改善しない

TUNが実際に起動しているか、ルーティングテーブルが別のVPNやセキュリティソフトによって書き換えられていないか、DNSリクエストが想定した名前解決経路に入っているかを確認します。仮想NICを作成するツールを複数同時に有効にしないでください。ほかのネットワークツールを終了して改善する場合は、ルートの優先順位またはドライバーの競合が原因である可能性が高くなります。

Microsoft Storeは閲覧できるがダウンロードできない

ストアページの読み込みとアプリパッケージのダウンロードでは、異なるサービスが使われる場合があります。この場合はClashのルールだけでなく、Windows Update、バックグラウンドインテリジェント転送サービス、関連するシステムサービスの状態も確認してください。ループバック除外は、コンテナーによるローカルアクセスにだけ影響し、停止されたシステムサービス、アカウント権限、ストアキャッシュを修復するものではありません。

ループバック除外を取り消して設定を復元する

アプリがClash経由で接続する必要がなくなった場合、アンインストールした場合、または原因がループバックと無関係だと判明した場合は、対応する除外を取り消せます。コマンドの -d は削除を示します。

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -d -n="$($pkg.PackageFamilyName)"

確認済みのパッケージファミリ名を使用することもできます。

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

取り消し後、CheckNetIsolation.exe LoopbackExempt -s をもう一度実行し、対象項目が一覧から削除されたことを確認します。その後、アプリを再起動してネットワーク動作を確認してください。トラブル対策中にシステムプロキシ、Clashのポート、DNS、ルールモード、TUNスイッチを変更した場合は、ループバック除外を削除するだけでなく、各項目を個別に元へ戻します。

残しておくとよいトラブル対策の記録

対象アプリの名前とPackage Family Name。
Clashで使用しているコア、待ち受けポート、プロキシモード。
除外を追加する前後のログの違い。
リクエストが適用されたルールとプロキシグループ。
TUN、ほかのVPN、ネットワークフィルタリングソフトを有効にしているか。
最終的な解決手順と取り消しコマンド。

このような記録があれば、「アプリがローカルプロキシへアクセスできない」状態と、「プロキシはリクエストを受け取っているが、その後の接続に失敗している」状態を区別できます。前者ではAppContainerとループバック権限を、後者ではルール、DNS、ノード、接続先サービスを重点的に確認します。接続経路ごとに段階を分けて判断するほうが、クライアントの再インストールやサブスクリプションの変更を繰り返すより、原因を早く特定できます。