WindowsストアアプリでClashのプロキシが使えない場合：CheckNetIsolationでUWPのループバック制限を解除

ブラウザーは使えるのにストアアプリは接続できない：まずはループバック制限を確認

WindowsでClashのシステムプロキシを有効にすると、ブラウザーではサイトを開けるのに、Microsoft Storeや一部のUWPアプリではネットワークに接続できないことがあります。この違いは、AppContainerによるネットワーク分離が原因かもしれません。システムプロキシの接続先は通常、127.0.0.1:7890のようなローカルアドレスです。分離されたアプリは、Clashのコアに接続する前にWindowsによって通信をブロックされる場合があります。

ただし、「ストアからインストールした」ことだけで「UWPサンドボックスで動作している」とは限りません。Microsoft Storeでは通常のデスクトップアプリも配布されており、MSIXでフル信頼のデスクトップアプリをパッケージ化することもできます。ループバック例外を設定する前に、対象アプリの実行方式を確認しましょう。アプリがシステムプロキシを使っていない、プロキシのポート番号が間違っている、ログインサービスに障害がある、といった理由でも同じような症状が起こります。

3つの状況をまとめて確認

通常のデスクトップブラウザーで同じサービスに接続できる：現在のノードと基本的なプロキシ経路が機能している可能性があります。ただし、ブラウザーに独自のプロキシ拡張機能がある場合、システムプロキシが有効だとは判断できません。
対象アプリの操作中に該当する接続記録がない：Clashの接続またはログ画面を開き、アプリを再読み込みします。記録がない場合、通信が事前にブロックされたか、アプリがシステムプロキシを使っていない可能性があります。
システムプロキシの接続先がローカルになっている：アドレスが127.0.0.1、localhost、またはループバックIPv6アドレスの::1か確認し、ポート番号がコアの実際の待ち受けポートと一致しているかも確認します。

UWPサンドボックスと127.0.0.1の接続

ループバックアドレスはこのコンピューター自身を指し、外部のノードを指すものではありません。一般的な接続経路は「アプリ → ローカルHTTPプロキシポート → Clashまたはmihomoコア → ルールで選択された出口」です。システムプロキシの設定は、その設定に従うアプリに接続先を知らせるだけで、アプリに適用されるネットワーク分離を解除するものではありません。

UWPアプリは通常、AppContainer内で実行されます。Windowsはアプリとローカルサービスの分離を保つため、こうしたアプリがローカルのループバックサービスに接続することを既定で制限しています。プロキシサービスが起動していても、アプリは127.0.0.1:7890に接続できない場合があります。CheckNetIsolation LoopbackExemptを使うと、指定したアプリパッケージにループバック例外を設定し、ローカルサービスへのアクセスを許可できます。

操作	実際の役割	併せて確認する項目
システムプロキシを有効にする	ローカルのプロキシアドレスとポートを設定する	アプリがシステムプロキシを参照しているか
ループバック例外を追加する	指定したAppContainerからループバックサービスへのアクセスを許可する	プロキシの待ち受け、ノード、ルールによる振り分け
プロキシルールを変更する	コアに到達した接続の出口を決める	接続がコアに到達しているか
TUNを有効にする	仮想ネットワークインターフェース経由でIP通信を取り込む	ルーティング、DNS、権限、アプリのネットワーク動作

そのため、例外を追加してもアプリがプロキシ経由になるわけではありません。接続がコアに到達した後も、DIRECTに振り分けられたり、REJECTで拒否されたりする場合があります。ループバック制限とルールによる振り分けは別のレイヤーです。まず通信をコアに到達させ、その後で出口を確認してください。

操作前にシステムプロキシと待ち受けポートを確認

Clashクライアントとコアを起動したままにし、有効なノードを含む設定が読み込まれていることを確認します。
Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシセットアップ」→「プロキシサーバーを使う」の「セットアップ」を開きます。Windows 10も「設定」→「ネットワークとインターネット」→「プロキシ」から開けますが、スイッチの配置は異なります。
クライアントでシステムプロキシを有効にした後、設定されたアドレスとポートを確認します。ローカルプロキシを使う場合、アドレスは通常127.0.0.1です。ポートは現在のHTTPポートまたは混合ポートと一致している必要があります。
PowerShellで該当ポートへのTCP接続を確認してから、アプリの例外を設定します。

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
netstat -ano | findstr ":7890"

TcpTestSucceeded : Trueは、現在のPowerShellプロセスがそのポートに接続できることを示します。UWPアプリにアクセスが許可されたことや、プロキシ経由で外部に接続できることを示すものではありません。netstatの結果には、該当ポートのLISTENINGが表示される必要があります。他の接続状態だけでは、コアが待ち受けている証拠にはなりません。

