まず確認:ブラウザーは使えるのに、特定のストアアプリだけ接続できない
まずClashクライアントを起動したまま、サブスクリプションが有効で、ノードに接続できることを確認してから、問題のアプリを開きます。ブラウザーはシステムプロキシ経由で通信できるのに、特定のUWPアプリだけオフライン表示やログインタイムアウトになったり、コンテンツを更新できなかったりする場合は、ローカルループバック制限を確認しましょう。いきなりサブスクリプションを変更したり、DNSを変更したり、すべてのアプリを免除対象にしたりする必要はありません。
この記事では、Windows 10/11でローカルHTTPプロキシを使う場合のトラブルシューティングを解説します。クライアントによって画面上の項目名は異なりますが、Windows標準のCheckNetIsolation.exeでも同じ操作ができます。7890は設定例であり、すべてのクライアントで共通のポート番号ではありません。操作前に現在の設定を確認してください。
まず確認する3項目
- クライアントでシステムプロキシが有効になっていることを確認します。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開き、プロキシサーバーが
127.0.0.1:7890などのローカルアドレスを指しているか確認します。Windows 10では「設定」→「ネットワークとインターネット」→「プロキシ」を開きます。 - そのポートがHTTPポートまたは
mixed-portであることを確認します。SOCKS5専用ポートは、Windowsの手動HTTPプロキシのポートとしてそのまま使えません。 - クライアントの接続一覧またはログを開き、対象アプリでコンテンツを更新します。時刻、接続の有無、適用されたルール、接続エラーの表示を記録してください。
UWPのループバック制限:ローカルプロキシにも接続できない理由
ローカルループバックとは、アプリが127.0.0.1やIPv6の::1などを使い、同じPC上のネットワークサービスにアクセスすることです。ClashやClash Meta(mihomo)のコアは通常、ローカルでプロキシポートを待ち受けます。デスクトップアプリがリクエストをそのポートに送り、コアがルールに従って直接接続するか、プロキシノードを経由するかを決定します。
UWPでよく使われるAppContainerサンドボックスには、ネットワーク分離のルールがあります。アプリがシステムプロキシの設定を読み取れても、制限によってローカルのプロキシ待ち受けポートに接続できない場合があります。そのため、「設定でシステムプロキシが有効」と「アプリがローカルプロキシに接続できる」は別の条件です。アプリがエラーを表示することもあれば、アプリ自身の動作に従って別のネットワーク経路を試すこともあります。必ずプロキシを迂回するとは限りません。
通常のプロキシ経路:
アプリ → 127.0.0.1:7890 → Clash / mihomo → ルールによる振り分け → 接続先サービス
制限される可能性がある箇所:
AppContainerアプリ → ローカルループバックポートへの接続が制限される → リクエストがプロキシコアに届かない
ループバック免除を追加すると、指定したアプリがこのループバック分離制限を越えて接続できるようになります。アプリのプロキシ設定を変更するものではなく、アプリがシステムプロキシを使うことを保証するものでもありません。タイトルの「解除」は、該当アプリのループバック制限を解除するという意味で、実際に行うのは免除の追加であり、免除の削除ではありません。
- ルールモードとは別の設定です:ルールが決めるのはリクエストがコアに届いた後の接続先です。コアに届く前に適用されるサンドボックス制限は解消できません。
- サブスクリプションとは別の設定です:サブスクリプションで提供されるのはノード、ポリシーグループ、ルール設定などであり、Windowsのアプリ分離状態は変更しません。
- allow-lanとは別の設定です:
allow-lanはLAN上のデバイスからプロキシに接続できるようにする設定です。ローカルUWPアプリのループバック問題を調べるために、先にLANアクセスを許可する必要はありません。
方法1:クライアント内蔵のループバック免除ツールを使う
まずクライアントの設定やツール欄で、「UWP Loopback」「Loopback exemption」「ループバック免除」などの項目を探します。バージョンによっては独立したツールが開き、この機能がないものもあります。同じ名前のボタンを探すために、サポートが終了した古いクライアントをインストールしないでください。項目が見つからない場合は、次のセクションでWindows標準のコマンドを使います。
対象アプリを選択して保存する
- 対象アプリをインストールした状態にして、操作後も古い接続が使われ続けないよう、先にアプリを終了します。
- クライアントのループバックツールを開きます。ユーザーアカウント制御の確認画面が表示された場合は、プログラムの提供元を確認してから管理者権限を許可してください。
- 一覧から対象アプリを探し、表示名とパッケージ情報を確認して、ローカルプロキシへのアクセスが必要なアプリだけを選択します。
- ツールの「保存」「適用」または該当する確定ボタンをクリックします。選択しただけで保存しないと、通常はシステム設定に反映されません。
- 対象アプリを再起動し、明確なネットワーク操作を行ってから、クライアントの接続一覧を確認します。
一覧に対象アプリがない場合は、現在のWindowsユーザーにインストールされているか確認してから、ツールを開き直してください。一部のツールでは、新しいバージョンのアプリや別のユーザーアカウントのパッケージが一覧に表示されないことがあります。その場合は、実際のパッケージファミリ名を調べ、名前が似ている項目を選ばないようにしてください。
方法2:CheckNetIsolationで指定したパッケージに免除を追加する
スタートメニューを右クリックし、「ターミナル(管理者)」を選択します。Windows 10では「Windows PowerShell(管理者)」と表示される場合もあります。パッケージ情報を調べる以下のコマンドは、PowerShellで実行してください。免除リストの変更には管理者権限が必要ですが、照会時には実行ユーザーにも注意が必要です。別の管理者アカウントの資格情報でターミナルを起動すると、表示されるアプリ一覧が、現在ログイン中のユーザーのものと異なる場合があります。
手順1:現在の免除リストを記録する
CheckNetIsolation.exe LoopbackExempt -s
-sは、現在のループバック免除を一覧表示するオプションです。対象パッケージがすでに登録されているか確認できるよう、まず出力を保存してください。出力にはアプリ名やセキュリティ識別情報が含まれる場合があります。一覧が長いからといって、他のソフトが利用している可能性のある設定をまとめて消去しないでください。
手順2:対象アプリのパッケージファミリ名を調べる
PowerShellで以下のコマンドを実行すると、現在のユーザーのアプリのパッケージ名とパッケージファミリ名を一覧表示できます。一覧が長い場合は、2つ目のコマンドで実際の名前を指定して絞り込みます。以下ではMicrosoft Storeを例にしていますが、ストアのネットワーク問題がすべてループバック制限によるものとは限りません。
Get-AppxPackage | Select-Object Name, PackageFamilyName
Get-AppxPackage -Name Microsoft.WindowsStore |
Select-Object Name, PackageFamilyName
-nに指定するのはPackageFamilyNameです。スタートメニューに表示される名前や、バージョンとアーキテクチャを含むPackageFullNameではありません。Microsoft Storeでよく使われるパッケージファミリ名はMicrosoft.WindowsStore_8wekyb3d8bbweですが、必ずこのPCでの照会結果を確認してください。
手順3:確認した対象パッケージだけに免除を追加する
以下のPowerShellコードは、まずMicrosoft Storeを検索します。見つからない場合は処理を停止し、空の値のまま実行されるのを防ぎます。別のアプリを調べる場合は、検索名を直前の一覧で確認した実際のNameに変更してください。この例をすべてのアプリに使える修復コマンドとして扱わないでください。
$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $pkg) {
throw "現在のユーザーに Microsoft.WindowsStore が見つかりません。アプリ名とログイン中のアカウントを確認してください。"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s
-aは免除の追加を意味します。コマンドが正常に実行されたことを確認し、続けて-sを実行して対象項目が一覧に表示されるか確認してください。このPCでパッケージファミリ名を確認済みの場合は、下のコマンドを直接実行することもできます。同様に管理者権限が必要です。
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe
手順4:アプリを終了して再テストする
作業内容を保存して対象アプリを終了します。必要に応じてタスクマネージャーで残っているプロセスを終了してから、アプリを起動し直し、コンテンツを更新してください。通常、PC全体を再起動する必要はありません。このときもクライアントを起動し、システムプロキシを有効にして、事前に接続を確認したノードを使ってください。
「アクセスが拒否されました」と表示される場合は、管理者ターミナルを使っているか確認します。無効なパラメーターと表示される場合は、ハイフン、パッケージファミリ名、コマンドのコピー時に改行で途切れていないかを確認してください。組織管理のデバイスでは、組織のポリシーによって制限される場合があります。セキュリティ機能を何度も無効にするのではなく、管理者に確認してください。
確認方法:ポートの接続、アプリからの通信、接続先の確認
コマンドの実行に成功しただけでは、免除設定が適用されたことしか分かりません。アプリがプロキシを経由している証明にはなりません。確認は3段階に分け、原因を特定しやすいよう一度に変更する条件は1つにしてください。
| 確認項目 | 確認方法 | 確認できる内容 |
|---|---|---|
| プロキシポート | ローカルTCPポート7890をテスト | 接続可能な待ち受けサービスがあるか |
| アプリのリクエスト | 対象アプリを更新して接続一覧を確認 | リクエストがClashまたはmihomoに届いているか |
| ルールによる接続先 | ドメイン、ルール、ポリシーチェーンを確認 | リクエストが最終的に直接接続とプロキシのどちらを選んだか |
PowerShellで以下のコマンドを実行します。現在の設定で7897を使っている場合は、ポートも7897に変更してください。出力のTcpTestSucceeded : Trueが示すのはTCP接続の成功だけです。接続先の待ち受けサービスがClashであることや、UWPのループバック権限が正常であることまでは証明できません。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
Windows標準のcurl.exeでHTTPプロキシを明示し、通常のデスクトッププロセスからそのポートを使ってHTTPSリクエストを送信できるかテストする方法もあります。curl.exeと完全な名前で実行すると、一部のPowerShellバージョンで同名のエイリアスが使われるのを避けられます。
curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://www.microsoft.com/
HTTPレスポンスが返れば、このコマンドに対してサーバーまたは中継機器から応答があったことは分かりますが、全体の結果はログと照らし合わせて確認してください。対象のUWPアプリを直接テストしたことにはなりません。最終的にはアプリに戻り、ログインや更新などの操作を行って、同じ時刻に新しい接続が記録されるか確認します。バックグラウンド通信が多い場合は、他のアプリを一時的に終了して影響を減らしてください。
免除を設定しても解決しない場合:症状別に確認する
接続一覧に対象のリクエストがまったく表示されない
まず対象アプリがAppContainerのループバック制限を受ける種類であることと、現在インストールされているパッケージに免除を設定したことを確認します。次に、アプリがシステムプロキシを使っているか確認してください。独自のネットワークスタックを使うアプリもあれば、システムサービスや別のプロセスがリクエストを送る場合もあります。画面を表示しているアプリのパッケージに免除を追加しても、他のプロセスの通信動作は変わりません。
- Windowsの設定にある手動プロキシ、PACによる自動設定、WinHTTPプロキシは、それぞれ別の設定項目です。
netsh winhttp import proxy source=ieを万能な修復方法として使わないでください。別系統のプロキシ設定が変更されても、対象アプリには反映されない場合があります。 - Microsoft Storeの画面表示、アカウントへのログイン、アプリのダウンロードでは、異なるコンポーネントを使う場合があります。画面が表示されても、ダウンロードサービスが同じ経路を使っているとは限りません。それぞれ別々にテストしてください。
- ストアのキャッシュ削除やアプリの再インストールで解決するのは、別の種類の問題です。ループバック免除の確認の代わりにはならず、問題を示す根拠がない段階で先に行う必要もありません。
リクエストは表示されるが、ルールの結果がDIRECTになっている
リクエストがコアに届いているため、次は免除を追加するのではなく、ルールとポリシーグループを確認します。接続に表示されるドメイン、接続先IP、適用ルール、実際の接続先を確認してください。設定によりそのサービスがDIRECTに割り当てられている場合、ループバック免除を追加してもプロキシ接続には切り替わりません。
比較のために一時的にグローバルモードへ切り替える方法もあります。ただしグローバルモードでも、利用可能なプロキシポリシーを選ぶ必要があります。テスト後は元のルールモードに戻してください。「グローバルモードなら使える」という理由だけでルール全体を置き換えず、まず対象ドメインとルールの優先順位を確認しましょう。
リクエストはプロキシ経由だが、ログインできない
ログのDNSエラー、接続タイムアウト、TLSエラーに加えて、アカウントの地域、システム時刻、サービスの稼働状況を確認してください。Web閲覧に使えるノードでも、接続先サービスがその出口を受け入れるとは限りません。証明書エラーを隠すために証明書検証を無効にしないでください。まずシステム時刻、証明書チェーン、HTTPS通信を検査する他のソフトウェアがないか確認します。
TUNモードを有効にする必要はある?
TUNは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。システムプロキシに従わないアプリの調査に役立ちますが、「ループバック免除を追加する」ことと同じではありません。結果はクライアント、mihomoの設定、ルーティング、DNS、Windowsのネットワーク分離ポリシーによって変わり、有効にしてもすべてのUWP通信が使えるとは限りません。
TUNを試す場合は、まず現在の設定を保存し、クライアントの手順に従ってサービスをインストールまたは有効にしてから、一度に変更する設定を1つにします。有効にする前後の接続やルーティングの状態を記録してください。Fake-IP、ルール、システムプロキシ、ファイアウォールを同時に変更すると、どの操作が結果に影響したか判断しにくくなります。関連する設定は応用設定もご覧ください。
免除の取り消しと日常の管理
アプリがローカルプロキシにアクセスする必要がなくなった場合は、そのアプリの免除を取り消せます。以下では、パッケージファミリ名を確認済みのMicrosoft Storeを例にします。-dは指定した項目の削除を意味し、アプリのアンインストールやClashの設定削除は行いません。
CheckNetIsolation.exe LoopbackExempt -d -n=Microsoft.WindowsStore_8wekyb3d8bbwe
CheckNetIsolation.exe LoopbackExempt -s
1つの設定を取り消すために、すべての免除を消去しないでください。通常、アプリの更新後もパッケージファミリIDは維持されますが、再インストール、配布元の変更、別アカウントへの切り替え後は、改めて名前を調べてください。古い名前を機械的に再登録する必要はありません。システムプロキシのポートを変更した場合は、Windowsのプロキシアドレスも確認してください。ループバック免除ではポートは自動更新されません。
- ブラウザーも接続できない:まずクライアント、待ち受けポート、サブスクリプション、ノードへの接続を確認します。
- 隔離されたアプリだけ接続できず、接続一覧にも記録がない:アプリの種類、パッケージファミリ名、ループバック免除を確認します。
- 接続一覧に記録がある:ルール、DNS、プロキシの接続先、対象サービスを確認し、問題の原因をすべてUWPに求めないでください。
確認の順序を「ローカルプロキシの動作確認、対象アプリの特定、必要に応じて免除を追加、アプリを再起動、接続と出口を確認」に固定すると、ローカルループバック制限が原因の問題に対処しつつ、ルールによる振り分け、システムサービスのプロキシ、アカウントの問題を切り分けやすくなります。