検索意図：「VS は普通なのに Codex だけ固まる」が半プロキシで起きやすい理由

ユーザーがブラウザや Teams でmicrosoft.com系を見る体感が安定していても、VS Codeの拡張ホストは別プロセスになり、環境変数の HTTP(S)_PROXY を読まずOS のソケット経路だけを見ることがあります。Microsoft FoundryやAzure OpenAIをまたぐフローでは、(1) アカウント連携のためのlogin.microsoftonline.com、(2) リソースメタやモデルカードを返す管理平面、(3) 実際にトークンを流すRegional OpenAI on Azureホスト、(4) 拡張自体の更新や WebView に載る静的ファイルのCDN、が短時間に連続します。ここで (1)(4) だけが細い uplink のDIRECT、(3) だけが輻輳したPROXYノードへ向かうと、アプリ側から見ると認証は成功したのに最初の completion が返らないという見え方になりがちです。GPT‑5.2‑Codexのような長コンテキスト志向モデルほど、TLS の握手から最初の chunk までのウォームアップが長く見えるため、タイムアウト値が厳しいクライアントでは切断ログだけが残ります。

そこで有用なのは RTT を個別に叩く前に、Mihomo 互換クライアントの同一ウィンドウに並んだ接続行で FQDN と Policy が揃っているかを確認することです。一般的な Clash トラブルシュートでも触れているとおり、症状の原因がノード品質か経路分裂かを混ぜないほど復旧が速くなります。

Foundry・Azure OpenAI・VS Code のレイヤーをログ語彙で対応づける

名前は環境やテナント設定により変わりますが、典型的には次のような塊が現れます。Entra IDとマーケットプレイスを担うホスト群、リソース ID を解決するmanagement.azure.comやAzure Resource Managerまわり、実際の推論を返す*.openai.azure.comまたはcognitiveservices.azure.comに類する名前、そしてアイコンやローカライズ JSON を運ぶ静的 CDNです。Microsoft Foundryポータル自体をブラウザで触っているときと、VS Codeからだけ閉じるときでホスト集合が微妙に違うことも珍しくありません。ブラウザはシステムプロキシや拡張の PACを読む一方、CLI／エディタの一部機能は読まない、という古典的なズレが2026 年のエンタープライズ AI ツールチェーンでもそのまま効いてきます。

ヒント：Azure の公式ドキュメントでホスト名が一覧化されていても、実運用テナントでは別リージョンのエイリアスやプライベート エンドポイントが追加されます。分流ルールは「記事に載っているサンプル文字列」より自分の接続ログに出た FQDNを優先して足してください。

症状のパターン：どのホストだけが伸びているか

次のような組み合わせは策略分裂を疑う目安です。(A) OAuth フローだけ秒で終わるのに、最初の completion が数十秒〜タイムアウトまで進まない。(B) 短いプロンプトは失敗しないが長いストリームだけ途中で止まる。(C) マーケットプレイスのページは開けるが、拡張の更新ダウンロードだけ繰り返し失敗する。(D) 会社 VPN を切ると直るが、VPN＋Clash の二重構成では再発する。これらはすべて、ログに並んだ行ごとのPolicy と実ノード名を見れば、単純な輻輻とは別物かどうかが切り分けやすいタイプです。fake-ipを使っている場合は、ブラウザと VS Code でキャッシュされた仮想 IP の寿命がずれ、見かけ上だけホストが食い違うこともあるため、DNS セクションもセットで見ます。

分流ルール設計：広い microsoft 行を細かい Azure 行が負わないようにする

購読ルールセットにDOMAIN-SUFFIX,microsoft.comのような広い行が先頭付近にあると、自分で追加したopenai.azure.com向けの細かい行より先に評価され、結果としてREST だけ別グループへ落ちることがあります。対策は、(1) ログに確実に出ていた名前を上の方へ移す、(2) AZURE_OPENAIやMS_LOGINのような策略グループ名でブロックを分けて思考しやすくする、(3) RULE-SET の順序とno-resolveやDOMAIN-KEYWORDの相互作用を疑う、の三段です。Clash Verge Revなどビジュアルが強いクライアントでも裏側は同じ評価器なので、GUI で並べ替えたつもりがプロファイルの実ファイルでは別順序になっているケースには注意してください。

