トラブルシューティング 読了目安 11分

Windows UWPアプリがプロキシに接続できない：ループバック制限の解除とトラブルシューティング

Windowsのストアアプリで発生するループバック制限の症状、解除方法、復旧確認を解説。システムプロキシは正常でも一部アプリだけ通信できない場合に対応します。

まずUWPのループバック制限かどうかを確認する

Windowsで「ブラウザーはClash Verge経由で接続できるのに、Microsoft Store、Xbox、フォト、メールなどのストアアプリだけ通信できない」場合、よくある原因の一つがAppContainerのループバックアクセス制限です。ここでいう「ループバック」とは、127.0.0.1、localhost、IPv6のループバックアドレスなど、アプリがローカルホストへ接続することを指します。Clash Vergeでシステムプロキシを有効にすると、通常はWindowsのプロキシサーバーがローカルの待受ポートを指すため、アプリはまずこのローカルポートへ接続し、その後mihomoコアがルールに従って通信を転送します。

従来型のデスクトップアプリはローカルのプロキシポートへ直接アクセスできることが多い一方、AppContainerの分離環境で動作するパッケージアプリには追加の制限がかかる場合があります。対象アプリにループバックの例外が設定されていないと、ClashのローカルHTTP、SOCKS、Mixed待受ポートへ接続できないことがあります。その結果、すべてのアプリが同時にオフラインになるのではなく、一部のストアアプリだけ読み込みに失敗する、ログイン画面が空白になる、内容の更新を繰り返す、「ネットワークを利用できません」と表示される、といった症状が現れます。

ただし、「ストアアプリが通信できない」からといって、必ずしもループバック制限が原因とは限りません。確認前に、次の特徴が組み合わさっているかを見ます。

  • Clash Vergeに利用可能な設定がインポートされ、現在の設定とプロキシグループが有効になっている。
  • Edge、Firefoxなどのデスクトップアプリが、同じシステムプロキシ経由で対象サイトへ正常にアクセスできる。
  • 対象アプリはシステムプロキシを無効にすると直接接続できる、またはエラー状態がシステムプロキシのオン・オフに連動する。
  • 対象アプリを開いてもClash Vergeの接続ログに該当リクエストがなく、通信がローカルのプロキシポートまで届いていない可能性がある。
  • 問題が一つ、または少数のパッケージアプリに限られ、すべてのアプリやドメインが同時に失敗しているわけではない。

システムプロキシ、AppContainer、ローカルポートの接続経路を理解する

トラブルシューティングの前に、接続経路を分けて考えます。Clash Vergeでシステムプロキシを有効にすると、Windowsにプロキシアドレスが書き込まれます。ポート番号は現在の設定によって異なり、一般的には127.0.0.1:7890のようになりますが、別のHTTPポートやMixedポートが使われる場合もあります。システムプロキシに対応したアプリはこの設定を読み取り、ネットワークリクエストをローカルのmihomo待受ポートへ渡します。

  1. アプリがWindowsのシステムプロキシ設定を読み取る。
  2. アプリが127.0.0.1上のClash待受ポートへ接続を試みる。
  3. mihomoがリクエストを受け取り、ドメイン、IP、プロセス、ルールセットに基づいて、直接接続、拒否、指定したプロキシグループのいずれかを選択する。
  4. 選択されたノードまたは直接接続先が外部接続を確立し、レスポンスが同じ経路をたどってアプリへ戻る。

UWPや一部のMSIXパッケージアプリは、AppContainerのセキュリティ境界内で動作します。この境界は、分離されたアプリがローカルのネットワークリソースを自由に探索・呼び出すことを防ぐため、ローカルネットワーク資源へのアクセスを制限します。システムプロキシはまさにローカルアドレス上にあるため、アプリがプロキシ設定を読み取れても、2段階目でブロックされることがあります。ループバック例外は、指定したパッケージにローカルのループバックインターフェースへのアクセスを許可するものです。Clashのルールを変更したり、利用できないノードを復旧させたりする機能ではありません。

