2026、Cline・Roo Code を Clash で安定：
VS Code 拡張マーケットと API を DOMAIN-SUFFIX で分流する

1 独立 IDE ではなく「VS Code 本体＋拡張市場＋拡張内通信」

Cline や Roo Code は、いずれも Visual Studio Code（および互換フォーク）の拡張として動きます。利用者の体感は「エディタの中でエージェントが動いている」一点に見えますが、ネットワークの実体は次の複数レーンに分かれます。① Microsoft 公式の拡張マーケットからのメタデータ取得・更新確認。② ギャラリーに紐づくCDN上の VSIX やアセット。③ 設定や同期に関わる Microsoft 系ホスト。④ 拡張が直接呼び出すLLM・ツール API（OpenAI、Anthropic、OpenRouter、各種ローカル／セルフホスト endpoint など）。⑤ チームによっては OpenVSX や企業内レジストリへ向ける代替経路。

このため、当ブログのCursor 向け記事のような「Electron 単体アプリのシステムプロキシ」と同じ貼り方でも多くは動きますが、優先してプロキシへ送るべきドメイン集合が異なります。Cursor は自前の配布・更新・モデル接続に寄りますが、VS Code 路線は marketplace.visualstudio.com や *.vsassets.io 系が必ず通る土俵になりやすい——ここをルールで抜けると「拡張の検索だけ遅い」「更新チェックがタイムアウト」といった部分故障に見えます。

2026 年時点でも、拡張ごとに接続先は増減します。本稿の YAML 断片は再現用の出発点であり、実環境では Clash の接続ログと Developer Tools（必要なら）を見ながら DOMAIN-SUFFIX を足し引きしてください。重要なのは、「AI っぽいホストだけ」ではなくマーケットと CDN を同じアウトバウンドに寄せることで、名前解決と TLS の一貫性を保ちやすくする点です。

2 通信が分散する理由（遅延より「別経路」が敵になりやすい）

VS Code 系は Chromium 由来のネットワークスタックと Node ランタイムの両方から外向き接続を張ります。システムプロキシを見るパスと、環境変数や直結ソケットに逃げるパスが混在すると、同じ画面内でもホストごとに出口が変わる状態になります。FakeIP や Split DNS を使っている場合、解決結果がホスト間で揃わないと、ルールは正しくても実接続だけ別リージョンに飛ぶ、といった見かけ上の不整合が出ます。

Cline／Roo Code のような拡張は、エージェント実行中に長めの HTTP/2 ストリームや SSE を張ることがあります。帯域が足りないより、途中で RST されるノードや、認証トークン取得だけ別経路で失敗するケースの方が、UI では「たまに応答が止まる」ように見えます。分流設計では、マーケット・CDN・モデル API を同じ安定したプロキシグループに載せ、国内向けサービスは GEOIP,CN,DIRECT などで素直に直結させる二層が扱いやすいです。

3 DOMAIN-SUFFIX で押さえる「VS Code 周辺」の土台

以下は、拡張の取得・更新・ギャラリー資産に頻出するドメインの例です。環境や VS Code のビルド（安定版／Insiders）によってホスト名は増えます。接続ログに出たホストをその都度 DOMAIN-SUFFIX として追記する運用と組み合わせてください。

# VS Code marketplace & gallery CDN (examples — extend via your logs)
DOMAIN-SUFFIX,visualstudio.com,AI_PROXY
DOMAIN-SUFFIX,vsassets.io,AI_PROXY
DOMAIN-SUFFIX,msecnd.net,AI_PROXY
DOMAIN-SUFFIX,azureedge.net,AI_PROXY
DOMAIN-SUFFIX,live.com,AI_PROXY
DOMAIN-SUFFIX,microsoftonline.com,AI_PROXY

# OpenVSX (when using open registry)
DOMAIN-SUFFIX,open-vsx.org,AI_PROXY
DOMAIN-SUFFIX,blob.core.windows.net,AI_PROXY

# Common LLM API endpoints (add/remove per provider you use)
DOMAIN-SUFFIX,openai.com,AI_PROXY
DOMAIN-SUFFIX,anthropic.com,AI_PROXY
DOMAIN-SUFFIX,openrouter.ai,AI_PROXY
DOMAIN-SUFFIX,googleapis.com,AI_PROXY

blob.core.windows.net は広くマッチするため、運用では Rule Provider 側でサブセット化するか、より具体的なサフィックスに分解する方が安全です。逆に、マーケットだけ通して CDN を直結のまま残すと、VSIX 取得だけ失敗する——といった非対称な障害が起きやすいので、ギャラリーと CDN をセットで同じグループへ寄せるのが無難です。

GitHub Copilot 公式拡張を併用する場合は、Copilot 向け記事のドメインと重複する部分があります。ルールの行順が前後すると片方だけ別アウトバウンドに落ちるため、PROVIDER 名と優先順位をチーム内で固定しておくと再現性が上がります。

4 Rule Provider でリストを外だしし、2026 年も保守しやすくする

