症状：ブラウザは大丈夫なのに、ストアだけ「止まったまま」に見える

Windows で Clash 系のクライアント（Mihomo 互換を含む）を動かしていると、Chrome や Edgeでは海外のページも比較的安定する一方、Microsoft Store でゲームやアプリを入れようとしたときのプログレスバーがほとんど動かない、Xbox アプリの更新やクラウド同期の表示だけ妙に遅い、ゲームのパス版インストールが途中で失敗する、といった差が出ることがあります。まずは「プロキシそのものが壊れている」のではなく、どのアプリがどの API を通じてプロキシ情報を読むかがブラウザとストア系で分かれている、と捉えると切り分けが速くなります。

本稿でいう UWP／ストア系は、厳密な開発者用語よりもMicrosoft Store から配信されるサンドボックス寄りのアプリと、その周辺サービス（Xbox、ゲームサービスなど）をまとめた呼び方です。目的は検索意図どおり、「Chrome と同じノードに乗せたい」ときに、Clash 側で何をオンにし、OS 側で何を確認すべきかを順に並べることにあります。

なぜ UWP は「Chrome と同じ」にならないことがあるのか

デスクトップ版の Chromium 系ブラウザは、多くの場合 Windows が提供するユーザー向けのプロキシ構成（設定アプリの「ネットワークとインターネット」→「プロキシ」や、旧来のインターネットオプションに相当する情報）を参照します。一方、システムの各所では歴史的経緯からWinHTTP スタックが別枠でプロキシ情報を保持していることがあり、サービスや一部のコンポーネントはこちらを見に行きます。

加えて、ストアアプリはサンドボックスとネットワーク隔離の設計が前提です。利用者側から見ると「同じ PC のはずなのに挙動がちぐはぐ」に感じるのは、セキュリティ上の境界がユーザープロファイル単位やアプリ単位で細かく分かれているためでもあります。だからこそ、Clash が「OS にプロキシを書き込めているか」と、書き込んだ内容が Store の通信経路まで伝播しているかをセットで確認するのが得策です。

システムプロキシと TUN：どちらが Store に効きやすいか

Clash／Mihomo 互換クライアントでは、大きく次の二つを対比で覚えると運用が楽です。

システムプロキシ（System Proxy）は、Windows のユーザー設定に HTTP プロキシのアドレス（多くは 127.0.0.1 と mixed-port／HTTP ポート）を登録し、それを尊重するアプリのトラフィックを Clash のローカルリスナーに流すやり方です。Chrome のように「OS が案内するプロキシ先」へ素直に従うアプリとは相性がよく、Microsoft Store や Xbox まわりもここに乗る場面が多い、とまずは考えてよいです。実際の ON／OFF の名称は Clash Verge Rev などクライアントごとに「システムプロキシを有効化」といった表記になります。

TUN モードは、仮想ネットワークアダプタやルーティングルールを用いて、より広い範囲のトラフィックをカーネル近くに引き寄せます。環境によっては「システムプロキシを張らなくても大方ついてくる」一方、ポリシー・ドライバ・セキュリティ製品と相互作用し、期待どおりにストアの取得パケットだけが抜けていく、というケースもあります。深い挙動の整理はTUN モードの解説に譲りますが、「ストアだけダメ」を直す第一候補としてシステムプロキシを試すのは現場ではかなり有効です。

Clash 側のチェックリスト：ポート、Allow LAN、システムプロキシ

まず Clash が実際に待ち受けているポートを確認します。mixed-port が 7890 であれば、システムプロキシにも同じ番号が入っているのが望ましいです。ポートがずれている・別プロセスに奪われていると、OS はプロキシを指すのに SYN が届かずタイムアウトします。疑わしいときは7890 占有の稿で PID を特定してください。

次に、Allow LAN（設定ファイルでは allow-lan）は本来「別マシンからその PC の Clash に繋ぐ」話ですが、仮想アダプタや特殊な名前解決経路が絡む環境でも延長線上で議論に出ることがあります。LAN 共有の考え方はLAN 共有の記事と共通です。

そして本題のシステムプロキシをオンにし、Windows の設定画面で「手動プロキシ」に 127.0.0.1:7890（ご自身の値へ置換）のような行が現れるかを見ます。GUI では自動検出やスクリプトの項目もありますが、トラブル時は手動でホストとポートが明示されている状態に一度寄せると原因が追いやすいです。クライアントの導入から全体像を押さえたい場合はWindows 向けセットアップガイドも参照ください。

WinHTTP をユーザー設定と揃える（管理者コマンド）

ブラウザ向けの「ユーザー」プロキシと別枠の WinHTTP が食い違うと、ストアや Windows Update のコンポーネントなど、背景のサービス側で奇妙な挙動が出ることがあります。管理者権限のコマンドプロンプトまたは PowerShell で、次のようなコマンドを知っておくと切り分けが速いです（利用は自己責任のうえ、社用端末ではポリシーを確認してください）。

