症状の型：ブラウザは通るのに Store や Xbox だけが直結する
多くの Clash 系 GUI は、既定で ローカルの HTTP／SOCKS リスナ を立て、Windows の システムプロキシ をそのポートへ向けます。Chromium 系ブラウザや Edge はこの表に従うことが多いので、「購読は取り込めているし、ブラウザの IP 確認サイトも出口が変わっている」という状態になりやすいです。
一方、WinRT 上の UWP や一部のストア配布アプリは、次のどちらか（あるいは両方）に当たると、同じデスクトップでも 全く別の経路 を取ります。第一に、WinHTTP のプロキシ表を参照しない、あるいは参照しても実装が限定的である。第二に、サンドボックスにより 同一端末上の 127.0.0.1 へのアウトバウンド がブロックされ、結果としてローカルの Clash リスナへ届かない。ユーザーから見ると「ブラウザだけ魔法が効いている」ように見えますが、OS の設計としては一貫した挙動です。
ここで重要なのは、ループバック問題と「プロキシ非対応」は別レイヤ だという点です。ループバックを解放しても、まだシステムプロキシを読まないプロセスは残ります。逆に TUN をオンにしても、特定の通信が 127.0.0.1 前提で組まれていると、別の詰まり方をします。だから本稿では、まず症状を二つの軸に分け、それぞれに効く手段を順番に当てはめます。
なぜ UWP は Clash と相性の悪い場面が多いのか
UWP（ユニバーサル Windows プラットフォーム）アプリは、従来の Win32 と比べて ネットワーク隔離（network isolation） が強く、同一マシン内の他プロセスや localhost との通信にも制約がかかります。Microsoft はセキュリティ上の理由から、既定で ループバックによる横断通信 を制限しています。Clash が 127.0.0.1:7890 のような ループバック上のプロキシ を提供している構成では、この制限に正面からぶつかりやすいです。
加えて、ストアアプリの更新チャネルや Xbox の各種サービスは、システムコンポーネントに近い権限とスタック を持ち、企業ポリシーやゲームモード、別途有効な VPN 製品と相互作用します。症状が「常に直結」なのか「特定アプリだけタイムアウト」なのかをメモしておくと、後述の CheckNetIsolation が必要な層か、TUN や DNS の層かを切り分けやすくなります。
システムプロキシだけでは足りないとき：TUN が担う役割
システムプロキシ は、プロキシ設定を尊重するアプリに対して効き目があります。しかし前述のとおり、UWP やゲーム、一部の CLI ツールはこの経路を使いません。そこで登場するのが TUN（仮想アダプタによる透明プロキシ） で、OS のルーティングを介してトラフィックを Clash 側へ寄せます。Windows 11 での有効化手順、権限、DNS、他 VPN との競合などは、すでに TUN とシステムプロキシの比較記事 でステップ化してあるので、本稿では重複を避け、UWP 特有のループバック制限 と TUN の 組み合わせ順 に筆力を集中させます。
実務のおすすめ順序は次のとおりです。まずシステムプロキシでブラウザが期待どおりか確認する。次に、UWP だけが 127.0.0.1 上のプロキシに届いていない疑いが強いときは LoopbackExempt を検討する。それでも外向きの TCP がルールに乗らないときに TUN をオン にし、最後に YAML の MATCH や DNS（fake-ip など）が意図せず干渉していないかを見る。この順にすると、「TUN を入れた瞬間にマシン全体が沈む」リスクのある変更と、局所的なループバック解放とを切り離して試せます。
CheckNetIsolation：localhost ループバック免除の具体手順
Microsoft が提供する CheckNetIsolation.exe は、開発者向けツールとしてループバック免除を管理するための公式手段です。管理者権限の コマンド プロンプト または Windows PowerShell を開き、対象アプリの パッケージ ファミリ名（PFN） を指定して免除を追加します。PFN は次のように取得できます（表示例は環境により異なります）。
| 目的 | コマンド例 |
|---|---|
| PFN の確認 | Get-AppxPackage *store* | Select-Object Name, PackageFamilyName |
| 免除の追加 | CheckNetIsolation LoopbackExempt -a -n="<PackageFamilyName>" |
| 一覧の確認 | CheckNetIsolation LoopbackExempt -c |
-a は追加、削除は -d です。複数の UWP が同時に不調なら、まず Microsoft Store と Xbox、問題のサードパーティ UWP の PFN をそれぞれ追加し、ストアのキャッシュやアプリの再起動後にもう一度挙動を見ます。企業端末では AppLocker や MDM によりこの操作自体が禁止されている場合があります。そのときはクライアント側の工夫より、承認された VPN やプロキシ構成の枠内で相談するのが現実的です。
一部の Clash 系 GUI には、同等の処理をワンクリックで行う UWP ツール／ループバック補助 が同梱されているものもあります。内部では同種の免除登録に相当することが多いですが、実装は派生版ごとに異なるため、画面の説明文と本節のコマンドを突き合わせ、何がレジストリやネットワーク隔離に書き込まれるか を理解したうえで使うと安全です。
TUN を有効にしたあとの分流「実測」：ログで当たりを取る
TUN をオンにすると、多くの構成で DNS クエリも Clash の DNS セクションに寄る ようになります。外向きの接続はルールどおりに見えるのに、ストアだけ妙に遅い、というときは、fake-ip と実名解決の取り合い を疑います。切り分けの基本は、クライアントのログで該当ホスト名の行を拾い、DIRECT に落ちていないか、意図した ポリシーグループ に乗っているかを確認することです。DNS モード全般の整理は Fake-IP と redir-host の記事 が近いです。
「TUN をオンにしたら丸ごとオフライン」になった場合は、まず TUN をオフに戻し、ブラウザだけで復帰するかを見ます。復帰するなら、原因は TUN スタック、他社 VPN、Windows ファイアウォール、strict route 系のオプションなど、ルート全体に効く層に絞れます。ここは TUN 記事の「丸ごと断」節 と同じ順序で潰すのが早いです。
外向き通信が期待どおりプロキシチェーンに乗ったうえで、まだ Store の UI だけ不安定なら、Windows の ストアキャッシュのリセット や配信最適化の設定も候補になります。ただしそれらは Clash の外側の話なので、必ず Clash をオフにしたときとオンにしたとき の差分を取ってから当たりを付けてください。差分が再現しないなら、そもそも Clash ではなく Windows Update や CDN 側の話である可能性が上がります。
YAML 分流との共存：UWP でも効く「順序」と「例外」
TUN で取り込めたトラフィックは、最終的には YAML の ルール順序 に従って出口が決まります。Microsoft 系のドメインを特定リージョンのノードへ固定したい場合は、DOMAIN-SUFFIX や購読の RULE-SET で束ね、ポリシーグループに割り当てます。逆に、証明書ピン留めの強いコンポーネントを壊さないよう、公式が推奨する DIRECT 経路を残したい場合は、広すぎる GEOIP ルール が先に当たっていないかを確認します。
社内イントラやプリンタ、ローカル開発サーバを併用している環境では、127.0.0.0/8 やプライベート帯の IP-CIDR を早い段階で DIRECT にしておくパターンが一般的です。開発者向けの整理は Cursor と npm の分流記事 にも触れてあり、UWP 以外の直結原因切り分けにも流用できます。
チェックリスト：上から順に潰す
- システムプロキシ が Clash のポートを指しているか（設定アプリと GUI の両方）。
- ブラウザで出口が変わるか（ここでダメなら UWP 以前の問題）。
- 対象が UWP か、Win32 か（Win32 ならループバック免除よりプロセス別設定や TUN を優先）。
- PFN を取得 し、
CheckNetIsolation LoopbackExempt -a -n="..."を試す。 - 必要なら TUN をオン（管理者権限・他 VPN 停止・DNS 設定を確認）。
- ログでホスト名とポリシー決定を確認し、YAML の順序・fake-ip を調整。
- それでも再現するなら、企業ポリシーや別セキュリティスイートのフィルタを疑う。
このリストは「一度に全部いじらない」ことが前提です。変更点を一つずつ入れ、各段階でブラウザと Store の両方を見ると、後から設定を巻き戻す手間が激減します。
まとめ
Windows 11 で Clash を使うとき、ブラウザは通るのに UWP や Microsoft Store だけが直結する主因は、システムプロキシ非対応 と localhost ループバック制限 の二段です。CheckNetIsolation LoopbackExempt は前者だけでは解けない隔離問題に効き、TUN はルーティング層で捕捉範囲を広げます。両者は置き換えではなく補完関係なので、症状に応じて順序立てて適用してください。
クライアントの世代やコアが古いと、TUN スタックや DNS 実装の差で手順がずれます。長期運用なら Meta（mihomo）コアの更新 を前提に、画面と YAML をあわせて読み解くのがおすすめです。実行ファイルの入手や各 OS 向けパッケージの比較は、ダウンロードページ でまとめて確認できます。