Windows プロキシ迷宮：WinINet、WinHTTP、Clash のシステムプロキシと Microsoft Store のオフライン事象

汎用
, , , ,
1

この2日間で、また Windows のプロキシ体系に教育されました。表面症状は：

  • Chrome は普通にネットに出られる
  • コマンドラインも大半のサイトにアクセスできる
  • なのに Microsoft Store だけは真顔で「インターネットに接続されていません」と言ってくる

最後の真相は：ネットがないんじゃなくて、「別のネットワークスタックを通っていた」。

先に結論（忙しい人向け）

Windows には、よくあるだけでも少なくとも3つのプロキシ入口があります：

  1. WinINet：多くのデスクトップアプリ、ブラウザ、UWP の前景が参照（「システムプロキシ」は通常これを指す）
  2. WinHTTP：多くのシステムサービス/バックグラウンドコンポーネントが使用（netsh winhttp show proxy のやつ）
  3. 環境変数プロキシ：HTTP_PROXY/HTTPS_PROXY/NO_PROXY、主に CLI ツール向け

Clash で「システムプロキシ」を押したとき、だいたい変更されるのは WinINet で、WinHTTP は変わらないことがあります。

私の現場：なぜ「Store はオフライン、ブラウザはオンライン」なのか

当時の私の設定：

  • WinINet = 127.0.0.1:7890（mihomo のローカルプロキシ）
  • WinHTTP = DIRECT
  • Clash の TUN は有効

挙動：

  • Chrome は WinINet を通り、プロキシが使えるので「ネットは正常」に見える
  • Microsoft Store（UWP/AppContainer）がネットワークエラー 0x80072EFD（CannotConnect）を出す

ポイントはここ：

UWP はデフォルトで本機のループバックアドレス（127.0.0.1/localhost）にアクセスできない。

そのため Store が本機プロキシのポートに接続しようとすると、サンドボックスの規則で弾かれる可能性があります。インターネットに出られないのではなく、まず「プロキシ入口」に到達できていません。

「中国本土の Store は直繋ぎできる」でもなぜコケる？

よく言われるのが：storeedge.microsoft.com は中国本土ではもともと直繋ぎできる、という話。これは間違っていませんが、不十分です。

なぜなら経路は：

UWP アプリ -> 本機プロキシ(127.0.0.1:7890) -> ルール分岐(DIRECT/PROXY) -> 対象サイト

最初の1ホップ（UWP からローカルループバック）が弾かれると、その先の「本来なら直繋ぎ」は発生する余地がありません。

今回ちゃんと直った実際の操作

全体プロキシを切らず、WinHTTP も触らず、既存の依存サービスも動かさず、最小変更だけやりました：

checknetisolation loopbackexempt -a -n=microsoft.windowsstore_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.storepurchaseapp_8wekyb3d8bbwe
checknetisolation loopbackexempt -a -n=microsoft.xboxidentityprovider_8wekyb3d8bbwe

その後 Store を再起動して復旧。

これは UWP ループバック例外（loopback exempt）：指定した UWP のパッケージ名をホワイトリスト化し、本機の localhost/127.0.0.1 へのアクセスを許可するものです。

Windows のプロキシが「ややこしく見える」理由

なぜなら一本道ではなく、「複数車線が並走」しているから：

  • ブラウザ/一部デスクトップアプリ：WinINet を参照
  • システムサービス：WinHTTP を参照
  • ターミナルツール：環境変数しか見ないことがある
  • UWP：AppContainer のループバック安全ポリシーの影響も受ける
  • TUN：IP レイヤーで一部トラフィックを横取りすることもある

こちらは「スイッチ1個」を見ているのに、システム内部には実際「ゲートが5つ」あります。

Linux / macOS との比較

Linux

  • 「システムプロキシの総合スイッチ」で全アプリを覆うものはない
  • よくあるのは env 変数 + アプリごとの設定
  • 透過プロキシは通常 tun + iptables/nftables + policy routing に頼る
  • 良い点：制御しやすい、スクリプト化しやすい；悪い点：断片化が目立つ

macOS

  • 比較的統一されたネットワークサービスのプロキシ設定（System Settings）がある
  • ただし CLI ツールは依然として env 変数を見ることが多い
  • UWP のような AppContainer loopback のセマンティクスはない（サンドボックスモデルが異なる）

Windows

  • GUI 体験は「統一入口」っぽいが、内部の歴史的負債が最大
  • WinINet / WinHTTP / UWP / TUN が共存し、「これだけ繋がる、あれだけオフライン」が最も起きやすい

私が今よく使う切り分け手順

  1. WinINet を確認：プロキシが 127.0.0.1:xxxx になっているか
  2. WinHTTP を確認：netsh winhttp show proxy
  3. プロキシポートが本当に LISTEN しているか（Get-NetTCPConnection）
  4. UWP ループバック例外を確認（checknetisolation loopbackexempt -s）
  5. アプリのログ/エラーコードを見る（例：Store の 0x80072EFD）
  6. それからプロキシ問題か、DNS 問題か、対象サイト問題かを判断

ひと言ぼやいて締め

Windows のプロキシは「設定を間違えた」んじゃなくて、「そのうちの1層だけ正しく設定した」だけ。

「ブラウザは普通なのに、Store だけ断線扱い」になったら、まず人生を疑う前に、そもそも同じ道を通っていない可能性を疑ったほうがいい。:slightly_smiling_face:

「いいね！」 1