方法1：CheckNetIsolationで指定アプリに例外を追加

ここではMicrosoft Storeを例に説明します。影響を受けているWindowsユーザーのセッションで「スタート」を開き、PowerShellを検索して「管理者として実行」を選びます。別の管理者アカウントの資格情報を使って昇格すると、実行ユーザーのコンテキストが変わります。その場合、Get-AppxPackageの既定の検索結果は影響を受けているユーザーのものとは限らないため、対象ユーザーを確認してください。

1. アプリのパッケージファミリー名を確認

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

例外の追加にはPackageFamilyNameを使います。表示名や、バージョンとアーキテクチャを含むPackageFullNameではありません。Microsoft Storeでよく使われるパッケージファミリー名はMicrosoft.WindowsStore_8wekyb3d8bbweですが、必ず現在のPCでの検索結果を確認してください。

別のアプリを調べる場合は、現在のユーザーにインストールされているアプリパッケージを一覧表示し、アプリ名で絞り込めます。画面に表示されるアプリ名とパッケージ名は一致するとは限らないため、アイコンの表示名だけでパッケージファミリー名を判断しないでください。

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

2. 例外を追加して結果を確認

次のコマンドはインストール済みのMicrosoft Storeパッケージから名前を取得するため、手入力による誤記を防げます。パッケージが見つからない場合は処理を停止し、引数が空のコマンドを続けて実行することはありません。

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "現在のユーザーにMicrosoft.WindowsStoreアプリパッケージが見つかりません"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-a：指定したパッケージにループバック例外を追加します。
-n=：パッケージファミリー名でアプリを指定します。
-s：現在のループバック例外一覧を表示します。

実行後、一覧に対象アプリの名前または対応するSIDが表示されることを確認します。一覧に何か表示されているだけでは、追加したアプリが含まれているとは限りません。アクセス拒否が表示された場合は、ターミナルを管理者として実行しているか確認します。引数やパッケージ名のエラーが表示された場合は、パッケージファミリー名を再確認してください。フルパッケージ名で何度も試すのは避けましょう。

3. アプリを再起動して接続を確認

対象アプリを終了してから再度起動し、先ほど失敗した操作を試します。ウィンドウを閉じてもバックグラウンドプロセスが残るアプリもあります。タスクマネージャーで対象プロセスが終了しているか確認し、必要なら作業を保存してからアプリのプロセスを終了してください。例外を追加するだけなら、通常はPC全体を再起動する必要はありません。

Clashの接続記録で対象ドメイン、適用ルール、ポリシーグループ、実際に選択されたノードも確認します。接続記録があるのにページを開けない場合は、ルールによる振り分け、DNS、サービスの地域制限、ログイン状態を確認してください。アプリの例外をさらに追加しても、これらの問題は解決しません。

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

Windows向けの一部GUIクライアントには、「UWPループバック」「Loopback」などの項目があり、Windowsのループバック例外一覧を管理できます。この機能はクライアントの画面から利用するもので、Clash設定の共通YAML項目ではありません。また、すべてのmihomoクライアントに付属しているわけではありません。

旧版Clash for Windows 0.20.xでよく使われていた場所は「Settings」→「System」→「UWP Loopback」→「Launch Helper」です。この旧版の画面構成は、既存のインストールを確認するための参考です。新しいクライアントを選ぶ基準にはしないでください。ほかのクライアントでは、現在のバージョンの設定画面を確認します。該当する項目がない場合は、上記のシステムコマンドを使ってください。

ループバックツールを起動し、システムの指示に従って管理者権限を付与します。
アプリ一覧から、ローカルプロキシへのアクセスが必要なアプリのパッケージを探します。
対象アプリにチェックを入れて変更を保存します。更新ボタンがある場合、新しいアプリをインストールした後に一覧を更新してください。
CheckNetIsolation.exe LoopbackExempt -sを実行し、保存後のシステム一覧を照合します。
対象アプリを再起動し、接続がコアに届いているか確認します。

ループバック例外を取り消して、確認記録を残す

ローカルのシステムプロキシを使わなくなった場合や、原因の確認のため一時的に例外を追加した場合は、対象アプリだけを取り消せます。以下では引き続きMicrosoft Storeを例に、追加時と同じパッケージファミリー名を使います。

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "現在のユーザーにMicrosoft.WindowsStoreアプリパッケージが見つかりません"
}
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-dは指定したパッケージの例外を削除します。削除後、一覧を再表示して該当項目が消えたことを確認します。ほかのアプリや開発環境が既存の項目に依存している可能性があるため、例外一覧全体を消去するのは避けてください。対象アプリをアンインストール済みの場合は、以前に保存したパッケージファミリー名または一覧のSIDを使って古い項目を特定します。アプリ検索で結果が得られないまま、値を取得しようとしないでください。

