なぜ Copilot と Marketplace は「一括プロキシ」に弱いか

Visual Studio Code は、起動時に拡張の一覧取得、更新確認、アイコンや README の取得など、複数の HTTPS エンドポイントへ短い間隔でアクセスします。GitHub Copilot を有効にすると、エディタ本体の通信に加え、認可フロー、モデル推論、テレメトリや設定同期に関わる Microsoft 側の名前空間が加わります。これらがすべて同じ出口品質のプロキシに流れ込むと、「マーケットだけ遅い」「ログインは通るのに補完だけ落ちる」といった部分的成功が起きやすくなります。

Clash は接続ごとにルールでポリシーグループを選びます。ルールが粗いと、国内向けに安定しているはずの CDN が海外ノードへ迂回したり、逆に企業プロキシと競合して TLS が途中で切れたりします。結果として UI 上は単なるスピナーや API タイムアウト に見えますが、実態は「どのホストがどのポリシーに乗ったか」の不整合であることが多いです。

ℹ 観測のコツ：失敗ログに出るホスト名をメモし、拡張インストール時・Copilot サインイン時・補完リクエスト時で名前が変わるかを比較します。層が分かれば、ルールの追加位置と MATCH のデフォルトを誤魔化さずに済みます。

三つの層：マーケット／CDN、GitHub API、Microsoft と Copilot

実務では次の三層に分けて考えると設定がブレにくいです。(1) VS Code 拡張マーケットと配信 CDN——拡張のメタデータ、検索、VSIX やアセットの取得に関わるホスト。(2) GitHub 本体と API——github.com の UI、api.github.com の REST、GraphQL、Git 操作、Issue や PR の連携など。(3) Microsoft アカウントと Copilot バックエンド——サインイン、トークン、Copilot サービスが依存する microsoft.com 系や関連サブドメインです。公式がホスト名を増やすことはあるため、固定リストを一度きりコピーするより、ルールプロバイダで追従しつつ、自環境で観測した不足分だけを上書きする方が長持ちします。

層ごとの典型ホスト（参考）

具体名は時期と SKU で変わり得ますが、分流設計の出発点としては次を押さえます。拡張まわりでは marketplace.visualstudio.com や Visual Studio ブランドの配信ドメイン、パッケージ取得に使われる CDN 系が挙がります。GitHub 側は DOMAIN-SUFFIX,github.com と DOMAIN-SUFFIX,githubusercontent.com をまとめて扱うことが多く、API 専用のサブドメインが別ルールに割れると認可トークンの検証だけ失敗する、といったパターンが出ます。Microsoft 側は login.microsoftonline.com や microsoft.com、Copilot 連携で githubcopilot.com などが議論に上がります。いずれも「全部同じノード」より、レイテンシが許容できる経路に揃えることが安定の鍵です。

ルールとルールセットでホストを束ねる

ルールの並び順は意味を持ちます。狭い DOMAIN や DOMAIN-SUFFIX を先に置き、広いカテゴリルールや GEOIP の前に「開発者スタック用」の束を差し込むと、意図しないマッチを減らせます。サードパーティの巨大ルールセットは便利ですが、github.com を広告ブロックや脅威リスト側が先に捕捉していると、ブラウザでは問題なくても VS Code の子プロセスだけ失敗する、という切り分けが難しくなります。ルールの責務をコメントで残し、更新手順は ルール分流のベストプラクティス に沿って整理するとチームでも再利用しやすいです。

次の例は概念図です。実際のポリシー名やグループは利用中のサブスクリプションに合わせて置き換えてください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Place explicit developer domains before broad catch-all rules
rules:
  - DOMAIN-SUFFIX,marketplace.visualstudio.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,visualstudio.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,vsassets.io,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,github.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,githubusercontent.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,githubcopilot.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,microsoft.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,microsoftonline.com,DEVELOPER_STABLE
  - DOMAIN-SUFFIX,live.com,DEVELOPER_STABLE
  - MATCH,PROXY_OR_DEFAULT

DEVELOPER_STABLE を DIRECT にするか特定の低遅延ノードにするかは、自宅・職場・テザリングのどれで使うかによります。国内直結が速いなら GitHub 本体は DIRECT、Copilot のみ別グループ、といった二段構えも有効です。重要なのは、マーケット取得と API 呼び出しが別ポリシーに割れて Cookie や証明書の文脈が食い違わないことです。

システムプロキシと TUN：優先順位と取りこぼし

macOS や Windows では、Clash が「システムプロキシを注入する」モードと「TUN で仮想インタフェースを立てる」モードの二系統が一般的です。システムプロキシは設定を読むアプリには手軽に効きますが、Electron 系の一部プロセスや CLI ツールは環境変数や独自設定を優先し、OS のプロキシを継承しないことがあります。TUN はカーネルレベルでトラフィックを捕捉するため取りこぼしは減りますが、企業 VPN やゼロトラスト製品とルーティング優先度が衝突することがあります。