「UWPアプリ」「ストアからインストールしたアプリ」「すべてのモダンUIアプリ」は区別する必要があります。Microsoft Storeには、AppContainerアプリだけでなく、ストア経由で配布される従来型デスクトップアプリも含まれます。後者は同じループバック制限の対象にならない場合があります。判断する際はインストール元だけで決めつけず、パッケージIDと実際の通信挙動を確認してください。

ループバック例外で解決できること

  • 指定したAppContainerパッケージが、Clashのローカルプロキシポートへアクセスできない。
  • デスクトップアプリは正常なのに、同じネットワーク上の特定のパッケージアプリだけリクエストが記録されない。
  • システムプロキシを有効にすると対象アプリで直ちにネットワークエラーが発生し、無効にすると直接接続できる。

ループバック例外で代替できないこと

  • 期限切れのサブスクリプション、無効なノード、設定ファイルの構文エラーは修復できない。
  • DNS名前解決の失敗、証明書の時刻エラー、ルールの誤マッチングを自動的に解決することはできない。
  • システムプロキシを読み取らないアプリに、HTTPプロキシの使用を強制することはできない。
  • Microsoftアカウント、Storeのキャッシュ、Windows Updateサービス自体の障害は修復できない。

制限を解除する前の基本チェック

ループバック例外リストを直接変更する前に、Clash Vergeのローカルプロキシが正常に動作しているか確認します。これにより、ポート番号の誤り、システムプロキシの残設定、設定の未有効化をAppContainer制限と誤認するのを防げます。

Clash Vergeの待受ポートを確認する

Clash Vergeの設定画面を開き、HTTP、SOCKS、Mixedの各ポートを確認して、コアが正常に動作していることを確かめます。次にWindowsの「設定 → ネットワークとインターネット → プロキシ」を開き、手動プロキシのアドレスとポートがClash Vergeの現在の待受設定と一致しているか確認します。Clash Vergeでポートを変更したのに、Windowsが古いアドレスを保持していると、システムプロキシを読み取るすべてのアプリで接続に失敗する可能性があります。

複数のプロキシアプリで同じポートを同時に使用しないでください。ポートが競合すると、Clash Vergeが待受を開始できなかったり、システムプロキシが実際には別のアプリを指したりします。その場合は、まず競合しているアプリを終了し、ポートを変更してからシステムプロキシをいったんオフにして再度オンにします。

設定とプロキシグループの状態を確認する

現在のサブスクリプションが更新済みで選択されていること、よく使うプロキシグループに利用可能なノードがあることを確認します。まずデスクトップブラウザーで、明らかにプロキシが必要なURLへアクセスし、Clash Vergeの接続ログを確認してください。ブラウザーのリクエストが記録され、完了するなら、ローカル待受、基本ルール、少なくとも一つの出口は概ね利用可能です。

対象アプリが本当にシステムプロキシを使っているか確認する

アプリによっては独自のネットワークスタックを使用し、Windowsのシステムプロキシを無視することがあります。また、一部のシステムコンポーネントは、現在のユーザーのインターネットプロキシ設定ではなくWinHTTP設定を使用します。ループバック例外はローカルアクセスを許可するだけで、アプリがどのプロキシインターフェースを選ぶかは変えません。アプリがシステムプロキシを読み取らず、TUNにも取り込まれていない場合、例外を追加してもClashに通信が入らないことがあります。

ループバック例外でUWPアプリの制限を解除する

一部のClash VergeバージョンやWindows用補助ツールには、UWPループバックを管理する画面があります。現在のクライアント設定に「UWPループバック」「Loopback」「ループバック制限の解除」などの機能があれば、まずその画面でアプリパッケージの一覧を確認し、ローカルプロキシ経由の通信が必要なアプリだけを選択してください。バージョンによってメニューの場所は異なるため、古いスクリーンショットを頼りに固定メニューを探すのは避けましょう。

