Windows トラブルシュート · · 読了まで約 12 分

Clash TUN を有効にしても UWP がプロキシを通らない? ループバック免除と PROCESS-NAME ルールの実践手順

Windows で Clash(mihomo コア)の TUN モードをオンにしたのに、ブラウザやデスクトップアプリは問題ないのに、Microsoft Store や特定の UWP アプリだけ期待どおりに通信しない——という相談は珍しくありません。本稿では、ループバック(Loopback)制限PROCESS-NAME ルールに焦点を当て、誤解されやすいポイントを整理しながら、自分の環境で再現・切り分けできる手順をまとめます。

1. まず押さえる:症状のパターンと前提

ここでいう UWP(ユニバーサル Windows プラットフォーム)アプリとは、Microsoft Store から入手するパッケージ型アプリや、システム同梱の「設定」「ストア」など、サンドボックス寄りの実行モデルを持つアプリを広く指します。デスクトップ向けの Win32 アプリと違い、ネットワークまわりの制約や挙動が読みにくいのが悩みどころです。

典型的な症状は次のようなものです。例えば、Chrome では海外サイトに問題なくつながるのに、Store の更新確認だけ失敗する。あるいは、特定の UWP クライアントだけタイムアウトし、同じサービスのブラウザ版は動く。こうした「一部のアプリにだけ起きる不整合」は、単にノードの品質が悪いだけでは説明しきれないことが多く、Windows 側の制限ルーティング順序を疑う価値があります。

以降の手順は、mihomo(旧 Clash Meta)系のクライアントを想定しています。GUI の名称は Clash Verge Rev などでも異なりますが、コア設定の考え方は共通です。購読の取り込みや基本操作については、サブスクリプション導入ガイドもあわせて参照してください。

2. UWP が「特別」に見える理由(AppContainer とループバック)

UWP アプリは AppContainer 上で動作し、既定ではローカルホスト(127.0.0.1)へのループバック通信が制限されます。これはセキュリティ上の設計で、ローカルに立てたサービスへの不意の接続を難しくする狙いがあります。一方で、ユーザーが「ローカルの HTTP/ SOCKS プロキシに明示的につなぐ」構成を取る場合、この制限がそのまま障害に見えることがあります。

ここが紛らわしいのですが、TUN モードは「システムのトラフィックを仮想インターフェース側へ誘導する」ための仕組みであり、必ずしも「すべての UWP の悩みを一発で解消する」わけではありません。実際には、クライアントがローカルプロキシへフォールバックする設定、ブラウザ拡張との併用、特定アプリだけ直結する実装など、残りの経路が複数に分岐します。

そのため現場の切り分けでは、「ループバック免除が必要なタイプの問題」と、「ルールや DNS、プロセス名の取り違えによるタイプ」を分けて考えるのが早いです。前者は OS のネットワーク隔離に近く、後者は mihomo のルール設計に近い——というイメージを持つと整理しやすくなります。

3. ループバック免除(Loopback Exemption)の実手順

ループバック免除は、管理者権限のコマンドプロンプトや PowerShell から checknetisolation を使ってパッケージ単位に許可を与える方法が一般的です。対象は「パッケージ ファミリ名」であり、ストアアプリごとに異なります。まずは対象アプリの名前を特定し、次のような流れで確認します。

PowerShell でパッケージ名を調べる例

以下はイメージです。実際の PackageFamilyName は環境により異なります。コメントは英語表記にしています。

# List Store apps and show family names
Get-AppxPackage | Select-Object Name, PackageFamilyName | Format-Table -AutoSize

免除を入れる際は、管理者として開いたコマンドプロンプトで checknetisolation LoopbackExempt サブコマンドを使います。具体的なパッケージ指定は、次のように -n にファミリ名を渡す形が一般的です(例示であり、実際の値はご自身の環境のものに置き換えてください)。

# Add loopback exemption for a package family (run as Administrator)
checknetisolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

一度設定しても、アプリの再インストールや大きなアップデートのあとに挙動が戻ることはあります。トラブル時は「免除が残っているか」「対象パッケージが想定どおりか」を再確認してください。また、過度に広い免除を安易に増やすと攻撃面が広がるため、必要最小限のパッケージに留めるのが無難です。

なお、純粋な TUN 直結でローカルプロキシを経由しない構成であれば、ループバックの影響は相対的に小さくなる場合があります。それでも症状が残るときは、次章以降の「誤解」と「PROCESS-NAME」の観点に進んでください。

4. TUN をオンにしたのに効かない? よくある誤解