netsh winhttp show proxy

ここが「直接アクセス」とだけ表示されているのに、設定アプリ側ではプロキシが有効――といったズレが見えたら、ユーザー側の設定を WinHTTP に取り込む操作が案内されることがあります。

netsh winhttp import proxy source=ie

逆にトラブル後の後片付けとしてプロキシをリセットしたい場合は、ドキュメント化された手順に沿って reset 系のサブコマンドを使う運用があります。重要なのは、「Store だけおかしい」ときにWinHTTP の表示だけを別ウィンドウで開いて眺める癖を付けることです。

「配信の最適化」と帯域・経路の認識違い

Windows の「配信の最適化（Delivery Optimization）」は、更新ファイルを近隣マシンやインターネット上のピアと分け合う仕組みです。プロキシ環境では、期待したノード経由ではなく別経路のピアに振られた結果、進捗表示だけ妙に不安定に見える、という認識違いが起きがちです。切り分けの一環として、一時的に制限をきつくする／オフに近い設定へ寄せて挙動差を見る、というやり方もあります（組織配下の PC ではポリシー優先）。

ここは「Clash のルールが悪い」より先に、OS の更新配信の思想を疑った方が早いケースがあります。ストアの取得が落ち着いたら元の設定に戻すかは、帯域とセキュリティ要求のバランス次第です。

Microsoft Store のキャッシュ疑い：wsreset と再ログイン

プロキシが正しくても、ストア側のキャッシュ破損で UI だけが止まったように見えることがあります。定番は wsreset.exe を実行してストアのキャッシュを空に近い状態へ戻す手順です（実行後にストアが開き直る挙動）。併せて、Microsoft アカウントのサインイン状態を確認し、必要なら一度サインアウトして戻す、Xbox アプリでも同様にアカウントの食い違いがないかを見ます。

これらは「Clash を疑う前」でも効くメンテナンスなので、長時間ダウンロードが 0％のまま固まっているときは、ネットワーク以前にストア本体の状態を疑う順序も持っておくと精神衛生上よいです。

ルールと名前解決：ダウンロード CDN が別ドメインになっていないか

ストアの大容量取得は、一覧画面のドメインとは別のCDN ホストに切り替わる段階があります。分流ルールの並びによっては、画面までは速いのにバイト列の本体だけ遅いノードや DIRECTに落ちていて、バーが伸びない――というパターンがあります。connections ログやヒットルールを追い、microsoft.com や xboxlive.com 近傍、実際に出てきた CDN のホスト名を同じポリシーグループに束ねる検討をします。

DNS モード（fake-ip と redir-host の違いなど）がアプリによって解釈差を生む話は、本ブログのDNS 稿で掘り下げています。ストアで不安定なときは、一時的にルールを単純化して同一出口に固定し、症状が消えるかを見るのが古典的で効きます。

ループバック免除（開発者向け補足）

一般ユーザー向けのストアアプリより、サイドロードした UWP や開発中のアプリでは、ループバック隔離の制約を手で緩める話題が出ます。CheckNetIsolation ツールによるループバック免除は検索すると手順が並びますが、セキュリティ上の意味が大きい操作なので、本稿の主線（システムプロキシと WinHTTP）を試してからにし、業務端末では申請のうえで、と心がけてください。

まだ止まるときの短いチェック表

システムプロキシが実はオフ

Clash を再起動したあとトグルが戻っている、別プロファイルに切り替わって書き込みが消えた、など。設定画面の手動プロキシとクライアントの表示を両方見直します。

TUN だけオンでシステムプロキシ未設定

環境によってはこれで十分なこともありますが、ストアだけ期待外れならシステムプロキシを追加して差分を見る価値があります。

セキュリティ製品や社内エージェント

HTTPS インスペクションや独自フィルタが挙げる証明書とストアのコード署名検証が衝突すると、進捗が中途半端に見えることがあります。社内網では IT 窓口との併用が現実的です。

まとめ

Microsoft Store や Xbox アプリの取得が Chrome ほど素直に伸びないとき、第一に疑うのはWindows のユーザー向けプロキシ設定に Clash のローカル HTTP 入口がきちんと書かれているか、第二にWinHTTP の表示がそれと矛盾していないか、第三にTUN 単独で足りていないレイヤーが残っていないか、の三段です。そのうえで配信の最適化やストアキャッシュといった OS 側の要因を外し、必要ならルールで CDN ホストを束ね直す、という順序が実務的です。

クライアントの入手やバイナリごとの注意点はサイトのダウンロードページにまとめています。ソースコードや Issue を追う方は各プロジェクトの GitHub も有用ですが、配布パッケージの取り違えを避ける意味では、まずサイト側の導線から入る運用をおすすめします。設定の筋が通ったら、→ Clash を無料ダウンロードし、システムプロキシでストア取得を再試行するところから確認してみてください。