まずUWPのループバック制限が原因か確認する

典型的な症状は、Clashが起動していてブラウザーは正常にアクセスでき、従来型のデスクトップアプリもプロキシを利用できる一方で、Microsoft Store、旧版メール、フォト、Xbox、一部のストアアプリだけが直結になったり、読み込みがタイムアウトしたり、「ネットワークに接続できません」と表示されたりするケースです。この場合、プロキシノードやサブスクリプションではなく、WindowsがAppContainerアプリに適用するネットワーク分離ルールに原因があることが多くあります。

多くのClash GUIクライアントでは、「システムプロキシ」を有効にすると、Windowsのプロキシサーバーにローカルアドレス（HTTPプロキシなら 127.0.0.1:7890 など、またはmixed-portと同じポート）が設定されます。通常のWin32アプリはこのローカルの待ち受けアドレスへ接続できますが、AppContainerの分離対象であるUWPアプリは既定ではローカルのループバックインターフェースへ自由にアクセスできません。そのため、リクエストがClashのコアまで届かなくなります。

4つの確認で原因を絞り込む

  1. Clashクライアントで現在の設定が有効になっていることを確認し、接続可能なポリシーを選択します。
  2. 「設定」または「全般」を開き、「システムプロキシ」が有効になっていることを確認します。
  3. Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、プロキシアドレスが 127.0.0.1 であり、ポートがClashの現在の待ち受けポートと一致していることを確認します。
  4. デスクトップブラウザーと対象のストアアプリをそれぞれテストします。ブラウザーは正常で対象アプリだけが失敗する場合、ループバック分離でよく見られる症状に該当します。

ポートは必ずしも7890とは限りません。mihomoコアを採用するクライアントでは mixed-port: 7890 が使われることもあれば、ユーザーが7891、7897など別の未使用ポートへ変更している場合もあります。診断では、現在の設定とクライアントの設定画面に表示されるポートを基準にしてください。

方法1：Clashクライアント内蔵のUWPループバックツールを使う

一部のWindows GUIクライアントには、ループバック例外を管理する機能が組み込まれています。パッケージファミリ名やコマンドラインに慣れていない場合に適した方法です。実際にはWindowsのAppContainerループバック例外リストを変更するため、クライアントを終了しても、システムへ書き込まれたルールは通常すぐには消えません。

一般的な入口と操作手順

メニュー名はクライアントによって多少異なります。従来のClash for Windowsでは、「General」→「UWP Loopback」→「Launch Helper」が一般的です。ほかのクライアントでは、「設定」→「システム設定」→「UWPループバック」や「ネットワークツール」などに配置されています。次の順番で操作してください。

  1. テスト中のUWPアプリをいったん終了し、古い接続やキャッシュが結果に影響しないようにします。
  2. 通常どおりClashクライアントを起動し、有効な設定を読み込みます。
  3. UWP Loopbackまたはループバック例外ツールを開きます。Windowsで権限の確認が表示されたら、プログラムの入手元を確認したうえで、今回の管理操作を許可します。
  4. アプリ一覧から対象のプログラム（Microsoft Store、Xbox、指定のストアアプリなど）を探します。
  5. 対象のプログラムにチェックを入れ、「Save Changes」「変更を保存」など、同等の機能を持つボタンを選択します。
  6. クライアントに戻り、システムプロキシが引き続き有効であることを確認してから、対象アプリを再起動します。

一覧に対象アプリが見つからない場合

  • まず対象アプリを少なくとも1回起動してください。一部のパッケージは登録が完了してから一覧に表示されます。
  • アプリがMicrosoft Storeから入手したもの、またはAppX、MSIXパッケージとしてインストールされたものか確認します。通常のWin32アプリにUWPのループバック例外は必要ありません。
  • ループバックツールを再起動し、登録済みパッケージを再読み込みさせます。
  • それでも認識できない場合は、後述のPowerShellと CheckNetIsolation を使う方法に切り替えてください。

新しいアプリの中には、Microsoft Storeからインストールしたものでも、内部では通常のデスクトッププロセスを動かしている場合があります。また、デスクトッププロセスとAppContainerコンポーネントを同時に含むアプリもあります。「ストアから入手した」ことだけでループバック制限の対象と決めつけず、実際のプロセスとテスト結果を合わせて判断してください。

方法2：CheckNetIsolationで例外を正確に追加する