まず確認したいのは、TUN が実際に有効化されているかです。ドライバの読み込み失敗、競合する別の VPN、企業ポリシー、セキュリティソフトのフィルタなどで、画面上はオンでも下層が有効になっていないケースがあります。ログに TUN 関連のエラーが出ていないか、管理者権限が必要なクライアントでは昇格できているかを見直してください。

次に、「システムプロキシ」と TUN の関係です。ユーザー環境によっては、システムプロキシをオフにしつつ TUN だけで賄う構成、あるいは併用する構成など、複数の経路が混在します。UWP 側がどの経路を選ぶかはアプリ実装依存であり、ここを「TUN さえオンなら全部同じ」として短絡的に考えると、想定外のバイパスが残りがちです。

さらに、DNSも重要です。mihomo 側で仮想 DNS や fake-ip を使う設定のとき、UWP がシステムスタブに期待する挙動とズレると、名前解決段階でつまずきます。症状が「接続タイムアウト」ではなく「名前が解決できない」に近い場合は、DNS の切り分けを優先してください。

5. PROCESS-NAME ルールでプロセス単位に切り分ける

mihomo では PROCESS-NAME を使って、実行ファイル名ベースでポリシーに振り分けられます。UWP でも、実際に動いているプロセス名(例:WinStore.App.exe など)をタスクマネージャーやリソースモニタで確認し、ルールに反映させるのが実測的なアプローチです。名前はビルドやチャネルで変わることがあるため、常に最新の実行体を確認してください。

設定イメージは次のとおりです(値は例示です。実際のポリシー名はご自身の proxy-groups に合わせます)。

# rules snippet — process-based routing
rules:
  - PROCESS-NAME,WinStore.App.exe,PROXY
  - PROCESS-NAME,OneDrive.exe,DIRECT
  - MATCH,PROXY

重要なのはルールの順序です。PROCESS-NAME をどこに置くかで、ドメインルールや GEOIP より先に評価させるかどうかが変わります。意図せず広いルールが先にマッチすると、プロセス指定が効かないように見えます。高度なフィルタ設計の全体像は、ルールルーティング解説の考え方も参考になります。

なお、PROCESS-NAME はあくまで「プロセス名」ベースであり、サンドボックス内の細かい権限や証明書ピンニングまで保証するものではありません。効かないと感じたら、ルールが本当にロードされているか(設定の再読み込み)、同名プロセスが複数ないか、という当たり前の点に立ち返るのが確実です。

6. 見落としがちな要因(DNS・権限・ルール順)

まとめると、次のような落とし穴が多いです。第一に、管理者権限と TUN ドライバ。昇格が不十分だと、見かけ上は動いても一部のトラフィックだけ通らないことがあります。第二に、競合するフィルタドライバ。他社 VPN や企業エンドポイント保護が WFP の順序に割り込むと、想定と異なる経路になります。

第三に、ルールの優先順位とサブルールです。サブスクリプション由来の大きなルールセットを使う場合、末尾の MATCH や広い DOMAIN ルールが、細かい例外を飲み込んでいないかを確認してください。第四に、アプリ側のプロキシ非対応です。一部の UWP はシステムプロキシを無視する実装があり、その場合は TUN 側での捕捉が鍵になります。それでもダメなら、ループバック免除やプロセス名の切り分けに戻ります。

これらはいずれも「単一のスイッチ」では解けず、ログを見ながらの積み上げが現実的です。mihomo のログレベルを上げ、どのルールにマッチしたか、どのインターフェースを使ったかを追跡すると、感覚的な当て推量から抜け出せます。

7. 実践チェックリスト

まとめ

Windows の UWP は、見た目以上にネットワーク制約のレイヤが多く、Clash の TUN を有効にしただけでは説明しきれない挙動が残りがちです。本稿で示したように、ループバック免除はローカル宛通信の壁を扱うための鍵であり、PROCESS-NAME はプロセス単位の振り分けを精密にするための鍵です。両者を混同せず、ログとともに一歩ずつ切り分けるのが最短です。

クライアント側の総合的な使い勝手と保守状況を踏まえると、mihomo コアを前提にした現行の GUI クライアントは、ルール表現の豊富さと更新の継続性のバランスが取りやすく、長期運用にも向きます。環境ごとの差は残りますが、設定の再現性とログの追いやすさは、体感的なストレス軽減に直結します。

まずは手元のクライアントを最新に近づけ、購読とルールを整えたうえで、本稿のチェックリストに沿って観察してみてください。安定したクライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す のがおすすめです。

関連記事