# Illustrative YAML only — replace FQDNs with values from your logs
rules:
  - DOMAIN-SUFFIX,login.microsoftonline.com,MS_ID_PROXY
  - DOMAIN-SUFFIX,login.live.com,MS_ID_PROXY
  - DOMAIN-SUFFIX,management.azure.com,AZ_ARM
  - DOMAIN-SUFFIX,openai.azure.com,AZURE OAI MATCH
  - DOMAIN-SUFFIX,cognitiveservices.azure.com,AZURE OAI MATCH
  - DOMAIN-SUFFIX,download.visualstudio.microsoft.com,VS_CDN
  - DOMAIN-SUFFIX,azureedge.net,AZ_CDN
  - DOMAIN-SUFFIX,microsoft.com,MS_CATCHALL
  - MATCH,FINAL_GROUP

AZURE OAI MATCH をDIRECTにするか低遅延のプロキシに固定するかは自環境の uplink によりますが、まずは認証・ARM・推論で三種類の出口が混ざっていないかだけを潰すほうが成功率が高いです。Azure CDN由来の名前が別ペアのノードへ向くと、テレメトリだけ失敗して拡張がretryループに入る、という派生症状も起きます。

注意：社内セキュリティポリシーで特定地域へのプロキシ迂回が禁止されている場合、本稿の手順は許可された経路の範囲に限って適用してください。規約違反を助長する意図はありません。

Visual Studio Code 側で増えやすい「見えない」経路

VS Codeは拡張ごとにExtension Hostプロセスを分け、Git／ターミナル／言語サーバーとも別です。システムプロキシだけ有効にしている状態でも、ネイティブモジュールを含む拡張が Winsock を直接叩くとClash を迂回します。Visual Studio（IDE）本体より軽量なぶん、ユーザーがTUN をオフにしたまま長期運用しがちな点も、タイムアウト体感を裏で増幅します。Visual Studio とインストーラ CDN を分流する記事とセットで読むと、「開発ツールチェーン全体でログイン・大容量・REST が別策略になっていないか」という見取り図を共有できます。

また、マーケットプレイスや設定同期まわりはGitHub由来のホストへも触れるため、GitHub Copilot／Models と Microsoft ログインを整理した稿とルールの競合がないかだけは周期性にチェックしてください。

マイクロソフト CDN と Azure CDN を一枚に載せるときのコツ

CDNのエッジ名は時間と地域で変わるため、過度にホワイトリスト化するとすぐにメンテナンス地獄になります。現実的には、(1) ログに週次で現れる上位ホストだけをルールプロバイダ化、(2) GEOSITEやGEOIPの広い行で丸めない、(3) TLS の SNI と実 IP の両方をログで追えるビューアを使う、がバランス良いです。Brazil Southなどリージョン選択が特殊なテナントでは、CDN の地理 DNSだけ別経路にしてしまい、結果としてLatency が跳ねることもあります。このときDNS のクエリ元アドレスがプロキシ側の出口 IPになっているかどうかも、切り分けのポイントになります。

TUN とシステムプロキシ：どちらを先に疑うか

ブラウザでのFoundryポータル操作だけ見て問題がなくても、VS Codeの子プロセスには届かない場合はTUNモードやシステムワイドの転送が必要になります。手順の詳細はTUN モードの導入ガイドに譲りますが、ここでの判断基準は単純で、(A) UAC 昇格後のプロセスまで含めて揃えたい、(B) dotnet ツールや言語ランタイムがプロキシ環境変数を無視する、(C) WSL やコンテナからホスト側の Clash をまたぐ、のどれかが一つでも当てはまればTUN を検討です。逆に、(A) だけブラウザで試している、(B) 短時間だけ直結テストしたい、(C) 会社ポリシーで TUN が禁止、のときはシステムプロキシ＋拡張側の明示設定に留めるほうが無難です。