手書きの DOMAIN-SUFFIX が数十行を超えると、購読更新のたびにコンフリクトしやすくなります。Rule Provider に「VS Code マーケット＋CDN」「LLM API」「Microsoft 認証」など用途別の YAML／text を分け、rules では RULE-SET で取り込むと、差分レビューがしやすくなります。社内ではプライベート Git リポジトリや社内 CDN に置き、Clash の proxy-providers と同様にバージョン付き URLで配る運用が一般的です。

外部のコミュニティリストをそのまま信頼するかどうかは組織ポリシー次第です。最低限、取得元の整合性（HTTPS・署名・タグ）と、リストに含まれる広すぎるサフィックス（例：クラウドストレージ全体）を監査してください。DOMAIN-SUFFIX は便利ですが、1 行の影響範囲が大きい——だからこそ Provider を分割し、拡張 AI 用のセットだけを頻繁に更新する、という切り口が現実的です。

DNS とセットで見る

ルールだけ整えても、名前解決がブラウザや別リゾルバに逃げると意味が半減します。Mihomo／Meta コアでは DoH・FakeIP・fallback の実務を参照し、OS のスタブとコアの listen を二重管理しないよう揃えてください。Chromium 系の「セキュア DNS」がオンだと解決だけ別経路になるため、併せてChrome／Edge のセキュア DNS 記事も必要に応じて確認するとよいでしょう。

5 システムプロキシと TUN：ターミナル・CLI まで含めて一枚にする

VS Code の UI まわりは OS のシステムプロキシを尊重しやすい一方、統合ターミナルから動く git、npm、コンテナツールは環境変数や仮想 NIC 側の捕捉が必要になることがあります。Clash Verge Rev の TUN モードを有効化すると、同じマシン上の開発者トラフィックを一枚のルール集合に載せやすくなり、拡張の API 呼び出しと CLI の外向き通信のズレを減らせます。

TUN を使わない方針なら、シェルに http_proxy／https_proxy／ALL_PROXY を明示し、NO_PROXY に社内 Git とレジストリを列挙します。VS Code の http.proxy 設定を手で書くより、Clash を単一の出口に寄せて OS 設定に従わせる方が、拡張ごとの差異を吸収しやすいケースが多いです。

6 OpenVSX・VSCodium 系と「レジストリの切り替え」

Microsoft 公式マーケットを使わないビルドでは、OpenVSX レジストリとそのストレージエンドポイントが主経路になります。上記リストに open-vsx.org と Azure Blob 系を入れても、実際のホスト名はログで確認するのが確実です。社内ミラーやオフライン VSIX 配布に切り替えた場合は、ルールから余計なサフィックスを外し、実際に解決・接続している FQDNだけを残すと誤ルーティングが減ります。

中国本土向けのミラーや CDN（例：vscode.cdn.azure.cn など）を使う構成では、地理的に近いエッジへ直結させた方が速いこともあります。その場合でも「拡張パネルは速いがモデル API だけ遅い」といった分割が起きないよう、API 側のサフィックスは別セレクタで束ね、A/B 切り替えしやすい YAML 構造にしておくと運用が楽です。

7 切り分け（症状別）

• 拡張の検索・インストールだけ失敗する： マーケット／CDN の DOMAIN-SUFFIX が DIRECT に落ちていないか、DNS が期待と異なる答えを返していないかをログで確認。セキュア DNS の迂回も疑う。
• チャットは動くが更新確認が遅い： ギャラリーと本体更新 CDN が別ルールに分断されていないか。帯域より経路の一貫性を優先。
• 認証だけ失敗する： Microsoft／GitHub の OAuth 系ホストをプロキシでブロックしていないか、企業フィルタと衝突していないか。
• ターミナルだけ別出口になる： TUN オフかつ環境変数未設定の典型。TUN ガイドで仮想 NIC を有効化するか、シェルにプロキシを足す。
• 証明書エラー： TLS インスペクション環境では OS 信頼ストアと VS Code（Electron）が同じ CA を見ているか確認。

8 まとめ

Cline や Roo Code のような VS Code 拡張型ツールは、拡張マーケット・CDN・モデル APIに通信が分散します。独立 IDE 向け記事と棲み分けがつくのは、「Microsoft／OpenVSX 系のドメインを最初から分流リストに含める」ことです。DOMAIN-SUFFIX と Rule Provider で保守性を確保し、システムプロキシと TUN で CLI まで含めた一貫した出口を作ると、2026 年現在の AI コーディング拡張でも再現性の高い安定運用に近づきます。

ルールと DNS はセットです。コア内部の DNS 設計は Meta カーネル向け DNS 記事を、クライアント操作は TUN ガイドを参照しつつ、本稿のリストを出発点にログで磨き込んでください。

単機能の HTTP プロキシより、ルール分流と DNS を一体で扱える Clash 互換スタックの方が、マーケットと API が同居する IDE トラフィックには向きやすいです。長めの推論セッションでは、ノードの安定性がそのまま生産性に効きます。

→ 無料で Clash をダウンロードし、VS Code 拡張のマーケットと API をまとめて整える