Windowsストアアプリが Clash のプロキシを通らない?UWPループバック制限の解除手順
Windowsストアアプリは既定でループバック制限によりプロキシから除外される。UWPのネットワーク分離の仕組みを解説し、標準ツールとクライアント内蔵機能で制限を解除する手順と検証方法を紹介する。
ブラウザは繋がるのにストアアプリだけ繋がらない理由
この問題に初めて遭遇するユーザーの多くは、同じような場面に出くわす。デスクトップ版ブラウザや従来のexe形式のソフトはプロキシ経由で何の問題もなく、速度測定も正常、ルールもきちんとマッチしている。ところがMicrosoft Storeからインストールしたアプリ――チャットツールでもリーダーでも一部のゲームクライアントでも――に切り替えると、決まって「ネットワーク異常」と表示され、まるでプロキシがまったく機能していないかのように見える。ひととおり確認してもシステムのプロキシ設定は間違っておらず、Clashクライアントも正常に動作している。問題はアプリそのものの動作方式にある。
Microsoft Storeのアプリの大半はUWP(Universal Windows Platform)アーキテクチャで動いており、従来のWin32デスクトッププログラムとは根本的に異なる仕組みで動作する。UWPアプリはAppContainerと呼ばれるサンドボックス環境の中で動作し、権限は従来のプログラムよりずっと制限されている。ネットワークアクセスはシステムが事前に宣言した「機能」(Capability)によって許可される仕組みで、Win32プログラムのようにデフォルトでマシン全体のネットワーク権限を持っているわけではない。このサンドボックス設計はセキュリティ向上を目的としたものだが、副作用として、アプリがローカルのループバックアドレス(127.0.0.1またはlocalhost)へ接続することを既定で禁止してしまう。
この点がClashの動作方式を直接妨げる。Clashクライアントはローカルでリスンポート(一般的にはシステムプロキシポート7890)を開いており、システム層のプロキシ設定は本質的に、各プログラムのネットワークリクエストをこのループバックアドレス 127.0.0.1:7890 へ転送させる仕組みである。Win32プログラムはもともとループバックアドレスへのアクセスが可能なため、ブラウザやチャットソフトは問題なく転送できる。UWPアプリはサンドボックス隔離のためループバックアドレスへの経路自体がシステムに阻まれ、リクエストがそもそも送信できない。結果としてアプリはネットワークエラーを返すか、あるいは素の直接接続に切り替わる――直接接続自体が遮断されていれば「まったく繋がらない」という症状になり、直接接続は通るが対象サービスに地域制限がある場合は「エラーは出ないのにコンテンツが読み込まれない」という症状になる。
標準ツール CheckNetIsolation で制限を解除する
Microsoftはこの問題に対して公式の解決策を用意している。コマンドラインツール CheckNetIsolation はWindows 10/11に標準搭載されており、追加インストールは不要だ。個々のUWPアプリに対して「ループバック除外」(LoopbackExempt)を設定できる。これはシステムのサンドボックスに対して「このアプリはローカルのループバックアドレスへのアクセスを許可する」と伝えるようなものだ。
- Winキーで「コマンドプロンプト」を検索し、右クリックして「管理者として実行」を選ぶ。管理者権限でなければコマンドは無反応のまま失敗する。
- 以下のコマンドを入力し、現在インストール済みの全UWPアプリとそのパッケージ名を一覧表示して、問題となっているアプリの
PackageFamilyNameを探す:CheckNetIsolation LoopbackExempt -s - パッケージ名を確認したら、除外コマンドを実行する。
パッケージ名は前の手順で確認した完全な文字列に置き換える:CheckNetIsolation LoopbackExempt -a -n="パッケージ名" - コマンド実行後にエラーが出なければ成功で、システムの再起動は不要だが、そのUWPアプリを完全に終了してから再度開き、新しいネットワーク権限を反映させることを推奨する。
具体的なパッケージ名がすぐに見つからない場合は、一つのコマンドでインストール済みの全UWPアプリに一括でループバック除外を付与することもできる。原因確認のための切り分け作業には向いている:
CheckNetIsolation LoopbackExempt -a -p=*問題解決を確認したあとは、以下のコマンドで範囲を単一アプリに絞り直すことを推奨する。全ストアアプリに対してこの許可を長期的に開けたままにしないためだ:
CheckNetIsolation LoopbackExempt -c
CheckNetIsolation LoopbackExempt -a -n="対象アプリのパッケージ名"| コマンド | 役割 |
|---|---|
-s | 現在のループバック除外レコードとインストール済みパッケージ名を一覧表示 |
-a -n="パッケージ名" | 指定アプリにループバック除外を追加 |
-d -n="パッケージ名" | 指定アプリのループバック除外を削除 |
-c | 追加済みの除外レコードをすべてクリア |
クライアント内蔵機能:TUNモードでシステムプロキシ層を回避する
コマンドライン方式は単一アプリに対しては正確に効くが、家庭内に影響を受けるストアアプリが複数ある場合、一つずつ手動で除外設定するのは手間がかかる。より手軽な方法は、Clashクライアントを TUNモード(一部クライアントでは「仮想ネットワークカードモード」や「強化モード」と表記)に切り替えることだ。
TUNモードの仕組みはシステムプロキシ設定とは完全に異なる。システムプロキシはプログラムにリクエストをローカルのループバックポートへ転送させる方式で、各アプリが「システムプロキシ設定に協力する意思がある」ことに依存している。TUNモードはシステム内に仮想ネットワークカードを作成し、クライアントがネットワーク層で全ての送信トラフィックを横取りして引き受ける方式だ。リクエストを発するプログラムがWin32であろうとUWPであろうと、標準のTCP/IPスタックを使っている限りこの仮想ネットワークカードに捕捉されて転送される。ループバックアドレス経路に依存しないため、UWPサンドボックスによるループバックアクセス制限を自然に回避できる。
有効化の手順はクライアントの画面によって多少異なるが、大まかな流れは共通している:
- クライアントの設定画面を開き、「ネットワークモード」または「接続方式」の項目を探す。
- モードを「システムプロキシ」から「TUN」または「仮想ネットワークカード」に切り替える。
- 初回の有効化には追加の許可が必要になることが多い:仮想ネットワークカードドライバを一度インストールし、クライアントの管理者権限での実行を許可する。システムからドライバインストールの確認ダイアログが一度表示される。
- 切り替えが成功すればシステムプロキシ設定はデフォルトのままで構わない。手動で再設定する必要はなく、ストアアプリと通常のデスクトップアプリは同じ転送経路を通ることになる。
どちらの方法を選ぶべきか、よくあるエラーの調べ方
個別の1、2個のストアアプリだけ異常で他は正常なら、まず CheckNetIsolation による精密な除外設定を優先すべきだ。変更範囲が小さく、他のネットワーク設定に影響を与えない。家庭内のストアアプリ全般に影響が出ている場合や、もともと長期的に安定した転送方式を使いたい場合は、TUNモードに直接切り替えるほうが一度で解決でき、その後新しくインストールしたストアアプリについても個別対応が不要になる。
対処後も依然として繋がらない場合は、以下の順序で確認する:
- コマンドプロンプトが管理者権限で実行されているか確認する。管理者権限でない場合、
CheckNetIsolationコマンドは成功メッセージを返すが実際には反映されない。これが最も見落とされやすいポイントだ。 -sパラメータで除外リストを再確認し、対象のパッケージ名が確かにリストに存在しているかを確認する。スペルミスによって存在しないパッケージに除外を付与してしまっているケースもある。- Clashクライアントのリスンポートとシステムプロキシ設定のポートが一致しているか確認する。ループバック制限の解除はアクセス経路を通しただけで、ポートの設定が間違っていれば依然として接続できない。
- TUNモードに切り替えても変化がない場合は、クライアントが仮想ネットワークカードドライバのインストール失敗を通知していないか確認する。クライアントの再起動またはシステムの再起動後にもう一度有効化を試す。
- 一部のストアアプリは独自のネットワーク設定項目を持っている場合がある(一部の読書系・ダウンロード系アプリに多い)。アプリ内部で「直接接続のみを使用」といった項目を個別に無効化する必要がある。
プロキシが本当に有効になっているかの検証
制限を解除したあとは、アプリでコンテンツが開けるかどうかだけを見てはいけない。それだけでは「繋がったように見えるが実際は直接接続のまま」という誤判定をしやすい。以下の3つの方法を組み合わせて検証するのが確実だ:
- IPの所在地を比較する:ブラウザでIP確認ページを開き、直接接続時に表示される地域を記録しておく。次にストアアプリ内でネットワークリクエストを一度発生させ(例えば地域制限のあるページを更新する)、その挙動の差がプロキシノードの所在地域と一致しているかを比較する。
- クライアントの接続ログ:Clashクライアントのログまたは接続パネルを開き、ストアアプリを操作しながら対応する接続レコードが新たに追加されるかを観察する。具体的なドメイン名と使用されたプロキシノードが確認できれば、最も直接的な証拠になる。
- 意図的にノードを切り替えて再検証する:プロキシノードを別の地域に切り替え、同じ操作を繰り返す。ストアアプリ内のコンテンツ表示がそれに応じて変化すれば、キャッシュ経由の直接接続ではなく実際にプロキシを経由していることが確認できる。
3つの方法のうち、クライアントの接続ログが最も説得力がある。ストアアプリ自体の画面表示に依存せず、トラフィック転送層から直接リクエストが引き受けられているかを確認できるからだ。ログに該当アプリの接続レコードが一切表示されない場合は、ループバック制限またはTUNモードの設定が実際には反映されていないことを意味し、上記の確認順序をもう一度やり直す必要がある。