変更前に対象アプリのパッケージファミリー名と、すでに例外一覧に含まれているかを記録します。
現在のプロキシアドレス、ポート、クライアントで有効にしている設定名を記録し、「例外の変更」と「設定の変更」を区別できるようにします。
テスト後は必要な項目だけを残し、一時的に許可したアプリは個別に例外を取り消します。

代替案としてのTUNモード：ループバックを開放せずに通信を取り込む

アプリがシステムプロキシを使わない場合、ループバック例外を設定してもClash経由にはなりません。TUNに対応したmihomoクライアントは、仮想ネットワークインターフェースとルーティングを使ってIP通信を取り込めるため、通常は直接通信する一部のアプリもルール処理の対象にできます。これは「アプリがローカルHTTPプロキシに接続する」方法とは異なります。適切なルーティングとDNS設定を行えば、ローカルプロキシポートに依存せずに済む場合があります。

TUNは、あらゆるUWPのネットワーク問題を解決する万能策ではありません。アプリがシステムプロキシを参照して制限対象のループバックアドレスに接続しようとする場合、TUNを有効にしただけでは状況が変わらないことがあります。原因を切り分けるには、元の設定を記録してからシステムプロキシを無効にし、TUNだけでテストします。その前に、クライアントが対象の通信を実際に取り込んでいることを確認してください。

手順に沿ってTUNを確認

コアがTUNに対応しているか確認します。mihomoと旧Clashコアでは機能が異なるため、クライアント名だけで判断できません。
クライアントの要件に従ってサービスをインストールするか管理者権限を付与し、仮想ネットワークインターフェースが作成されたことを確認します。
自動ルーティングが有効か確認し、出所の不明なTUN設定を複数コピーするのではなく、クライアントが生成した最終設定を確認します。
DNS要求が想定どおりコアに届いているか確認します。DNSハイジャック、システムDNS、アプリ内蔵の暗号化DNSでは、異なる経路を通ることがあります。
既定ルートの競合を減らすため、ほかのVPNや通信を制御するソフトを一時的に終了してから対象アプリをテストします。

方式の選択はシンプルです。アプリがシステムプロキシを使い、問題がループバック制限に限られるなら、まずアプリ単位で例外を設定します。アプリがシステムプロキシを使わない場合や、より広い範囲の通信を取り込む必要がある場合はTUNを検討します。TUNに切り替えた後も適用ルールの確認が必要です。通信を取り込んでも、すべての接続がプロキシノード経由になるわけではありません。

よくある結果と次の確認項目

例外の追加に成功してもストアが接続できない場合、次に何を確認する？

対象パッケージが例外一覧に含まれていることを確認してアプリを再起動し、コアに接続記録が現れるか確認します。接続記録がある場合は、DIRECTに振り分けられていないか、ノードから対象ドメインに接続できるか、システムの日付と時刻が正しいかを確認してください。ストアではアカウント、サービスの稼働状況、地域制限が関係する場合もあります。追加コマンドを繰り返すのではなく、アプリのエラーコードをもとに原因を調べましょう。

netsh winhttp import proxy source=ieを実行する必要はある？

このコマンドはユーザーのプロキシ設定をWinHTTPのプロキシ設定にインポートするもので、別のプロキシ利用場面に関係します。AppContainerのループバック制限は解除されません。CheckNetIsolationと同じ修復方法として扱わないでください。対象のコンポーネントがWinHTTPを使うと確認でき、システム全体への影響を理解している場合に限り、別途この設定を調べてください。

Clashクライアントを変更した後も例外を確認する必要があるのはなぜ？

例外はアプリのパッケージを対象とし、サブスクリプションファイルではなくWindowsに保存されます。クライアントを変更しても通常、対象アプリの例外識別情報は変わりませんが、ローカルの待ち受けポート、システムプロキシのアドレス、通信の取り込み方法は変わる可能性があります。アプリを更新してもパッケージファミリー名が同じなら、通常は既存の項目を引き続き使えます。再パッケージ化された場合や配布元を変更した場合は、もう一度名前を確認してください。

確認は、コアの起動とポートの待ち受け、システムプロキシの接続先、対象アプリがAppContainerのループバック制限を受けているかの特定、アプリ単位での例外追加、接続ルールと出口の確認、の順に進めます。一度に変更する項目を一つに絞ることで、Windowsの通信経路の問題と、サブスクリプション、ノード、DNS、ルールの問題を切り分けられます。

設定レイヤーの違いをさらに確認するには、ルールによる振り分けのガイドとコアの解説をご覧ください。初回接続の基本手順はプロキシ接続ガイドで確認できます。