優先関係を誤解しやすいのは、「ブラウザでは GitHub にログインできるのに VS Code だけダメ」というケースです。ブラウザはシステムプロキシを踏み、VS Code は別経路——という状況は珍しくありません。方針としては、(1) まずシステムプロキシだけで再現するか確認、(2) 取りこぼしが残るなら TUN を試す、(3) それでも企業 VPN 下なら split tunnel と IT ポリシーを確認、の順が安全です。TUN の前提や競合の典型は TUN の深掘り記事 も参照してください。

ループプロキシ に注意します。OS 全体を Clash へ向けたまま、サブスクリプション取得やルールプロバイダ更新まで不安定なチェーンに流すと、ルールが古いままになり「昨日まで動いていた」状態に陥ります。更新系は確実な DIRECT か専用の低リスクグループを残してください。

DNS・fake-ip と「名前は解けるのに API が timeout」

fake-ip モードでは、アプリに返る IP が合成値であり、実際の名前解決はプロキシ側や Clash の DNS 設定に依存します。DOMAIN-SUFFIX が薄いと、一見すぐに応答が返るのに接続だけが進まず、API タイムアウト に見える現象が出ます。GitHub や Microsoft の公式名を明示ルールで覆い、DNS の nameserver-policy やフォールバックとルール判断を一致させると改善しやすいです。

企業ネットワークでは、社内 DNS が同じラベルに別答えを返し、外部の正しいアドレスに届かないこともあります。split tunnel と整合を取るか、一時的にクリーンな回線で比較試験し、「名前が悪い」のか「経路が悪い」のかを分けます。一般的な DNS の整理は FAQ も併せて参照してください。

Cursor 向け記事との棲み分け

当サイトの Cursor 向けの記事 は、別ベンダーの IDE と OAuth・長寿命セッションの切り分けに焦点を当てています。本稿は Microsoft が提供する VS Code エコシステムと GitHub Copilot に絞り、拡張マーケットと github.com／microsoft.com 系の公式名前空間を Clash でどう束ねるかを扱います。AI サービス全般の分流としては ChatGPT／OpenAI 向け や Gemini 向け の記事と役割が異なり、読者は使うプロダクトに応じて記事を選べます。

⚠ コンプライアンス：法令、利用規約、職場のセキュリティ方針を遵守してください。本稿は許可されたネットワークでの接続安定化の整理であり、未承認の迂回やポリシー回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash と GitHub／Microsoft サービスを使うことが許可されているか確認する。
  2. 失敗時のホスト名を列挙し、マーケット／GitHub API／Microsoft 認証のどの層かを分類する。
  3. ルール順とルールプロバイダの版を確認し、意図しないブロックや誤った GEOIP マッチがないか見る。
  4. システムプロキシのみ、TUN のみ、の A/B 比較で VS Code プロセスの取りこぼしを潰す。
  5. DNS モードと fake-ip をルールと整合させ、「即解決・接続停滞」を再現ログで切り分ける。
  6. サブスクとルール更新がループせず成功する直列経路を残す。
  7. 別回線やモバイルテザリングで切り分け、ISP 側とサービス側障害を除外する。

各ステップの前後でスクリーンショットやログ行を残すと、設定の総入れ替えより早く収束します。

まとめ

GitHub Copilot と VS Code 拡張の不安定さは、単一の「GitHub が落ちている」では説明できないことが多く、マーケット／CDN・GitHub API・Microsoft アカウントと Copilot バックエンドという複数層に分けて見ると対処が明確になります。Clash はドメインルールとルールセットで出口を指定できるため、層ごとに DIRECT とプロキシを揃え、システムプロキシと TUN のどちらが実トラフィックを覆っているかを一致させることが重要です。DNS／fake-ip を同じ設計言語で扱えば、見かけの API タイムアウト の多くは観測可能なずれに還元できます。

ブラックボックスな「アクセラレータ」より、ルールとログが読めるクライアントの方が、開発者の時間を節約します。Cursor 向けや他 AI ベンダー向けの記事と併せ、自分のスタックに合った分流だけをプロファイルに載せるのが長期運用では一番ラクです。

同種のツールと比べると、Clash 系はポリシー表現が明示的で、接続ログから握手・転送・切断の段階を追いやすいです。謎のプリセットに振り回されるより、再現手順が残る設定の方がチームでも再利用しやすくなります。

→ ルール設計が固まったら、Clash を無料ダウンロードし、同じ方針を日々の開発環境に載せてみてください。拡張の再試行や Copilot の再接続に費やす時間を、本来のコーディングに戻せます。