現象：編輯器能開，Cascade、雲端補全卻一直轉

在 AI 程式開發工具競爭白熱的 2025–2026 年，Windsurf（內建 Codeium 技術的 IDE）是許多團隊的選項之一。實務上卻很常出現一種弔詭狀況：同一台筆電上，瀏覽器上網正常，Windsurf 介面也打得開，但 Cascade 面板空白、登入轉圈、內聯 補全 或遠端代理請求在狀態列顯示 API 逾時。此時若直覺把問題歸因於「沒開代理」或單純更換訂閱，往往事倍功半，因為真正卡住的，多半是與 Codeium 雲端後端、Windsurf 更新與帳務相關的 HTTPS 主機被寬泛規則導到錯誤出口，或與 DNS／fake-ip 行為不一致，導致「看得到殼、載不到心」。

Clash／Mihomo 的價值在於讓「哪條連線走哪個策略群組」可排程、可觀測。本篇從 開發者本機代理 場景出發，示範如何把 codeium.com 與 windsurf.com 一類後綴置前命中，與站內以 Cursor 擴充功能市集、VS Code 資產鏈 為敘事主軸的專文分開產品與主機集合，避免讀者混用兩邊的網域清單卻沒有對照自己的連線日誌。

文件裡的線索：要放行哪些主機？

Codeium 官方說明企業與學校網路可能需設定 HTTP／HTTPS Proxy，並在編輯器內提供「偵測系統 Proxy」或手動填入位址，以排除登入、Cascade 讀取失敗、或持續顯示連線錯誤。網路需求面向也普遍提到需允許 連接埠 443，以及讓 *.codeium.com 與 *.windsurf.com 可達。另有狀態查詢用的 status.codeium.com 可供對照服務健康度，不應當成一般 API 流量混在同一組過於寬鬆的規則裡，以免除錯時難以分辨「產品真的掛了」還是「本機被規則帶到錯節點」。

實作上請您仍以實際連線日誌與應用程式內的網路診斷為準，補上遺漏的 DOMAIN 或子網域。產品更新會帶入新的後端，下列僅作學習用分桶，不應當成「永久正確的防火牆清單」整包貼上。

和 Cursor 那篇有什麼不同？

站內 Cursor 專文 以「擴充功能市集、VS Code 更新 CDN、Cursor 品牌 API」為主要收斂對象，適合已在使用 Cursor 且遇到市集／外掛下載與內建模型同時不穩的情況。Windsurf 同樣衍生自 VS Code 生態，部分外掛與圖示可能仍會碰到 marketplace.visualstudio.com 等主機，但讀者若主訴是 Cascade、Codeium 雲端補全、帳戶與產品更新，優先關注 codeium.com 與 windsurf.com 相關後綴，通常能更快把症狀從「一般瀏覽可達」與「IDE 內 AI 不可達」分開。若同時有 MCP、套件登錄庫、Git 一類工具鏈需求，可再併讀專文，但請避免把多篇文章的規則不加區分地合併成一大包，否則命中順序難以維護。

為什麼不把所有流量丟給單一「PROXY」？

在 TUN 模式 或系統代理下，若僅以巨大的 GEOIP 或 MATCH,PROXY 兜底，實務上常出現兩件事：第一，國內可直連的 API 被一併繞到高延遲或高風控的境外節點，反而讓 逾時 變多；第二，同一策略群組內的 url-test 只對測速 URL 友善，卻與實際 Codeium 長連線特性不一致，表面延遲低、實際對話斷斷續續。較能長期維護的做法是：保留公司內網、常用套件鏈與地區直連邏輯，再把 Windsurf／Codeium 相關後綴用置前規則導入獨立群組，必要時與 國內外分流骨架 並列檢視，確認沒有更早的寬泛規則攔胡。

規則順序：DOMAIN-SUFFIX 要放在會提前結束比對的規則之前

在 mode: rule 下，核心由上而下比對，命中即停。若 GEOIP,XX,DIRECT 或整包 RULE-SET 放在您為 Codeium 寫的細緻網域之前，表面症狀就會是「我明明加了 codeium.com 怎麼沒用」。請在編輯訂閱合併結果後，實際捲動到產生最終 rules 串列 的位置確認順序，而不是只看您手寫的片段。

策略群組建議：WINDSURF_CODEIUM 要手選還是自動測速？