クライアントに該当する項目がない場合は、Windows標準のCheckNetIsolation.exeで例外リストを管理できます。操作にはアプリのPackage Family Name、つまりパッケージファミリ名を正確に確認する必要があります。これはスタートメニューに表示されるアプリ名でも、インストール先フォルダー名でもありません。

手順1：パッケージファミリ名を確認する

PowerShellを管理者として開き、まず現在のユーザーがインストールしているパッケージアプリとパッケージファミリ名を一覧表示します。

Get-AppxPackage | Select-Object Name, PackageFamilyName

一覧が長い場合は、名前で絞り込めます。たとえばMicrosoft Store関連のパッケージを検索するには、次のように実行します。

Get-AppxPackage -Name "*WindowsStore*" |
  Select-Object Name, PackageFamilyName

コマンド結果に表示されるPackageFamilyNameが、以降の操作で使用する値です。Microsoft Storeでよく見られるパッケージファミリ名はMicrosoft.WindowsStore_8wekyb3d8bbweですが、ほかのアプリは必ず実機で確認した結果を使ってください。似た名前でも、メインプログラム、ランタイム、拡張パッケージが異なる場合があるため、名前だけで推測してはいけません。

手順2：指定したアプリにループバック例外を追加する

管理者権限のターミナルで次のコマンドを実行し、例示された値を対象アプリの実際のパッケージファミリ名に置き換えます。

CheckNetIsolation.exe LoopbackExempt -a -n="PackageFamilyName"

たとえば、検索で確認したMicrosoft Storeパッケージに例外を追加する場合は、次のコマンドを実行します。

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

-aは追加を表し、-nの後ろにはパッケージファミリ名を指定します。完了したら、バックグラウンドに残っている可能性のあるプロセスも含めて対象アプリを完全に終了し、再起動してテストします。ウィンドウを最小化しただけでは、完全なネットワークセッションを再確立できないことがあります。

手順3：現在の例外リストを確認する

次のコマンドで、項目が書き込まれているか確認します。

CheckNetIsolation.exe LoopbackExempt -s

出力には、ループバック例外を取得したアプリパッケージが一覧表示されます。対象パッケージがすでに存在するなら、繰り返し追加する必要はありません。追加コマンドを何度も実行しても、ルール、DNS、ノードの問題は解決せず、原因の切り分けを難しくするだけです。

手順4：不要になった例外を削除する

対象アプリがローカルプロキシを使わなくなった場合や、変更前の状態に戻したい場合は、-dで指定した項目を削除できます。

CheckNetIsolation.exe LoopbackExempt -d -n="PackageFamilyName"

削除後は-sを再実行して一覧を確認し、アプリも再起動します。例外リストは必要最小限に保ち、ローカルプロキシへのアクセスが必要なパッケージだけにループバックを許可してください。すべてのアプリを一括変更するのは避けましょう。

例外追加後の確認手順

コマンドが正常に実行されたことは、Windowsが設定を受け付けたことを示すだけで、プロキシ経路全体が正常とは限りません。確認時は「アプリプロセス、ローカル接続、ルールマッチング、上流出口」の順に観察します。

  1. アプリを再起動：タスクマネージャーで古いプロセスが終了していることを確認してから、対象アプリを開きます。必要に応じて現在のWindowsユーザーからサインアウトしますが、通常はPC全体をすぐ再起動する必要はありません。
  2. Clashの接続ログを確認：Clash Vergeの接続またはログ画面を開き、アプリで更新操作を行います。対象ドメインや関連プロセスのリクエストが表示されれば、通信はコアまで到達しています。
  3. ルールの結果を確認：リクエストがどのルールとプロキシグループにマッチしたか確認します。REJECT、誤ったDIRECTルール、利用できないプロキシグループにマッチしている場合は、ループバックではなく設定を修正するかプロキシグループを切り替えます。
  4. 複数の機能入口をテスト：Storeのトップページ、検索、画像リソース、アカウントログイン、ダウンロードサービスでは異なるドメインが使われることがあります。トップページが開いても、すべてのAPIが復旧したとは限りません。
  5. システムプロキシのオン・オフを比較：ほかの条件を変えずに有効時と無効時をテストし、現象が本当にプロキシ経路に関係しているか確認します。