CheckNetIsolation.exe はWindowsに標準搭載されているネットワーク分離管理ツールで、AppContainerのループバック例外を一覧表示、追加、削除できます。コマンドには対象アプリのPackage Family Name（PFN）が必要です。PFNはスタートメニューに表示される名前でも、インストール先フォルダー名でもありません。

手順1：アプリのPackage Family Nameを確認する

スタートボタンを右クリックし、「ターミナル（管理者）」または「Windows PowerShell（管理者）」を開きます。まずアプリ名でインストール済みパッケージを絞り込みます。次の例では、名前にXboxを含むパッケージを検索します。

Get-AppxPackage *Xbox* | Select-Object Name, PackageFamilyName

パッケージ名が分からない場合は、現在のユーザーに登録されているすべてのAppXパッケージを一覧表示し、ターミナルで対象名を検索します。

Get-AppxPackage | Sort-Object Name | Select-Object Name, PackageFamilyName

出力には通常、2つの列が含まれます。コピーするのは PackageFamilyName の完全な値で、名前と発行元IDを組み合わせた長い文字列です。PackageFullName はコピーしないでください。こちらには通常、バージョン番号、アーキテクチャ、リソース識別子も含まれます。

手順2：ループバック例外を追加する

次のコマンドにある例示用のPFNを、実際に確認した値へ置き換えます。-a は追加を示し、-n の後にパッケージファミリ名を指定します。

CheckNetIsolation LoopbackExempt -a -n="対象アプリのPackageFamilyName"

コマンドが正常に実行されると、通常は完了メッセージが表示されます。続けて現在の例外項目を一覧表示し、対象パッケージが登録されたことを確認します。

CheckNetIsolation LoopbackExempt -s

一覧が長い場合は、結果をいったんテキストファイルへ出力してからパッケージファミリ名を検索できます。

CheckNetIsolation LoopbackExempt -s > "$env:TEMP\loopback-list.txt"
notepad "$env:TEMP\loopback-list.txt"

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

アプリがローカルプロキシへ接続する必要がなくなった場合や、誤ったパッケージファミリ名を追加した場合は、-d で該当項目を削除できます。

CheckNetIsolation LoopbackExempt -d -n="対象アプリのPackageFamilyName"

削除後、もう一度 CheckNetIsolation LoopbackExempt -s を実行し、その項目が一覧から消えたことを確認します。例外の変更にWindowsの再起動は通常必要ありませんが、対象アプリを完全に終了してから再度開き、新しい接続を確立させてください。

リクエストが本当にClashへ届いているか確認する

アプリが再びネットワークへ接続できても、リクエストが必ず現在のプロキシを経由しているとは限りません。確認時は、アプリの動作、Clashの接続ログ、システムプロキシの状態を同時に確認し、キャッシュされた内容を修復成功と誤認しないようにします。

確認1：Clashの接続ログを見る

  1. クライアントで「接続」「Connections」など、同等の画面を開きます。
  2. 既存のログを消去するか、現在時刻を記録します。
  3. 対象のUWPアプリを完全に終了し、再度起動してネットワークリクエストを1回発生させます。
  4. アプリがアクセスしたドメインに対応する新しい接続が表示されるか確認します。
  5. 接続に適用されたルール、ポリシーグループ、最終ノードを確認し、設定の想定どおりの結果になっているか確認します。

接続画面に対象ドメインが表示されれば、リクエストはClashコアまで届いています。接続が存在するのに開けない場合は、ルールの適用結果、DNS解決、ノードの疎通を確認してください。ループバック例外を繰り返し追加する必要はありません。

確認2：システムプロキシのオン・オフを比較する

対象アプリを完全に終了した状態に保ち、Clashのシステムプロキシを有効にして1回テストし、次に無効にしてもう1回テストします。有効時に接続ログが現れ、無効時に消え、アプリのネットワーク動作も連動して変化するなら、通信経路の関係は明確です。テスト後は元のプロキシ設定に戻してください。

確認3：ローカルの待ち受けポートを確認する

PowerShellで、Clashが想定したポートを待ち受けているか確認します。mixed-portが7890の場合は、次のコマンドを実行できます。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

正常な結果では、ポートがListen状態で表示されます。何も表示されない場合、コアがそのポートを待ち受けていないか、クライアントが別のポートを使用しています。この状態では、ループバック例外が正しく設定されていても、UWPアプリはプロキシへ接続できません。

例外を追加しても解決しない場合の確認順序

1. システムプロキシのポートとClashの待ち受けポートが一致していない

その後に起きる問題として最も多いケースです。たとえば設定が mixed-port: 7897 なのに、Windowsのプロキシが 127.0.0.1:7890 を指している場合があります。クライアントの「設定」→「パラメーター設定」で混合ポートを確認し、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」でアドレスとポートを照合してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