實務上可採一個選擇器 select 搭配內層 url-test，讓您可在面板一鍵固定到單一節點做對照實驗。當 API 逾時 但測速卻全綠時，先手動固定可快速判斷是否為自動挑節點在長工作階段中頻繁切換出口所導致。若你使用 Clash Verge Rev 等圖形介面，群組名稱請與訂閱注入名稱避開衝突，并保持簡短，以便 YAML 合併與日誌搜尋。

YAML 骨架範例（請替換為您環境的真實值）

以下片段示範如何在寬泛兜底前插入 Codeium／Windsurf 相關後綴。節點名稱、測速 URL 與是否併入 status.codeium.com 請依實測調整，勿未審核即用於生產環境：

YAMLproxy-groups:
  - name: "WINDSURF_CODEIUM"
    type: select
    proxies:
      - "CODEIUM_AUTO"
      - "Your-Hand-Picked-Node"
      - DIRECT
  - name: "CODEIUM_AUTO"
    type: url-test
    proxies:
      # Inject real proxy names from your subscription
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 30

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  # Place BEFORE broad GEOIP / catch-all MATCH
  - DOMAIN-SUFFIX,codeium.com,WINDSURF_CODEIUM
  - DOMAIN-SUFFIX,windsurf.com,WINDSURF_CODEIUM
  - DOMAIN,status.codeium.com,WINDSURF_CODEIUM
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

若您尚未完成訂閱匯入，請先參考 訂閱匯入教學 建立基礎群組，再回來補上段規則，以免發生「規則寫了但 proxy-groups 名稱與實際核心運行不一致」的合併錯位。

Windsurf 內部設定：讓它「偵測到」Clash 的系統代理

在 Clash 端開啟系統代理 後，Windsurf 內可開啟「偵測 Proxy」選項，讓編譯層的網路堆疊走與作業系統一致的路徑。若僅有瀏覽器可走代理、桌面程式卻沒有，症狀會非常像本流程—此時可對照 僅瀏覽器通、桌面程式不跟代理 一文，釐清是否需改為 TUN 或補作業系統層權限。遠端開發（SSH、Dev Container）時，官方另區隔「Windsurf Remote」用的 HTTP／HTTPS 代理欄位；若遠端視窗內建工具仍逾時，請分開驗證本機與遠端兩邊的 DNS／Proxy，不要混在一起猜。

DNS、fake-ip 與「規則看起來對卻不生效」

在 enhanced-mode: fake-ip 下，解析結果與規則匹配型別綁在一起。若 fake-ip-filter 或略過名單遺漏了某個內部測試網域，或系統同時啟用安全 DNS 導致解析不經過 Clash，都會讓日誌裡的命中與您預期不同。建議在穩定重現的時段，暫關作業系統的 DoH 做對照，並從日誌確認 最終導向的策略群組 是否為 WINDSURF_CODEIUM。

除錯檢查清單

1. 先確認 443 與主機層可達性：用瀏覽器或 curl 粗測，排除純本機防火牆誤擋。
2. 讀日誌看命中的規則名稱：是否被更前面的 RULE-SET 或地區規則截走。
3. 分開驗證「登入」「Cascade」「內聯補全」：可能對應不同子網域，一次只改一個變因。
4. 比對 status.codeium.com 與實際功能：若狀態全綠但本機仍失敗，優先懷疑出口或 DNS，而非產品全掛。
5. 手動固定節點對照 url-test：若固定後就穩，調整 tolerance 與 interval，減少長會話中切出口。

結語

圍繞 Windsurf 與 Codeium 的連線議題，核心往往在於雲端 AI 所依賴的網域與本機 Clash 規則是否同頻，而不是多裝一個外掛就能解。把 codeium.com 與 windsurf.com 相關流量收斂到可觀測的策略群組、把規則放在會提早結束比對的寬泛條目之前，再搭配編輯器內的系統 Proxy 偵測與 DNS 檢查，多數「載入中無限迴圈」都能收斂成可重現的網路問題。相較於把全部流量丟進單一 PROXY，這種寫法通常更利於與 AI 程式開發 工作流共處，也讓和 Cursor 等工具並行的人能清楚劃分設定邊界。

若您需要 Windows、macOS 上安裝用戶端與圖形介面操作說明，可從本站 教學文件 取得索引，再依實測日誌微調 網域規則。