例外追加後にClash Vergeでリクエストが表示されるようになったのに、アプリが失敗を示す場合、問題は「ローカルポートへ接続できない」段階から後続の処理へ移っています。この時点ではログのエラー種別を重点的に確認します。たとえばDNSクエリのタイムアウトならnameserver、DNSハイジャック、ネットワーク到達性を確認し、接続タイムアウトならノードとルーティングを確認します。TLSエラーは、システム時刻、証明書環境、中間経路が関係している可能性があります。

Microsoft Storeのページ内容、アプリ認証、ダウンロードタスクは、別々のシステムサービスで処理されることがあります。Storeのメインパッケージにループバック例外を追加するとページ閲覧は復旧しても、ダウンロードキューはWindows Update、Delivery Optimization、アカウント状態、サービスのポリシーの影響を受け続ける場合があります。このような場合は個別に切り分け、Storeで発生するすべてのエラーを一つのパッケージのループバック問題として扱わないでください。

システムプロキシが機能しない場合、TUNモードを使うべきか

TUNモードは仮想ネットワークインターフェース層で通信を取り込むため、アプリがWindowsのシステムプロキシを自発的に読み取ることに完全には依存しません。そのため、システムプロキシを無視するプログラムにも広く適用できます。ローカルHTTPプロキシを安定して使えないアプリでは、TUNを別の切り分け方法として試せますが、ループバック例外を単純に置き換えるスイッチではありません。

TUNを有効にする前に、Clash Vergeの関連サービスや権限が正しく設定されていることを確認し、現在のシステムプロキシ状態を記録します。TUNはルーティング、DNSハイジャック、インターフェースの優先順位、プロセス通信の取り込みに関係するため、問題の範囲は単一のUWPパッケージより広くなります。明確に一つのAppContainerアプリだけが127.0.0.1のプロキシへ接続できない場合は、まず対象を限定したループバック例外を追加するほうが確認しやすく、元に戻すのも簡単です。

TUNを検討しやすいケースは次のとおりです。

  • 対象アプリがWindowsのシステムプロキシを読み取らないことが確認でき、システムプロキシの有効・無効を切り替えても接続ログに変化がない。
  • ゲームランチャー、コマンドラインプログラム、特定のネットワークコンポーネントが使うプロトコルを、通常のHTTPプロキシではカバーできない。
  • 明示的なプロキシに対応していない、より多くのプロセス通信を同じルール体系で処理したい。

TUNを有効にした後にLAN内のデバイスへ接続できない、DNSクエリが異常になる、仮想NICが競合するといった症状が出た場合は、Clash設定のDNS、ルーティング除外、インターフェース設定を確認します。VPN、仮想マシンソフト、コンテナネットワーク、ほかのネットワークフィルタリングプログラムがルーティングの優先順位を変えることもあります。切り分け中にシステムプロキシ、TUN、ノード、DNSを同時に何度も切り替えると、原因を特定しにくくなります。

接続できない場合のレイヤー別チェックリスト

Clash Vergeにリクエストがまったく表示されない

まずパッケージファミリ名が正しいか確認し、CheckNetIsolation.exe LoopbackExempt -sで例外が存在するか調べます。続いてWindowsのシステムプロキシのアドレスとポートを確認します。アプリがシステムプロキシを使わない場合は、短時間だけTUNを試し、接続ログが表示され始めるか観察します。ログがない場合、問題は通常、リクエストがmihomoへ到達する前に発生しています。