allow-lan はLAN上のデバイスがClashの待ち受けポートへ接続できるかを制御する項目であり、ローカルのUWPループバック制限を解決するスイッチではありません。ローカルアプリへの対処だけを目的に true へ変更する必要は通常ありません。

2. 対象アプリが別のパッケージを使用している

同じ製品に、正式版、ベータ版、ゲームサービスコンポーネント、独立したログインコンポーネントが存在する場合があります。メインプログラムに例外を追加しても、実際にリクエストを発生させているのは別のAppXパッケージかもしれません。もう一度 Get-AppxPackage を実行し、製品名に関連するパッケージを確認して、Clashのログと照合しながら一つずつ検証してください。

3. アプリのプロセスが完全に終了していない

ウィンドウの閉じるボタンを押しても、アプリがバックグラウンドで動作し続けることがあります。「タスク マネージャー」→「プロセス」で該当タスクを終了し、5秒待ってから再起動してください。必要に応じて現在のWindowsユーザーセッションからサインアウトし、AppContainerのネットワーク状態を再構築します。

4. ルールによってリクエストが直接接続になっている

ループバックの修正は、リクエストをClashへ届けるだけで、ルールの結果は変えません。接続画面に DIRECT と表示される場合、ドメインまたはIPが直結ルールに一致しています。設定内のドメインルール、ルールセットの順序、最終的に一致した項目を確認し、ループバックの問題とプロキシルールの問題を混同しないでください。

5. DNSまたはTUNモードが二次的な問題を起こしている

TUNモードを有効にすると、一部のクライアントはより多くのシステム通信を引き受けますが、UWPアプリの実際の動作は、クライアントの実装、Windowsのネットワークスタック、現在の設定にも左右されます。システムプロキシで正常に戻ることを確認してから、TUNへ切り替えて比較してください。ループバック、DNS、TUN、ルールを同時に変更すると、どの変更が効果をもたらしたのか分からなくなります。

ループバック例外、システムプロキシ、TUNの関係

この3つの概念は異なる階層にあります。システムプロキシは、プロキシ設定に対応したプログラムへHTTPまたはHTTPSリクエストをローカルポートへ渡すよう指示します。ループバック例外は、分離されたAppContainerがこのローカルポートへアクセスできるようにします。TUNモードは、仮想ネットワークインターフェースを介して、より広い範囲のIP通信を引き受けます。

  • システムプロキシ：ブラウザーやWindowsのプロキシ設定に従うアプリに適しており、一般的な接続先は 127.0.0.1:7890 です。
  • UWPループバック例外：AppContainerがローカルのプロキシ待ち受けアドレスへアクセスできない問題を解決します。ノードの選択やルールの変更は行いません。
  • TUNモード：システムプロキシを読み取らないプログラムや、より複雑な通信の引き受けに適しています。通常はドライバー、サービス、または管理者権限が必要です。

システムプロキシを有効にしているのに、使えないUWPアプリが1〜2個だけある場合は、まず対象を絞ったループバック例外の追加を試してください。変更範囲を明確に保てます。システムプロキシに対応しないプログラムを多数引き受ける必要がある場合に、TUNモードを検討します。モードを切り替える前に、現在使えている設定を保存し、mixed-port、DNS、ルールモードを記録しておくと復元しやすくなります。

対応結果のチェックリスト

  • Clashコアが起動しており、設定ファイルの読み込みエラーがない。
  • 現在のノードが利用可能で、デスクトップブラウザーが同じ設定でネットワークへアクセスできる。
  • Windowsのシステムプロキシアドレスとmixed-portが完全に一致している。
  • 対象UWPアプリのPackage Family Nameがループバック例外に追加されている。
  • アプリを完全に終了して再起動し、古い接続を再利用していない。
  • Clashの接続画面に、対象アプリが発生させたドメインリクエストが表示される。
  • 接続に適用されたルールとポリシーが想定どおりで、誤ってDIRECTに割り当てられていない。
  • テスト終了後、実際に必要なループバック例外だけを残している。

以上を確認すれば、問題を3種類に切り分けられます。アプリがローカルプロキシへ接続できない、リクエストはClashへ届いているがルール選択が誤っている、ノードまたはDNS自体が利用できない、の3つです。通信経路を段階ごとに確認するほうが、ノードを何度も切り替えたりクライアントを再インストールしたりするより原因を特定しやすくなります。