1 為何 Windsurf 特別需要「拆流量」來做 Clash 分流
許多開發者的困擾是：Chrome 裡能開 windsurf.com、帳號頁面也看得到，但一回編輯器，Cascade 對話轉不停，或擴充安裝進度條卡在零。這類現象往往與「節點延遲數字」無直接關係，而是不同行程走了不同出口：OAuth 與網頁授權走瀏覽器；Electron 主程序與語言伺服器走桌面應用程式堆疊；模型推論、索引與部分遙測則可能打到獨立的子網域。只要其中一段落在錯誤策略組，體感就會像「半套能用」。
Clash 分流的價值，在於把與 Windsurf／Codeium相關的連線綁到同一個穩定、低抖動的策略組，同時讓區網、內部 Git、套件鏡像維持直連，避免無謂繞路。若採「全局代理」固然省事，卻常拖慢本可直連的大型檔案下載；若規則過粗，又可能讓擴充 CDN 誤走直連而被重置。換句話說，您需要的是可維護的模組化規則，而不是一次性口令。
在訂閱仍是二進位或第三方格式時，可先完成訂閱轉 Clash YAML，再把本文整理的條目插入 rules 前段，讓它們優先於寬鬆的 GEOIP 或 MATCH，減少被提前截斷的機率。
2 登入流程、擴充市集與官方網域：先分類再寫規則
實務上建議先把流量分成四類，除錯時會清楚許多。
帳號與產品網頁
訂閱方案、帳單、團隊管理與部分說明文件，主要落在 windsurf.com 與 codeium.com 家族。裝置授權、重新導向與 Cookie 寫入對時間同步與 TLS 中間人極度敏感；若公司網路有 HTTPS 檢查，請先處理憑證信任，否則規則再正確也會握手失敗。
後端服務與資料平面
Windsurf 官方文件在說明防火牆／代理白名單時，建議放行 *.codeium.com、*.windsurf.com 與 *.codeiumdata.com。這三組後綴涵蓋了授權校驗、模型與同步相關連線的主體；具體子網域可能隨版本演進增減，因此除錯時仍應以連線日誌中的實際 SNI 為準，再決定是否補上更細的 DOMAIN 規則。
擴充市集與 CDN
編輯器要下載或更新擴充時，常會打到 Visual Studio Marketplace、vscode-cdn.net 一類 CDN，以及開源社群常用的 open-vsx.org。這些主機與 Codeium 核心網域不同，卻同樣會影響「擴充裝不起來」的體感；建議一併納入同一策略組，或在 Clash 連線面板確認命中規則後再微調。
可選：GitHub 與其他開發者服務
若工作流程會從 Windsurf 內建流程連到 GitHub（Issue、PR、套件下載等），可視需要把 github.com 相關規則與本專題並列；更完整的 GitHub 系流量可另參考GitHub Copilot 與 Clash 分流一文中的網域拆分方式，避免與本文規則互相打架。
3 可複製的規則思路：DOMAIN-SUFFIX 與策略組綁定
下列 YAML 片段僅示範結構，請將 PROXY 換成您實際的策略組名稱（例如 🚀 節點自動）。原則是：與 Windsurf 直接相關的條目越靠前越好，較寬鬆的規則放在後方。
rules:
- DOMAIN-SUFFIX,codeium.com,PROXY
- DOMAIN-SUFFIX,windsurf.com,PROXY
- DOMAIN-SUFFIX,codeiumdata.com,PROXY
- DOMAIN-SUFFIX,open-vsx.org,PROXY
- DOMAIN-SUFFIX,marketplace.visualstudio.com,PROXY
- DOMAIN-SUFFIX,vscode-cdn.net,PROXY
# Observe your connection log and append exact hosts if needed:
# - DOMAIN,api.example.com,PROXY
若您已使用 Rule Provider，可把上述條目獨立成一份小型清單，與社群維護的「開發者規則集」並列，日後靠訂閱更新即可。請謹慎使用過寬的 DOMAIN-KEYWORD：例如單獨匹配 codeium 看起來省事，卻可能在未來誤傷無關資源；較穩健的流程仍是「先從日誌收集主機名，再改為精確的 DOMAIN 或 DOMAIN-SUFFIX」。
對需要固定出口 IP 的企業環境，可把上述規則指向固定節點子組而非「自動選最快」，降低授權或風控因頻繁換 IP 而中斷的風險。這與其他 AI 服務分流教學中強調的「規則一致性優先於測速數字」是同一邏輯。
4 Windsurf 內建代理選項如何與 Clash 對齊
Windsurf 基於 VS Code 技術棧，官方文件另闢章節說明代理：可優先嘗試「偵測系統代理」（Detect proxy），或在設定中手動填寫 HTTP／HTTPS 代理位址，並確認已勾選啟用代理相關選項。若版本較舊，曾有用戶回報編輯器未正確繼承代理的情況，建議更新至文件建議的較新版本後再驗證。
系統代理路線：在圖形用戶端開啟「Set System Proxy」，讓混合埠（常見 7890）承接 HTTP／HTTPS。接著在 Windsurf 設定中搜尋 proxy 相關項目，必要時手動指向 http://127.0.0.1:7890。若僅開系統代理、編輯器卻關閉代理支援，部分延伸或背景程序仍可能裸連。
TUN 模式路線：在核心層接管符合規則的封包，對「忘記設環境變數的子程序」通常最省心。設定步驟可對照Clash Verge Rev TUN 模式指南；啟用後仍建議保留清楚的 Rule 集，避免所有流量無差別進隧道而影響區網工具。
快速自檢混合埠（將埠號改成您的 mixed-port）：
curl -x http://127.0.0.1:7890 -I https://codeium.com若此指令成功、Windsurf 內仍異常，請優先懷疑「應用程式未繼承代理」或「規則把某網域送去錯誤策略」，而不是急著更換遠端節點。
5 DNS、連線日誌與規則誤判
AI IDE 的小封包互動對 DNS 解析路徑極度敏感。若本機與 Clash 核心的 FakeIP、DoH 設定不一致，症狀會像「偶爾能問答、多數時間轉圈」。使用 Meta／Mihomo 核心時，建議一併檢視 fake-ip-filter 與實際命中規則，必要時延伸閱讀DNS 防洩漏與 FakeIP 實作。
建議固定除錯流程：先關閉多餘 VPN，只保留 Clash；在連線列表以 codeium、windsurf 等關鍵字篩選，確認每一條命中規則與策略組；再切換 Global 與 Rule 對照。若 Global 正常而 Rule 異常，幾乎可斷定要改規則或 DNS，而非換用戶端版本。
若您同時使用其他雲端模型服務，可參考ChatGPT／OpenAI 分流教學：網域集合不同，但「拆 API／網頁／CDN」的思維可直接類比，方便在單一 Clash 設定檔內模組化管理。
6 與 Cursor、GitHub Copilot 專題並列讀：互補而不重複
本站以 Cursor 為主的AI IDE 與 Clash 代理教學，偏重多模型供應商與工具鏈協同；GitHub Copilot 分流文則鎖定 GitHub 帳號體驗與官方擴充路徑。Windsurf的流量重心在 Codeium 控制的 codeium.com／codeiumdata.com 與 windsurf.com，並沿用 VS Code 擴充生態；因此規則集應獨立維護，而不是把關鍵字全部塞進單一條 DOMAIN-KEYWORD。
若您同時安裝多款助手，建議在 Clash 裡分策略組：例如「Codeium／Windsurf 專用」與「其他 LLM API」分開，日後其中一方調整端點時，不會互相拖垮。這也是 2026 年開發者網路常見的維護方式：產品線愈多，規則愈要模組化。
尚未選定桌面用戶端時，可先從本站下載頁取得與站內教學一致的版本，再依本機環境決定只開系統代理或一併啟用 TUN。
7 總結
Windsurf要穩，關鍵是把「網頁登入、擴充市集 CDN、Codeium 後端與資料平面、編輯器背景連線」視為同一條開發者網路鏈路，而不是只測瀏覽器能否開首頁。透過 Clash 分流與清楚的 DOMAIN-SUFFIX，再輔以連線日誌驗證，就能把這條鏈路綁到一致的出口，並與直連流量和平共處。
相較一味追求測速數字，更值得投資的是低抖動的小封包互動與可預期的規則命中；在相同節點條件下，可視化規則與跨平台用戶端往往比臨時開全局代理更省事。若您希望本機與教學文章使用同一套用戶端體驗，歡迎透過站內入口取得安裝包。