ログにリクエストはあるが、ルールで拒否される

マッチしたドメイン、ルール、プロキシグループを確認します。ルールセットによって一部のMicrosoftドメインがDIRECTに分類されている場合や、カスタムルールが誤って拒否している場合があります。変更前に具体的なドメインとマッチ結果を記録し、アプリ名だけを根拠に広すぎるワイルドカードルールを追加しないでください。ルールを変更したら設定を再読み込みし、新しい接続が想定したプロキシグループを使っていることを確認します。

ログにDNSエラーが表示される

システムネットワークから設定中のDNSサーバーへアクセスできることを確認し、ClashのDNSが有効か、nameserverへ到達できるか、DNSハイジャックがほかのネットワークプログラムと競合していないか確認します。TUNを使う場合は、仮想インターフェースによるDNS取り込みの状態も確認してください。DNSエラーとループバック制限は、どちらも「ページが空白になる」似た症状を起こしますが、前者は通常、ログに名前解決エラーが残ります。

ログイン、画像、ダウンロードだけが失敗する

これは通常、メインのリクエストはプロキシを通過しているものの、子リソース、アカウントAPI、ダウンロードサービスが別のドメインやプロセスを使っていることを示します。機能ごとに操作して失敗を再現し、その時に追加された接続を確認してください。Microsoft Storeのダウンロードは、関連システムサービス、ディスク容量、時刻設定、アカウント認証にも依存するため、前面のアプリパッケージだけを確認しても不十分です。

プロキシを無効にしてもアクセスできない

Clash Vergeのシステムプロキシを無効にしてクライアントを終了しても問題が続く場合は、Windowsのネットワーク、アプリキャッシュ、アカウントのサインイン、システムサービスを確認します。まず「設定 → アプリ」で対象アプリを開き、利用できる修復オプションを試してください。リセットを実行するとアプリデータが消去されるため、影響を確認してから実行します。システムの日付、地域、ネットワーク接続が正常かどうかも確認できます。

システムプロキシの残設定またはポート変更

Clash Vergeが異常終了した後、Windowsに以前のプロキシアドレスが一時的に残ることがあります。クライアントを再起動してシステムプロキシをいったん正常に無効化するか、Windowsのプロキシ設定でスイッチを確認してください。ポートを変更した場合は、Windowsが指している新しいポートとmihomoが実際に待ち受けているポートを完全に一致させます。

復旧後も確認できる記録を残す

問題が解決したら、対象アプリの表示名、Package Family Name、Clash Vergeの待受ポート、使用したシステムプロキシまたはTUNモード、最終的に有効だった変更を記録しておくと便利です。アプリの更新では通常、同じパッケージファミリ名は変わりませんが、再インストール、プレビュー版への変更、配布元の変更後はパッケージIDが変わり、以前の例外が新しいパッケージを対象にしないことがあります。

再び同じ症状が出たら、まず例外リストの確認コマンドを実行し、次にClashの接続ログを確認します。リクエストがローカルプロキシまで到達しているかを把握できれば、AppContainerのループバック、プロキシポート、ルール設定、上流接続のどこに問題があるかをすばやく切り分けられます。使わなくなったアプリの例外は削除し、設定を整理しておきましょう。

トラブルシューティング全体は、デスクトップアプリが正常か、対象パッケージが分離環境の制限を受けているか、リクエストがmihomoに到達しているか、ルールが正しくマッチしているか、出口が利用可能か、という順に整理できます。この経路に沿って段階的に確認するほうが、ノードを何度も切り替えたりアプリを再インストールしたりするより、実際の障害箇所を見つけやすくなります。

Clash Vergeのインストールを続ける

ダウンロードページでOSとアーキテクチャを選ぶか、先にインストール手順を確認してください。

ダウンロードページへ チュートリアルを見る
Clash をダウンロード