OpenAI 直の Codex 故障記事との棲み分け

検索ユーザーによっては「Codex」という単語がOpenAI の開発者コンソールとAzure 上の同名モデル製品を混同します。前者はapi.openai.comやブラウザ UI のホスト集合が中心で、後者はテナント境界・ARM・Regional Endpointが増えます。社内ドキュメントがMicrosoft FoundryやAzure AI Foundryという語を使っている場合は、まず本稿のフレームでログを眺め、OpenAI 直のコンソールだけが怪しいときはOpenAI Codex の分流稿へ移ると迷いが減ります。Anthropic／Claude系とはドメインも規約も別物なので、検索キーワードが誤っているときは記事タイトルだけでなく実際に張っている DNS 名で振り直してください。

実測チェックリスト（短い順）

  1. VS Codeだけで症状を再現し、接続ビューをazureとmicrosoftonlineでフィルタする。
  2. 同一秒内の行でPolicy と実サーバー名が揃っているかスクリーンショットかログファイルに残す。
  3. DNSを一時的に単一路に寄せ、fake-ipと通常モードを隔離環境で比較する。
  4. ルールを並べ替えたあと短い completionだけを連打し、タイムアウトが消えるか確認する。
  5. 問題が残る場合のみTUNをオンにし、同じ操作を繰り返して差分を見る。
  6. 切り分け後は過剰な DOMAIN-KEYWORDを削って最小構成へ戻し、保守コストを抑える。

一度Clash を停止して直経路のみで改善するかだけを確認し、社内ポリシーが許す範囲でプロフィールを戻すのが安全です。

関連：マーケットプレイスと QUIC／DNS の交差点

VS Codeの拡張取得が別経路にずれる典型は、マーケットプレイスと QUIC の組み合わせでも起きます。Cursor とマーケットプレイス分流の記事は製品名が異なりますが、Marketplace × CDN × ブラウザ実装という切り口はVS Codeにも転用しやすいです。Chromeとセットで困っている場合はChrome QUIC とセキュア DNS の稿も参照してください。

本稿は、所属組織の利用規約とネットワーク方針を遵守したうえで、正当な開発業務のためにAzure OpenAIへ接続する開発者向けの経路整理を説明するものです。モデルやエンドポイントの名称、リージョン構成は変更され得ます。記載の YAML は説明用であり、そのままのコピペ運用を推奨するものではありません。

まとめ

GPT‑5.2‑CodexとMicrosoft Foundryがセットで語られる2026 年のエンタープライズ AIでは、VS CodeからAzure OpenAIへ届くパケットが、ログイン・管理平面・推論・Azure CDN／マイクロソフト CDNの静的取得へ分割されます。ClashまたはClash Vergeなど Mihomo 互換クライアントで分流ルールとDNSを揃え、必要ならTUNでプロセス横断の取りこぼしを塞げば、「UI は軽いのに応答だけタイムアウト」というストレスはかなり減らせます。

一方で、ブラウザ専用の簡易 VPN や、ログが読めない単機能プロキシでは、どのホストがDIRECTとPROXYに割れたかを確認するのに時間がかかり、試行錯誤が長引きがちです。設定ファイルを細かく書けるツールでも可視化が弱いと同じ症状を追いかけにくく、結果としてモデル側のせいに見えてしまいます。接続一覧とルールスタックが同じ画面で追える Clash エコシステムなら、Foundry 由来の長めのストリームでも経路の齟齬にすぐ気づけるタイプの運用になりやすいです。まずは手元のログでホスト名と Policy を一枚に揃えてから、ノード品質の話に進むと早いです。Clash を無料ダウンロードし、Azure OpenAI と CDN の出口をログで揃えたうえで、もう一度 GPT‑5.2‑Codex のワークフローを試すことも検討してください。