1 為何這不是「另一篇 Cursor 獨立應用程式」教學
Cursor、Windsurf 這類產品是獨立 Electron 應用程式：品牌方可以高度掌控更新通道、內建模型請求與帳號體驗，站內也有對應的Cursor 分流與Windsurf 分流專文。相對地，Cline、Roo Code 等工具跑在 VS Code 擴充主程序（Extension Host）裡：您先安裝的是「編輯器本體」，再從擴充市集拉套件、更新圖示與中繼資料，最後才在背景對OpenAI、Anthropic、Google等供應商發出模型請求。
這代表故障現象會拆成三層：市集與 CDN 載不進來（搜尋不到外掛、安裝卡住）、VS Code 自己更新失敗（下載逾時）、以及擴充已安裝但模型 API 逾時（其實是規則沒命中供應商網域）。若只用「AI 大分類」的 GEOSITE 或關鍵字規則，很容易出現要嘛整包走代理、要嘛漏掉某一條 CDN 子網域兩種極端。本文把Microsoft／市集／OpenVSX與模型供應商拆開談，讓您能用 DOMAIN-SUFFIX 與 Rule Provider 維護一份可複用的清單。
成功標準可以具體化成：在 Rule 模式下，搜尋與安裝 Cline／Roo Code、更新 VS Code、以及實際送出模型請求時，連線日誌中的 SNI 都能穩定命中您為「開發工具鏈」保留的同一策略組（或您刻意拆開的多策略組）。
2 市集、更新與擴充聯網：先把流量形狀分桶
當您在 VS Code 裡打開擴充面板並搜尋 Cline 或 Roo Code，前端會向市集 API與靜態資源 CDN請求清單、圖示與版本資訊；按下安裝後，還可能觸發額外的套件下載與完整性驗證。若您使用官方組建的 VS Code 並連到 Visual Studio Marketplace，常見主機會落在 marketplace.visualstudio.com、*.visualstudio.com 樹，以及 vsassets.io 這類資源網域（實際子網域請以連線紀錄為準）。
另一條常見路徑是開源／企業內部偏好的 Open VSX（open-vsx.org）：部分發行版或內部鏡像會改從這裡拉擴充，資產也可能落在雲端儲存體上，SNI 會比「只記一個根網域」更發散。第三條路是 VS Code 應用程式更新本身：與編輯器版本通道相關的網域／CDN（例如 vscode-cdn.net、*.vo.msecnd.net 等）若被誤判成直連，會表現成「下載更新永遠轉圈圈」，與 AI 無關卻常被誤會成節點問題。
與 Copilot 官方外掛的界線
若您使用的是 GitHub Copilot 官方擴充，還會多出登入與授權相關的 GitHub 網域；這條路徑在站內Copilot 分流已另文整理。本文聚焦第三方 AI 擴充如何依託 VS Code 基礎設施，並在末段說明與 Copilot 文的互補關係，避免讀者把「所有 VS Code AI」混成同一組規則卻漏掉市集或 CDN。
3 網域分類心智模型（請以實際日誌校準）
下列分類是撰寫規則時的思考框架，不是保證永久完整的官方清單。產品改版、CDN 調度與企業代理都可能新增主機名稱；實務上請以 Clash 連線日誌或 TLS SNI 為準補洞，必要時搭配HTTPS Sniffer收斂。
- 市集與中繼資料（Microsoft 生態）：
marketplace.visualstudio.com、廣義的visualstudio.com子網域（含 API／驗證相關主機，依環境而異）。 - 擴充資產與圖示 CDN：
vsassets.io樹常出現於圖示、套件片段與靜態資源；若規則只寫市集主機而漏掉 CDN，會出現「列表看得到、縮圖與安裝失敗」。 - VS Code 更新與發佈資產：
vscode-cdn.net、以及歷史上常見的*.vo.msecnd.net類更新承載網域；不同通道（Stable／Insiders）實際主機請以日誌為準。 - Open VSX：
open-vsx.org與其關聯的資產下載主機；若您看到blob.core.windows.net這類儲存體網域，請審慎評估是否要以過寬後綴放行，避免把不相關 Azure 流量全導向代理。 - 模型與身分驗證：當 Cline／Roo Code 設定為呼叫 OpenAI、Anthropic、Google 等供應商時，請求會落在各廠 API 與 OAuth 網域；這一段與「市集」無關，應沿用各廠專文或您自建的供應商 Rule Provider。
*.visualstudio.com 或 CDN 子網域；也避免把過寬的 MATCH 放在前面，導致後續細則永遠無法命中。
4 Rule Provider 與 DOMAIN-SUFFIX：讓「開發工具鏈」可版本化
對需要長期維護桌面環境的使用者，建議把「VS Code 市集＋CDN＋更新」收成單一 Rule Provider（或獨立 YAML 片段），設定每日／每週自動拉取；本地再以幾條 DOMAIN-SUFFIX 作補丁，專門承接日誌裡新出現的後綴。相較於每次故障就手動在訂閱裡搜尋關鍵字，這種結構比較容易做 code review，也方便團隊成員共用。
若您尚未把供應商訂閱轉成可用的設定檔，可先完成訂閱轉換與合併，再把自建的 vscode-ecosystem.yaml 以 rule-providers 掛進主設定。記得讓策略組名稱與規則引用一致，並確認 RULE-SET 的類型（classical／domain）與核心版本相容。
5 Clash 設定範例：市集／CDN 與策略組綁定
下方為教學用結構示例：假設您已定義名為 PROXY 的策略組（請替換成您實際的代理組名稱）。第一段示範以遠端 Rule Provider 承載「VS Code 生態」規則；第二段示範純本機 DOMAIN-SUFFIX 最小集合。實務可擇一或合併，並依日誌增刪，切勿照抄後就不再更新。
# Example only — replace PROXY and provider URL with your own
rule-providers:
vscode-ecosystem:
type: http
behavior: classical
url: "https://example.com/rules/vscode-ecosystem.yaml"
path: ./ruleset/vscode-ecosystem.yaml
interval: 86400
rules:
- RULE-SET,vscode-ecosystem,PROXY
- DOMAIN-SUFFIX,visualstudio.com,PROXY
- DOMAIN-SUFFIX,vsassets.io,PROXY
- DOMAIN-SUFFIX,vscode-cdn.net,PROXY
- DOMAIN-SUFFIX,open-vsx.org,PROXY
若您希望把「模型 API」與「市集 CDN」拆成不同策略組（例如 API 走低延遲專線、市集走一般代理），只要再新增 PROXY_API 等名稱，並在供應商規則中引用即可。需要自動測速與容錯切換時，可延伸閱讀URL-Test 與 Fallback 策略組，讓規則與節點選擇協同。
6 DNS、TUN 與 Extension Host：為何「只開系統代理」有時不夠
VS Code 的擴充程序大多跑在 Node 相容的執行緒中；許多 HTTP 客戶端預設會讀取系統 Proxy，但也有例外（自訂 Agent、gRPC、或某些 SDK 預設直連）。若您只開系統代理而沒開 TUN，最常見的症狀是：市集頁面正常，但某一個模型供應商的 SDK 仍從本機直接連線，規則上看起來「隨機失敗」。
建議把 DNS 一併納入設計：讓域名解析走您信任的上游，並避免瀏覽器或系統層的加密 DNS 繞過 Clash 預期鏈路。可對照Meta 核心 DNS 防洩漏與Chrome／Edge 安全 DNS兩文，把「誰負責解析」與「誰負責路由」對齊。若您希望封包層級統一接管，亦可參考Clash Verge Rev TUN 模式指南。
7 模型供應商網域：不要跟市集混在同一個「模糊標籤」
Cline 與 Roo Code 的設定介面通常允許您選擇多家模型供應商；一旦切換供應商，實際對外連線就會從 OpenAI 端點換成 Anthropic、Google 或其他相容端點。這些網域與 visualstudio.com 完全無關，若硬塞進同一個過寬分類，除錯時很難判斷究竟是「市集壞了」還是「API 金鑰／路由壞了」。
建議直接沿用站內已整理好的供應商專文，將 API 規則與市集規則分檔維護：例如 ChatGPT 與 OpenAI、Claude 與 Anthropic，以及 Gemini 與 Google AI Studio。您的 VS Code 規則集只需在主設定中按順序引用這些片段，就能同時覆蓋「編輯器基建」與「模型供應商」。
8 與 Cursor、Windsurf、Copilot 教學的系列定位
站內Cursor與Windsurf兩篇聚焦獨立 IDE 客戶端的系統代理、TUN 與內建更新；GitHub Copilot則偏重官方擴充＋GitHub 身分與模型端點。本文則補上開源擴充生態這一塊：VS Code 本體＋Marketplace／OpenVSX＋CDN，關鍵字與故障型態與前三者互補而非重複，方便讀者依實際工具鏈各取所需。
9 除錯清單：先對齊規則與 DNS，再換節點
- 搜尋得到外掛但安裝失敗：優先檢查
vsassets.io與相關 CDN 子網域是否被更早的直連規則攔截；對照連線日誌補DOMAIN-SUFFIX。 - VS Code 更新永遠失敗：單獨觸發一次更新並觀察 SNI，常會看到與市集不同的 CDN 後綴；請勿只規劃 Marketplace 而忽略更新通道。
- 只有模型對話失敗、市集正常：轉向供應商專文檢查 API 網域與金鑰環境；並確認 Extension Host 相關程序是否走 TUN 或正確讀取系統 Proxy。
- Rule 模式異常、Global 正常：回到規則順序與 Rule Provider 更新節奏；不要先把問題歸因於節點「不夠快」。
需要挑選與教學一致的桌面用戶端時，建議使用本站下載頁取得安裝包，再依需求開啟 TUN 或僅使用系統代理。
10 總結
2025–2026 年 VS Code 上 Cline、Roo Code 等 AI 擴充的熱度，本質上把開發者的網路依賴拆成「Microsoft／市集基建」與「多供應商模型 API」兩條軸；用 Clash 分流處理時，最穩的做法是分桶＋可維護規則集：以 Rule Provider 或精準 DOMAIN-SUFFIX 覆蓋市集、CDN、更新與 OpenVSX，再引用各供應商專文處理 OpenAI、Anthropic、Google 等端點，並讓 DNS、TUN／系統代理與 Extension Host 的實際行為對齊。
相較於遇到問題就切換 Global，長期更划算的是保留連線日誌作為補規則依據、固定更新 Rule Provider，並清楚區分「這不是 Cursor 獨立應用程式那條路徑」。若您尚未安裝或準備更新用戶端，建議從本站下載頁開始；相較其他同類工具，Clash 系列在規則可維護性與策略組彈性上，對需要細緻調校開發環境的使用者通常更順手。
